| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
diagnostics in the future. Make it so.
llvm-svn: 144347
|
| |
|
|
| |
llvm-svn: 144277
|
| |
|
|
|
|
|
|
| |
via the libclang API.
I've tested it on simple cases and it works. Test cases to follow as well as a few tweaks.
llvm-svn: 144269
|
| |
|
|
| |
llvm-svn: 144115
|
| |
|
|
|
|
| |
function template instantiations. Fixes <rdar://problem/10398005> / PR11312.
llvm-svn: 143984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is not infrequently
adding paths to the header search based on their existence on the
filesystem. For that, it has to add the sysroot anyways, we should pass
it on down to CC1 already joined. More importantly, the driver cannot in
all cases distinguish between sysrooted paths and paths that are
relative to the Clang binary's installation directory. Essentially, we
always need to ignore the system root for these internal header search
options. It turns out in most of the places we were already providing
the system root in the driver, and then another one in CC1 so this fixes
several bugs.
llvm-svn: 143917
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the first (and diff-noisiest) step to making Linux header searching
tremendously more principled and less brittle. Note that this step
should have essentially no functional impact. We still search the exact
same set of paths in the exact same order. The only change here is where
the code implementing such a search lives.
This has one obvious negative impact -- we now pass a ludicrous number
of flags to the CC1 layer. That should go away as I re-base this logic
on the logic to detect a GCC installation. I want to do this in two
phases so the bots can tell me if this step alone breaks something, and
so that the diffs of the refactoring make more sense.
llvm-svn: 143822
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
actually manage the builtin header file includes as well as the system
ones.
This one is actually debatable whether it belongs in the driver or not,
as the builtin includes are really an internal bit of implementation
goop for Clang. However, they must be included at *exactly* the right
point in the sequence of header files, which makes it essentially
impossible to have this be managed by the Frontend and the rest by the
Driver. I have terrible ideas that would "work", but I think they're
worse than putting this in the driver and making the Frontend library
even more ignorant of the environment and system on which it is being
run.
Also fix the fact that we weren't properly respecting the flags which
suppress standard system include directories.
Note that this still leaves all of the Clang tests which run CC1
directly and include builtin header files broken on Windows. I'm working
on a followup patch to address that.
llvm-svn: 143801
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|