| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
encode the *exact* semantics which the header search paths internally
built by the Frontend layer have had, which is both non-user-provided,
and at times adding the implicit extern "C" bit to the directory entry.
There are lots of CC1 options that are very close, but none do quite
this, and they are all already overloaded for other purposes. In some
senses this makes the command lines more clean as it clearly indicates
which flags are exclusively used to implement internal detection of
"standard" header search paths.
Lots of the implementation of this is really crufty, due to the
surrounding cruft. It doesn't seem worth investing lots of time cleaning
this up as it isn't new, and hopefully *lots* of this code will melt
away as header search inside of the frontend becomes increasingly
trivial.
llvm-svn: 143798
|
| |
|
|
| |
llvm-svn: 143776
|
| |
|
|
| |
llvm-svn: 143765
|
| |
|
|
|
|
| |
diagnostics block.
llvm-svn: 143764
|
| |
|
|
|
|
| |
blocks. The goal is to remove BLOCK_STRINGS so that the bitcode file can potentially be streamed.
llvm-svn: 143763
|
| |
|
|
| |
llvm-svn: 143762
|
| |
|
|
| |
llvm-svn: 143761
|
| |
|
|
|
|
| |
number" of serialized diagnostics.
llvm-svn: 143760
|
| |
|
|
|
|
| |
diagnostics.
llvm-svn: 143759
|
| |
|
|
|
|
| |
errors.
llvm-svn: 143758
|
| |
|
|
|
|
| |
SerializedDiagnosticPrinter.
llvm-svn: 143757
|
| |
|
|
|
|
|
|
|
| |
Windows. There are still FIXMEs and lots of problems with this code.
Some of them will be addressed shortly by my follow-up patches, but most
are going to wait until we isolate this code and can fix it properly.
This version should be no worse than what we had before.
llvm-svn: 143752
|
| |
|
|
|
|
| |
structs. Original behavior can be restored using -fno-limit-debug-info.
llvm-svn: 143733
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the second pass reports warnings/errors. This has the effect that we follow
the more canonical "last option wins" paradigm when there are conflicting
options.
rdar://10383776
Previously, we parsed the warning options in order. This caused non-intuitive
behavior:
1) clang test.c -Wnosuchwarning -Wno-unknown-warning-option
Before:
warning: unknown warning option '-Wnosuchwarning' [-Wunknown-warning-option]
1 warning generated.
After:
[0 warning generated.]
2) clang test.c -Wnosuchwarning -Werror=unknown-warning-option
Before:
warning: unknown warning option '-Wnosuchwarning' [-Wunknown-warning-option]
1 warning generated.
After:
error: unknown warning option '-Wnosuchwarning' [-Werror,-Wunknown-warning-option]
3) clang test.c -Werror=unknown-warning-option -Wnosuchwarning -Wno-error=unknown-warning-option -Wnosuchwarning
Before:
error: unknown warning option '-Wnosuchwarning' [-Werror,-Wunknown-warning-option]
warning: unknown warning option '-Wnosuchwarning' [-Wunknown-warning-option]
After:
warning: unknown warning option '-Wnosuchwarning' [-Wunknown-warning-option]
warning: unknown warning option '-Wnosuchwarning' [-Wunknown-warning-option]
2 warnings generated.
4) clang test.c -Werror=unknown-warning-option -Wnosuchwarning -Wno-error=unknown-warning-option -Wno-unknown-warning-option -Wnosuchwarning
Before:
error: unknown warning option '-Wnosuchwarning' [-Werror,-Wunknown-warning-option]
After:
[0 warning generated.]
llvm-svn: 143657
|
| |
|
|
|
|
| |
the preamble.
llvm-svn: 143647
|
| |
|
|
|
|
|
|
|
|
|
| |
A PCH file keeps track of #pragma diagnostics state; when loading the preamble, they conflicted
with the #pragma diagnostic state already present in the DiagnosticsEngine object due to
parsing the preamble.
Fix this by clearing the state of the DiagnosticsEngine object.
Fixes rdar://10363572 && http://llvm.org/PR11254.
llvm-svn: 143644
|
| |
|
|
|
|
|
|
| |
region and
use it for clang_getCursor.
llvm-svn: 143605
|
| |
|
|
|
|
| |
Ahmed Charles!
llvm-svn: 143569
|
| |
|
|
|
|
|
|
| |
version in PR11298.
I hear-by apologize for adding yet more code to this monstrosity.
llvm-svn: 143567
|
| |
|
|
|
|
| |
<rdar://problem/10374763>
llvm-svn: 143527
|
| |
|
|
| |
llvm-svn: 143503
|
| |
|
|
|
|
|
| |
This is intended for direct access of the ASTReader for uses that make
little sense to try to shoehorn in the ExternalASTSource interface.
llvm-svn: 143465
|
| |
|
|
|
|
|
|
|
|
|
|
| |
in "reparse"
because we don't want to take this performance hit when doing code completion
Log of r143342:
Move caching of code-completion results from ASTUnit::Reparse to ASTUnit::CodeComplete,
so that it will happen when we are doing code-completion, not reparsing.
llvm-svn: 143367
|
| |
|
|
|
|
|
|
|
|
|
| |
search logic. The Debian multiarch seems to have completely changed from
when these were originally added, and I'd like to remove a bunch of
them, but I'll be lazy and delay that until this logic is hoisted into
the driver where it belongs.
This should resolve PR11223.
llvm-svn: 143345
|
| |
|
|
|
|
|
|
| |
ASTUnit::CodeComplete,
so that it will happen when we are doing code-completion, not reparsing.
llvm-svn: 143342
|
| |
|
|
|
|
| |
that contains them.
llvm-svn: 143338
|
| |
|
|
|
|
|
| |
-mlink-bitcode-file flag), and more generally llvm::Modules, before
running optimisations.
llvm-svn: 143314
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
serializes out the diagnostics for a given translation unit to a bit code file. This is a WIP.
The motivation for this new DiagnosticConsumer is to provide a way for tools invoking the compiler
to get its diagnostics via a libclang interface, rather than textually parsing the compiler output.
This gives us flexibility to change the compiler's textual output, but have a structured data format
for clients to use to get the diagnostics via a stable API.
I have no tests for this, but llvm-bcanalyzer so far shows that the emitted file is well-formed.
More work to follow.
llvm-svn: 143259
|
| |
|
|
|
|
|
| |
committee hasn't set a value for __STDC_VERSION__ yet, so this is a
placeholder. But at least it's > 199901L.
llvm-svn: 143245
|
| |
|
|
|
|
| |
the previous ASTDeserializationListener.
llvm-svn: 143241
|
| |
|
|
|
|
| |
as libclang could be processing multiple ASTUnit's at once.
llvm-svn: 143138
|
| |
|
|
|
|
| |
lazily-created static DenseMap. This DenseMap is cleared (and the files erased) via an atexit routine in the case an ASTUnit is not destroyed. Fixes <rdar://problem/10293367>.
llvm-svn: 143115
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deserializing
preprocessed entities that are #included in the range that we are interested.
This is useful when we are interested in preprocessed entities of a specific file, e.g
when we are annotating tokens. There is also an optimization where we cache the last
result of PreprocessingRecord::getPreprocessedEntitiesInRange and we re-use it if
there is a call with the same range as before.
rdar://10313365
llvm-svn: 142887
|
| |
|
|
|
|
| |
Suggested by John McCall.
llvm-svn: 142836
|
| |
|
|
|
|
| |
Ted came upon the bug but I couldn't make a test out of it.
llvm-svn: 142805
|
| |
|
|
| |
llvm-svn: 142797
|
| |
|
|
|
|
|
| |
closer to what GCC does, except that GCC also checks that the inodes for $PWD
and '.' match.
llvm-svn: 142633
|
| |
|
|
|
|
| |
and not defining it causes the system headers on multiple platforms to break with -fms-extensions because they assume the lack of a definition of __STDC__ implies a traditional (pre-ANSI) preprocessor. PR10324 and <rdar://problem/10313809> .
llvm-svn: 142554
|
| |
|
|
| |
llvm-svn: 142418
|
| |
|
|
|
|
|
| |
r142300 but not this patch, clang -S may emit .s files that assemblers other
than llvm-mc can't parse.
llvm-svn: 142301
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
function. No functionality changed.
llvm-svn: 142128
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 142109
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
function) to agree with the coding conventions, and in one case have
a bit more information in it.
llvm-svn: 142088
|
| |
|
|
|
|
|
|
|
|
| |
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
|