invalidate lookup_iterators and lookup_results for some name within a
DeclContext if the lookup results for a *different* name change.
llvm-svn: 230121
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
This reapplies r230044 with a fixed configure+make build and updated
dependencies. Take 2.
llvm-svn: 230089
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
This reapplies r230044 with a fixed configure+make build and updated
dependencies.
llvm-svn: 230067
There are two issues here:
1) It's too late to rebuild at this point, because we won't go through
removeModules and when we try to reload the new .pcm we'll get the old
one instead. We might be able to call removeModules after an OutOfDate
here, but I'm not yet confident that it is always safe to do so.
2) In practice, this check fails spuriously when the umbrella header
appears to change because of a VFS change that means it maps to a
different copy of the same file. Because of this, we just skip the
check for now.
llvm-svn: 230064
This is a necessary prerequisite for debugging with modules.
The .pcm files become containers that hold the serialized AST which allows
us to store debug information in the module file that can be shared by all
object files that were built importing the module.
rdar://problem/19104245
llvm-svn: 230044
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
llvm-svn: 229909
The member gets invalidated as elements are added to the dense set. Directly
access the underlying pointer instead. Not sure how to create a test case for
this :-(. Maybe Richard can help.
llvm-svn: 229673
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
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.
llvm-svn: 228966
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
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
object. In such a case, use the TU's DC for merging global decls rather than
giving up when we find there is no TU scope.
Ultimately, we should probably avoid all loading of decls when preprocessing,
but there are other reasonable use cases for loading an AST file with no Sema
object for which this is the right thing.
llvm-svn: 228234
encountered any definition for the class; this happens when the definition is
added by an update record that is not yet loaded. In such a case, eagerly pick
the original parent of the member as the canonical definition of the class
rather than muddling through with the canonical declaration (the latter can
lead to us failing to merge properly later if the canonical definition turns
out to be some other declaration).
llvm-svn: 226977
record, and that class declaration is not the canonical definition of the
class, be sure to add the class to the list of classes that are consulted when
we look up a special member in the canonical definition.
llvm-svn: 226778
on top of a local declaration of the same entity, we still need to remember
that we loaded the first one or we may fail to merge the second one properly.
llvm-svn: 226765
load the definition data from the declaration itself. In that case, merge
properly; don't assume the prior definition is the same as our own.
llvm-svn: 226761
This just tweaks the fix from r224892 (which handled PCHs) to work with
modules, where we will serialize each method individually and hence the
hasMoreThanOneDecl bit needs to be updated as we add the methods.
llvm-svn: 225659
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.
llvm-svn: 224892
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.
llvm-svn: 224876
Bitfield RefersToEnclosingLocal of Stmt::DeclRefExprBitfields renamed to RefersToCapturedVariable to reflect latest changes introduced in commit 224323. Also renamed method Expr::refersToEnclosingLocal() to Expr::refersToCapturedVariable() and comments for constant arguments.
No functional changes.
llvm-svn: 224329
the simplest case, which is used when no chunk_size is specified in
the schedule(static) or no 'schedule' clause is specified - the
iteration space is divided by the library into chunks that are
approximately equal in size, and at most one chunk is distributed
to each thread. In this case, we do not need an outer loop in each
thread - each thread requests once which iterations range it should
handle (using __kmpc_for_static_init runtime call) and then runs the
inner loop on this range.
Differential Revision: http://reviews.llvm.org/D5865
llvm-svn: 224233
components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.
llvm-svn: 224055
module, use the path from the module map file in preference to the path from
the .pcm file when resolving relative paths in the .pcm file. This allows
diagnostics (and .d output) to give relative paths if the module was found via
a relative path.
llvm-svn: 223577
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.
llvm-svn: 223539
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.
llvm-svn: 223443
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.
llvm-svn: 223095
to be newer than we were expecting. That happens if .pcm's get moved between
file systems during a distributed build. (It's still not OK for them to actually
be different, though, so we still check the size and signature matches.)
llvm-svn: 222507
special member function.
No test yet: the only testcases we have for this issue are extremely complex.
Testcase will be added once I get a reasonable reduction.
llvm-svn: 222506
According to OpenMP standard, Section 2.12.6, atomic Construct, '#pragma omp atomic read' is allowed to be used only for expression statements of form 'v = x;', where x and v (as applicable) are both l-value expressions with scalar type. Patch adds checks for it.
llvm-svn: 222231
Richard Smith