When deserializing a the (named) members of a class hierarchy, we
needn't walk all the way up the hierarchy, just into our superclass.
This will, in turn, walk to its superclass, etc. This is as opposed to
this work being repeated at each level of the recursive hierarchy.
Should be a small perf win over the last patch.
An unfortunate pessimization that is needed in order to properly build the member table to run override checking. Considering this was happening anyways thanks to re-entrant lookups, there shouldn't actually be a perf hit here.
Bridging headers are weird.
A general principle in the Clang Importer is that when it comes to the
notion of "overrides" or "redeclarations", it's always better to prefer
a declaration in the same translation unit, module, header, etc. over
a declaration outside of that thing.
This behavior, unfortunately, occurred as an emergent property of the
re-entrant lookup that was being performed when importing properties.
The behavior of the visible categories list is in "deserialization
order" - that is, a category defined in a header that imports a module
can potentially appear before the module has had its declarations fully
deserialized and installed. We were assuming this order was instead
"source order", in which modules would be recursively expanded and their
declarations installed sequentially. If this assumption were to hold,
then the visible categories list would respect the principle above, and
we would see categories in defining modules and headers before we saw
categories in extant translation units.
This is not the case. Delayed deserialization of modules means
the first category that gets parsed actually wins. We were not noticing
this, however, because the few places where it actually mattered were
performing re-entrant lookup and were accidentally deserializing modules
and installing decls in this fictitious "source order". Since we've
untangled this behavior, we now have to emulate the order the Importer
expects.
Introduce the notion of a "delayed category" - a category that is
defined outside of a module, usually by us. As the name implies, we'll
try to load the categories defined in modules first, then go after the
delayed categories defined in extant translation units. This gives us
a stable "source order", preserves the Principle of Closest Definition,
and undoes the behavior change for overriden property declarations in
the previous commit.
The nested types table contains more than just nested typedefs and aggregate decls, it also contains classes that we've imported under nested names. We were previously falling back to direct lookup to resolve (cross) references to these entities. Instead, relax the preconditions for searching the table.
This breaks a few cycles involving re-entrant calls to lookupDirect/lookupQualified through the ClangImporter.
Set it up as part of configuring the modules build. Should help diminish
the amount of clang modules rebuilds due to mtime invalidation.
rdar://problem/57309954
ClangImporter::canReadPCH has been trying to reset the main
CompilerInstance back to as if it hadn't run, but there's a long tail of
potential memory corruption here. One example is that it's reusing
HeaderSearch, but HeaderSearch contains a ModuleMap whose
SourceLocations will point into the soon-to-be-released ASTContext on
the stack. Instead, just use a separate CompilerInstnace, like the rest
of the ClangImporter does when it needs a different ASTContext.
This fixes a few potential memory corruption bugs, and it *may* be
related to the persistent "missing submodule X" problems hitting Linux
bots.
By convention, most structs and classes in the Swift compiler include a `dump()` method which prints debugging information. This method is meant to be called only from the debugger, but this means they’re often unused and may be eliminated from optimized binaries. On the other hand, some parts of the compiler call `dump()` methods directly despite them being intended as a pure debugging aid. clang supports attributes which can be used to avoid these problems, but they’re used very inconsistently across the compiler.
This commit adds `SWIFT_DEBUG_DUMP` and `SWIFT_DEBUG_DUMPER(<name>(<params>))` macros to declare `dump()` methods with the appropriate set of attributes and adopts this macro throughout the frontend. It does not pervasively adopt this macro in SILGen, SILOptimizer, or IRGen; these components use `dump()` methods in a different way where they’re frequently called from debugging code. Nor does it adopt it in runtime components like swiftRuntime and swiftReflection, because I’m a bit worried about size.
Despite the large number of files and lines affected, this change is NFC.
Christopher Rogers' (good) work in 49fd5acbb2 caught places where
the Swift compiler was allowing a @class to resolve to a Swift class
even if that class had a conflicting Objective-C name, or wasn't
intended to be exposed to Objective-C at all. Unfortunately, this
broke source compatibility in projects where people were relying on
this. Restore that functionality, but only as a fallback; matching the
Objective-C name is better than matching the Swift name.
rdar://problem/56681046
1. Set the diagnostic location to where the attribute was written (or
to the Clang decl's source, if the attribute came from API notes)
2. Add a note to contact the owners of the framework to make it clear
that the client of the framework didn't do anything wrong.
rdar://problem/52736145
Emitting Swift diagnostics in Clang buffers requires making those
buffers valid places to put Swift SourceLocs, which means making a
mirror of those buffers in the Swift SourceManager. This isn't a copy;
instead, any Clang SourceManagers that are involved are kept alive
until the importer is torn down. (There might be more than one because
of diagnostics emitted during module building.)
For a long time we only emitted diagnostics in Clang buffers if the
diagnostics came from Clang, but then we added another case for custom
Swift names that fail to import. I'm about to add another such
diagnostic, so let's formalize this buffer mapping first.
No intended functionality change.
...rather than replacing particular macros with an 'annotate'
attribute and then looking for that. This isn't /really/ any
particular win except maybe ever-so-slightly faster module imports
(with one fewer attribute being added to each declaration in a
mixed-source header).
This doesn't remove the SWIFT_CLASS_EXTRA, SWIFT_PROTOCOL_EXTRA, or
SWIFT_ENUM_EXTRA macros from PrintAsObjC (note that
SWIFT_EXTENSION_EXTRA was never used). They're not exactly needed
anymore, but they're not doing any harm if someone else is using them.
Computing the interface type of a typealias used to push validation forward and recompute the interface type on the fly. This was fragile and inconsistent with the way interface types are computed in the rest of the decls. Separate these two notions, and plumb through explicit interface type computations with the same "computeType" idiom. This will better allow us to identify the places where we have to force an interface type computation.
Also remove access to the underlying type loc. It's now just a cache location the underlying type request will use. Push a type repr accessor to the places that need it, and push the underlying type accessor for everywhere else. Getting the structural type is still preferred for pre-validated computations.
This required the resetting of a number of places where we were - in many cases tacitly - asking the question "does the interface type exist". This enables the removal of validateDeclForNameLookup
A DirectoryEntryRef was added to wrap DirectoryEntrys and numerous
APIs were changed to use it in clang. Change one usage here to account
for the difference.
Removes duplicated logic from the implementations of
FileUnit::lookupValue, and simplifies the interface to
ModuleDecl::lookupValue, where everyone was passing an empty
(non-filtering) access path anyway /except/ during actual lookup from
source code. No functionality change.
If, while loading a bridging header, we pick up a Clang module that
claims to have an overlay Swift module, and that Swift module turns
out to have a bridging header, we can end up reallocating the array
of modules to process while we're looping over it. Be defensive
against this occurrence.
This just fixes a crash; it does not at all solve the problem of this
being broken in several ways:
- Accidentally naming your module the same as a system module shadows
the latter (if the system module is a Swift module) or *makes your
module into an overlay* (if the system module is a Clang module).
- Bridging headers are only officially supported on executable targets
and unit tests, but this isn't really enforced.
- Implicit inclusion of a bridging header *when you import a Swift
module* is a hack to begin with, and a hack that worsens when the
main module also has a bridging header. (All the bridging headers
get folded together into the "same" module, which leads to more
visibility than desired as well as cycles in the import graph.)
- Combining all of these can result in some pretty bizarre behavior.
rdar://problem/54581756
