Age | Commit message (Collapse) | Author |
|
interface. This is currently limited to modules with umbrella
headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144736 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
incrementally with a new frontend action.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144723 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
differing from GeneratePCHAction fairly soon.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144703 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
building modules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144680 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144672 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
only be emitting
warnings/errors for unknown warning options. getDiagnosticsInGroup returns false if the
diagnostics is found and true otherwise. Thus, if we're reporting and we have a valid
diagnostic, we were actually setting the flag and causing mayhem.
rdar://10444207
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144670 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
don't display either.
Also add a maximum edit distance threshold, so we don't correct "-Wx" to "-W#pragma-messages".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144644 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144604 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
$ clang -Wololo t.c
warning: unknown warning option '-Wololo'; did you mean '-Wall'? [-Wunknown-warning-option]
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144591 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
diagnostics in the future. Make it so.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144347 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144277 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
via the libclang API.
I've tested it on simple cases and it works. Test cases to follow as well as a few tweaks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144269 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144115 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
function template instantiations. Fixes <rdar://problem/10398005> / PR11312.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143984 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143917 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143822 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143801 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143798 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143776 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143765 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
diagnostics block.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143764 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
blocks. The goal is to remove BLOCK_STRINGS so that the bitcode file can potentially be streamed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143763 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143762 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143761 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
number" of serialized diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143760 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143759 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
errors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143758 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
SerializedDiagnosticPrinter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143757 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143752 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
structs. Original behavior can be restored using -fno-limit-debug-info.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143733 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.]
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143657 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the preamble.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143647 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143644 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
region and
use it for clang_getCursor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143605 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Ahmed Charles!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143569 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
version in PR11298.
I hear-by apologize for adding yet more code to this monstrosity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143567 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<rdar://problem/10374763>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143527 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143503 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is intended for direct access of the ASTReader for uses that make
little sense to try to shoehorn in the ExternalASTSource interface.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143465 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143367 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143345 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ASTUnit::CodeComplete,
so that it will happen when we are doing code-completion, not reparsing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143342 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that contains them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143338 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-mlink-bitcode-file flag), and more generally llvm::Modules, before
running optimisations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143314 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143259 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
committee hasn't set a value for __STDC_VERSION__ yet, so this is a
placeholder. But at least it's > 199901L.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143245 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the previous ASTDeserializationListener.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143241 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
as libclang could be processing multiple ASTUnit's at once.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143138 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143115 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142887 91177308-0d34-0410-b5e6-96231b3b80d8
|