This can only happen in one case today: a module imports a bridging
header, but the header on disk has disappeared, and now we need to
fall back to the (often inadequate) version that's stored inside the
swiftmodule file. Even if the module fails to load, the bridging
header has already been imported, and so anything else that happens
might still emit diagnostics and need that text to be alive, which
means we need to keep the buffer alive too.
This reverts commit bb16ee049d,
reversing changes made to a8d831f5f5.
It's not sufficient to solve the problem, and the choices were to do
something more complicated, or just take a simple brute force
approach. We're going with the latter.
This can't arise from a clean build, but it can happen if you have
products lingering in a search path and then either rebuild one of
the modules in the cycle, or change the search paths.
The way this is implemented is for each module to track whether its
imports have all been resolved. If, when loading a module, one of its
dependencies hasn't resolved all of its imports yet, then we know
there's a cycle.
This doesn't produce the best diagnostics, but it's hard to get into
this state in the first place, so that's probably okay.
https://bugs.swift.org/browse/SR-7483
ModuleDecl::forAllVisibleModules() now has a includeLinkOnlyModules
parameter. This is intended to be used when computing the set of
libraries to autolink.
Allow substitution maps to be serialized directly (via an ID), writing out
the replacement types and conformances as appropriate. This is a more
efficient form of serialization than the current SubstitutionList approach,
because it maintains uniqueness of substitution maps within a module file,
and is a step toward eliminating SubstitutionList entirely.
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.
We can't make the same assumptions about .sib files.
Ideally, we should serialize the module's stage and set WasDeserializedCanonical
based on that state. However, we probably still want the IsSIB flag for
assertions.
When loading the named members for a given name, we want to load all
of the members with that base name... not only the ones that match the
full name, because the lookup table is indexed by base name and
filtering too early drops candidates.
Fixes rdar://problem/36085994.
Rather than inlining generic signatures in a half dozen places throughout
the serialization format, serialize (uniqued) generic signatures with their
own GenericSignatureID. Update various layouts (generic function types,
SIL function types, generic environments, extension cross-references) to
use GenericSignatureID.
Shaves ~187k off the size of Swift.swiftmodule.
When serializing cross-references to a (private) module that is
re-exported through another (public) module, record the
cross-reference as if the entity were found in named public module.
Finishes rdar://problem/34438586.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
This shows up with swift_wrapper typedefs, which get imported into
Swift as structs. If someone makes an extension of a swift_wrapper
type, but the swift_wrapper is only applied in Swift 4 mode, that
extension will break any Swift 3 clients. Recover by just dropping
the extension entirely.
There's still more complexity around extensions---what if a
requirement can't be deserialized? what if something's depending on
the protocol conformance provided by the extension?---but the missing
base type case should be pretty safe. If you can't see the type at
all, things that depend on its conformances are already in trouble.
rdar://problem/33636733
We use this to avoid circularity issues in serialization; we'd like to
extend that to the Clang importer. This is only necessary because we
can't look up a single member at a time, but it can still fix issues
in the short term.
This commit should have no effect on functionality.
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.
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
