clang-cl: Add /Yc argument to /showIncludes output.

To make this work, delay printing of ExtraDeps in HeaderIncludesCallback a bit,
so that it happens after CompilerInstance::InitializeSourceManager

clang-cl: Add /Yc argument to /showIncludes output.

To make this work, delay printing of ExtraDeps in HeaderIncludesCallback a bit,
so that it happens after CompilerInstance::InitializeSourceManager() has run.

General /FI arguments are still missing from /showIncludes output, this still
needs to be fixed.

llvm-svn: 263352

show more ...

clang-cl: Implement initial limited support for precompiled headers.

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

clang-cl: Implement initial limited support for precompiled headers.

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

llvm-svn: 262420

show more ...

[modules] Flatten -fmodule-name= and -fmodule-implementation-of= into a single
option. Previously these options could both be used to specify that you were
compiling the implementation file of a modu

[modules] Flatten -fmodule-name= and -fmodule-implementation-of= into a single
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.

This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.

llvm-svn: 261372

show more ...

Reduce the number of implicit StringRef->std::string conversions by threading StringRef through more APIs.

No functionality change intended.

llvm-svn: 260815

Update for llvm API change.

llvm-svn: 255838

[Frontend] Rangify for loop. NFC.

llvm-svn: 253178

[modules] If we're given a module file, via -fmodule-file=, for a module, but
we can't load that file due to a configuration mismatch, and implicit module
building is disabled, and the user turns off

[modules] If we're given a module file, via -fmodule-file=, for a module, but
we can't load that file due to a configuration mismatch, and implicit module
building is disabled, and the user turns off the error-by-default warning for
that situation, then fall back to textual inclusion for the module rather than
giving an error if any of its headers are included.

llvm-svn: 252114

show more ...

Introduce module file extensions to piggy-back data onto module files.

Introduce the notion of a module file extension, which introduces
additional information into a module file at the time it is b

Introduce module file extensions to piggy-back data onto module files.

Introduce the notion of a module file extension, which introduces
additional information into a module file at the time it is built that
can then be queried when the module file is read. Module file
extensions are identified by a block name (which must be unique to the
extension) and can write any bitstream records into their own
extension block within the module file. When a module file is loaded,
any extension blocks are matched up with module file extension
readers, that are per-module-file and are given access to the input
bitstream.

Note that module file extensions can only be introduced by
programmatic clients that have access to the CompilerInvocation. There
is only one such extension at the moment, which is used for testing
the module file extension harness. As a future direction, one could
imagine allowing the plugin mechanism to introduce new module file
extensions.

llvm-svn: 251955

show more ...

[modules] Allow the error when explicitly loading an incompatible module file
via -fmodule-file= to be turned off; in that case, just include the relevant
files textually. This allows module files to

[modules] Allow the error when explicitly loading an incompatible module file
via -fmodule-file= to be turned off; in that case, just include the relevant
files textually. This allows module files to be unconditionally passed to all
compile actions via CXXFLAGS, and to be ignored for rules that specify custom
incompatible flags.

llvm-svn: 250577

show more ...

Use llvm::errc instead of std::errc.

llvm-svn: 249302

Replace double negation of !FileID.isInvalid() with FileID.isValid().
+couple more of double-negated !SourceLocation.isInvalid() unfixed in r249228.

llvm-svn: 249235

[CUDA] Allow parsing of host and device code simultaneously.

* adds -aux-triple option to specify target triple
* propagates aux target info to AST context and Preprocessor
* pulls in target spec

[CUDA] Allow parsing of host and device code simultaneously.

* adds -aux-triple option to specify target triple
* propagates aux target info to AST context and Preprocessor
* pulls in target specific preprocessor macros.
* pulls in target-specific builtins from aux target.
* sets appropriate host or device attribute on builtins.

Differential Revision: http://reviews.llvm.org/D12917

llvm-svn: 248299

show more ...

createOutputFile should set Error to something if it returns null.

This is not portably unit-testable because the only visible
effect is a change from one random message string to another.

llvm-svn

createOutputFile should set Error to something if it returns null.

This is not portably unit-testable because the only visible
effect is a change from one random message string to another.

llvm-svn: 247900

show more ...

Initialize the AST consumer as soon as we have both an ASTConsumer and an
ASTContext. Fixes some cases where we could previously initialize the AST
consumer more than once.

llvm-svn: 245346

[modules] When explicitly building a module file, don't include timestamps in
the produced pcm file for stable file creation across distributed build
systems.

llvm-svn: 245199

[modules] Stop dropping 'module.timestamp' files into the current directory
when building with implicit modules disabled.

llvm-svn: 245136

Add sanitizer blacklists to the rules generated with -M/-MM/-MD/-MMD.

Summary:
Clang sanitizers, such as AddressSanitizer, ThreadSanitizer, MemorySanitizer,
Control Flow Integrity and others, use bl

Add sanitizer blacklists to the rules generated with -M/-MM/-MD/-MMD.

Summary:
Clang sanitizers, such as AddressSanitizer, ThreadSanitizer, MemorySanitizer,
Control Flow Integrity and others, use blacklists to specify which types / functions
should not be instrumented to avoid false positives or suppress known failures.

This change adds the blacklist filenames to the list of dependencies of the rules,
generated with -M/-MM/-MD/-MMD. This lets CMake/Ninja recognize that certain
C/C++/ObjC files need to be recompiled (if a blacklist is updated).

Reviewers: pcc

Subscribers: rsmith, honggyu.kim, pcc, cfe-commits

Differential Revision: http://reviews.llvm.org/D11968

llvm-svn: 244867

show more ...

Fix some tabs.

llvm-svn: 244537

[modules] Remove now-dead code for lazy loading of files specified by -fmodule-file=.

llvm-svn: 244417

[modules] PR22534: Load files specified by -fmodule-file= eagerly. In particular, this avoids the need to re-parse module map files when using such a module.

llvm-svn: 244416

Unrevert r244412 (reverted in r244414), and delete the bogus line left behind
in the unit test that was checking a file the test no longer creates.

llvm-svn: 244415

Revert "[modules] Don't leak -M flags for dependency file generation into the module"

This was failing tests on a bunch of bots:

http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/29919/ste

Revert "[modules] Don't leak -M flags for dependency file generation into the module"

This was failing tests on a bunch of bots:

http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/29919/steps/check-all
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/29627/steps/check-all
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/9959/
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/5591/

This reverts r244412

llvm-svn: 244414

show more ...

[modules] Don't leak -M flags for dependency file generation into the module
build process when we implicitly build a module. Previously, we'd create the
specified .d file once for each implicitly-bu

[modules] Don't leak -M flags for dependency file generation into the module
build process when we implicitly build a module. Previously, we'd create the
specified .d file once for each implicitly-built module and then finally
overwrite it with the correct contents after the requested build completes.
(This fails if you use stdout as a dependency file, which is what the provided
testcase does, and is how I discovered this brokenness.)

llvm-svn: 244412

show more ...

[modules] Attach dependency listeners to the module manager once when it's
created, rather than creating and attaching a new listener each time we load a
module file (yes, the old ones were kept arou

[modules] Attach dependency listeners to the module manager once when it's
created, rather than creating and attaching a new listener each time we load a
module file (yes, the old ones were kept around too!). No functionality change
intended, but a bit more sanity.

llvm-svn: 244411

show more ...

[modules] Produce an error if -cc1 wants to implicitly build a module and no
module cache has been provided, rather than creating one in the current
directory.

llvm-svn: 242819