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
Unfortunately, we don't seem to have a standard way to do this. I'm using
the __OPTIMIZE__ GNU extension that Clang also defines, but that doesn't
help MSVC. I suppose we could remove the check entirely, but it's useful
for developing new constraint managers.
llvm-svn: 170915
deterministic.
Commit message for r170826:
[analyzer] Traverse the Call Graph in topological order.
Modify the call graph by removing the parentless nodes. Instead all
nodes are children of root to ensure they are all reachable. Remove the
tracking of nodes that are "top level" or global. This information is
not used and can be obtained from the Decls stored inside
CallGraphNodes.
Instead of existing ordering hacks, analyze the functions in topological
order over the Call Graph.
Together with the addition of devirtualizable ObjC message sends and
blocks to the call graph, this gives around 6% performance improvement
on several large ObjC benchmarks.
llvm-svn: 170906
We used to not really format them. Now we do:
for (MachineBasicBlock::succ_iterator SI = BB->succ_begin(),
SE = BB->succ_end();
SI != SE; ++SI) {
This is just one example and I am sure we still mess some of them up, but it
is a step forward.
llvm-svn: 170899
Daniel Jasper