| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
textually included into a file in the module.
llvm-svn: 235661
|
|
|
|
|
|
| |
not visible definition of the same template.
llvm-svn: 233430
|
|
|
|
| |
llvm-svn: 233425
|
|
|
|
|
|
|
|
| |
if the merged definition is visible, and perform lookups into all merged copies
of the definition (not just for special members) so that we can complete the
redecl chains for members of the class.
llvm-svn: 233420
|
|
|
|
| |
llvm-svn: 233407
|
|
|
|
|
|
| |
top of an existing imported-but-not-visible definition.
llvm-svn: 233345
|
|
|
|
|
|
| |
imported-but-not-visible definition.
llvm-svn: 233341
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 233327
|
|
|
|
|
|
|
| |
modules, and allow sub-modules of a module with a use-declaration to make use
of the nominated modules.
llvm-svn: 233323
|
|
|
|
|
|
|
|
| |
templates. Turns out all of this works correctly (so far). But it should
cover more code paths and will let me test some things that don't
actually work next.
llvm-svn: 233263
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 233261
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 233250
|
|
|
|
|
|
|
|
|
| |
This fixes my stress tests non-determinism so far. However, I've not
started playing with templates, friends, or terrible macros. I've found
at least two more seeming instabilities and am just waiting for a test
case to actually trigger them.
llvm-svn: 233162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 233115
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 232928
|
|
|
|
| |
llvm-svn: 232909
|
|
|
|
|
|
| |
which was reverted because it was causing LLDB test failures
llvm-svn: 232907
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 232870
|
|
|
|
|
|
|
|
|
| |
consumers of that module.
Previously, such a file would only be available if the module happened to
actually import something from that module.
llvm-svn: 232583
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
namespace to not merge properly.
We have an invariant here: after a declaration reads its canonical declaration,
it can assume the canonical declaration is fully merged. This invariant can be
violated if deserializing some declaration triggers the deserialization of a
later declaration, because that later declaration can in turn deserialize a
redeclaration of that first declaration before it is fully merged.
The anonymous namespace for a namespace gets stored with the first declaration
of that namespace, which may be before its parent namespace, so defer loading
it until after we've finished merging the surrounding namespace.
llvm-svn: 232455
|
|
|
|
|
|
|
|
|
|
|
| |
building its redecl chains, make sure we pull in the redeclarations of those
canonical declarations.
It's pretty difficult to reach a situation where we can find more canonical
declarations of an entity while building its redecl chains; I think the
provided testcase (4 modules and 7 declarations) cannot be reduced further.
llvm-svn: 232411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with a subset of the existing target CPU features or mismatched CPU
names.
While we can't check that the CPU name used to build the module will end
up being able to codegen correctly for the translation unit, we actually
check that the imported features are a subset of the existing features.
While here, rewrite the code to use std::set_difference and have it
diagnose all of the differences found.
Test case added which walks the set relationships and ensures we
diagnose all the right cases and accept the others.
No functional change for implicit modules here, just better diagnostics.
llvm-svn: 232248
|
|
|
|
| |
llvm-svn: 232159
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
headers even if they arrived when merging non-system modules.
The idea of this code is that we don't want to warn the user about
macros defined multiple times by their system headers with slightly
different definitions. We should have this behavior if either the
macro comes from a system module, or the definition within the module
comes from a system header. Previously, we would warn on ambiguous
macros being merged when they came from a users modules even though they
only showed up via system headers.
By surviving this we can handle common system header macro differences
like differing 'const' qualification of pointers due to some headers
predating 'const' being valid in C code, even when those systems headers
are pre-built into a system module.
Differential Revision: http://reviews.llvm.org/D8310
llvm-svn: 232149
|
|
|
|
|
|
|
|
|
|
| |
definition, be sure to update the definition data on all declarations, not just
the canonical one, since the pattern might not be in the list of pending
definitions (if it used to be canonical itself).
One-line fix by me; reduced testcase by Daniel Jasper!
llvm-svn: 231950
|
|
|
|
|
|
| |
while we're writing out the identifier table.
llvm-svn: 231890
|
|
|
|
|
|
|
|
|
| |
specification, update all prior declarations if the new one has an explicit
exception specification and the prior ones don't.
Patch by Vassil Vassilev! Some minor tweaking and test case by me.
llvm-svn: 231738
|
|
|
|
|
|
|
| |
move the operator delete updating into a separate update record so we can cope
with updating another module's destructor's operator delete.
llvm-svn: 231735
|
|
|
|
|
|
| |
private header within the same module.
llvm-svn: 231725
|
|
|
|
| |
llvm-svn: 231346
|
|
|
|
|
|
| |
Macro names that got undefined inside a module may not have their MacroInfo set.
llvm-svn: 231251
|
|
|
|
|
|
|
|
| |
ASTUnit::LoadFromASTFile.
rdar://19997358
llvm-svn: 231060
|
|
|
|
|
|
|
| |
a map keyed off the canonical declaration. Don't try to set it if we're loading
some non-canonical merged declaration.
llvm-svn: 230716
|
|
|
|
|
|
|
| |
accumulate the set of specializations rather than overwriting one list
with another.
llvm-svn: 230712
|
|
|
|
|
|
|
|
| |
one can give us more lookup results (due to implicit special members). Be sure
to complete the redecl chain for every kind of DeclContext before performing a
lookup into it, rather than only doing so for NamespaceDecls.
llvm-svn: 230558
|
|
|
|
|
|
|
|
| |
exported from multiple modules."
This reverts commits r230477 and r230478.
llvm-svn: 230526
|
|
|
|
|
|
| |
(re-) exported from multiple modules."", since I have reverted r230446.
llvm-svn: 230477
|
|
|
|
|
|
|
|
|
|
| |
multiple modules."
This reverts the revert from commit r230406.
The changes in r230445 and r230446 make the test pass on Windows now.
llvm-svn: 230448
|
|
|
|
|
|
|
|
|
|
| |
from multiple modules."
It crashes for targeting (i686|x86_64)-win32.
clang: clang/lib/AST/VTableBuilder.cpp:142: {anonymous}::FinalOverriders::OverriderInfo {anonymous}::FinalOverriders::getOverrider(const clang::CXXMethodDecl*, clang::CharUnits) const: Assertion `OverridersMap.count(std::make_pair(MD, BaseOffset)) && "Did not find overrider!"' failed.
llvm-svn: 230406
|
|
|
|
|
|
|
| |
Fixes multiple crashes where a non-canonical decl would be used as key
in a lookup.
llvm-svn: 230314
|
|
|
|
|
|
|
|
|
|
|
| |
This would cause frameworks to have spurious "redefinition" errors if
they had both a (legacy) "module.map" and a (new) "module.modulemap" file and we
happened to do a sub-directory search in that directory using a
non-framework include path (e.g. -Ifoo/ -Ffoo/). For migration
purposes it's very handy that the compiler will prefer the new spelling
of the filename and not look at the old one if it doesn't need to.
llvm-svn: 230308
|
|
|
|
|
|
|
| |
bug is not actually modules-specific, but it's a little tricky to tickle it
outside of modules builds, so submitting with the reduced testcase I have.
llvm-svn: 230303
|
|
|
|
|
|
|
| |
attempting to lazily deserialize its specializations; otherwise, there might be
pending specializations that we don't know about yet.
llvm-svn: 230301
|
|
|
|
|
|
|
| |
If this flag is set, we error out when a module build is required. This is
useful in environments where all required modules are passed via -fmodule-file.
llvm-svn: 230006
|
|
|
|
|
|
| |
a prebuilt form from a module, prefer the modular form, all else being equal.
llvm-svn: 229188
|
|
|
|
|
|
|
|
|
|
| |
entity, put the originally-canonical decl IDs in the right places in the redecl
chain rather than reordering them all to the start. If we don't ensure that the
redecl chain order is consistent with the topological module order, we can fail
to make a declaration visible if later declarations are in more IDNSs than
earlier ones (for instance, because the earlier decls are invisible friends).
llvm-svn: 228978
|
|
|
|
|
|
|
|
|
| |
already have, check whether the name from the module is actually newer than the
existing declaration. If it isn't, we might (say) replace a visible declaration
with an injected friend, and thus make it invisible (or lose a default argument
or an array bound).
llvm-svn: 228661
|
|
|
|
|
|
|
| |
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.
llvm-svn: 228485
|
|
|
|
|
|
| |
DeclContext::noload_lookup.
llvm-svn: 228475
|
|
|
|
|
|
|
|
|
| |
of that entity, ensure that the redeclaration chain is reordered properly on
reload. Otherwise, the result of name lookup for that entity may point to an
entity that is too old; if that's an injected friend name or the like, that
can result in the name not being found at all.
llvm-svn: 228371
|