top-level declarations that occurred inside an ObjC container.
This is useful to keep track of such decls otherwise when e.g. a function
is declared inside an objc interface, it is not passed to HandleTopLevelDecl
and it is not inside the DeclContext of the interface that is returned.
llvm-svn: 142232
as part of the hash rather than ignoring them. This means we'll end up
building more module variants (overall), but it allows configuration
macros such as NDEBUG to work so long as they're specified via command
line. More to come in this space.
llvm-svn: 142187
This also applies to C99-style aggregate literals, should they be used in C++11, since they are effectively identical to constructor call list-initialization syntax.
llvm-svn: 142147
'libdir' mean the actual library directory, not the GCC subdirectory of
the library directory. That was just a confusing pattern. Instead,
supply proper GCC subdirectories when scanning for various triple-based
subdirectories with a GCC installation in them. This also makes it much
more obvious how multiarch installations, which have a triple-based
prefix as well as suffix work.
Also clean up our handling of these triple-prefixed trees by using them
in both a multiarch pattern and a non-multiarch pattern whenever they
exist.
Note that this *does not* match what GCC does on Debian, the only truly
multiarch installation I've been able to get installed and test on. GCC
appears to have a bug, and ends up searching paths like
'/lib/../../lib32' which makes no sense what-so-ever. Instead, I've
tried to encode the rational logic that seems clearly intended by GCC's
pattern. GCC ends up with patterns like:
/lib/../../lib32
/usr/lib/../../lib32
/usr/lib/x86_64-linux-gnu/../..lib32
Only the last one makes any sense having a '/../..' in it, so in Clang,
that's the only one which gets a '/../..' in it.
I *think* this will fix Debian multiarch links. I'm committing without
baking this logic into our test suite so I can test on a few different
systems. If all goes well (and no one screams) I'll check in some more
comprehensive tests for multiarch behavior tomorrow.
llvm-svn: 142133
formatting as any other diagnostic, they will be properly line wrapped and
otherwise pretty printed. Let's take advantage of that and the new factoring to
add some helpful information to them (much like template backtrace notes and
other notes): the name of the macro whose expansion is being noted. This makes
a world of difference if caret diagnostics are disabled, making the expansion
notes actually useful in this case. It also helps ensure that in edge cases the
information the user needs is present. Consider:
% nl -ba t5.cc
1 #define M(x, y, z) \
2 y
3
4 M(
5 1,
6 2,
7 3);
We now produce:
% ./bin/clang -fsyntax-only t5.cc
t5.cc:6:3: error: expected unqualified-id
2,
^
t5.cc:2:3: note: expanded from macro: M
y
^
1 error generated.
Without the added information in the note, the name of the macro being expanded
would never be shown.
This also deletes a FIXME to use the diagnostic formatting. It's not yet clear
to me that we *can* do this reasonably, and the production of this message was
my primary goal here anyways.
I'd love any comments or suggestions on improving these notes, their wording,
etc. Currently, I need to make them provide more helpful information in the
presence of a token-pasting buffer, and I'm pondering adding something along
the lines of "expanded from argument N of macro: ...".
llvm-svn: 142127
this long quest: actually use the note printing machinery for each macro
expansion note rather than a hacky version of it. This will colorize and
format the notes the same as any other. There is still some stuff to fix
here, but it's one step closer.
No test case changes because currently we don't do anything differently
that I can FileCheck for -- I don't really want to try matching the
color escape codes... Suggestions for how to test this are welcome. =]
llvm-svn: 142121
standing deficiency: we were providing no macro backtrace information
whenever caret diagnostics were turned off. This sinks the logic for
suppressing the code snippet and caret to the code that actually prints
tho code snippet and caret. Along the way, clean up the naming of
functions, remove some now fixed FIXMEs, and generally improve the
wording and logic of this process.
Add a test case exerecising this functionality. It is notable that the
resulting messages are extremely low quality. I'm working on a follow-up
patch that should address this and have left a FIXME in the test case.
llvm-svn: 142120
the important code in this test to make the test more stable. Now adding
further tests won't shift the line numbers occuring in the diagnostic
output.
llvm-svn: 142118
the SourceManager doesn't change, and the source files don't change.
This greatly simplifies the interfaces and interactions. The lifetime of
the TextDiagnostic object forms the 'session' over which we attempt to
condense and deduplicate information in diagnostics.
llvm-svn: 142104
been there. Also delete their redundant doxyments in favor of those in
the source file. I'm putting the doxyments for private and static
helpers into the implementation file, and only the public interface
doxyments into the header. If folks have strong opinions about this type
of split, feel free to chime in, I'm happy to re-organize.
llvm-svn: 142087
making it accessible to anyone from the Frontend library. Still a good
bit of cleanup to do here, but its a good milestone. This ensures that
*all* of the functionality needed to implement the DiagnosticConsumer is
exposed via the generic interface in some form. No sneaky re-use of
static functions.
llvm-svn: 142086
diagnostics to control suppression of redundant information. It now
follows the same model as all the other state, and has a bit more clear
semantics.
This is making the duality of the state a bit annoying, and I've added
a FIXME to resolve it. The problem is that I need to lift the
TextDiagnostic up into an externally visible layer before that can
happen.
llvm-svn: 142083
This only has an effect with fairly new binutils (2.21.51 or later). Other ELF targets probably want this as well, but on BSDs binutils is usually old so it doesn't matter.
llvm-svn: 142076
Argyrios Kyrtzidis