| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
parsing then merged again when the module was loaded.
llvm-svn: 240700
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
|
|
|
|
| |
all modules even if we've already found a definition that's not visible.
llvm-svn: 240204
|
|
|
|
| |
llvm-svn: 240200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce context-sensitive, non-underscored nullability specifiers
(nonnull, nullable, null_unspecified) for Objective-C method return
types, method parameter types, and properties.
Introduce Objective-C-specific semantics, including computation of the
nullability of the result of a message send, merging of nullability
information from the @interface of a class into its @implementation,
etc .
This is the Objective-C part of rdar://problem/18868820.
llvm-svn: 240154
|
|
|
|
|
|
| |
imported definition.
llvm-svn: 240068
|
|
|
|
|
|
| |
making either of them visible makes the merged definition visible.
llvm-svn: 239969
|
|
|
|
| |
llvm-svn: 239954
|
|
|
|
|
|
|
| |
modules, and allow use of a default template argument if any of the parameters
providing it is visible.
llvm-svn: 239485
|
|
|
|
|
|
| |
than wasting storage and triggering eager deserializations by serializing it.
llvm-svn: 239454
|
|
|
|
|
|
|
| |
This is just a preparatory step towards fixing visibility for default template
arguments in modules builds.
llvm-svn: 239447
|
|
|
|
|
|
|
| |
Skip imports when we know that we do not need to visit any imports
because we've already deserialized the redecls from a module.
llvm-svn: 237782
|
|
|
|
|
|
|
|
| |
VarDeclBitfields contained bits which are never present in parameters.
Split these out so that ParmVarDeclBitfields wouldn't grow past 32-bits
if another field was added.
llvm-svn: 237648
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, enabling -fmodules-local-submodule-visibility results in name
visibility rules being applied to submodules of the current module in addition
to imported modules (that is, names no longer "leak" between submodules of the
same top-level module). This also makes it much safer to textually include a
non-modular library into a module: each submodule that textually includes that
library will get its own "copy" of that library, and so the library becomes
visible no matter which including submodule you import.
llvm-svn: 237473
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modules builds fundamentally have a non-linear macro history. In the interest
of better source fidelity, represent the macro definition information
faithfully: we have a linear macro directive history within each module, and at
any point we have a unique "latest" local macro directive and a collection of
visible imported directives. This also removes the attendent complexity of
attempting to create a correct MacroDirective history (which we got wrong
in the general case).
No functionality change intended.
llvm-svn: 236176
|
|
|
|
| |
llvm-svn: 235163
|
|
|
|
|
|
| |
Thanks to Michael Schlottke.
llvm-svn: 235162
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
top of an existing imported-but-not-visible definition.
llvm-svn: 233345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deserializing an inherited constructor.
This is the exact same logic we use when deserializing method overrides
for the same reason: the canonical decl may end up pinned to a different
decl when we are improting modules, we need to re-pin to the canonical
one during reading.
My test case for this will come in a subsequent commit. I was trying to
test a more tricky bug fix and the test case happened to tickle this bug
as well.
llvm-svn: 233325
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
More than 2x speedup on modules builds with large redecl chains.
Roughly 15-20% speedup on non-modules builds for very large TUs.
Between 2-3% cost in memory on large TUs.
llvm-svn: 233228
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 233052
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
with them.
llvm-svn: 232853
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
all the existing declarations of a record-like entity with a pointer to its
definition.
llvm-svn: 231901
|
|
|
|
|
|
| |
actually loading a formerly-canonical declaration.
llvm-svn: 231742
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 231424
|
|
|
|
|
|
| |
very first step in updating it.
llvm-svn: 230840
|
|
|
|
|
|
| |
imported modules.
llvm-svn: 230834
|
|
|
|
|
|
|
|
| |
undeserialized specializations (because we merged an imported declaration of
the same template since we last added one), don't bother reading in the
specializations themselves just so we can write out their IDs again.
llvm-svn: 230805
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
constructor.
llvm-svn: 230417
|
|
|
|
|
|
| |
requiring the macro. NFC; Clang edition.
llvm-svn: 229339
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
don't think we're providing a new one in an update record adding a definition
to another declaration of the same class.
llvm-svn: 228104
|
|
|
|
|
|
|
| |
specialization from an update record exactly once, even if we needed to fake up
the definition.
llvm-svn: 227939
|
|
|
|
|
|
|
|
|
|
|
| |
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
|