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.
The Bitstream part of Bitcode moved to llvm/Bitstream in LLVM. This
updates the uses in swift.
See r365091 [Bitcode] Move Bitstream to a separate library.
(cherry picked from commit 1cd8e19357)
* Fix Swift following bitstream reader API update
Upstream change in rL364464 broke downstream Swift.
(cherry picked from commit 50de105bf1)
Conflicts:
lib/Serialization/Deserialization.cpp
lib/Serialization/ModuleFile.cpp
tools/driver/modulewrap_main.cpp
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.
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
The one for enum raw value checking isn't serialized anywhere, so we
can use normal in-process hashing. The ones in the Clang importer's
lookup tables are serialized, but the lookup table is already only
valid for a particular compiler build anyway (it goes into a Clang
PCM, which has the full compiler version in its cache key).
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances in the swift repo.
The Bitstream part of Bitcode moved to llvm/Bitstream in LLVM. This
updates the uses in swift.
See r365091 [Bitcode] Move Bitstream to a separate library.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
This is overkill when we could just be better about updating the
lookup table version, but it's hard to remember to do that when
changing something in ImportName.cpp or whatever.
In particular, there are frameworks with more than 65536 entries for
'init' as a base name.
I can't think of a test case for this besides actually adding such a
massive framework, but the assertions that were added here should
catch the issue in Debug builds if it ever comes up again. I'm going
to go harden everything else that uses this API next.
rdar://problem/40828315
If the Clang declrations are *types*, canonical declaration in Swift is
imported for newest version of Swift. In interface generation, if the
declaration is versioned and it's imported as a member in either or both
version of Swift, we have to take compatibility typealias into account.
* Fixed 'ClangModuleUnit::getTopLevelDecls' to take isCompatibilityAlias() into account
* Fixed bugs in ClangImporter where member-to-member versioned types aren't properly imported.
* Fixed 'SwiftDeclConverter::importFullName' to check equality of getEffectiveContext()
* Fixed 'importer::addEntryToLookupTable' to check equality of getEffectiveContext()
(moved 'ClangImporter::Implementation::forEachDistinctName' to 'NameImporter')
When forming the Swift name lookup tables, import-as-member'd
declarations can precede the declaration of the context into which
they'll be imported as a member. In such cases, we already had logic
to delay the resolution until the end of the model (when the context
must be complete).
However, we would only delay when there is a swift_name attribute on
the declaration, which is... conceptually correct. If the swift_name
exists but is versioned (e.g., it is present only for Swift 4+), and
we're building before the swift_name took effect (e.g., in Swift 3
mode), the swift_name is buried under a "versioned" attribute in the
Clang AST. Therefore, we would end up dropping the declaration from
the name lookup table, which almost doesn't matter, except...
Serialization records the newest names for such declarations (e.g.,
Swift 4+ name in this case), so deserialization would fail to find the
declaration that had been dropped, causing a crash.
Eliminate the "optimization" that looks for the swift_name attribute
before delaying the resolution of such a declaration, so we'll visit
these later. Fixes rdar://problem/39115605.
The obsolete llvm::HashString() was equivalent to
llvm::djbHash(seed=0) and was removed from llvm. This patch replaces
all occurences of llvm::HashString() with llvm::djbHash(seed=0), no
functional change.
The default seed of llvm::djbHash() is supposed to yield a higher
quality result that using seed=0, but changing it looks like it
affects the ordering of SIL serialization.
This includes 'LONG_MAX' in the Darwin module, which is defined by the
system and then immediately redefined by Clang's copy of limits.h.
The general strategy here is that if two definitions of a macro in the
same module are in separate explicit submodules, we need to keep track
of both of them, but if they're in the same explicit submodule then
one is probably deliberately redefining the other. This isn't fully
correct because one explicit submodule could include another explicit
submodule, but it's a good first approximation, which we can refine if
we come across problem cases in practice.
Swift /also/ has the ability to distinguish between ModuleA.MACRO and
ModuleB.MACRO if you've imported both modules, although there's an
issue that the two of them end up getting the same mangled name if you
try to use both in the same compilation unit. (Filed
rdar://problem/34968281.) That ability is preserved with this change.
All of this will likely change if/when we switch to Clang's "local
submodule visibility" mode, which is needed for the C++ Modules TS but
is also incompatible with Apple's SDKs at the moment. In that case,
macros in two separate explicit submodules will no longer have an
'override' relationship just because they're mentioned sequentially in
the module map.
rdar://problem/34413934
...so that we don't have to keep coming back to update it every major
release. And also so we can actually put methods on it instead of
using free functions.
No intended behavior change (yet).
In theory, Clang's module system supports the notion of "public" and
"private" macros in a framework, currently implemented by the
supported feature at this point, but we do make sure the Swift
compiler can handle them.
However, visibility directives for built-in macros would end up
showing up in the list of defined macros that we iterate over to write
out the Swift name lookup tables for a module. Since we pack
ModuleMacro and MacroInfo pointers into the same data structure
/without/ a discriminator bit, this led to a nonsense reinterpret_cast
later on. This manifested as rare test failures later.
Bail out in this case, and assert in NDEBUG builds that it's actually
this case and not some other problematic case that we haven't
encountered yet.
I'm not filing a bug for real support of the macro visibility
directives because it wouldn't be prioritized until there's a
real-world test case anyway (sad realities of compiler development).
rdar://problem/33745657
Special DeclNames represent names that do not have an identifier in the
surface language. This implies serializing the information about whether
a name is special together with its identifier (if it is not special)
in both the module file and the swift lookup table.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
Previously this (1) did not work (the constant just disappeared), and
(2) would actually crash if the destination context was a class.
rdar://problem/32208235
...and Swift 4 versions in Swift 3, and Swift 2 and "raw" versions in
both. This allows the compiler to produce sensible errors and fix-its
when someone uses the "wrong" name for an API. The diagnostics
certainly have room to improve, but at least the essentials are there.
Note that this commit only addresses /top-level/ decls, i.e. those
found by lookup into a module. We're still limited to producing all
members of a nominal type up front, so that'll require a slightly
different approach.
Part of rdar://problem/29170671
The compiler uses the non-active names to import unavailable
declarations telling the user the correct name. Right now it's still
only importing "Swift 2" and "current", but that should change.
For reference, the best example of a declaration that has four names
is a factory method with a custom NS_SWIFT_NAME annotation:
- Its raw name is the plain Objective-C name, written as a method:
'fooByFrobnicatingBar(_:)'.
- Its "Swift 2" name is the Swift-2-style translation of that to an
initializer: 'init(byFrobnicatingBar:)'
- Its "Swift 3" name applies the "omit needless words" transformation:
'init(frobnicating:)'.
- Its "Swift 4" name uses the name specified by NS_SWIFT_NAME.
