Lazy member loading had an antagonistic relationship with the import-as-member facilities. The member tables were stored in a hash map that is keyed by serialized declaration context. While this was good for importing the entire member set of a given extension, it's in the complete wrong order for lazy member loading, which wants the same data keyed by base name.
Given that it is annoying to redo the globals-as-member tables to support one use case or the other, coupled with the fact that optimizing for one use-case automatically pessimizes the other, just take a page from rdar://18696086 and store the same information twice in two separate formats each optimized for the task at hand.
Preliminary benchmarks indicate that this leads to a 5% reduction in Clang-Imported entities which will drastically speed up most apps that use Dispatch and CoreGraphics.
This reverts commit e805fe486e, which reverted
the change earlier. The problem was caused due to a simultaneous change to some
code by the PR with parsing and printing for Clang function types (#28737)
and the PR which introduced Located<T> (#28643).
This commit also includes a small change to make sure the intersecting region
is fixed: the change is limited to using the fields of Located<T> in the
`tryParseClangType` lambda.
This reverts commit c362e925af.
This might be causing hard to reproduce issues. Taking it out until
we have further investigation.
rdar://problem/57964637
This is primarily meant to used for testing LLDB's DWARFImporterDelegate,
however, this could become the default option for LLDB once
DWARFImporterDelegate is sufficiently mature.
<rdar://problem/57880844>
When checking whether we can load a bridging precompiled header (PCH), we end
up parsing module maps. If Clang emits a warning or error while parsing the
module maps we encounter, the Swift compiler would crash because we have not
properly established the invariants of Clang's diagnostic engine. Perform a
pairsed set of BeginSourceFile/EndSourceFile calls on the Clang diagnostic
consumer to set up the appropriate state.
Fixes rdar://problem/57626886.
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.
