Currently, clang-cl always uses Windows style for unquoting, and clang always
uses POSIX style for unquoting.
With this flag, it's possible to change these defaults.
In general, response file quoting should match the shell the response file is
used in. On Windows, it's possible to run clang-cl in a bash shell, or clang in
cmd.exe, so a flag for overriding the default behavior is natural there.
On non-Windows, Windows quoting probably never makes sense (except maybe in
Wine), but having clang-cl behave differently based on the host OS seems
strange too. So require that people who want to use posix-style response
files with clang-cl on non-Windows pass --rsp-quoting=posix.
http://reviews.llvm.org/D19425
llvm-svn: 267474
Summary:
https://llvm.org/bugs/show_bug.cgi?id=27396
This fixes an issue in response files where "\r\n" was being interpreted
as two EOL markers (i.e. we consumed the '\r' as terminating the
previous token, and then parsed the '\n' as a significant EOL). This
breaks response files where joined arguments get split across multiple
lines (like "-x\r\nc"). I also fixed an accidental issue in the
response-file.c test, where the response file is appended to, instead of
being overwritten.
Reviewers: rnk
Subscribers: danalbert, llvm-commits
Differential Revision: http://reviews.llvm.org/D19289
llvm-svn: 266840
This patch changes the default DWARF version for cc1as from invalid 0 to 2,
which should be the lowest common denominator on all platforms.
rdar://problem/24735813
llvm-svn: 266814
This is re-landing r260742. I've reworked the conditionals so that it only hits when targeting Apple platforms with ld64.
Original Summary:
With this change generating clang order files using dtrace uses the following workflow:
cmake <whatever options you want>
ninja generate-order-file
ninja clang
This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.
CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.
llvm-svn: 265864
The CMake EXISTS operator needs to have the variable expanded. Not expanding this was causing the if statement to always be false, which made it impossible to pass linker order files in.
llvm-svn: 264757
This appears to be passing '-Wl,-order_file' to Linux link commands,
which then causes the linker to silently, behind the scenes, write the
output to 'rder_file' instead of somewhere else. Will work with Chris to
figure out the proper support for this, but so far there are numerous
people who can't get Clang to update when they build because of this.
llvm-svn: 261054
Summary:
This commit re-lands r259862. The underlying cause of the build breakage was an incorrectly written capabilities test. In tools/Driver/CMakeLists.txt I was attempting to check if a linker flag worked, the test was passing it to the compiler, not the linker. CMake doesn't have a linker test, so we have a hand-rolled one.
Original Patch Review: http://reviews.llvm.org/D16896
Original Summary:
With this change generating clang order files using dtrace uses the following workflow:
cmake <whatever options you want>
ninja generate-order-file
ninja clang
This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.
CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.
Reviewers: bogner
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16999
llvm-svn: 260742
This reverts commit r259862, and attempts to fix builder CMakeCaches.
Will try this again some other time...
Conflicts:
CMakeLists.txt
tools/driver/CMakeLists.txt
llvm-svn: 259872
Summary:
With this change generating clang order files using dtrace uses the following workflow:
cmake <whatever options you want>
ninja generate-order-file
ninja clang
This patch works by setting a default path to the order file (which can be overridden by the user). If the order file doesn't exist during configuration CMake will create an empty one.
CMake then ties up the dependencies between the clang link job and the order file, and generate-order-file overwrites CLANG_ORDER_FILE with the new order file.
Reviewers: bogner
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D16896
llvm-svn: 259862
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"This is the way [autoconf] ends
Not with a bang but a whimper."
-T.S. Eliot
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D16472
llvm-svn: 258862
This change brings forward the LLVM convention that "executables" are just runnable binaries, and "tools" are executables that are part of the project's install.
Having this abstraction will allow us to simplify some of the tool CMakeLists files, and it will standardize some of the install behaviors.
llvm-svn: 258209
The /Brepro flag controls whether or not the compiler should embed
timestamps into the object file. Object files which do not embed
timestamps are not suitable for incremental linking but are suitable for
hermetic build systems and staged self-hosts of clang.
A normal clang spelling of this flag has been added,
-mincremental-linker-compatible.
llvm-svn: 256204
LLVM_SUBMIT_VERSION and LLVM_SUBMIT_SUBVERSION are commonly used variable names in the autoconf build system. They seem to have leeched into clang's CMake in a few places, and should just be replaced by the LLVM_VERSION_* variables where appropriate.
llvm-svn: 250246
With this change, most 'g' options are rejected by CompilerInvocation.
They remain only as Driver options. The new way to request debug info
from cc1 is with "-debug-info-kind={line-tables-only|limited|standalone}"
and "-dwarf-version={2|3|4}". In the absence of a command-line option
to specify Dwarf version, the Toolchain decides it, rather than placing
Toolchain-specific logic in CompilerInvocation.
Also fix a bug in the Windows compatibility argument parsing
in which the "rightmost argument wins" principle failed.
Differential Revision: http://reviews.llvm.org/D13221
llvm-svn: 249655
logic to select an alternate target based on the executable it was
called as. For instance, if you symlink i686-linux-android-gcc to clang
and invoke it, the driver will act as though it were called with another
argument ("-target i686-linux-android"). This leads to visible effects
even in syntax-only compilations (like the ANDROID preprocessor symbol
being defined).
This behavior is not replicated for tool invocations--for instance,
clang::createInvocationFromCommandLine will not choose an alternate
target based on ArgList[0]. This means that configurations stored in
compilation databases aren't accurately replayed.
This patch separates the logic for selecting a mode flag and target from
the executable name into a new member function on ToolChain. It should
have no functional effects (but will allow other code to reuse the
target/mode selection logic).
Patch by Luke Zarko!
llvm-svn: 248592
Generation of clang symlinks now uses add_clang_symlink macro which uses add_llvm_symlink. Also the list of symlinks to generate is configurable via CLANG_LINKS_TO_CREATE.
This re-lands r248015, with fixes for clang symlinks to always be generated as part of the clang and install-clang targets.
llvm-svn: 248043
Generation of clang symlinks now uses add_clang_symlink macro which uses add_llvm_symlink. Also the list of symlinks to generate is configurable via CLANG_LINKS_TO_CREATE.
llvm-svn: 248015
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change. Thanks go to Pavel Labath for fixing LLDB for me.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247692
Summary:
This is the first patch in the series to migrate Triple's (which are ambiguous)
to TargetTuple's (which aren't).
For the moment, TargetTuple simply passes all requests to the Triple object it
holds. Once it has replaced Triple, it will start to implement the interface in
a more suitable way.
This change makes some changes to the public C++ API. In particular,
InitMCSubtargetInfo(), createMCRelocationInfo(), and createMCSymbolizer()
now take TargetTuples instead of Triples. The other public C++ API's have
been left as-is for the moment to reduce patch size.
This commit also contains a trivial patch to clang to account for the C++ API
change.
Reviewers: rengolin
Subscribers: jyknight, dschuff, arsenm, rampitec, danalbert, srhines, javed.absar, dsanders, echristo, emaste, jholewinski, tberghammer, ted, jfb, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10969
llvm-svn: 247683
cl uses 'CL' and '_CL_' to prepend and append command line options to
the given argument vector. There is an additional quirk whereby '#' is
transformed into '='.
Differential Revision: http://reviews.llvm.org/D11896
llvm-svn: 244473
noticed until now.
The code for setting up the driver's InstalledDir didn't respect
-no-canonical-prefixes. Because of this, there are a few places in the
driver where we would unexpectedly form absolute paths, notably when
searching for and finding GCC installations to use, etc. The fix is
straightforward, and I've added this path to '-v' both so we can test it
sanely and so that it will be substantially more obvious the next time
someone has to debug something here.
Note that there is another bug that we don't actually *canonicalize* the
installed directory! I don't really want to fix that because I don't
have a realistic way to test the usage of this mode. I suspect that
folks using the shared module cache would care about getting this right
though, and so they might want to address it. I've left the appropriate
FIXMEs so that it is clear what to change, and I've updated the test
code to make it clear what is happening here.
llvm-svn: 244065
In clang cc1as_main, when the output file type is “asm”, AsmStreamer
owns a formatted_raw_ostream which has a reference to FDOS
(raw_ostream), so AsmStreamer must be closed before FDOS is closed.
llvm-svn: 243085
- introduces a new cc1 option -fmodule-format=[raw,obj]
with 'raw' being the default
- supports arbitrary module container formats that libclang is agnostic to
- adds the format to the module hash to avoid collisions
- splits the old PCHContainerOperations into PCHContainerWriter and
a PCHContainerReader.
Thanks to Richard Smith for reviewing this patch!
llvm-svn: 242499
We were still using the Unix response file tokenizer for all driver
modes. This was difficult to get right in the beginning because there is
a circular dependency. The Driver class also can't officially determine
its mode until it can see all possible --driver-mode= flags, and those
flags could come from the response file.
Now we use the Windows parsing algorithm if the program name looks like
clang-cl, or if the --driver-mode=cl flag is present on the main command
line.
Fixes PR23709.
Reviewers: hans
Differential Revision: http://reviews.llvm.org/D11229
llvm-svn: 242346
This patch adds ObjectFilePCHContainerOperations uses the LLVM backend
to put the contents of a PCH into a __clangast section inside a COFF, ELF,
or Mach-O object file container.
This is done to facilitate module debugging by makeing it possible to
store the debug info for the types defined by a module alongside the AST.
rdar://problem/20091852
llvm-svn: 241620
CMake-2.8.12 is hardcoded to create symlinked clang.exe if the target property VERSION is present and the host is not Win32.
Then clang.exe-*.* is generated and clang.exe is symlinked to it.
lrwxrwxrwx. 1 bb bb 13 Jul 5 18:04 clang.exe -> clang.exe-3.7
-rwxr-x---. 1 bb bb 244763 Jul 5 18:04 clang++.exe
-rwxr-x---. 1 bb bb 244763 Jul 5 18:04 clang.exe-3.7
It made me unhappy when built binaries were copied to the Windows target.
FIXME: Could we just remove the target property VERSION in add_llvm_executable() ?
llvm-svn: 241403
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
A PCHContainerOperations abstract interface provides operations for
creating and unwrapping containers for serialized ASTs (precompiled
headers and clang modules). The default implementation is
RawPCHContainerOperations, which uses a flat file for the output.
The main application for this interface will be an
ObjectFilePCHContainerOperations implementation that uses LLVM to
wrap the module in an ELF/Mach-O/COFF container to store debug info
alongside the AST.
rdar://problem/20091852
llvm-svn: 240225
Summary:
This affects other tools so the previous C++ API has been retained as a
deprecated function for the moment. Clang has been updated with a trivial
patch (not covered by the pre-commit review) to avoid breaking -Werror builds.
Other in-tree tools will be fixed with similar patches.
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
The first time this was committed it accidentally fixed an inconsistency in
triples in llvm-mc and this caused a failure. This inconsistency was fixed in
r239808.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10366
llvm-svn: 239812
Summary:
This affects other tools so the previous C++ API has been retained as a
deprecated function for the moment. Clang has been updated with a trivial
patch (not covered by the pre-commit review) to avoid breaking -Werror builds.
Other in-tree tools will be fixed with similar trivial patches.
This continues the patch series to eliminate StringRef forms of GNU triples
from the internals of LLVM that began in r239036.
Reviewers: rengolin
Reviewed By: rengolin
Subscribers: llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D10366
llvm-svn: 239721
Summary:
Make DiagnosticsEngine::takeClient return std::unique_ptr<>. Updated
callers to store conditional ownership using a pair of pointer and unique_ptr
instead of a pointer + bool. Updated code that temporarily registers clients to
use the non-owning registration (+ removed extra calls to takeClient).
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6294
llvm-svn: 222193
Currently, when --serialize-diagnostics is passed this only includes
the diagnostics from clang -cc1, and driver diagnostics are
dropped. This causes issues for tools that use the serialized
diagnostics, since stderr is lost and these diagnostics aren't seen at
all.
We handle this by merging the diagnostics from the CC1 process and the
driver diagnostics into a single file when the driver invokes CC1.
Fixes rdar://problem/10585062
llvm-svn: 220525
We currently use a null FailingCommand when generating crash reports
as an indication that the cause is FORCE_CLANG_DIAGNOSTICS_CRASH, the
environment variable that exists to test crash dumps. This means that
our tests don't actually cover real crashes at all, and adds a more
complicated code path that's only used in the tests.
Instead, we can have the driver synthesize that every command failed
and just call generateCompilationDiagnostics normally.
llvm-svn: 220234
Clang would previously not get into C++ mode when invoked as 'clang++3.6'
(though clang++-3.6 would work).
I found the previous loop logic in this function confusing; hopefully this
makes it a little clearer.
Differential Revision: http://reviews.llvm.org/D5833
llvm-svn: 220052
(also, the code executed once the element was found was split half
inside the loop and half after it - now put it all together after the
find operation)
I'm a bit concerned that this code is rather untested (commenting out
this whole function and running check-clang doesn't fail any tests)...
And I wish I had polymorphic lambdas.
llvm-svn: 219938
Utilize Process::FixupStandardFileDescriptors, introduced in r219170, to
guard against files from being treated as one of the standard file
descriptors.
llvm-svn: 219174
This patch aims at fixing PR17239.
This bug happens because the /link (clang-cl.exe argument) is marked as
"consume all remaining arguments". However, when inside a response file,
/link should only consume all remaining arguments inside the response
file where it is located, not the entire command line after expansion.
The LLVM side of the patch will change the semantics of the
RemainingArgsClass kind to always consume only until the end of the
response file when the option originally came from a response file.
There are only two options in this class: dash dash (--) and /link.
This is the Clang side of the patch in http://reviews.llvm.org/D4899
Reviewered By: rafael, rnk
Differential Revision: http://reviews.llvm.org/D4900
Patch by Rafael Auler!
llvm-svn: 216281
This reverts commit r215785 / 170ebf4f19459ae51a9561d0e65c87ee4c9b2c97.
LLD has some StringSavers that need to be updated. One of which takes a
lock and I need to investigate that more closely.
llvm-svn: 215791
There is more cleanup to be done here. Once
llvm::sys::Process::GetArgumentVector is switched over to StringSaver,
we can simplify this code a fair amount.
llvm-svn: 215785
This also suggests some refactoring to simplify this code. Basically, a
ton of complexity in this argument handling code comes from the need to
save const char *'s in stable storage for pushing onto argv.
It seems like llvm:🆑:StringSaver can be improved to cover all the
needs here.
llvm-svn: 215761
The core logic in main() is actually pretty simple, but there's lots of
stuff that has been added over time which obscures the flow of the code.
In upcoming patches, I'll be pulling more stuff out of the main
codepath.
I'm open to naming suggestions for these helper functions.
llvm-svn: 215751
The rewrite facility's footprint is small so it's not worth going to these
lengths to support disabling at configure time, particularly since key compiler
features now depend on it.
Meanwhile the Objective-C rewriters have been moved under the
ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still
potentially worth excluding from lightweight builds.
Tests are now passing with any combination of feature flags. The flags
historically haven't been tested by LLVM's build servers so caveat emptor.
llvm-svn: 213171
The clang -cc1as options are nearly a strict subset of -cc1. Instead of
duplicating the definitions and documentation, let's go ahead and share the
definitions in a similar way the current handling of combined driver and
frontend flags, eliminating some of the vestigial legacy surrounding the
assembler subcommand.
llvm-svn: 212620
Assertion failures call abort(), which return an exit code of 3 on
Windows. The 'not' utility has the same check.
Unfortunately, the crash-report.c test requires a shell, so it does not
run for me locally, so I can only test this manually.
There's still more work to be done here: we should generate a batch
script instead of a shell script on Windows.
llvm-svn: 212481
Fix the build when no targets are enabled. This dependency is incurred by two
unfortunate entries in LinkAllPasses.h included from cc1_main.cpp:
llvm::createJumpInstrTablesPass();
llvm::createCodeGenPreparePass();
llvm-svn: 212084
This corrects long-standing misuses of LLVM's internal config.h.
In most cases the public llvm-config.h header was intended and we can now
remove the old hacks thanks to LLVM r210144.
The config.h header is private, won't be installed and should no longer be
included by clang or other modules.
llvm-svn: 210145
All callers were passing in "a.out" or garbage so a sensible default works fine
here as a cleanup.
This also brings about the possibility of adapting the value based on the
driver's compatibility mode in future.
The setting can still be changed via Driver::DefaultImageName as needed.
llvm-svn: 208926
Update clang to use the InstrProfReader from LLVM to read
instrumentation based profile data. This also switches us from the
naive text format to the binary format, since that's what's
implemented in the reader.
llvm-svn: 206658
Code review feedback from Eric Christopher on r204261.
I didn't want to go into too much detail (the revision history should
provide the full stuff) - but I can add more if that's preferred.
Also moved this up to right by the construction of the MCAsmInfo so
there's less chance that other things might sneak in in between.
llvm-svn: 205267
For those playing at home this produced some fairly subtle behavior. The
sections created in InitMCObjectFileInfo were created without compressed
debug info (a mistake, but not necessarily /broken). Since these
sections were almost always referenced by the existing MCSection object,
this almost worked.
This got weird when we got to handling the relocations for a section.
See ELFObjectWriter::WriteSection where we compute the true section for
a relocation section by simply stripping the ".rela" prefix and then
looking up that section - doing so hit the compression codepath, looked
up .zdebug_blah and found a newly constructed empty section... thus,
things got weird.
This is untestable without a cross-project test (let me know if people
would prefer that to no testing).
llvm-svn: 205261
This updates CodeGenPGO to use the ProfileDataReader introduced to
llvm in r203703 and the new API for writing out the profile introduced
to compiler-rt in r203710.
llvm-svn: 203711
An option with the same name already exists in the makefile build.
The name CLANG_IS_PRODUCTION is historical. We should probably change it, but
should change the configure build at the same time.
llvm-svn: 203325
In r199283 I switched the name of this variable to CCC_OVERRIDE_OPTIONS, but
I kept some code to continue recognizing the old name temporarily. As far as
I know, the only use of this was for some internal testing at Apple, and we've
now switched to use the new name. If anyone else is still using this and needs
more time to switch names, I guess we'll find out! <rdar://problem/15821425>
llvm-svn: 201962
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
The separate Xcode project generated for Clang is putting the clang
executables into the same location where the LLVM executables are
going. This is wrong, and breaks the Clang build because we try to
create clang++ and clang-cl symlinks in the wrong place and to the
wrong place.
As a stop-gap to get these builds working again, teach the symlink
generation to point into the LLVM executable directory instead.
llvm-svn: 198319
Also stop setting passing -dead_strip explicitly for libclang and instead
rely on this now happening by default. (And make it happen by default for
add_clang_library, which doesn't use the library cmake functions from llvm.)
llvm-svn: 198200
Summary:
Use the arguments given to the OS at process creation-time instead of
the arguments passed into main() by the C runtime environment. The ones
that main() received may not be suitable (e.g. not Unicode).
Depends on D1834
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1835
llvm-svn: 192091
The previous change caused the driver to translate -Wa,-L to the
-msave-temp-labels option for cc1as, but cc1as did not accept that option.
This patch follows the same approach used for similar options (-relax-all,
-noexecstack) in the previous patch.
llvm-svn: 191458
Use the same filtering for assembly arguments to -cc1as as we do for
-cc1, this allows a consistent (& more useful) diagnostic experience for
users (rather than getting an error from -cc1as (which a user shouldn't
really be thinking about) about --foo, they get an error from clang
about --foo in -Wa,)
I'm sort of surprised by the separation of -cc1as & the separate
argument handling, etc, but at least this removes a little bit of the
duplication.
llvm-svn: 187156
and add a new option --driver-mode= to control it explicitly.
The CCCIsCXX and CCCIsCPP flags were non-overlapping, i.e. there
are currently really three modes that Clang can run in: gcc, g++
or cpp, so it makes sense to represent them as an enum.
Having a command line flag to control it helps testing.
llvm-svn: 186605
MSBuild writes response files as UTF-16 little endian with a byte order
mark. With this change, clang will be able to read them, although we
still can't parse any of their flags.
Adds a UTF-16-LE response file with a BOM for testing.
Differential Revision: http://llvm-reviews.chandlerc.com/D1137
llvm-svn: 186603
The big changes are:
- Deleting Driver/(Arg|Opt)*
- Rewriting includes to llvm/Option/ and re-sorting
- 'using namespace llvm::opt' in clang::driver
- Fixing the autoconf build by adding option everywhere
As discussed in the review, this change includes using directives in
header files. I'll make follow up changes to remove those in favor of
name specifiers.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D975
llvm-svn: 183989
This is a nop right now, but committing this first avoids a temporary breakage
when the llvm files change to not default to exporting symbols.
llvm-svn: 178723
Before: clang-3: error: no input files
After: clang-3.3: error: no input files
This means that we'll also print clang.exe on windows, but I don't see a problem
with that.
llvm-svn: 176788
subsequent commands from being executed.
The diagnostics generation isn't designed for this use case, so add a note to
fix this in the very near future. For now, just generated the diagnostics for
the first failing command.
Part of rdar://12984531
llvm-svn: 173825
Also, it was the only reason that `argc` and `argv` were being passed
into createDiagnostics, so remove those parameters and clean up callers.
llvm-svn: 172945
AT_producer. Which includes clang's version information so we can tell
which version of the compiler was used.
This is second of the two steps to allow us to do this. The first was a
change to llvm-mc with revision 172630 to provide a method to set the
AT_producer string. This second step has the clang driver passing the value
of getClangFullVersion() via the new flag -dwarf-debug-producer when invoking
the integrated assembler on assembly source files. Then using the new
setDwarfDebugProducer() method to set the AT_producer string.
rdar://12888242
llvm-svn: 172758
warning options to setup diagnostic state, but should not be emitting warnings as these would be
rudndant with what the frontend emits.
rdar://13001556
llvm-svn: 172497
This also requires adding support to -cc1as for passing the detecting
PWD down through LLVM's debug info (which in turn required the LLVM
change in r170371).
The test case is weak (we only test the driver behavior) because there
is currently to infrastructure for running cc1as in the test suite. So
those four lines are untested (much like all other lines in that file),
but we have a test for the same pattern using llvm-mc in the LLVM
repository.
llvm-svn: 170373
specifies not to. Dont build ASTMatchers with Rewriter disabled and
StaticAnalyzer when it's disabled.
Without all those three, the clang binary shrinks (x86_64) from ~36MB
to ~32MB (unstripped).
llvm-svn: 170135
the various stakeholders bump up the reference count. In particular,
the diagnostics engine now keeps the DiagnosticOptions object alive.
llvm-svn: 166508
This is similar to how we divide up the StaticAnalyzer libraries to separate
core functionality to what is clearly associated with Frontend actions.
llvm-svn: 163050
- lib/Driver/Driver.cpp, tools/driver/driver.cpp: Exit status should not be propagated, although clang driver should catch exceptions.
- test/Driver/crash-report.c: Add REQUIRES:shell for now.
FIXME: setenv should work also on Lit.InternalShellRunner.
- test/Driver/crash-report.c: Remove XFAIL.
Thanks to Chad, To point out the issue.
llvm-svn: 160343
express library-level dependencies within Clang.
This is no more verbose really, and plays nicer with the rest of the
CMake facilities. It should also have no change in functionality.
llvm-svn: 158888
That commit added a new library just to hold the RawCommentList. I've
started a discussion on the commit thread about whether that is really
meritted -- it certainly doesn't seem necessary at this stage.
However, the immediate problem is that the AST library has a hard
dependency on the Comment library, but the dependencies were set up
completely backward. In addition to the layering violation, this had an
unfortunate effect if scattering the Comments library dependency
throughout the build system, but inconsistently so -- several parts of
the CMake dependencies were missing and only showed up due to transitive
deps or the fact that the target wasn't being built by tho bots.
It turns out that the Comments library can't (currently) be a well
formed layer *below* the AST library either, as it has an API that
accepts an ASTContext. That parameter is currently unused, so maybe that
was a mistake?
Anyways, it really seems like this is logically part of the AST --
that's the whole point of the ASTContext providing access to it as far
as I can tell -- so I've merged it into the AST library to solve the
immediate layering violation problems and remove some of the churn from
our library dependencies.
llvm-svn: 158807
* Retain comments in the AST
* Serialize/deserialize comments
* Find comments attached to a certain Decl
* Expose raw comment text and SourceRange via libclang
llvm-svn: 158771
Previously, only diagnostics thrown by the cc1 process were
actually honoring the diagnostic options given on the command line,
like -Werror.
Reuse the existing code in Frontend currently used for cc1,
adjusting it to not interpret -Wl, linker flags as warnings.
Also fix a faulty test exposed by this change.
It wasn't actually testing anything, and was giving this warning:
clang-3: warning: argument unused during compilation: '-verify'
Which -Werror didn't turn into an error because it was output
by the driver, not the cc1 process, and diagnostic options
weren't parsed by the driver. And you couldn't see the warning
when running the test suite.
Fixes PR12181.
Patch by Dylan Noblesmith <nobled@dreamwidth.org>.
llvm-svn: 152660
the new Objective-C NSArray/NSDictionary/NSNumber literal syntax.
This introduces a new library, libEdit, which provides a new way to support
migration of code that improves on the original ARC migrator. We now believe
that most of its functionality can be refactored into the existing libraries,
and thus this new library may shortly disappear.
llvm-svn: 152141
When creating the MCSubtargetInfo, the assembler driver uses the CPU and
feature string to construct a more accurate model of what instructions
are and are not legal.
rdar://10840476
llvm-svn: 150273
This fixes the FIXMEs in ParseAnalyzeArgs. (Also a
precursor to moving the analyzer into an AST plugin.)
For consistency, do the same with AssemblerInvocation.
llvm-svn: 147218
This patch ensures that no passes are deleted from clang, such that the loading
of plugins does not fail because of passes being unavailable. This increases
the size of the clang binary from 43029853 to 43915291 bytes (around 2%).
llvm-svn: 143414
Richard Smith