it is going to be rewritten (and the chain will be serialized again), otherwise we may form a cycle in its
categories list when deserializing.
Also introduce ASTMutationListener::CompletedObjCForwardRef to notify that a forward reference
was completed; using Decl's isChangedSinceDeserialization/setChangedSinceDeserialization
is bug inducing and kinda gross, we should phase it out.
Fixes infinite loop in rdar://10418538.
llvm-svn: 144465
the module is described in one of the module maps in a search path or
in a subdirectory off the search path that has the same name as the
module we're looking for.
llvm-svn: 144433
map, so long as they have an umbrella header. This makes it possible
to introduce a module map + umbrella header for a given set of
headers, to turn it into a module.
There are two major deficiencies here: first, we don't go hunting for
module map files when we just see a module import (so we won't know
about the modules described therein). Second, we don't yet have a way
to build modules that don't have umbrella headers, or have incomplete
umbrella headers.
llvm-svn: 144424
the corresponding (top-level) modules. This isn't actually useful yet,
because we don't yet have a way to build modules out of module maps.
llvm-svn: 144410
to disable the corresponding -Wc++98-compat warnings in addition to the C++11
extension warnings, so that people already using these flags can switch to C++11
mode and turn on -Wc++98-compat.
llvm-svn: 144404
Module map files provide a way to map between headers and modules, so
that we can layer a module system on top of existing headers without
changing those headers at all.
This commit introduces the module map file parser and the module map
that it generates, and wires up the module map file parser so that
we'll automatically find module map files as part of header
search. Note that we don't yet use the information stored in the
module map.
llvm-svn: 144402
Cut down the number of callbacks to more generic ones. Clients can check
an enum to find out what kind of declaration it is and they can call functions
to get more specific information than the generic provided info.
llvm-svn: 144343
In certain cases ASTReader would call the normal DiagnosticsEngine API to initialize
the state of diagnostic pragmas but DiagnosticsEngine would try to compare source locations
leading to crash because the main FileID was not yet initialized.
Yet another case of the ASTReader trying to use the normal APIs and inadvertently breaking
invariants. Fix this by having the ASTReader set up the internal state directly.
llvm-svn: 144153
which they do. This avoids all of the default argument promotions that
we (1) don't want, and (2) undo during that custom type checking, and
makes sure that we don't run into trouble during template
instantiation. Fixes PR11320.
llvm-svn: 144110
This patch just adds a simple NeonTypeFlags class to replace the various
hardcoded constants that had been used until now. Unfortunately I couldn't
figure out a good way to avoid duplicating that class between clang and
TableGen, but since it's small and rarely changes, that's not so bad.
llvm-svn: 144054
initializer; all other constexpr variables are merely required to be
initialized. In particular, a user-provided constexpr default constructor can be
used for such initialization.
llvm-svn: 144028
default", make a note of which is used when creating the
initial declaration. Previously, we would wait until later to handle
default/delete as a definition, but this is too late: when adding the
declaration, we already treated the declaration as "user-provided"
when in fact it was merely "user-declared".
Fixes PR10861 and PR10442, along with a bunch of FIXMEs.
llvm-svn: 144011
We don't actually need a separate flag for non-sysrooted paths as the
driver has to manage the sysroot anyways. The driver is not infrequently
adding paths to the header search based on their existence on the
filesystem. For that, it has to add the sysroot anyways, we should pass
it on down to CC1 already joined. More importantly, the driver cannot in
all cases distinguish between sysrooted paths and paths that are
relative to the Clang binary's installation directory. Essentially, we
always need to ignore the system root for these internal header search
options. It turns out in most of the places we were already providing
the system root in the driver, and then another one in CC1 so this fixes
several bugs.
llvm-svn: 143917
property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressions implementing it.
This should significantly reduce the complexity required
elsewhere in the compiler to deal with these kinds of
expressions (e.g. IR generation's special l-value kind,
the static analyzer's Message abstraction), at the lower
cost of specifically dealing with the odd AST structure
of these expressions. It should also greatly simplify
efforts to implement similar language features in the
future, most notably Managed C++'s properties and indexed
properties.
Most of the effort here is in dealing with the various
clients of the AST. I've gone ahead and simplified the
ObjC rewriter's use of properties; other clients, like
IR-gen and the static analyzer, have all the old
complexity *and* all the new complexity, at least
temporarily. Many thanks to Ted for writing and advising
on the necessary changes to the static analyzer.
I've xfailed a small diagnostics regression in the static
analyzer at Ted's request.
llvm-svn: 143867
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.
llvm-svn: 143801
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.
llvm-svn: 143798
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.
llvm-svn: 143686
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.
llvm-svn: 143684
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>.
llvm-svn: 143599
This is intended for direct access of the ASTReader for uses that make
little sense to try to shoehorn in the ExternalASTSource interface.
llvm-svn: 143465
it contains give it a USR based on its semantic context, which is the interface.
This follows what we already did for objc methods. rdar://10371669
llvm-svn: 143464
that it retains source location information for the type. Aside from
general goodness (being able to walk the types described in that
information), we now have a proper representation for dependent
delegating constructors. Fixes PR10457 (for real).
llvm-svn: 143410
Track the function invocation where an lvalue referring to a constexpr function
parameter originated from, and use it to substitute the correct argument and to
determine whether such an argument's lifetime has ended.
llvm-svn: 143296
implicitly perform an lvalue-to-rvalue conversion if used on an lvalue
expression. Also improve the documentation of Expr::Evaluate* to indicate which
of them will accept expressions with side-effects.
llvm-svn: 143263
The motivation for this new DiagnosticConsumer is to provide a way for tools invoking the compiler
to get its diagnostics via a libclang interface, rather than textually parsing the compiler output.
This gives us flexibility to change the compiler's textual output, but have a structured data format
for clients to use to get the diagnostics via a stable API.
I have no tests for this, but llvm-bcanalyzer so far shows that the emitted file is well-formed.
More work to follow.
llvm-svn: 143259
Introduce a FILE_SORTED_DECLS [de]serialization record that contains
a file sorted array of file-level DeclIDs in a PCH/Module.
The rationale is to allow "targeted" deserialization of decls inside
a range of a source file.
Cocoa PCH increased by 0.8%
Difference of creation time for Cocoa PCH is below the noise level.
llvm-svn: 143238
constexpr function arguments outside of their function (passing or returning
them by reference) does not work correctly yet.
Calling constexpr function templates does not work yet, since the bodies are not
instantiated until the end of the translation unit.
llvm-svn: 143234
are present in all the necessary places:
In constant expression evaluation, evaluate lvalues as lvalues and rvalues as
rvalues. Remove special case for caching reference initialization and fix a
cyclic initialization crash in the process.
llvm-svn: 143204
Argyrios Kyrtzidis