Move the Linux header searching from the Frontend to the Driver. This is
the first (and diff-noisiest) step to making Linux header searching
tremendously more principled and less brittle. Note that this step
should have essentially no functional impact. We still search the exact
same set of paths in the exact same order. The only change here is where
the code implementing such a search lives.
This has one obvious negative impact -- we now pass a ludicrous number
of flags to the CC1 layer. That should go away as I re-base this logic
on the logic to detect a GCC installation. I want to do this in two
phases so the bots can tell me if this step alone breaks something, and
so that the diffs of the refactoring make more sense.
Change this test to reflect the state we are moving in. The Clang
builtin headers are no longer going to receive the old 'implicit extern
"C" block' semantics. This hint is actually ignored by both Clang and
GCC at this point, and Clang's own builtin headers can simply be changed
if there is any issue with this. Clang should be free to include these
however it wants, and so shorter and simpler is better.
Note: *nothing* is changing about the *system* stddef.h include. That
should always have the exact same include semantics, whether with Clang
or GCC or any other compiler. Only the compiler-builtin header search
path is changing.
If anyone knows of some risk that this introduces that I've not thought
of, please chime in. So far, only Windows has switched to the Brave New
World, but others should be switching soon.
Switch these two tests to use the Clang driver instead of CC1. They want
to do "realistic" includes, and so need the header search logic now in
the driver. This in turn requires switching the CC1 options to the
actual driver options, and passing -Xclang where there is no analogy.
Teach Lit to pass the CC1 invocation the builtin include directory. This
is a pretty gross hack, but I don't have any significantly cleaner ideas
for this. There are several things obviously gross about it:
1) Lit shouldn't know that Clang needs this. This really that bad, as
Lit already knows about CC1 and other internal details.
2) This hard codes the '3.0' version number, which is pretty lame.
3) This hard codes every other aspect of the resource dir structure
which is less lame than the version number, but still not great.
However, it should bring the MSVC tests back to life, and it should
unblock the rest of the move from Frontend to Driver, so I think it's
worth a bit of grossness that is isolated in our testing infrastructure
while we figure out the best long term approach. I have the following
ideas, some of which only solve part of the problem (and thus might need
to be combined with other ideas):
a) Create a symlink or other convenience path instead of a version
number.
b) Run 'clang' directly in the lit.cfg, look at its resource dir, and use
that.
c) Switch all the tests to use the driver instead of CC1.
d) Hack the frontend to synthesize builtin include directories when none
are provided by the driver.
I don't like (d) because it feels very hackish and likely to break. We
can only solve a small part of the problem with (a). I wanted to vote
for (c), but lots of the tests in this bucket are really heavily using
internal-only flags like -verify and -triple. I'm loath to complicate
them with the full driver layer. Also, switching them to the driver adds
more than just builtin headers, but all of the rest of the system
headers!
This leaves me with (b). If others like (b), I'll switch to it, but it
felt a bit icky. Nothing concrete, and the other options look
significantly worse, but I felt icky enough that I wanted to start with
a more brain-dead patch to stop the bleeding, and gauge others' feelings
here.
Fix a significant oversight in my move of MSVC includes to the driver:
actually manage the builtin header file includes as well as the system
ones.
This one is actually debatable whether it belongs in the driver or not,
as the builtin includes are really an internal bit of implementation
goop for Clang. However, they must be included at *exactly* the right
point in the sequence of header files, which makes it essentially
impossible to have this be managed by the Frontend and the rest by the
Driver. I have terrible ideas that would "work", but I think they're
worse than putting this in the driver and making the Frontend library
even more ignorant of the environment and system on which it is being
run.
Also fix the fact that we weren't properly respecting the flags which
suppress standard system include directories.
Note that this still leaves all of the Clang tests which run CC1
directly and include builtin header files broken on Windows. I'm working
on a followup patch to address that.
Add two flags to the CC1 layer that I was hoping to avoid. We need to
encode the *exact* semantics which the header search paths internally
built by the Frontend layer have had, which is both non-user-provided,
and at times adding the implicit extern "C" bit to the directory entry.
There are lots of CC1 options that are very close, but none do quite
this, and they are all already overloaded for other purposes. In some
senses this makes the command lines more clean as it clearly indicates
which flags are exclusively used to implement internal detection of
"standard" header search paths.
Lots of the implementation of this is really crufty, due to the
surrounding cruft. It doesn't seem worth investing lots of time cleaning
this up as it isn't new, and hopefully *lots* of this code will melt
away as header search inside of the frontend becomes increasingly
trivial.
Ted Kremenek [Sat, 5 Nov 2011 07:34:28 +0000 (07:34 +0000)]
Tweak LookThroughStmt() in LiveVariables to properly look through alternativing ParenExprs and OpaqueValueExprs. Thanks to Anna and Argiris for iterating on this function. My original patch embarssingly didn't even pass the Clang tests.
Ted Kremenek [Sat, 5 Nov 2011 00:10:04 +0000 (00:10 +0000)]
Serialized diagnostics: pull category name serialization into diagnostic blocks. The goal is to remove BLOCK_STRINGS so that the bitcode file can potentially be streamed.
Begin the migration of header search logic to the driver, starting with
Windows. There are still FIXMEs and lots of problems with this code.
Some of them will be addressed shortly by my follow-up patches, but most
are going to wait until we isolate this code and can fix it properly.
This version should be no worse than what we had before.
Switch the C++ include interface in the ToolChain to use the same naming
as the system include interface before I start adding implementations of
it to individual ToolChain implementations.
In ARC, when applying an ownership to a non-objc pointer, instead of ignoring it
create an attributed type with same type as the original type.
We effectively retain the source info that an ownership attribute was present but the attribute
is ignored by not modifying the type that it was applied to.
Sink the strange '-stdlib=...' flag handling into the C++ include
handling logic of the generic ToolChain. This flag, despite its name,
has *nothing* to do with the GCC flag '-nostdlib' that relates
(exclusively) to the linking behavior. It is a most unfortunate name in
that regard...
It is used to tell InitHeaderSearch.cpp *which* set of C++ standard
library header search paths to use -- those for libstdc++ from GCC's
installation, or those from a libc++ installation. As this logic is
hoisted out of the Frontend, and into the Driver as part of this
ToolChain, the generic method will be overridden for the platform, where
it can implement this logic directly. As such, hiding the CC1 option
passing in the generic space is a natural fit despite the odd naming.
Also, expand on the comments to clarify whats going on, and tidy up the
Tools.cpp code now that its simpler.
Sink the handling of -fobjc-arc-cxxlib to live with the other -fobjc-arc
implementation in the driver. This cleans up the signature and semantics
of the include flag adding component of the toolchain. Another step to
ready it for holding all the InitHeaderSearch logic.
Add a FIXME to cleanup the CPATH handling. It's currently burried with
the rest of the mess in InitHeaderSearch.cpp. We could hoist it into the
driver profitably, removing more noise from the driver -> frontend
communication.
Add a system include management interface to the toolchain, and call it
and the C++ include management routine from the proper place when
forming preprocessor options in the driver. This is the first step to
teaching the driver to manage all of the header search paths. Currently,
these methods remain just stubs in the abstract toolchain. Subsequent
patches will flesh them out with implementations for various toolchains
based on the current code in InitHeaderSearch.cpp.
Richard Smith [Fri, 4 Nov 2011 05:33:44 +0000 (05:33 +0000)]
Constant expression evaluation: refactor to start the groundwork for coping with
initializations which refer indirectly to elements of the object being
initialized.
Richard Smith [Fri, 4 Nov 2011 02:25:55 +0000 (02:25 +0000)]
Constant expression evaluation: track the manner in which an lvalue was written,
to allow us to implement the C++11 rule that a non-active union member can't be
read, and use it to implement subobject access for string literals.
Richard Smith [Fri, 4 Nov 2011 01:10:57 +0000 (01:10 +0000)]
Constant expression evaluation: although we don't know whether a literal will
be at the same address as another object, we do know it won't alias a null
pointer.
Chad Rosier [Thu, 3 Nov 2011 21:23:39 +0000 (21:23 +0000)]
Parse the warning options twice. The first pass sets diagnostic state, while
the second pass reports warnings/errors. This has the effect that we follow
the more canonical "last option wins" paradigm when there are conflicting
options.
rdar://10383776
Previously, we parsed the warning options in order. This caused non-intuitive
behavior:
[libclang] Fix crash when a #pragma diagnostic is included in the preamble.
A PCH file keeps track of #pragma diagnostics state; when loading the preamble, they conflicted
with the #pragma diagnostic state already present in the DiagnosticsEngine object due to
parsing the preamble.
Fix this by clearing the state of the DiagnosticsEngine object.
Fixes rdar://10363572 && http://llvm.org/PR11254.
Douglas Gregor [Thu, 3 Nov 2011 16:37:14 +0000 (16:37 +0000)]
When we're checking a friend function template in an out-of-line class
definition, we may not have a scope corresponding to the namespace
where that friend function template actually lives. Work around this
issue by faking up a scope with the appropriate DeclContext.
This is a bit of a hack, but it fixes <rdar://problem/10204947>.
Douglas Gregor [Thu, 3 Nov 2011 00:16:13 +0000 (00:16 +0000)]
Add a printing policy flag to suppress printing "<anonymous>::" prior
to types. Enable this flag for code completion, where knowing whether
something is in an anonymous or inline namespace is actually not
useful, since you don't have to type it anyway. Fixes
<rdar://problem/10208818>.
Eli Friedman [Wed, 2 Nov 2011 23:06:23 +0000 (23:06 +0000)]
Use native endianness for writing out character escapes to the result buffer for string literal parsing. No functional change on little-endian architectures; should fix test failures on PPC.
projects / clang / log