Age | Commit message (Collapse) | Author |
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@121284 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120297 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119746 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-Move the stuff of Diagnostic related to creating/querying diagnostic IDs into a new DiagnosticIDs class.
-DiagnosticIDs can be shared among multiple Diagnostics for multiple translation units.
-The rest of the state in Diagnostic object is considered related and tied to one translation unit.
-Have Diagnostic point to the SourceManager that is related with. Diagnostic can now accept just a
SourceLocation instead of a FullSourceLoc.
-Reflect the changes to various interfaces.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@119730 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
When -working-directory is passed in command line, file paths are resolved relative to the specified directory.
This helps both when using libclang (where we can't require the user to actually change the working directory)
and to help reproduce test cases when the reproduction work comes along.
--FileSystemOptions is introduced which controls how file system operations are performed (currently it just contains
the working directory value if set).
--FileSystemOptions are passed around to various interfaces that perform file operations.
--Opening & reading the content of files should be done only through FileManager. This is useful in general since
file operations will be abstracted in the future for the reproduction mechanism.
FileSystemOptions is independent of FileManager so that we can have multiple translation units sharing the same
FileManager but with different FileSystemOptions.
Addresses rdar://8583824.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@118203 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
'../lib/clang/<version>'. Actually use '..' rather than removing the trailing
component to correctly handle paths containing '.' or symlinks in the presence
of -no-canonical-prefixes, etc. This shouldn't change any existing behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116803 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@116183 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114713 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114712 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114711 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Rewrite linker arguments to use libclang_rt.cc_kext.a
instead of gcc-specific libcc_kext.a
Resolves Radar 7808495
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114193 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114155 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-lstdc++. This is the best gross solution for a gross problem.
This issue is that historically, GCC has add -L options to its internally
library directories. This has allowed users and platforms to end up depending on
the layout of GCC's internal library directories.
We want to correct this mistake by eliminating that -L, but this means that
existing libraries which are in the GCC lib dir won't be found. We are going to
handle this by treating those -l names as "reserved", and requiring toolchains
to know how to add the right full path to the reserved library.
The immediately side effect of this is that users trying to use -L to find their
own -lstdc++ will need to start using -nostdlib (which is a good idea
anyway). Another side effect is that -stdlib=libc++ -lstdc++ will now do the
"right" thing, for curious definitions of right.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114144 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Patch by nobled.
I also took the opportunity to make the field private since now it is only ready from the
outside.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@113138 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-obvious.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111838 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111748 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
reported as unused.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111310 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
if detected.
- This is a hack, we really want the linker version at execution time, but we
don't have any infrastructure for getting that. Yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110886 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110027 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ToolChain::LookupTypeForExtension.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110024 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
avoided this originally to enforce that the driver actions aren't toolchain
dependent, but it isn't worth the cumbersone additional hostinfo split.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110023 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
don't have to deal with nested jobs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110015 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110011 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110010 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110009 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110008 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
too many other things.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110007 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
taking it in pieces.
- Fixes a problem where the Clang executable path was not initialized properly
on Win32, because sys::Path::getBasename() doesn't do what I always think it
does. Imagine that, a sys::Path interface that is confusing!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108667 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
looking up Clang in the normal search paths (which may end up finding the wrong
clang).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108346 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
from PR7583
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107788 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of the compilation.
- <rdar://problem/8141387> clang is always invoking dsymutil
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107149 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106039 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105966 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
collect2 option that is passed by some projects (notably WebKit).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105964 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105844 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
are going to need this to handle things like -Xassembler, -Xpreprocessor, and -Xlinker which we might have to introspect.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105842 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105762 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- We actually pretend that we have two separate types for LLVM assembly/bitcode because we need to use the standard suffixes with LTO ('clang -O4 -c t.c' should generate 't.o').
It is now possible to do something like:
$ clang -emit-llvm -S t.c -o t.ll ... assorted other compile flags ...
$ clang -c t.ll -o t.o ... assorted other compile flags ...
and expect that the output will be almost* identical to:
$ clang -c t.c -o t.o ... assorted other compile flags ...
because all the target settings (default CPU, target features, etc.) will all be initialized properly by the driver/frontend.
*: This isn't perfect yet, because in practice we will end up running the optimization passes twice. It's possible to get something equivalent out with a well placed -mllvm -disable-llvm-optzns, but I'm still thinking about the cleanest way to solve this problem more generally.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105584 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
added as the last output step, instead of just hacking it into the link step.
- Among other things, this fixes dSYM generation when using multiple -arch options.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105475 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
short name of the tool in use, instead of the name of the action that created
the command. The practical impact is we now get:
clang: error: clang frontend command failed due to signal 6 (use -v to see invocation)
instead of:
clang: error: assembler command failed due to signal 6 (use -v to see invocation)
when clang crashes on a job that uses the integrated assembler.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104417 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-static.
- How else will we figure out what is broken, eh?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103759 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
print out all of the category numbers with their description. This is useful
for clients that want to map the numbers produced by
--fdiagnostics-show-category=id to their human readable string form. The
output is simple but utilitarian:
$ clang --print-diagnostic-categories
1,Format String
2,Something Else
This implements rdar://7928193
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103080 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
deciding when we need to emit an extra "command failed" diagnostic.
- This also fixes the case where we were emitting that extra diagnostics, even
when using clang w/ the integrated assembler, which has good diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100529 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Clang++ support, even in "Production" mode (for testing purposes).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100119 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
toolchain configurations and is a small step toward FreeBSD support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99159 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-v style) to a file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99054 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98263 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97746 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97106 91177308-0d34-0410-b5e6-96231b3b80d8
|