constructors in the current lexical context even though name lookup
found them via some other context merged into the redecl chain.
This can only happen for implicit constructors which can only have the
name of the type of the current context, so we can fix this by simply
*always* merging those names first. This also has the advantage of
removing the walk of the current lexical context from the common case
when this is the only constructor name we need to deal with (implicit or
otherwise).
I've enhanced the tests to cover this case (and uncovered an unrelated
bug which I fixed in r233325).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233327 91177308-0d34-0410-b5e6-96231b3b80d8
Clang was inserting these into a dense map. While it never iterated the
dense map during normal compilation, it did when emitting a module. Fix
this by using a standard MapVector to preserve the order in which we
encounter the late parsed templates.
I suspect this still isn't ideal, as we don't seem to remove things from
this map even when we mark the templates as no longer late parsed. But
I don't know enough about this particular extension to craft a nice,
subtle test case covering this. I've managed to get the stress test to
at least do some late parsing and demonstrate the core problem here.
This patch fixes the test and provides deterministic behavior which is
a strict improvement over the prior state.
I've cleaned up some of the code here as well to be explicit about
inserting when that is what is actually going on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233264 91177308-0d34-0410-b5e6-96231b3b80d8
deterministically.
This fixes a latent issue where even Clang's Sema (and diagnostics) were
non-deterministic in the face of this pragma. The fix is super simple --
just use a MapVector so we track the order in which these are parsed (or
imported). Especially considering how rare they are, this seems like the
perfect tradeoff. I've also simplified the client code with judicious
use of auto and range based for loops.
I've added some pretty hilarious code to my stress test which now
survives the binary diff without issue.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233261 91177308-0d34-0410-b5e6-96231b3b80d8
updated decl contexts get emitted.
Since this code was added, we have newer vastly simpler code for
handling this. The code I'm removing was very expensive and also
generated unstable order of declarations which made module outputs
non-deterministic.
All of the tests continue to pass for me and I'm able to check the
difference between the .pcm files after merging modules together.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233251 91177308-0d34-0410-b5e6-96231b3b80d8
non-visible definition, skip the new definition and make the old one visible
instead of trying to parse it again and failing horribly. C++'s ODR allows
us to assume that the two definitions are identical.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233250 91177308-0d34-0410-b5e6-96231b3b80d8
decl context lookup tables.
The first attepmt at this caused problems. We had significantly more
sources of non-determinism that I realized at first, and my change
essentially turned them from non-deterministic output into
use-after-free. Except that they weren't necessarily caught by tools
because the data wasn't really freed.
The new approach is much simpler. The first big simplification is to
inline the "visit" code and handle this directly. That works much
better, and I'll try to go and clean up the other caller of the visit
logic similarly.
The second key to the entire approach is that we need to *only* collect
names into a stable order at first. We then need to issue all of the
actual 'lookup()' calls in the stable order of the names so that we load
external results in a stable order. Once we have loaded all the results,
the table of results will stop being invalidated and we can walk all of
the names again and use the cheap 'noload_lookup()' method to quickly
get the results and serialize them.
To handle constructors and conversion functions (whose names can't be
stably ordered) in this approach, what we do is record only the visible
constructor and conversion function names at first. Then, if we have
any, we walk the decls of the class and add those names in the order
they occur in the AST. The rest falls out naturally.
This actually ends up simpler than the previous approach and seems much
more robust.
It uncovered a latent issue where we were building on-disk hash tables
for lookup results when the context was a linkage spec! This happened to
dodge all of the assert by some miracle. Instead, add a proper predicate
to the DeclContext class and use that which tests both for function
contexts and linkage specs.
It also uncovered PR23030 where we are forming somewhat bizarre negative
lookup results. I've just worked around this with a FIXME in place
because fixing this particular Clang bug seems quite hard.
I've flipped the first part of the test case I added for stability back
on in this commit. I'm taking it gradually to try and make sure the
build bots are happy this time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233249 91177308-0d34-0410-b5e6-96231b3b80d8
lookup tables, we need to establish a stable ordering for constructing
the hash table. This is trickier than it might seem.
Most of these cases are easily handled by sorting the lookup results
associated with a specific name that has an identifier. However for
constructors and conversion functions, the story is more complicated.
Here we need to merge all of the constructors or conversion functions
together and this merge needs to be stable. We don't have any stable
ordering for either constructors or conversion functions as both would
require a stable ordering across types.
Instead, when we have constructors or conversion functions in the
results, we reconstruct a stable order by walking the decl context in
lexical order and merging them in the order their particular declaration
names are encountered. This doesn't generalize as there might be found
declaration names which don't actually occur within the lexical context,
but for constructors and conversion functions it is safe. It does
require loading the entire decl context if necessary to establish the
ordering but there doesn't seem to be a meaningful way around that.
Many thanks to Richard for talking through all of the design choices
here. While I wrote the code, he guided all the actual decisions about
how to establish the order of things.
No test case yet because the test case I have doesn't pass yet -- there
are still more sources of non-determinism. However, this is complex
enough that I wanted it to go into its own commit in case it causes some
unforseen issue or needs to be reverted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233156 91177308-0d34-0410-b5e6-96231b3b80d8
There are two aspects of non-determinism fixed here, which was the
minimum required to cause at least an empty module to be deterministic.
First, the random number signature is only inserted into the module when
we are building modules implicitly. The use case for these random
signatures is to work around the very fact that modules are not
deterministic in their output when working with the implicitly built and
populated module cache. Eventually this should go away entirely when
we're confident that Clang is producing deterministic output.
Second, the on-disk hash table is populated based on the order of
iteration over a DenseMap. Instead, use a MapVector so that we can walk
it in insertion order.
I've added a test that an empty module, when built twice, produces the
same binary PCM file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233115 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we'd deserialize the list of mem-initializers for a constructor when
we deserialized the declaration of the constructor. That could trigger a
significant amount of unnecessary work (pulling in all base classes
recursively, for a start) and was causing problems for the modules buildbot due
to cyclic deserializations. We now deserialize these on demand.
This creates a certain amount of duplication with the handling of
CXXBaseSpecifiers; I'll look into reducing that next.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233052 91177308-0d34-0410-b5e6-96231b3b80d8
for a DeclContext, and fix propagation of exception specifications along
redeclaration chains.
This reverts r232905, r232907, and r232907, which reverted r232793, r232853,
and r232853.
One additional change is present here to resolve issues with LLDB: distinguish
between whether lexical decls missing from the lookup table are local or are
provided by the external AST source, and still look in the external source if
that's where they came from.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232928 91177308-0d34-0410-b5e6-96231b3b80d8
give an exception specification to a declaration that didn't have an exception
specification in any of our imported modules, emit an update record ourselves.
Without this, code importing the current module would not see an exception
specification that we could see and might have relied on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232870 91177308-0d34-0410-b5e6-96231b3b80d8
Now that SmallString is a first-class citizen, most SmallString::str()
calls are not required. This patch removes a whole bunch of them, yet
there are lots more.
There are two use cases where str() is really needed:
1) To use one of StringRef member functions which is not available in
SmallString.
2) To convert to std::string, as StringRef implicitly converts while
SmallString do not. We may wish to change this, but it may introduce
ambiguity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232622 91177308-0d34-0410-b5e6-96231b3b80d8
consumers of that module.
Previously, such a file would only be available if the module happened to
actually import something from that module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232583 91177308-0d34-0410-b5e6-96231b3b80d8
move the operator delete updating into a separate update record so we can cope
with updating another module's destructor's operator delete.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231735 91177308-0d34-0410-b5e6-96231b3b80d8
of extern "C" declarations. This is simpler and vastly more efficient for
modules builds (we no longer need to load *all* extern "C" declarations to
determine if we have a redeclaration).
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231538 91177308-0d34-0410-b5e6-96231b3b80d8
We used to save out and eagerly load a (potentially huge) table of merged
formerly-canonical declarations when we loaded each module. This was extremely
inefficient in the presence of large amounts of merging, and didn't actually
save any merging lookup work, because we still needed to perform name lookup to
check that our merged declaration lists were complete. This also resulted in a
loss of laziness -- even if we only needed an early declaration of an entity, we
would eagerly pull in all declarations that had been merged into it regardless.
We now store the relevant fragments of the table within the declarations
themselves. In detail:
* The first declaration of each entity within a module stores a list of first
declarations from imported modules that are merged into it.
* Loading that declaration pre-loads those other entities, so that they appear
earlier within the redeclaration chain.
* The name lookup tables list the most recent local lookup result, if there
is one, or all directly-imported lookup results if not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231424 91177308-0d34-0410-b5e6-96231b3b80d8
dynamic classes in the translation unit and check whether each one's key
function is defined when we got to the end of the TU (and when we got to the
end of each module). This is really terrible for modules performance, since it
causes unnecessary deserialization of every dynamic class in every compilation.
We now use a much simpler (and, in a modules build, vastly more efficient)
system: when we see an out-of-line definition of a virtual function, we check
whether that function was in fact its class's key function. (If so, we need to
emit the vtable.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230830 91177308-0d34-0410-b5e6-96231b3b80d8
invalidate lookup_iterators and lookup_results for some name within a
DeclContext if the lookup results for a *different* name change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230121 91177308-0d34-0410-b5e6-96231b3b80d8
the one in the current compiler invocation. If they differ reject the PCH.
This protects against the badness occurring from getting modules loaded from different module caches (see crashes).
rdar://19889860
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229909 91177308-0d34-0410-b5e6-96231b3b80d8
When mangling the module map path into a .pcm file name, also mangle the
IsSystem bit, which can also depend on the header search paths. For
example, the user may change from -I to -isystem. This can affect
diagnostics in the importing TU.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228966 91177308-0d34-0410-b5e6-96231b3b80d8
context as anonymous for merging purposes. They can't be found by their names,
so we merge them based on their position within the surrounding context.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228485 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes PR21587, what r221933 fixed for regular programs is now also
fixed for decls coming from PCH files.
Use another bit from the count/bits uint16_t for storing the "more than one
decl" bit. This reduces the number of bits for the count from 14 to 13.
The selector with the most overloads in Cocoa.h has ~55 overloads, so 13 bits
should still be plenty. Since this changes the meaning of a serialized bit
pattern, also increase clang::serialization::VERSION_MAJOR.
Storing the "more than one decl" state of only the first overload isn't quite
correct, but Sema::AreMultipleMethodsInGlobalPool() currently only looks at
the state of the first overload so it's good enough for now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224892 91177308-0d34-0410-b5e6-96231b3b80d8
Remove ObjCMethodList::Count, instead store a "has more than one decl" bit in
the low bit of the ObjCMethodDecl pointer, using a PointerIntPair.
Most of this patch is replacing ".Method" with ".getMethod()".
No intended behavior change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224876 91177308-0d34-0410-b5e6-96231b3b80d8
components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224055 91177308-0d34-0410-b5e6-96231b3b80d8
the root of the module and use paths relative to that directory wherever
possible. This is a step towards allowing explicit modules to be relocated
without being rebuilt, which is important for some kinds of distributed builds,
for good paths in diagnostics, and for appropriate .d output.
This is a recommit of r223443, reverted in r223465; when joining together
imported file paths, we now use the system's separator rather than always
using '/'. This avoids path mismatches between the original module build and
the module user on Windows (at least, in some cases). A more comprehensive
fix will follow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223539 91177308-0d34-0410-b5e6-96231b3b80d8
the root of the module and use paths relative to that directory wherever
possible. This is a step towards allowing explicit modules to be relocated
without being rebuilt, which is important for some kinds of distributed builds,
for good paths in diagnostics, and for appropriate .d output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223443 91177308-0d34-0410-b5e6-96231b3b80d8
rather than trying to extract this information from the FileEntry after the
fact.
This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223095 91177308-0d34-0410-b5e6-96231b3b80d8
For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>);
In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>);
Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info.
Differential Revision: http://reviews.llvm.org/D4002
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221663 91177308-0d34-0410-b5e6-96231b3b80d8
Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221558 91177308-0d34-0410-b5e6-96231b3b80d8
Since the order of the IDs in the AST file (e.g. DeclIDs, SelectorIDs)
is not stable, it is not safe to load an AST file that depends on
another AST file that has been rebuilt since the importer was built,
even if "nothing changed". We previously used size and modtime to check
this, but I've seen cases where a module rebuilt quickly enough to foil
this check and caused very hard to debug build errors.
To save cycles when we're loading the AST, we just generate a random
nonce value and check that it hasn't changed when we load an imported
module, rather than actually hash the whole file.
This is slightly complicated by the fact that we need to verify the
signature inside addModule, since we might otherwise consider that a
mdoule is "OutOfDate" when really it is the importer that is out of
date. I didn't see any regressions in module load time after this
change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220493 91177308-0d34-0410-b5e6-96231b3b80d8
This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220448 91177308-0d34-0410-b5e6-96231b3b80d8
This is a better fix for 'duplicate key' problems in module continuous
range maps (vs what I added in r215810) by not adding any mappings at
all when there are no local entities. Now it also covers selectors,
which were not always being bumped because the record SELECTOR_OFFSET is
not always emitted. I'll back out most of r215810 in a future commit,
since it should no longer be needed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220207 91177308-0d34-0410-b5e6-96231b3b80d8
Plumb through the full QualType of the TemplateArgument::Declaration, as
it's insufficient to only know whether the type is a reference or
pointer (that was necessary for mangling, but insufficient for debug
info). This shouldn't increase the size of TemplateArgument as
TemplateArgument::Integer is still longer by another 32 bits.
Several bits of code were testing that the reference-ness of the
parameters matched, but this seemed to be insufficient (various other
features of the type could've mismatched and wouldn't've been caught)
and unnecessary, at least insofar as removing those tests didn't cause
anything to fail.
(Richard - perchaps you can hypothesize why any of these checks might
need to test reference-ness of the parameters (& explain why
reference-ness is part of the mangling - I would've figured that for the
reference-ness to be different, a prior template argument would have to
be different). I'd be happy to add them in/beef them up and add test
cases if there's a reason for them)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219900 91177308-0d34-0410-b5e6-96231b3b80d8
We build a NestedNameSpecifier that records the CXXRecordDecl in which
__super appeared. Name lookup is performed in all base classes of the
recorded CXXRecordDecl. Use of __super is allowed only inside class and
member function scope.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218484 91177308-0d34-0410-b5e6-96231b3b80d8
We were passing < to std::unique, but it expects ==. Since the input is
sorted, we were always trimming it to one entry.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217402 91177308-0d34-0410-b5e6-96231b3b80d8
The warning warns on TypedefNameDecls -- typedefs and C++11 using aliases --
that are !isReferenced(). Since the isReferenced() bit on TypedefNameDecls
wasn't used for anything before this warning it wasn't always set correctly,
so this patch also adds a few missing MarkAnyDeclReferenced() calls in
various places for TypedefNameDecls.
This is made a bit complicated due to local typedefs possibly being used only
after their local scope has closed. Consider:
template <class T>
void template_fun(T t) {
typename T::Foo s3foo; // YYY
(void)s3foo;
}
void template_fun_user() {
struct Local {
typedef int Foo; // XXX
} p;
template_fun(p);
}
Here the typedef in XXX is only used at end-of-translation unit, when YYY in
template_fun() gets instantiated. To handle this, typedefs that are unused when
their scope exits are added to a set of potentially unused typedefs, and that
set gets checked at end-of-TU. Typedefs that are still unused at that point then
get warned on. There's also serialization code for this set, so that the
warning works with precompiled headers and modules. For modules, the warning
is emitted when the module is built, for precompiled headers each time the
header gets used.
Finally, consider a function using C++14 auto return types to return a local
type defined in a header:
auto f() {
struct S { typedef int a; };
return S();
}
Here, the typedef escapes its local scope and could be used by only some
translation units including the header. To not warn on this, add a
RecursiveASTVisitor that marks all delcs on local types returned from auto
functions as referenced. (Except if it's a function with internal linkage, or
the decls are private and the local type has no friends -- in these cases, it
_is_ safe to warn.)
Several of the included testcases (most of the interesting ones) were provided
by Richard Smith.
(gcc's spelling -Wunused-local-typedefs is supported as an alias for this
warning.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217298 91177308-0d34-0410-b5e6-96231b3b80d8
tables that correspond to ContinuousRangeMaps, since the keys to those
maps need to be unique, or we may map to the wrong offset.
This fixes a crash + malformed AST file seen when loading some modules
that import Cocoa on Darwin, which is a module with no contents except
imports of other modules. Unfortunately I have not been able to find a
reduced test case that reproduces this problem.
Also add an assert that we aren't mapping one key to multiple values
in CRM. We ought to be able to say there are no duplicate keys at all,
but there are a bunch of 0 -> 0 mappings that are showing up, probably
coming from the source location table.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215810 91177308-0d34-0410-b5e6-96231b3b80d8
definitions (because some other declaration declares a special member that
isn't present in the canonical definition), we need to search *all* of them; we
can't just stop when we find the requested name in any of the definitions,
because that can fail to find things (and in particular, it can fail to find
the member of the canonical declaration and return a bogus ODR failure).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215612 91177308-0d34-0410-b5e6-96231b3b80d8
redefinitions of that namespace have already been loaded. When writing out the
names in a namespace, if we see a name that is locally declared and had
imported declarations merged on top of it, export the local declaration as the
lookup result, because it will be the most recent declaration of that entity in
the redeclaration chain of an importer of the module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215518 91177308-0d34-0410-b5e6-96231b3b80d8
We already verified the primary module map file (either the one that
defines the top-level module, or the one that allows inferring it if it
is an inferred framework module). Now we also verify any other module
map files that define submodules, such as when there is a
module.private.modulemap file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215455 91177308-0d34-0410-b5e6-96231b3b80d8
class Module. It's almost always going to be the same as
getContainingModule() for top-level modules, so just add a map to cover
the remaining cases. This lets us do less bookkeeping to keep the
ModuleMap fields up to date.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215268 91177308-0d34-0410-b5e6-96231b3b80d8
also emit the updated 'operator delete' looked up for that destructor. Switch
from UpdateDecl to an actual update record when this happens due to implicitly
defining a special member function and unify this code path and the one for
instantiating a function definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215132 91177308-0d34-0410-b5e6-96231b3b80d8
intent when we added remark support, but was never implemented in the general
case, because the first -R flags didn't need it. (-Rpass= had special handling
to accomodate its argument.)
-Rno-foo, -Reverything, and -Rno-everything can be used to turn off a remark,
or to turn on or off all remarks. Per discussion on cfe-commits, -Weverything
does not affect remarks, and -Reverything does not affect warnings or errors.
The only "real" -R flag we have right now is -Rmodule-build; that flag is
effectively renamed from -Wmodule-build to -Rmodule-build by this change.
-Wpass and -Wno-pass (and their friends) are also renamed to -Rpass and
-Rno-pass by this change; it's not completely clear whether we intended to have
a -Rpass (with no =pattern), but that is unchanged by this commit, other than
the flag name. The default pattern is effectively one which matches no passes.
In future, we may want to make the default pattern be .*, so that -Reverything
works for -Rpass properly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215046 91177308-0d34-0410-b5e6-96231b3b80d8
* Add abbreviation for CXXMethodDecl and for FunctionProtoType. These come up
a *lot* in C++ modules.
* Allow typedef declarations to use the abbreviation if they're class members,
or if they're used.
In passing, add more record name records for Clang AST node kinds.
The downside is that we had already used up our allotment of 12 abbreviations,
so this pushes us to an extra bit on each record to support the extra abbrev
kinds, which increases file size by ~1%. This patch *barely* pays for that
through the other improvements, but we've got room for another 18 abbrevs,
so we should be able to make it much more profitable with future changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214024 91177308-0d34-0410-b5e6-96231b3b80d8
* Track override set across module load and save
* Track originating module to allow proper re-export of #undef
* Make override set properly transitive when it picks up a #undef
This fixes nearly all of the remaining macro issues with self-host.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213922 91177308-0d34-0410-b5e6-96231b3b80d8
thorough tests.
Original commit message:
[modules] Fix macro hiding bug exposed if:
* A submodule of module A is imported into module B
* Another submodule of module A that is not imported into B exports a macro
* Some submodule of module B also exports a definition of the macro, and
happens to be the first submodule of B that imports module A.
In this case, we would incorrectly determine that A's macro redefines B's
macro, and so we don't need to re-export B's macro at all.
This happens with the 'assert' macro in an LLVM self-host. =(
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213416 91177308-0d34-0410-b5e6-96231b3b80d8
This is breaking the system modules on Darwin, because something that
was defined and re-exported no longer is. Might be this patch, or might
just be a really poor interaction with an existing visibility bug.
This reverts commit r213348.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213395 91177308-0d34-0410-b5e6-96231b3b80d8
* A submodule of module A is imported into module B
* Another submodule of module A that is not imported into B exports a macro
* Some submodule of module B also exports a definition of the macro, and
happens to be the first submodule of B that imports module A.
In this case, we would incorrectly determine that A's macro redefines B's
macro, and so we don't need to re-export B's macro at all.
This happens with the 'assert' macro in an LLVM self-host. =(
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213348 91177308-0d34-0410-b5e6-96231b3b80d8
This begins to address cognitive dissonance caused by treating the Note
diagnostic level as a severity in the diagnostic engine.
No change in functionality.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210758 91177308-0d34-0410-b5e6-96231b3b80d8
Diagnostic mappings are used to calculate the final severity of diagnostic
instances.
Detangle the implementation to reflect the terminology used in documentation
and bindings.
No change in functionality.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210518 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements support for selectively disabling optimizations on a
range of function definitions through a pragma. The implementation is that
all function definitions in the range are decorated with attribute
'optnone'.
#pragma clang optimize off
// All function definitions in here are decorated with 'optnone'.
#pragma clang optimize on
// Compilation resumes as normal.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209510 91177308-0d34-0410-b5e6-96231b3b80d8
instantiated in another module, and the instantiation uses a partial
specialization, include the partial specialization and its template arguments
in the update record. We'll need them if someone imports the second module and
tries to instantiate a member of the template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209472 91177308-0d34-0410-b5e6-96231b3b80d8
ensure that querying the first declaration for its most recent declaration
checks for redeclarations from the imported module.
This works as follows:
* The 'most recent' pointer on a canonical declaration grows a pointer to the
external AST source and a generation number (space- and time-optimized for
the case where there is no external source).
* Each time the 'most recent' pointer is queried, if it has an external source,
we check whether it's up to date, and update it if not.
* The ancillary data stored on the canonical declaration is allocated lazily
to avoid filling it in for declarations that end up being non-canonical.
We'll still perform a redundant (ASTContext) allocation if someone asks for
the most recent declaration from a decl before setPreviousDecl is called,
but such cases are probably all bugs, and are now easy to find.
Some finessing is still in order here -- in particular, we use a very general
mechanism for handling the DefinitionData pointer on CXXRecordData, and a more
targeted approach would be more compact.
Also, the MayHaveOutOfDateDef mechanism should now be expunged, since it was
addressing only a corner of the full problem space here. That's not covered
by this patch.
Early performance benchmarks show that this makes no measurable difference to
Clang performance without modules enabled (and fixes a major correctness issue
with modules enabled). I'll revert if a full performance comparison shows any
problems.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209046 91177308-0d34-0410-b5e6-96231b3b80d8
This paves the way to making OnDiskHashTable work with hashes that are
not 32 bits wide and to making OnDiskHashTable work very large hash
tables. The LLVM change to use these types is upcoming.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206640 91177308-0d34-0410-b5e6-96231b3b80d8
To differentiate between two modules with the same name, we will
consider the path the module map file that they are defined by* part of
the ‘key’ for looking up the precompiled module (pcm file).
Specifically, this patch renames the precompiled module (pcm) files from
cache-path/<module hash>/Foo.pcm
to
cache-path/<module hash>/Foo-<hash of module map path>.pcm
In addition, I’ve taught the ASTReader to re-resolve the names of
imported modules during module loading so that if the header search
context changes between when a module was originally built and when it
is loaded we can rebuild it if necessary. For example, if module A
imports module B
first time:
clang -I /path/to/A -I /path/to/B ...
second time:
clang -I /path/to/A -I /different/path/to/B ...
will now rebuild A as expected.
* in the case of inferred modules, we use the module map file that
allowed the inference, not the __inferred_module.map file, since the
inferred file path is the same for every inferred module.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206201 91177308-0d34-0410-b5e6-96231b3b80d8
Committed this by accident before it was done last time.
Original message:
Rather than rolling our own functions to write little endian data
to an ostream, we can use the support in llvm's EndianStream.h.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205061 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than rolling our own functions to write little endian data to
an ostream, we can use the support in llvm's EndianStream.h.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205044 91177308-0d34-0410-b5e6-96231b3b80d8
an out-of-date external decls list). This happens if we declare some names,
force the lookup table for the decl context to be built, import a module that
adds more decls for the name, then write out our module without looking up the
name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204694 91177308-0d34-0410-b5e6-96231b3b80d8
specialization from a module. (This can also happen for function template
specializations in PCHs if they're instantiated eagerly, because they're
constexpr or have a deduced return type.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204547 91177308-0d34-0410-b5e6-96231b3b80d8
at which that PCH imported each visible submodule of the module. Such locations
are needed when synthesizing macro directives resulting from the import.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204417 91177308-0d34-0410-b5e6-96231b3b80d8
block as decl and type emission. This allows decl updates include statements
and expressions. No functionality change (but the generated PCM files are
incompatible with earlier versions of Clang).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204385 91177308-0d34-0410-b5e6-96231b3b80d8
When building an AST file, we don't want to output HeaderFileInfo
structures for files that are not actually used as headers in the
current context. This can lead to assuming that unrelated files have
include counts of 0, defeating multiple-include prevention.
This is accomplished by adding an IsValid bit to the HFI.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203813 91177308-0d34-0410-b5e6-96231b3b80d8
Add module dependencies to the dependency files created by -MD/-MMD/etc.
by attaching an ASTReaderListener that will call into the dependency
file generator when a module input file is seen in the serialized AST.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203208 91177308-0d34-0410-b5e6-96231b3b80d8
submodule macro overriding within the same top-level module (necessary for the
testcase to be remotely reasonable). Incidentally reduces the number of libc++
testsuite regressions with modules enabled from 7 to 6.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203063 91177308-0d34-0410-b5e6-96231b3b80d8
This is used to avoid conflicts with user modules with the same name from different workspaces.
rdar://16042513
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202683 91177308-0d34-0410-b5e6-96231b3b80d8
it, importers of B should not see the macro. This is complicated by the fact
that A's macro could also be visible through a different path. The rules (as
hashed out on cfe-commits) are included as a documentation update in this
change.
With this, the number of regressions in libc++'s testsuite when modules are
enabled drops from 47 to 7. Those remaining 7 are also macro-related, and are
due to remaining bugs in this change (in particular, the handling of submodules
is imperfect).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202560 91177308-0d34-0410-b5e6-96231b3b80d8
Add the ImportDecl to the set of interesting delcarations that are
deserialized eagerly when an AST file is loaded (rather than lazily like
most decls). This is required to get auto linking to work when there is
no explicit import in the main file. Also resolve a FIXME to rename
'ExternalDefinitions', since that is only one of the things that need eager
deserialization. The new name is 'EagerlyDeserializedDecls'. The corresponding
AST bitcode is also renamed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200505 91177308-0d34-0410-b5e6-96231b3b80d8
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200082 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199686 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the C++ ABI depend entirely on the target: MS ABI for -win32 triples,
Itanium otherwise. It's no longer possible to do weird combinations.
To be able to run a test with a specific ABI without constraining it to a
specific triple, new substitutions are added to lit: %itanium_abi_triple and
%ms_abi_triple can be used to get the current target triple adjusted to the
desired ABI. For example, if the test suite is running with the i686-pc-win32
target, %itanium_abi_triple will expand to i686-pc-mingw32.
Differential Revision: http://llvm-reviews.chandlerc.com/D2545
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199250 91177308-0d34-0410-b5e6-96231b3b80d8
Remove UnaryTypeTraitExpr and switch all remaining type trait related handling
over to TypeTraitExpr.
The UTT/BTT/TT enum prefix and evaluation code is retained pending further
cleanup.
This is part of the ongoing work to unify type traits following the removal of
BinaryTypeTraitExpr in r197273.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198271 91177308-0d34-0410-b5e6-96231b3b80d8
There's nothing special about type traits accepting two arguments.
This commit eliminates BinaryTypeTraitExpr and switches all related handling
over to TypeTraitExpr.
Also fixes a CodeGen failure with variadic type traits appearing in a
non-constant expression.
The BTT/TT prefix and evaluation code is retained as-is for now but will soon
be further cleaned up.
This is part of the ongoing work to unify type traits.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197273 91177308-0d34-0410-b5e6-96231b3b80d8
more than one such initializer in a union, make mem-initializers override
default initializers for other union members, handle anonymous unions with
anonymous struct members better. Fix a couple of semi-related bugs exposed by
the tests for same.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196892 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In general, this type node can be used to represent any type adjustment
that occurs implicitly without losing type sugar. The immediate use of
this is to adjust the calling conventions of member function pointer
types without breaking template instantiation.
Fixes PR17996.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D2332
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196451 91177308-0d34-0410-b5e6-96231b3b80d8
There are about 30 removed in this patch, generated by a new FixIt I haven't
got round to submitting yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@195814 91177308-0d34-0410-b5e6-96231b3b80d8
would be deleted are still declared, but are ignored by overload resolution.
Also, don't delete such members if a subobject has no corresponding move
operation and a non-trivial copy. This causes us to implicitly declare move
operations in more cases, but risks move-assigning virtual bases multiple
times in some circumstances (a warning for that is to follow).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193969 91177308-0d34-0410-b5e6-96231b3b80d8
requires ! feature
The purpose of this is to allow (for instance) the module map for /usr/include
to exclude <tgmath.h> and <complex.h> when building in C++ (these headers are
instead provided by the C++ standard library in this case, and the glibc C
<tgmath.h> header would otherwise try to include <complex.h>, resulting in a
module cycle).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193549 91177308-0d34-0410-b5e6-96231b3b80d8
A prior commit of this patch was reverted because it was within the blamelist's purview of a failing test. The failure of that test has been addressed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091546.html. Therefore I am recommitting this patch (all tests pass on windows, except for the usual modules & index suspects that never pass on my box).
Some background: Both Doug and Richard had asked me in Chicago to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.
In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier.
No change in functionality.
This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested):
http://llvm-reviews.chandlerc.com/D1856
Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193246 91177308-0d34-0410-b5e6-96231b3b80d8
They were causing CodeGenCXX/mangle-exprs.cpp to fail.
Revert "Remove the circular reference to LambdaExpr in CXXRecordDecl."
Revert "Again: Teach TreeTransform and family how to transform generic lambdas nested within templates and themselves."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193226 91177308-0d34-0410-b5e6-96231b3b80d8
Both Doug and Richard had asked me to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.
No change in functionality.
In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier.
This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested):
http://llvm-reviews.chandlerc.com/D1856
Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193223 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, the following features are not included in this commit:
- any sort of capturing within generic lambdas
- generic lambdas within template functions and nested
within other generic lambdas
- conversion operator for captureless lambdas
- ensuring all visitors are generic lambda aware
(Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit)
As an example of what compiles through this commit:
template <class F1, class F2>
struct overload : F1, F2 {
using F1::operator();
using F2::operator();
overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }
};
auto Recursive = [](auto Self, auto h, auto ... rest) {
return 1 + Self(Self, rest...);
};
auto Base = [](auto Self, auto h) {
return 1;
};
overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
int num_params = O(O, 5, 3, "abc", 3.14, 'a');
Please see attached tests for more examples.
This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics).
Some implementation notes:
- Add a new Declarator context => LambdaExprParameterContext to
clang::Declarator to allow the use of 'auto' in declaring generic
lambda parameters
- Add various helpers to CXXRecordDecl to facilitate identifying
and querying a closure class
- LambdaScopeInfo (which maintains the current lambda's Sema state)
was augmented to house the current depth of the template being
parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately
generate a template-parameter-type when 'auto' is parsed in a generic
lambda parameter context. (i.e we do NOT use AutoType deduced to
a template parameter type - Richard seemed ok with this approach).
We encode that this template type was generated from an auto by simply
adding $auto to the name which can be used for better diagnostics if needed.
- SemaLambda.h was added to hold some common lambda utility
functions (this file is likely to grow ...)
- Teach Sema::ActOnStartOfFunctionDef to check whether it
is being called to instantiate a generic lambda's call
operator, and if so, push an appropriately prepared
LambdaScopeInfo object on the stack.
- various tests were added - but much more will be needed.
There is obviously more work to be done, and both Richard (weakly) and Doug (strongly)
have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData
in a future patch which is forthcoming.
A greatful thanks to all reviewers including Eli Friedman, James Dennett,
and especially the two gracious wizards (Richard Smith and Doug Gregor)
who spent hours providing feedback (in person in Chicago and on the mailing lists).
And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified!
Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191453 91177308-0d34-0410-b5e6-96231b3b80d8
Review: http://llvm-reviews.chandlerc.com/D1546.
I have picked up this patch form Lawrence
(http://llvm-reviews.chandlerc.com/D1063) and did a few changes.
From the original change description (updated as appropriate):
This patch adds a check that ensures that modules only use modules they
have so declared. To this end, it adds a statement on intended module
use to the module.map grammar:
use module-id
A module can then only use headers from other modules if it 'uses' them.
This enforcement is off by default, but may be turned on with the new
option -fmodules-decluse.
When enforcing the module semantics, we also need to consider a source
file part of a module. This is achieved with a compiler option
-fmodule-name=<module-id>.
The compiler at present only applies restrictions to the module directly
being built.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191283 91177308-0d34-0410-b5e6-96231b3b80d8
When an AST file is built based on another AST file, it can use a decl from
the fist file, and therefore mark the "isUsed" bit. We need to note this in
the AST file so that the bit is set correctly when the second AST file is
loaded.
This patch introduces the distinction between setIsUsed() and markUsed() so
that we don't call into the ASTMutationListener callback when it wouldn't
be appropriate.
Fixes PR16635.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190016 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, the following features are not included in this commit:
- any sort of capturing within generic lambdas
- nested lambdas
- conversion operator for captureless lambdas
- ensuring all visitors are generic lambda aware
As an example of what compiles:
template <class F1, class F2>
struct overload : F1, F2 {
using F1::operator();
using F2::operator();
overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }
};
auto Recursive = [](auto Self, auto h, auto ... rest) {
return 1 + Self(Self, rest...);
};
auto Base = [](auto Self, auto h) {
return 1;
};
overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
int num_params = O(O, 5, 3, "abc", 3.14, 'a');
Please see attached tests for more examples.
Some implementation notes:
- Add a new Declarator context => LambdaExprParameterContext to
clang::Declarator to allow the use of 'auto' in declaring generic
lambda parameters
- Augment AutoType's constructor (similar to how variadic
template-type-parameters ala TemplateTypeParmDecl are implemented) to
accept an IsParameterPack to encode a generic lambda parameter pack.
- Add various helpers to CXXRecordDecl to facilitate identifying
and querying a closure class
- LambdaScopeInfo (which maintains the current lambda's Sema state)
was augmented to house the current depth of the template being
parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
so that Sema::ActOnLambdaAutoParameter may use it to create the
appropriate list of corresponding TemplateTypeParmDecl for each
auto parameter identified within the generic lambda (also stored
within the current LambdaScopeInfo). Additionally,
a TemplateParameterList data-member was added to hold the invented
TemplateParameterList AST node which will be much more useful
once we teach TreeTransform how to transform generic lambdas.
- SemaLambda.h was added to hold some common lambda utility
functions (this file is likely to grow ...)
- Teach Sema::ActOnStartOfFunctionDef to check whether it
is being called to instantiate a generic lambda's call
operator, and if so, push an appropriately prepared
LambdaScopeInfo object on the stack.
- Teach Sema::ActOnStartOfLambdaDefinition to set the
return type of a lambda without a trailing return type
to 'auto' in C++1y mode, and teach the return type
deduction machinery in SemaStmt.cpp to process either
C++11 and C++14 lambda's correctly depending on the flag.
- various tests were added - but much more will be needed.
A greatful thanks to all reviewers including Eli Friedman,
James Dennett and the ever illuminating Richard Smith. And
yet I am certain that I have allowed unidentified bugs to creep in;
bugs, that I will do my best to slay, once identified!
Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188977 91177308-0d34-0410-b5e6-96231b3b80d8
The problem was that an enum without closing semicolon could be associated as a forward enum
in an erroneous declaration, leading to the identifier being associated with the enum decl but
without a declaration actually referencing it.
This resulted in not having it serialized before serializing the identifier that is associated with.
Also prevent the ASTUnit from querying the serialized DeclID for an invalid top-level decl; it may not
have been serialized.
rdar://14539667
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@187914 91177308-0d34-0410-b5e6-96231b3b80d8
The headers in the compiler's own resource include directory are
system headers, which means we don't stat() them eagerly when loading
a module. Use module.map as a proxy for these headers and the compiler
itself. Fixes <rdar://problem/13856838>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186870 91177308-0d34-0410-b5e6-96231b3b80d8
declaration. This PCH a little lazier, and breaks a deserialization cycle that
causes crashes with modules enabled.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184904 91177308-0d34-0410-b5e6-96231b3b80d8
The goal of this sugar node is to be able to look at an arbitrary
FunctionType and tell if any of the parameters were decayed from an
array or function type. Ultimately this is necessary to implement
Microsoft's C++ name mangling scheme, which mangles decayed arrays
differently from normal pointers.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1014
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184763 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an expression goes from an InitListExpr with a
flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr
containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr).
This more detailed representation has several advantages, the most important of
which is that the new MaterializeTemporaryExpr allows us to directly model
lifetime extension of the underlying temporary array. Using that, this patch
*drastically* simplifies the IR generation of this construct, provides IR
generation support for nested global initializer_list objects, fixes several
bugs where the destructors for the underlying array would accidentally not get
invoked, and provides constant expression evaluation support for
std::initializer_list objects.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183872 91177308-0d34-0410-b5e6-96231b3b80d8
a FieldDecl from it, and propagate both into the closure type and the
LambdaExpr.
You can't do much useful with them yet -- you can't use them within the body
of the lambda, because we don't have a representation for "the this of the
lambda, not the this of the enclosing context". We also don't have support or a
representation for a nested capture of an init-capture yet, which was intended
to work despite not being allowed by the current standard wording.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181985 91177308-0d34-0410-b5e6-96231b3b80d8
we loaded from PCH, if we're building another PCH, create an update record to
patch the return type of the earlier declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181659 91177308-0d34-0410-b5e6-96231b3b80d8
After r180934 we may initiate module map parsing for modules not related to the module what we are building,
make sure we ignore the header file info of headers from such modules.
First part of rdar://13840148
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181489 91177308-0d34-0410-b5e6-96231b3b80d8
the actual parser and support arbitrary id-expressions.
We're actually basically set up to do arbitrary expressions here
if we wanted to.
Assembly operands permit things like A::x to be written regardless
of language mode, which forces us to embellish the evaluation
context logic somewhat. The logic here under template instantiation
is incorrect; we need to preserve the fact that an expression was
unevaluated. Of course, template instantiation in general is fishy
here because we have no way of delaying semantic analysis in the
MC parser. It's all just fishy.
I've also fixed the serialization of MS asm statements.
This commit depends on an LLVM commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180976 91177308-0d34-0410-b5e6-96231b3b80d8
are now two distinct canonical 'AutoType's: one is the undeduced 'auto'
placeholder type, and the other is a deduced-but-dependent type. All
deduced-to-a-non-dependent-type cases are still non-canonical.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180789 91177308-0d34-0410-b5e6-96231b3b80d8
The preprocessing record becomes important when modules are enabled, since it is used to calculate the
module cache hash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180635 91177308-0d34-0410-b5e6-96231b3b80d8
-Make sure that a deserialized external decl gets added to the TU scope.
-When associating an identifier with a set of decls, use the most recent local ones,
if they exist, otherwise associating decls from modules (that came after a local one)
will lead to an incomplete reconstructed re-declaration chain.
rdar://13712705
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180634 91177308-0d34-0410-b5e6-96231b3b80d8
This is done by extending ObjCMethodList (which is only used by the global method pool) to have 2 extra bits of information.
We will later take advantage of this info in global method pool for the overridden methods calculation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179652 91177308-0d34-0410-b5e6-96231b3b80d8
don't serialize a lookup map for the translation unit outside C++ mode, so we
can't tell when lookup within the TU needs to look within modules. Only apply
the fix outside C++ mode, and only to the translation unit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178706 91177308-0d34-0410-b5e6-96231b3b80d8
imports the module.
Getting diagnostic sections from modules properly working is a fixme.
rdar://13516663
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178151 91177308-0d34-0410-b5e6-96231b3b80d8
For each macro directive (define, undefine, visibility) have a separate object that gets chained
to the macro directive history. This has several benefits:
-No need to mutate a MacroDirective when there is a undefine/visibility directive. Stuff like
PPMutationListener become unnecessary.
-No need to keep extra source locations for the undef/visibility locations for the define directive object
(which is the majority of the directives)
-Much easier to hide/unhide a section in the macro directive history.
-Easier to track the effects of the directives across different submodules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178037 91177308-0d34-0410-b5e6-96231b3b80d8
-Serialize the macro directives history into its own section
-Get rid of the macro updates section
-When de/serializing an identifier from a module, associate only one macro per
submodule that defined+exported it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177761 91177308-0d34-0410-b5e6-96231b3b80d8
Configuration macros are macros that are intended to alter how a
module works, such that we need to build different module variants
for different values of these macros. A module can declare its
configuration macros, in which case we will complain if the definition
of a configation macro on the command line (or lack thereof) differs
from the current preprocessor state at the point where the module is
imported. This should eliminate some surprises when enabling modules,
because "#define CONFIG_MACRO ..." followed by "#include
<module/header.h>" would silently ignore the CONFIG_MACRO setting. At
least it will no longer be silent about it.
Configuration macros are eventually intended to help reduce the number
of module variants that need to be built. When the list of
configuration macros for a module is exhaustive, we only need to
consider the settings for those macros when building/finding the
module, which can help isolate modules for various project-specific -D
flags that should never affect how modules are build (but currently do).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177466 91177308-0d34-0410-b5e6-96231b3b80d8
The global module index was querying the file manager for each of the
module files it knows about at load time, to prune out any out-of-date
information. The file manager would then cache the results of the
stat() falls used to find that module file.
Later, the same translation unit could end up trying to import one of the
module files that had previously been ignored by the module cache, but
after some other Clang instance rebuilt the module file to bring it
up-to-date. The stale stat() results in the file manager would
trigger a second rebuild of the already-up-to-date module, causing
failures down the line.
The global module index now lazily resolves its module file references
to actual AST reader module files only after the module file has been
loaded, eliminating the stat-caching race. Moreover, the AST reader
can communicate to its caller that a module file is missing (rather
than simply being out-of-date), allowing us to simplify the
module-loading logic and allowing the compiler to recover if a
dependent module file ends up getting deleted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177367 91177308-0d34-0410-b5e6-96231b3b80d8
These will be available in the current translation unit anyway, for
modules they only waste space and deserialization time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177197 91177308-0d34-0410-b5e6-96231b3b80d8
When we're building a precompiled header or module against an SDK on
Darwin, there will be a file SDKSettings.plist in the sysroot. Since
stat()'ing every system header on which a module or PCH file depends
is performance suicide, we instead stat() just SDKSettings.plist. This
hack works well on Darwin; it's unclear how we want to handle this on
other platforms. If there is a canonical file, we should use it; if
not, we either have to take the performance hit of stat()'ing system
headers repeatedly or roll the dice by not checking anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@177194 91177308-0d34-0410-b5e6-96231b3b80d8
In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers
in order to associate the FileEntries with their modules and support implicit
module import.
Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about
the module that a header belongs to, and associate it with its module only when
there is a request for loading the header info for a particular file.
Part of rdar://13391765
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176976 91177308-0d34-0410-b5e6-96231b3b80d8
This allows resolving top-header filenames of modules to FileEntries when
we need them, not eagerly.
Note that that this breaks ABI for libclang functions
clang_Module_getTopLevelHeader / clang_Module_getNumTopLevelHeaders
but this is fine because they are experimental and not widely used yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176975 91177308-0d34-0410-b5e6-96231b3b80d8
Stat'ing all the headers from the PCH to make sure they are up-to-date takes significant time.
In a particular source file (whose PCH file included Cocoa.h) from total -fsyntax-only time
12% was just stat calls. Change pre-validation to only check non-system headers.
There are some notable disadvantages:
-If a system header, that is not include-guarded, changes after the PCH was created, we will not
find it in the header info table and we will #import it, effectively #importing it twice, thus
we will emit some error due to a multiple definition and after that the "header was modified" error will likely
be emitted, for example something like:
NSDictionary.h:12:1: error: duplicate interface definition for class 'NSDictionary'
@interface NSDictionary : NSObject <NSCopying, NSMutableCopying, NSSecureCoding, NSFastEnumeration>
^
NSDictionary.h:12:12: note: previous definition is here
@interface NSDictionary : NSObject <NSCopying, NSMutableCopying, NSSecureCoding, NSFastEnumeration>
^
fatal error: file 'NSDictionary.h' has been modified since the precompiled header was built
Though we get the "header was modified" error, this is a bit confusing.
-Theoretically it is possible that such a system header will cause no errors but it will just cause an
unfortunate semantic change, though I find this rather unlikely.
The advantages:
-Reduces compilation time when using a huge PCH like the Cocoa ones
-System headers change very infrequent and when they do, users/build systems should be able to know that
re-building from scratch is needed.
Addresses rdar://13056262
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176567 91177308-0d34-0410-b5e6-96231b3b80d8
Previously the hash would be the filename portion of the path, which could be
different for a filename with different case or a symbolic link with a different
name completely.
This did not actually create any issue so far because by validating all headers
in the PCH we created uniqued FileEntries based on inodes, so an #include of
a symbolic link (refering to a file from the PCH) would end up with a FileEntry
with filename same as the one recorded in the PCH.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176566 91177308-0d34-0410-b5e6-96231b3b80d8
Add an ability to specify custom documentation block comment commands via a new
class CommentOptions. The intention is that this class will hold future
customizations for comment parsing, including defining documentation comments
with specific numbers of parameters, etc.
CommentOptions instance is a member of LangOptions.
CommentOptions is controlled by a new command-line parameter
-fcomment-block-commands=Foo,Bar,Baz.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175892 91177308-0d34-0410-b5e6-96231b3b80d8
for the data specific to a macro definition (e.g. what the tokens are), and
MacroDirective class which encapsulates the changes to the "macro namespace"
(e.g. the location where the macro name became active, the location where it was undefined, etc.)
(A MacroDirective always points to a MacroInfo object.)
Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but
splitting the concepts allows us to better model the effect of modules to the macro namespace
(also as a bonus it allows better modeling of push_macro/pop_macro #pragmas).
Modules can have their own macro history, separate from the local (current translation unit)
macro history; MacroDirectives will be used to model the macro history (changes to macro namespace).
For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created
to indicate that "FOO" became active at the import location. Module "A" itself will contain another
MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives
will point to the same MacroInfo object.
Introducing the separation of macro concepts is the first part towards better modeling of module macros.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175585 91177308-0d34-0410-b5e6-96231b3b80d8
This commit introduces a set of related changes to ensure that the
declaration that shows up in the identifier chain after deserializing
declarations with a given identifier is, in fact, the most recent
declaration. The primary change involves waiting until after we
deserialize and wire up redeclaration chains before updating the
identifier chains. There is a minor optimization in here to avoid
recursively deserializing names as part of looking to see whether
top-level declarations for a given name exist.
A related change that became suddenly more urgent is to property
record a merged declaration when an entity first declared in the
current translation unit is later deserialized from a module (that had
not been loaded at the time of the original declaration). Since we key
off the canonical declaration (which is parsed, not from an AST file)
for emitted redeclarations, we simply record this as a merged
declaration during AST writing and let the readers merge them.
Re-fixes <rdar://problem/13189985>, presumably for good this time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175447 91177308-0d34-0410-b5e6-96231b3b80d8
filter the elements before emitting them into a PCH. No user-visible
functionality change, except that PCH files may be smaller?
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174034 91177308-0d34-0410-b5e6-96231b3b80d8
- The only group where it makes sense for the "ExternC" bit is System, so this
simplifies having to have the extra isCXXAware (or ImplicitExternC, depending
on what code you talk to) bit caried around.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173859 91177308-0d34-0410-b5e6-96231b3b80d8
DeclContext. When the DeclContext is of a kind that can only be
defined once and never updated, we limit the search to the module file
that conatins the lookup table. Provides a 15% speedup in one
modules-heavy source file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173050 91177308-0d34-0410-b5e6-96231b3b80d8
Makes sure that a deserialized macro is only added to the preprocessor macro definitions only once.
Unfortunately I couldn't get a reduced test case.
rdar://13016031
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172843 91177308-0d34-0410-b5e6-96231b3b80d8
Chandler Carruth