The reproducer should use -I/-F/-resource-dir in the same way as the
original command. The VFS already collects the right headers but without
these flags the reproducer will fail to do the right thing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265343 91177308-0d34-0410-b5e6-96231b3b80d8
The cc1 invocation in the reproducer script should contain a valid path in
-fmodule-cache-path; for that reuse "<name>.cache/module" dir we already
use to dump the vfs and modules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265162 91177308-0d34-0410-b5e6-96231b3b80d8
In the gcc precompiled header model, one explicitly runs clang with `-x
c++-header` on a .h file to produce a gch file, and then includes the header
with `-include foo.h` and if a .gch file exists for that header it gets used.
This is documented at
http://clang.llvm.org/docs/UsersManual.html#precompiled-headers
cl.exe's model is fairly different, and controlled by the two flags /Yc and
/Yu. A pch file is generated as a side effect of a regular compilation when
/Ycheader.h is passed. While the compilation is running, the compiler keeps
track of #include lines in the main translation unit and writes everything up
to an `#include "header.h"` line into a pch file. Conversely, /Yuheader.h tells
the compiler to skip all code in the main TU up to and including `#include
"header.h"` and instead load header.pch. (It's also possible to use /Yc and /Yu
without an argument, in that case a `#pragma hrdstop` takes the role of
controlling the point where pch ends and real code begins.)
This patch implements limited support for this in that it requires the pch
header to be passed as a /FI force include flag – with this restriction,
it can be implemented almost completely in the driver with fairly small amounts
of code. For /Yu, this is trivial, and for /Yc a separate pch action is added
that runs before the actual compilation. After r261774, the first failing
command makes a compilation stop – this means if the pch fails to build the
main compilation won't run, which is what we want. However, in /fallback builds
we need to run the main compilation even if the pch build fails so that the
main compilation's fallback can run. To achieve this, add a ForceSuccessCommand
that pretends that the pch build always succeeded in /fallback builds (the main
compilation will then fail to open the pch and run the fallback cl.exe
invocation).
If /Yc /Yu are used in a setup that clang-cl doesn't implement yet, clang-cl
will now emit a "not implemented yet; flag ignored" warning that can be
disabled using -Wno-clang-cl-pch.
Since clang-cl doesn't yet serialize some important things (most notably
`pragma comment(lib, ...)`, this feature is disabled by default and only
enabled by an internal driver flag. Once it's more stable, this internal flag
will disappear.
(The default stdafx.h setup passes stdafx.h as explicit argument to /Yc but not
as /FI – instead every single TU has to `#include <stdafx.h>` as first thing it
does. Implementing support for this should be possible with the approach in
this patch with minimal frontend changes by passing a --stop-at / --start-at
flag from the driver to the frontend. This is left for a follow-up. I don't
think we ever want to support `#pragma hdrstop`, and supporting it with this
approach isn't easy: This approach relies on the driver knowing the pch
filename in advance, and `#pragma hdrstop(out.pch)` can set the output
filename, so the driver can't know about it in advance.)
clang-cl now also honors /Fp and puts pch files in the same spot that cl.exe
would put them, but the pch file format is of course incompatible. This has
ramifications on /fallback, so /Yc /Yu aren't passed through to cl.exe in
/fallback builds.
http://reviews.llvm.org/D17695
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262420 91177308-0d34-0410-b5e6-96231b3b80d8
These two arguments tend to refer to a local path that won't exist
when we try to reproduce a bug. Strip them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244179 91177308-0d34-0410-b5e6-96231b3b80d8
Guessing which file name to replace based on the -main-file-name
argument to -cc1 is flawed. Instead, keep track of which arguments are
inputs to each command.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242504 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@242346 91177308-0d34-0410-b5e6-96231b3b80d8
We had a strange relationship here where we made a list of Jobs
inherit from a single Job, but there weren't actually any places where
this arbitrary nesting was used or needed.
Simplify all of this by removing Job entirely and updating all of the
users to either work with a JobList or a single Command.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241310 91177308-0d34-0410-b5e6-96231b3b80d8
For crashes with a VFS (ie, with modules), the -isysroot flag is often
necessary to reproduce the crash. This is especially true if some
modules need to be rebuilt, since without the sysroot they'll try to
read headers that are outside of the VFS.
I find it likely that we should keep some of the other -i flags in
this case as well, but I haven't seen that come up in practice yet so
it seems better to be conservative.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231997 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes crash report generation when filenames have spaces. It also
removes an awkward workaround that quoted *some* arguments when
generating crash reports.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220307 91177308-0d34-0410-b5e6-96231b3b80d8
This pushes the logic for generating a crash reproduction script
entirely into Command::Print, instead of Command doing half of the
work and then relying on textual substitution for the rest. This makes
this logic much easier to read and will simplify fixing a couple of
issues in this area.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220305 91177308-0d34-0410-b5e6-96231b3b80d8
There's probably never a good reason to iterate over unique_ptrs. This
lets us use range-for and say Job.foo instead of (*it)->foo in a few
places.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218938 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by Rafael Auler!
This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command line exceeds system limits. This
is a problem for Windows systems, whose maximum command-line length is
32kb.
I introduce the concept of "response file support" for each Tool object.
A given Tool may have full support for response files (e.g. MSVC's
link.exe) or only support file names inside response files, but no flags
(e.g. Apple's ld64, as commented in PR15171), or no support at all (the
default case). Therefore, if you implement a toolchain in the clang
driver and you want clang to be able to use response files in your
tools, you must override a method (getReponseFileSupport()) to tell so.
I designed it to support different kinds of tools and
internationalisation needs:
- VS response files ( UTF-16 )
- GNU tools ( uses system's current code page, windows' legacy intl.
support, with escaped backslashes. On unix, fallback to UTF-8 )
- Clang itself ( UTF-16 on windows, UTF-8 on unix )
- ld64 response files ( only a limited file list, UTF-8 on unix )
With this design, I was able to test input file names with spaces and
international characters for Windows. When the linker input is large
enough, it creates a response file with the correct encoding. On a Mac,
to test ld64, I temporarily changed Clang's behavior to always use
response files regardless of the command size limit (avoiding using huge
command line inputs). I tested clang with the LLVM test suite (compiling
benchmarks) and it did fine.
Test Plan: A LIT test that tests proper response files support. This is
tricky, since, for Unix systems, we need a 2MB response file, otherwise
Clang will simply use regular arguments instead of a response file. To
do this, my LIT test generate the file on the fly by cloning many -DTEST
parameters until we have a 2MB file. I found out that processing 2MB of
arguments is pretty slow, it takes 1 minute using my notebook in a debug
build, or 10s in a Release build. Therefore, I also added "REQUIRES:
long_tests", so it will only run when the user wants to run long tests.
In the full discussion in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130408/171463.html,
Rafael Espindola discusses a proper way to test
llvm::sys::argumentsFitWithinSystemLimits(), and, there, Chandler
suggests to use 10 times the current system limit (20MB resp file), so
we guarantee that the system will always use response file, even if a
new linux comes up that can handle a few more bytes of arguments.
However, by testing with a 20MB resp file, the test takes long 8 minutes
just to perform a silly check to see if the driver will use a response
file. I found it to be unreasonable. Thus, I discarded this approach and
uses a 2MB response file, which should be enough.
Reviewers: asl, rafael, silvas
Reviewed By: silvas
Subscribers: silvas, rnk, thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D4897
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217792 91177308-0d34-0410-b5e6-96231b3b80d8
This escapes any backslashes in the executable path and fixes an issue
with a trailing quote when the main file name had to be quoted during
printing.
It's impossible to test this without putting backslashes or quotes into
the executable path, so I didn't add automated tests.
The crash diagnostics are still only useful if you're using bash on
Windows, though. This should probably be writing a batch file instead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214924 91177308-0d34-0410-b5e6-96231b3b80d8
The modules cache path shouldn't be included in crash reports, as it's
a system (or run) specific directory.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206922 91177308-0d34-0410-b5e6-96231b3b80d8
When this flag is enabled, clang-cl falls back to cl.exe if it
cannot compile the code itself for some reason.
The idea is to use this to help build projects that almost compile
with clang-cl, except for some files that can then be built with
the fallback mechanism.
Differential Revision: http://llvm-reviews.chandlerc.com/D1711
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191034 91177308-0d34-0410-b5e6-96231b3b80d8
as suggested by Jordan on IRC. Also, use the unqualified name
in Job.cpp.
And while we're here, refer to StringRef with the unqualified
name, because we have a using directive for that too.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190909 91177308-0d34-0410-b5e6-96231b3b80d8
Seems like it was intentional to export ArgStringList as
driver::ArgStringList, and e.g. examples/clang-interpreter/main.cpp
uses it this way.
However, exporting it with a typedef seems like a more common way to do it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190906 91177308-0d34-0410-b5e6-96231b3b80d8
I think it makes sense that a Command knows how to execute itself.
There's no functionality change but i rewrote the code to avoid the manual
memory management of Argv.
My motivation for this is that I plan to subclass Command to build fall-back
functionality into clang-cl.
Differential Revision: http://llvm-reviews.chandlerc.com/D1654
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190621 91177308-0d34-0410-b5e6-96231b3b80d8
This moves the code to Job.cpp, which seems like a more natural fit,
and replaces the "is this a JobList? is this a Command?" logic with
a virtual function call.
It also removes the code duplication between PrintJob and
PrintDiagnosticJob and simplifies the code a little.
There's no functionality change here, except that the Executable is
now always printed within quotes, whereas it would previously not be
quoted in crash reports, which I think was a bug.
Differential Revision: http://llvm-reviews.chandlerc.com/D1653
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190620 91177308-0d34-0410-b5e6-96231b3b80d8
I was going to update the comment referring to PipedJob, which was removed
some time ago, but then it turned out that this method is not actually used
at all.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190171 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183989 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
information including the fully preprocessed source file(s) and command line
arguments. The developer is asked to attach this diagnostic information to a
bug report.
rdar://9575623
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@136702 91177308-0d34-0410-b5e6-96231b3b80d8
including the fully preprocessed source file(s) and command line arguments. The
developer is asked to attach this diagnostic information to a bug report.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@135614 91177308-0d34-0410-b5e6-96231b3b80d8
open them in fundamental-mode instead of c++-mode.
Also twiddle whitespace for consistency in ToolChains.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122646 91177308-0d34-0410-b5e6-96231b3b80d8
Mehdi Amini