assertions.
To ensure that custom assertions/conditional would also be supported,
just check if the ivar that needs to be invalidated or set to nil is
compared against 0.
Unfortunately, this will not work for code containing 'assert(IvarName)'
llvm-svn: 172147
storage and thus is implicitly zero-initialized, no need to
do C++11 memory model. This patch unconditionally detects
such condition and zeroinitializer's the variable.
Patch has been commented on and OKed by Doug off-line.
// rdar://12897704
llvm-svn: 172144
Objective-C method declarations look like this:
- (returntype)name:(type)argname anothername:(type)arg2name;
In google style, there's no space after the leading '-' but one after
"(returntype)" instead (but none after the argument types), see
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml#Method_Declarations_and_Definitions
Not inserting the space after '-' is easy, but to insert the space after the
return type, the formatter needs to know that a closing parenthesis ends the
return type. To do this, I tweaked the code in parse() to check for this, which
in turn required moving detection of TT_ObjCMethodSpecifier from annotate() to
parse(), because parse() runs before annotate().
(To keep things interesting, the return type is optional, but it's almost
always there in practice.)
http://llvm-reviews.chandlerc.com/D280
llvm-svn: 172140
In some cases, we just pick any ivar that needs invalidation and attach
the warning to it. Picking the first from DenseMap of pointer keys was
triggering non-deterministic output.
llvm-svn: 172134
Truncation happens regularly when find_first_not_of returns npos,
strings long enough to trigger bug here are implausible.
No functionality change intended (ignoring absurd string lengths).
llvm-svn: 172127
Before:
@property(assign, getter = isEditable) BOOL editable;
Now:
@property(assign, getter=isEditable) BOOL editable;
It'd be nice if some Apple person could let me know if spaces are preferred
around '=' in @synthesize lines (see FIXME in the test).
llvm-svn: 172110
Restructured the checker so that it could easily find two new classes of
issues:
- when a class contains an invalidatable ivar, but no declaration of an
invalidation method
- when a class contains an invalidatable ivar, but no definition of an
invalidation method in the @implementation.
The second case might trigger some false positives, for example, when
the method is defined in a category.
llvm-svn: 172104
Don't do this in Google style though:
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml#Protocols
Most other places (function declarations, variable declarations) still get
this wrong, and since this looks very similiar to template instantiations to
the lexer (`id <MyProtocol> a = ...`), it's going to be hard to fix in some
places.
llvm-svn: 172099
The first token in @implementation, @interface, and @protocol lines is now
marked TT_ObjCDecl, and lines starting with a TT_ObjCDecl token are now marked
LT_ObjCMethodDecl.
llvm-svn: 172093
-provide a "raw_ostream'ish" class to make it convenient to output logging info.
-use macros to automate a bit the logging functionality inside libclang functions
-when logging, print a stack trace if "LIBCLANG_LOGGING=2" environment is set.
-add logging to more functions.
llvm-svn: 172089
This will be a new style requirement going forwards: a diagnostic can only
use the implicit InGroup<DiagGroup<"foo">> syntax if "foo" is not used by
any other diagnostics; as soon as it is, it needs an explicit group.
This also brings some stray "conversion" diagnostics into the
"Value Conversion Issue" category, instead of the more generic
"Semantic Issue" category. I consider this an improvement!
- warn_impcast_complex_scalar
- warn_impcast_float_integer
- warn_impcast_float_precision
- warn_impcast_integer_precision
- warn_impcast_vector_scalar
llvm-svn: 172088
Not only is this inefficient for TableGen, it's annoying for maintenance
when renaming warning flags (unusual) or adding those flags to a group
(more likely).
This uses the new fix-it infrastructure for LLVM's SourceMgr/SMDiagnostic,
as well as a few changes to TableGen to track more source information.
llvm-svn: 172087
This prepares the code for single line optimizations and changes the
dependencies between single-line-formats to the indent of the first
token.
Conceptually, the first token is "between" the lines anyway, as the
whitespace for the first token includes the previous end-of-line, which
needs to be escaped when inside a preprocessor directive.
llvm-svn: 172083
We now decide whether a newline should go before the closing brace
depending on whether a newline was inserted after the opening brace.
For example, we now insert a newline before '};' in:
static SomeClass WithALoooooooooooooooooooongName = {
100000000, \"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\"
};
... while not inserting a newline here:
static SomeClass = { a, b, c, d, e, f, g, h, i, j,
looooooooooooooooooooooooooooooooooongname,
looooooooooooooooooooooooooooooong };
Also fixes the formating of (column limit 25):
int x = {
avariable,
b(alongervariable)
};
llvm-svn: 172076
We're now formatting (column limit 25):
int x = {
avariable,
b(alongervariable) };
This also fixes:
Aaa({
int i;
}, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
ccccccccccccccccc));
... where we would previously break after the '},'.
Putting the closing curly into an extra line when there's a break
directly after the first curly will be done in a subsequent patch.
Paired with djasper.
llvm-svn: 172070
Before: int (^myBlock) (int) = ^(int num) {}
A<void ()>;
int (*b)(int);
After: int (^myBlock)(int) = ^(int num) {}
A<void()>;
int(*b)(int);
For function types and function pointer types, this patch only makes
the behavior consistent (for types that are keywords and other types).
For the latter function pointer type declarations, we'll probably
want to add a space after "int".
Also added LangOpts.Bool = 1, so we handle "A<bool()>" appropriately
Moved the LangOpts-settings to a public place for use by tests
and clang-format binary.
llvm-svn: 172065
Previously, we would not indent:
SOME_MACRO({
int i;
});
correctly. This is fixed by adding the trailing }); to the unwrapped
line starting with SOME_MACRO({, so the formatter can correctly match
the braces and indent accordingly.
Also fixes incorrect parsing of initializer lists, like:
int a[] = { 1 };
llvm-svn: 172058
This fixes llvm.org/PR14684.
Before: int *pa = (int *) & a;
After: int *pa = (int *)&a;
We still don't understand all kinds of casts. I added a FIXME to
address that.
llvm-svn: 172056
difference between type widths of a vector and the width of one of its elements
in the case of vector shifts. Use correct witdth in the vector case.
llvm-svn: 172047
Just reuse the @interface code for this. It accepts slightly more than
necessary (@implementation cannot have protocol lists), but that's ok.
llvm-svn: 172019
there are macro expansions inside macro arguments where the arguments are
not expanded in the same order as listed; don't assert that all macro expansions
are in source order.
rdar://12397063
llvm-svn: 172018
in case condition type. // rdar://11577384.
Test is conditionalized on x86_64-apple triple as
I am not sure if the INT_MAX/LONG_MAX values in the test
will pass this test for other hosts.
llvm-svn: 172016
This adds documentation for both LibFormat as well as the standalone
tools and integrations built on top of it. It slightly restructures
the ClangTools documentation.
llvm-svn: 172004
Previously:
@interface Foo + (id)init; @end
Now:
@interface Foo
+ (id)init;
@end
Some tweaking remains, but this is a good first step.
llvm-svn: 171995
Previously, we'd always start at indent level 0 after a preprocessor
directive, now we layout the following snippet (column limit 69) as
follows:
functionCallTo(someOtherFunction(
withSomeParameters, whichInSequence,
areLongerThanALine(andAnotherCall,
B
withMoreParamters,
whichStronglyInfluenceTheLayout),
andMoreParameters),
trailing);
Note that the different jumping indent is a different issue that will be
addressed separately.
This is the first step towards handling #ifdef->#else->#endif chains
correctly.
llvm-svn: 171974
This fixes llvm.org/PR14870 and we no longer mess up:
template <typename T1, typename T2 = char, typename T3 = char,
typename T4 = char>
void f();
It removes the nice aligment for assignments inside other expressions,
but I am not sure those are actually practically relevant. If so, we can
fix those later.
llvm-svn: 171966
This addresses llvm.org/PR14847.
We can now format something like:
int aaaaaaaaaaaaaaaaaaaaaaaaaaa =
// aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaiaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
clang-format unavoidably exceeds the column limit, but does not just
flush everything into a single line. Moreover, it tries to minimize the
number of characters beyond the column limit.
llvm-svn: 171964
This fixes llvm.org/PR14860.
Before, we messed up the format of:
if (DeclaratorInfo.isFunctionDeclarator() &&
//getDeclSpecContextFromDeclaratorContext(Context) == DSC_top_level &&
Tok.is(tok::semi) && NextToken().is(tok::l_brace)) {
}
llvm-svn: 171961
This addresses llvm.org/PR14864.
We used to completely mess this up and now format as:
Diag(NewFD->getLocation(),
getLangOpts().MicrosoftExt ? diag::ext_function_specialization_in_class :
diag::err_function_specialization_in_class)
<< NewFD->getDeclName();
llvm-svn: 171957
Clang doesn't understand it.
If someone wants to teach clang about that flag instead, please also add
support for -fno-diagnostics-parseable-fixits for consistency.
Until then, let the documentation match the current behavior.
llvm-svn: 171952
(because they are part of some module) but have not been made visible
(because they are in a submodule that wasn't imported), filter out
those declarations unless both the old declaration and the new
declaration have external linkage. When one or both has internal
linkage, there should be no conflict unless both are imported.
llvm-svn: 171925
-Wint-to-pointer-cast, added to match GCC's warning by the same name, doesn't
need to be in any other groups (as it isn't in any groups in GCC either).
Found in post-commit review by Ted Kremenek.
llvm-svn: 171893
With the new setting, we are not going to inline any functions that are
more than 50 basic blocks. (The analyzer is 20% faster on several
especially bad benchmarks with the new default.)
llvm-svn: 171891
In the source
static void f();
static void f();
template<typename T>
static void g() {
f();
}
static void f() {
}
void h() {
g<int>();
}
the call to f refers to the second decl, but it is only marked used at the end
of the translation unit during instantiation, after the third f decl has been
linked in.
With this patch we mark all subsequent decls used, so that it is easy to check
if a symbol is used or not.
llvm-svn: 171888
before doing the comparison.
This is because we can't set "FirstInDeclGroup" consistently; for example, when visiting a DeclStmt we will set
it but we don't set it on the result of clang_getCursorDefinition for a reference of the same declaration.
llvm-svn: 171878
In Clang/LLVM this seems to be the more common formatting for ##s. There
might still be case that we miss, but we'll fix those as we go along.
Before:
#define A(X)
void function ## X();
After:
#define A(X)
void function##X();
llvm-svn: 171862
This is a first step towards supporting more complex structures such
as #ifs inside unwrapped lines. This patch mostly converts the array-based
UnwrappedLine into a linked-list-based UnwrappedLine. Future changes will
allow multiple children for each Token turning the UnwrappedLine into a
tree.
No functional changes intended.
llvm-svn: 171856
bits from the number of parameters. This brings the bitfields down from 33 bits
to 32 bits, reducing the size of Types by 4 bytes on 32-bit systems.
llvm-svn: 171827
The issue here is that if we have 2 leaks reported at the same line for
which we cannot print the corresponding region info, they will get
treated as the same by issue_hash+description. We need to AUGMENT the
issue_hash with the allocation info to differentiate the two issues.
Add the "hash" (offset from the beginning of a function) representing
allocation site to solve the issue.
We might want to generalize solution in the future when we decide to
track more than just the 2 locations from the diagnostics.
llvm-svn: 171825
The test should be looking for gcrt0.o not crt0.o. Clang was already printing
"gcrt0", but the test was looking for "{{.*}}crt0.o", and the .* regexp
consumed "g".
Patch by Brad Smith.
llvm-svn: 171815
This is in preparation for using this to construct the function type for
pointers to member functions to include the implicit/artificial 'this'
parameter in that case as well. (feedback from GDB indicates that this might be
all that's necessary to get it to behave well with Clang's pointer-to-member
function debug output)
llvm-svn: 171809
This fixes the URL permanence of that URL. This is a bit of a hack. See
the FIXME in the patch for what the "real" solution should be.
llvm-svn: 171795
DenseMap and the lookups associated with it.
Instead of lexing for preprocessor tokens, associating the annotation with the location in a map,
and later lookup in the map in order to adjust the cursor annotation, just annotate the cursor
while lexing for preprocessor tokens.
llvm-svn: 171775
Previously type/storage qualifiers would not be annotated as the declaration they belonged to.
Just use the resulting source range of getRawCursorExtent() which is more correct
than what AnnotateTokensWorker::Visit() was adjusting it to.
llvm-svn: 171774
this was ever a macro name and return a specific CXCursor_MacroExpansion cursor in such a case,
instead of the generic CXCursor_MacroDefinition.
Checking for macro name makes sure the identifier is not part of the identifier list in a
function macro.
While, in general, resolving identifiers in macro definitions to other macros may not be completely accurate,
it greatly improves functionality such as give-me-the-definition-of-this, which was not working at all
inside macro definitions.
llvm-svn: 171773
Better handle the blacklisting of known bad deallocators when symbol
escapes through a call to CFStringCreateWithBytesNoCopy.
Addresses radar://12702952.
llvm-svn: 171770
When a property is "inherited" through both a parent class and directly
through a protocol, we should not require the child to invalidate it
since the backing ivar belongs to the parent class.
(Fixes radar://12913734)
llvm-svn: 171769
Previous indent:
class A {
}
a;
void f() {
};
With this patch:
class A {
} a;
void f() {
}
;
The patch introduces a production for classes and structs, and parses
the rest of the line to the semicolon after the class scope.
This allowed us to remove a long-standing wart in the parser that would
just much the semicolon after any block.
Due to this suboptimal formating some tests were broken.
Some unrelated formatting tests broke; those hit a bug in the ast
printing, and need to be fixed separately.
llvm-svn: 171761
Following r168626, in class declaration or definition, there are a combination of syntactic locations
where C++11 attributes could appear, and among those the only valid location permitted by standard is
between class-key and class-name. So for those attributes appear at wrong locations, fixit is used to
move them to expected location and we recover by applying them to the class specifier.
llvm-svn: 171757
rehashed, invaliding the iterator walking through the identifier
table. Separate out the identification of out-of-date identifiers from
updating them.
llvm-svn: 171756
with respect to the lower "left-hand-side bitwidth" bits, even when negative);
see OpenCL spec 6.3j. This patch both implements this behaviour in the code
generator and "constant folding" bits of Sema, and also prevents tests
to detect undefinedness in terms of the weaker C99 or C++ specifications
from being applied.
llvm-svn: 171755
This should make it slightly more readable as it more clearly separates
what happens where. No intended functional changes. More of this to
come..
llvm-svn: 171748
Also set ObjC1 in the formatter tests.
The only effect of this flag in the lexer is that '@' now gets turned into
tok::at instead of tok::unknown.
llvm-svn: 171742
This addresses llvm.org/PR14830.
Before:
unsigned Cost =
TTI.getMemoryOpCost(I->getOpcode(), VectorTy, SI->getAlignment(),
SI->getPointerAddressSpace());
CharSourceRange LineRange =
CharSourceRange::getTokenRange(TheLine.Tokens.front().Tok.getLocation(),
TheLine.Tokens.back().Tok.getLocation());
After:
unsigned Cost = TTI.getMemoryOpCost(I->getOpcode(), VectorTy,
SI->getAlignment(),
SI->getPointerAddressSpace());
CharSourceRange LineRange = CharSourceRange::getTokenRange(
TheLine.Tokens.front().Tok.getLocation(),
TheLine.Tokens.back().Tok.getLocation());
This required rudimentary changes to static initializer lists, but we
are not yet formatting them in a reasonable way. That will be done in a
subsequent patch.
llvm-svn: 171731
Before:
virtual void write(ELFWriter *writer, OwningPtr<FileOutputBuffer> &buffer) =
0
After:
virtual void write(ELFWriter *writerrr,
OwningPtr<FileOutputBuffer> &buffer) = 0;
This addresses llvm.org/PR14815.
To implement this I introduced a line type during parsing and moved the
definition of TokenType out of the struct for increased readability.
Should have done the latter in a separate patch, but it would be hard to
pull apart now.
llvm-svn: 171724
The case that we wanted to write a test for cannot happen, as the
UnwrappedLineParser already protects against it. Added an assert to
prevent regressions of that assumption.
llvm-svn: 171720
First check only wrapped with i==8, second wrapped at i==2,8,18,28,...
This fix restores the intended behavior: i==8,18,28,...
Found with -fsanitize=integer.
llvm-svn: 171718
We would format:
#define A \
int f(a); int i;
as
#define A \
int f(a);\
int i
The fix will break up macro definitions that could fit a line, but hit
the last column; fixing that is more involved, though, as it requires
looking at the following line.
llvm-svn: 171715
Previously, we'd format
int i;\
// comment
as
int i; // comment
The problem is that the escaped newline is part of the next token, and
thus the raw token text of the comment doesn't start with "//".
llvm-svn: 171713
If a token follows directly on an escaped newline, the escaped newline
is stored with the token. Since we re-layout escaped newlines, we need
to treat them just like normal whitespace - thus, we need to increase
the whitespace-length of the token, while decreasing the token length
(otherwise the token length contains the length of the escaped newline
and we double-count it while indenting).
llvm-svn: 171706
Using added LLVM functionality in r171698. This works in GDB for member
variable pointers but not member function pointers. See the LLVM commit and
GDB bug 14998 for details.
Un-xfailing cases in the GDB 7.5 test suite will follow.
llvm-svn: 171699
If we find an unexpected closing brace, we must not stop parsing, as
we'd otherwise not layout anything beyond that point.
If we find a structural error on the highest level we'll not re-indent
anyway, but we'll still want to format within unwrapped lines.
Needed to introduce a differentiation between an expected and unexpected
closing brace.
llvm-svn: 171666
To parse # correctly, we need to know whether it is the first token in a
line - we can deduct this either from the whitespace or seeing that the
token is the first in the file - we already calculate this information.
This patch moves the identification of the first token into the
getNextToken method and stores it inside the FormatToken, so the
UnwrappedLineParser can stay independent of the SourceManager.
llvm-svn: 171640
Catch some cases I'd missed in r171605 related to unnamed parameters of record
type. This resolves all remaining cases of PR14573 suppression in the GDB 7.5
test suite. Fix to the test suite to follow.
llvm-svn: 171633
Referring back to the original commit (r115090) which was a frontend only test
I adjusted this test to verify the frontend change that was made, to emit the
protected access value in the flags metadata field.
llvm-svn: 171604
It is somewhat hard to test linkage, so I decided to try to add an assert. This
already found some interesting cases where there were different.
llvm-svn: 171585
Some of this is still pretty rough (note the load of FIXMEs), but it is
strictly an improvement and fixes various bugs that were related to
macro processing but are also imporant in non-macro use cases.
Specific fixes:
- correctly puts espaced newlines at the end of the line
- fixes counting of white space before a token when escaped newlines are
present
- fixes parsing of "trailing" tokens when eof() is hit
- puts macro parsing orthogonal to parsing other structure
- general support for parsing of macro definitions
Due to the fix to format trailing tokens, this change also includes a
bunch of fixes to the c-index tests.
llvm-svn: 171556
__strong __block variables, perform objc_storeStrong on
source and destination instead of direct move. This
is done with -O0 and to improve some analysis.
// rdar://12530881
llvm-svn: 171555
This is a possible regression of moving to using ImplicitNullDerefEvent.
Fixing this for real (including the parameter name) requires more
plumbing in ImplicitNullDerefEvent. This is just a stop gap fix.
llvm-svn: 171502
The line information was changed when emitting debug information for all the
DeclRefExprs and we should change it back to get ready for PopClenupBlocks
called from FinishFunction.
rdar://11562117
llvm-svn: 171493
Uses of clang_getSpellingLocation should eventually move to calling
clang_getFileLocation, and clang_getSpellingLocation should do what
its name represents and actually point at the 'spelling' location, e.g.
inside a macro definition if the spelling of a token came from that.
llvm-svn: 171486
To do so we have to wait until we know that the type of a variable has been
deduced. Sema::FinalizeDeclaration is the first callback that is used for
decl with or without initializers.
llvm-svn: 171458
This is just the output of sphinx-quickstart. Now all that is needed
to begin converting the analyzer docs to reST is the server-side setup.
The analyzer folks have asked me to keep this segregated from the other
clang docs since the analyzer is a logically separate project (and has
its own separate web page) even though it resides in the clang tree.
llvm-svn: 171425
Patch by Will Dietz:
Minor touchup so the values of Offset/ID reflect their intention.
Previously, the sum (Offset+ID) was correct, but Offset/ID
individually were wrong.
Caught by investigating unsigned overflow reported by -fsanitize=integer.
llvm-svn: 171421
Even though we do have a `.. warning::` directive on the page, hopefully
having "In-Progress" in the title will help to condition people's
expectations a bit for when they run into the extremely bare-bones
release notes.
Also, when release season comes around again, maybe this will get
people's attention and avoid confusion about what is going into the
upcoming release, and what is for changes to trunk for the next version.
llvm-svn: 171419
The way Sphinx treats the "top-level" adornments is weird. It usually
uses the first top-level adornment as the page title, even if the
top-level adornment is just one "section" out of many (i.e. if the first
section is "Introduction", then it will make the page title be
"Introduction"). This behavior can be overriden by using an explicit
`.. title::` directive to set the title.
Since the Sphinx stylesheet that Clang is currently using ('haiku')
nicely puts the document title at the top of the page in the header,
this weird default behavior was resulting in a redundant "title" in the
body content. Getting rid of this redundant level of headings
effectively "exposes" one more level of heading from the stylesheet to
which now makes the real "sections" more distinct.
llvm-svn: 171417
Language extensions are highly relevant to using clang as a compiler, so
move LanguageExtensions up into `Using Clang as a Compiler` on the
landing page.
The other documents from the now-gone `Language Extensions and Specs`
section on the landing page nicely fit hierarchically under
LanguageExtensions.rst, so put them under LanguageExtensions.rst's
toctree instead of on the landing page.
Impetus from Jordan Rose.
llvm-svn: 171409
Fixes:
- incorrect handling of multiple consecutive preprocessor directives
- crash when trying to right align the escpaed newline for a line that
is longer than the column limit
- using only ColumnLimit-1 columns when layouting with escaped newlines
inside preprocessor directives
llvm-svn: 171401
This fixes llvm.org/PR14786.
We will need to split there as a last resort, but that should be done
consistently independent of whether the type is a template type or not.
Before:
template <typename T>
aaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaa<T>
::aaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
template <typename T>
aaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaa<T>::aaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 171400
This fixes llvm.org/PR14687.
Also fixes segfault for lines starting with * or &.
Before:
a *~b;
*a = 1; // <- this segfaulted
After:
a * ~b;
*a = 1; // no segfault :-)
llvm-svn: 171396
This is the first step towards handling preprocessor directives. This
patch only fixes the most pressing issue, namely correctly escaping
newlines for tokens within a sequence of a preprocessor directive.
The next step will be to fix incorrect format decisions on #define
directives.
llvm-svn: 171393
I clustered the docs by some intuitive/fuzzy notion of "similarity", and
some reasonable categories seemed to materialize. I tried to give the
clusters useful names, but you may want to take a look at the landing
page (<http://clang.llvm.org/docs/> for the lazy) and share your
thoughts.
I have to say, this small change really gives the docs a whole new life!
It makes our documentation quite a bit easier to navigate and scope out.
llvm-svn: 171379
The core of this page is a set of pros/cons for the different ways to
use clang as a library. The title should reflect that the page helps you
choose between alternatives.
llvm-svn: 171377
directly.
This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.
llvm-svn: 171254
This fixes pr14736. It is fairly ugly, but I don't think we can do much better
as we have to wait at least until the end of the typedef to know if the
function will have external linkage or not.
llvm-svn: 171240
to read and tell that it is a SWO -- we now descend through the
components and return a result at the first inequal component.
Also comment it a bit better and make it a total ordering by sorting on
the text of the suffix if necessary.
None of this should really be a visible change.
llvm-svn: 171219
This patch moves hasCLanguageLinkage to be VarDecl and FunctionDecl methods
so that they can be used from SemaOverload.cpp and then fixes the logic
in Sema::IsOverload.
llvm-svn: 171193
This makes the test not dependent on LLVM & won't vary/break based on LLVM
codegen related changes. Appropriately testing at the Clang level what was
fixed at the Clang level originally (in r124210).
llvm-svn: 171175
Changed getLocStart() and getLocEnd() to be required for Stmts, and make
getSourceRange() optional. The default implementation for getSourceRange()
is build the range by calling getLocStart() and getLocEnd().
llvm-svn: 171067
the body of a functions. The problem was that hasBody looks at the entire chain
and causes problems to -fvisibility-inlines-hidden if the cache was not
invalidated.
Original message:
Cache visibility of decls.
This unifies the linkage and visibility caching. I first implemented this when
working on pr13844, but the previous fixes removed the performance advantage of
this one.
This is still a step in the right direction for making linkage and visibility
cheap to use.
llvm-svn: 171053
This unifies the linkage and visibility caching. I first implemented this when
working on pr13844, but the previous fixes removed the performance advantage of
this one.
This is still a step in the right direction for making linkage and visibility
cheap to use.
llvm-svn: 171048
Apply all formatting changes that clang-format would apply to its own source
code. All choices seem to improve readability (or at least not make it worse).
No functional changes.
llvm-svn: 171039
This prevents formattings like this (assuming "parameter" doesn't fit the line):
bool f = someFunction() && someFunctionWithParam(
parameter) && someOtherFunction();
Here, "parameter" - the start of line 2 - has a parenthesis level of 2, but
there are subsequent tokens ("&&" and "someOtherFunction") with a lower level.
This is bad for readability as "parameter" hides "someOtherFunction". With this
patch, this changes to:
bool f = someFunction() &&
someFunctionWithParam(parameter) &&
someOtherFunction();
llvm-svn: 171038
This changes:
int Result = a + // force break
b;
return Result + // force break
5;
To:
int Result = a + // force break
b;
return Result + // force break
5;
llvm-svn: 171032
This fixes llvm.org/pr14686.
We used to add too many spaces for different versions of overloaded operator
function declarations/definitions. This patch changes, e.g.
operator *() {}
operator >() {}
operator () () {}
to
operator*() {}
operator>() {}
operator()() {}
llvm-svn: 171028
/// \param array - a value of type elementType*
/// \param destructionKind - the kind of destruction required
/// \param initializedElementCount - a value of type size_t* holding the number of successfully-constructed elements
llvm-svn: 171013
Using the file immediately after "> file 2>&1" causes weird behavior on win32.
For example, "foo > %t 2>&1; FileCheck --input-file=%t"
Use "foo 2>&1 | tee %t" instead.
Note, mixing stdout and stderr to the same handle might cause unexpected behavior, due to buffering.
llvm-svn: 171009
With this patch, splitting after binary operators has a panelty corresponding
to the operator's precedence. We used to ignore this and eagerly format like:
if (aaaaaaaaaaaaaaaaaaaaaaaaa || bbbbbbbbbbbbbbbbbbbbbbbbb &&
ccccccccccccccccccccccccc) { .. }
With this patch, this becomes:
if (aaaaaaaaaaaaaaaaaaaaaaaaa ||
bbbbbbbbbbbbbbbbbbbbbbbbb && ccccccccccccccccccccccccc) { .. }
llvm-svn: 171007
This is the last of the "regular" documents to convert to reST, and so
I'm declaring the initial clang reST conversion "done".
However,
- There are some documents in clang/www/ which probably should
be migrated into clang/docs/, such as www/OpenProjects.html
The primary thing blocking me from doing this right now is not knowing
how to set up a redirect so that the old URL's continue to work.
- LibASTMatchersReference.html is not reST. This page is auto-generated
by clang/docs/tools/dump_ast_matchers.py from the source and has some
collapse/expand logic that isn't expressible directly with Sphinx, so
just converting it to reST is not really a good strategy.
Manuel Klimek and I discussed this and the general agreed-upon
direction is making that page data-driven so that it, say, pulls in an
auto-generated blob of JSON which describes the matchers and builds up
the "matcher reference" part of the page with a small amount of JS.
- There are some rogue .txt files hanging around.
Also, I dropped the little dragon logo at the top because Sphinx was
warning about an external image reference (not sure why, but meh, I
didn't want to fight it). If anything, we would want such a logo
integrated into the site's overall theme, rather than hardcoded here.
llvm-svn: 170994
code-completion results, the SourceManager state may be slightly
different when code-completing.
And we don't even care for diagnostics when code-completing, anyway.
llvm-svn: 170979
This was removed with -Wunique-enum, which is still removed. The
corresponding thread on cfe-comments for that warning is here:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-September/024224.html
If we get specific user feedback for -Wduplicate-enum we can evaluate
whether or not to keep it.
llvm-svn: 170974
Our internal buildbot just failed because the tempfile happened to be named
'nodefaultlib-lcGA7k.o', which contains the substring '-lc'.
llvm-svn: 170941
Along the way, fix a bug in CheckLiteralKind(), previously in diagnoseObjCLiteralComparison, where we didn't ignore parentheses
in boxed expressions for purpose of classification.
In other words, both @42 and @(42) should be classified as numeric
literals.
llvm-svn: 170931
the values in the constructor. The constructor implementation is trivial
beyond the value initialisations. Patch by Saleem Abdulrasool!
llvm-svn: 170929
found by running -ast-print on all-std-headers.cpp
which caused it to go into infinite loop. Now
-ast-print prints all declarations found in
all-std-headers.cpp.
llvm-svn: 170928
Fariborz Jahanian