Driver: Remove the Job class. NFC

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 us

Driver: Remove the Job class. NFC

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.

llvm-svn: 241310

show more ...

Driver: Use pointee_iterator rather than iterating over unique_ptrs

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

Driver: Use pointee_iterator rather than iterating over unique_ptrs

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.

llvm-svn: 218938

show more ...

Teach Clang how to use response files when calling other tools

Patch by Rafael Auler!

This patch addresses PR15171 and teaches Clang how to call other tools
with response files, when the command li

Teach Clang how to use response files when calling other tools

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

llvm-svn: 217792

show more ...

Fix some cases where StringRef was being passed by const reference. Remove const from some other StringRefs since its implicitly const already.

llvm-svn: 216825

Update for llvm api change.

llvm-svn: 216397

Remove unused sys/stat.h includes

The facility was abstracted to LLVM in r187364.

llvm-svn: 212441

Driver: Record that we're in crashdump and push flags to ConstructJob

It's more flexible and arguably better layering to set flags to modify
compiling for diagnostics in the CC1 job themselves, rath

Driver: Record that we're in crashdump and push flags to ConstructJob

It's more flexible and arguably better layering to set flags to modify
compiling for diagnostics in the CC1 job themselves, rather than
tweaking the driver flags and letting them propagate.

There is one visible change this causes: crash report files will now
get preprocessed names (.i and friends).

llvm-svn: 211411

show more ...

Replace llvm::error_code with std::error_code.

llvm-svn: 210780

[C++11] Use 'nullptr'. Driver edition.

llvm-svn: 209069

Update for llvm api change.

llvm-svn: 202053

Remove a whole lot of unused variables

There are about 30 removed in this patch, generated by a new FixIt I haven't
got round to submitting yet.

llvm-svn: 195814

Move the execution code from Compilation::ExecuteCommand to Command::Execute

I think it makes sense that a Command knows how to execute itself.

There's no functionality change but i rewrote the cod

Move the execution code from Compilation::ExecuteCommand to Command::Execute

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

llvm-svn: 190621

show more ...

Move Compilation::PrintJob and PrintDiagnosticJob into Job::Print.

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

Move Compilation::PrintJob and PrintDiagnosticJob into Job::Print.

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

llvm-svn: 190620

show more ...

Remove the -ccc-echo option that is now unused.

llvm-svn: 186970

Update for llvm API change.

llvm-svn: 186448

Convert last use of PathV1.h in Compilation.cpp

The way we decide which file to remove is fairly odd. I took a quick look at
maybe changing that, but it would be a more work than I want to put at th

Convert last use of PathV1.h in Compilation.cpp

The way we decide which file to remove is fairly odd. I took a quick look at
maybe changing that, but it would be a more work than I want to put at this
right now, so I left pair of FIXMEs.

llvm-svn: 184766

show more ...

Convert a use of PathV1.h

llvm-svn: 184753

Use llvm::sys::fs::can_write.

llvm-svn: 184234

Include PathV1.h only where it is used.

llvm-svn: 184090

[Driver] Refactor clang driver to use LLVM's Option library

The big changes are:
- Deleting Driver/(Arg|Opt)*
- Rewriting includes to llvm/Option/ and re-sorting
- 'using namespace llvm::opt' in cla

[Driver] Refactor clang driver to use LLVM's Option library

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

show more ...

Use the sys::ExecuteAndWait that takes StringRefs.

Also don't depend on Program.h including PathV1.h.

llvm-svn: 183935

Use the global functions instead of the Program methods.

llvm-svn: 183861

[driver] Do not generate crash diagnostics if the compilation command failed
to execute as the crash will surely reoccur while generating the diagnostics.
rdar://13362359

llvm-svn: 178089

[driver] The failure of any phase (e.g., preprocess, compile, assemble) for a
single translation unit should prevent later phases from executing. Otherwise,
this generates lots of noise in build sys

[driver] The failure of any phase (e.g., preprocess, compile, assemble) for a
single translation unit should prevent later phases from executing. Otherwise,
this generates lots of noise in build systems. This a fallout from r173825.
Patch by Matthew Curtis <mcurtis@codeaurora.org>.
rdar://13298009

llvm-svn: 176198

show more ...

Form the default -fmodules-cache-path= properly.

llvm-svn: 174674