Unlike compiled modules, swiftdoc files are considered a stable
format, so we can't change how information is stored in them. If we
add any more string-hashed tables to swiftdoc files, we should
consider using a new hash seed for those.
A generic environment is always serialized as a GenericSignature with
a lazily-recreated environment, though sometimes it has to include
extra info specifically for generic environments used by SIL. The code
that was doing this claimed a bit for disambiguating between the two,
shrinking the permitted size of a compiled module from 2^31 bits to
2^30. (The code isn't just needlessly complicated; GenericEnvironments
used to be serialized with more information.)
Rather than have two representations for GenericEnvironmentID, this
commit just drops it altogether in favor of referencing
GenericSignatures directly. This causes a negligible file size
shrinkage for swiftmodules in addition to eliminating the problematic
disambiguation bit.
For now, the Deserialization logic will continue to cache
GenericEnvironments that are used directly by Deserialization, but
really that should probably be done at the AST level. Then we can
simplify further to ModuleFile tracking a plain list of
GenericSignatures.
...by making it a tagged union of either a DeclID or a
LocalDeclContextID. This should lead to smaller module files and be
slightly more efficient to deserialize, and also means that every
AST entity kind is serialized in exactly one way, which allows for
the following commit's refactoring.
We already do this for other ASTContext-allocated types (see
Decl.cpp). This will prevent the sort of mistakes in the previous two
commits.
Note that if any particular subclass of FileUnit wants to have its
destructor run, it can opt into that manually using
ASTContext::addDestructorCleanup. SourceFile and BuiltinUnit both do
this. But we generally don't /want/ to do this if we can avoid it
because it adds to compiler teardown time.
...rather than the buffer, for a compiled module that came from a
module interface.
This was already happening at a higher level
(ModuleDecl::getModuleFilename) so pushing it down to the low-level
ModuleFile::getModuleFilename doesn't really change things much. The
important fix that goes with this is that SerializedASTFile no longer
leaks this name by storing it outside of ModuleFile.
https://bugs.swift.org/browse/SR-11365
The code tried extra hard to make sure this stayed in sync with the
returned ValidationInfo, but there's no real reason for that. Just
keep a single "HasError" bit for checking that the module's not being
obviously misused. (I snuck some groundwork for this into the previous
commit.)
`ModuleFile::error` was being used both for errors of initial parse
and configuration (non-fatal) and format errors during actual
deserialization (fatal, indicating a corrupted module). Split out the
latter to `ModuleFile::fatal()` (to go with the existing
`ModuleFile::fatal(llvm::Error)`) and be more consistent about
explicitly setting statuses for the former.
Since 'fatal()' is always fatal, this also allows deleting dummy
recovery code that would never be used in practice.
Similar to 517f5d6b6a, the "shadowed" terminology didn't end up
describing the most common use of the feature; there is pretty much no
intended case where a Swift module shadows a Clang module without also
re-exporting it. Switch to "underlying", which was already in use in a
few places, and which better parallels "overlay".
No intended functionality change.
This commit adds a new type DynamicLookupInfo that provides information
about how a dynamic member lookup found a particular Decl. This is
needed to correctly handle KeyPath dynamic member lookups, but for now
just plumb it through everywhere.
Dependency tracking for cached compiled modules (compiled from
swiftinterfaces) can lead to a high percentage of the module being
SDK-relative paths when -track-system-dependencies is on. Cut down on
this by storing directory names in a separate record that gets
referenced from each file dependency. (Since a lot of per-file
dependencies are header files in a common directory, this is a win.)
We can do something more clever in the future, but this is a
reasonable start for, say, the overlays.
rdar://problem/50449802
When printing a swiftinterface, represent opaque result types using an attribute that refers to
the mangled name of the defining decl for the opaque type. To turn this back into a reference
to the right decl's implicit OpaqueTypeDecl, use type reconstruction. Since type reconstruction
doesn't normally concern itself with non-type decls, set up a lookup table in SourceFiles and
ModuleFiles to let us handle the mapping from mangled name to opaque type decl in type
reconstruction.
(Since we're invoking type reconstruction during type checking, when the module hasn't yet been
fully validated, we need to plumb a LazyResolver into the ASTBuilder in an unsightly way. Maybe
there's a better way to do this... Longer term, at least, this surface design gives space for
doing things more the right way--a more request-ified decl validator ought to be able to naturally
lazily service this request without the LazyResolver reference, and if type reconstruction in
the future learns how to reconstruct non-type decls, then the lookup tables can go away.)
When a Swift module built with debug info imports a library without
debug info from a textual interface, the textual interface is
necessary to reconstruct types defined in the library's interface. By
recording the Swift interface files in DWARF dsymutil can collect them
and LLDB can find them.
rdar://problem/49751363
When we build incrementally, we produce "partial swiftmodules" for
each input source file, then merge them together into the final
compiled module that, among other things, gets used for debugging.
Without this, we'd drop @_implementationOnly imports and any types
from the modules that were imported during the module-merging step
and then be unable to debug those types
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
...in preparation for me adding a third kind of import, making the
existing "All" kind a problem. NFC, except that I did rewrite the
ClangModuleUnit implementation of getImportedModules to be simpler!
It's a pretty obscure feature (and one we wish we didn't need), but
sometimes API is initially exposed through one module in order to
build another one, and we want the canonical presented name to be
something else. Push this concept into Swift's AST properly so that
other parts of the compiler stop having to know that this is a
Clang-specific special case.
No functionality change in this commit; will be used in the next
commit.
Add a bit to the module to determine whether the dependency’s stored bit pattern is a hash or an mtime.
Prebuilt modules store a hash of their dependencies because we can’t be sure their dependencies will have the same modtime as when they were built.
A module compiled with `-enable-private-imports` allows other modules to
import private declarations if the importing source file uses an
``@_private(from: "SourceFile.swift") import statement.
rdar://29318654
Previously, the fast path for nested types only worked when the nested
type was defined in a Swift module or a Clang module without an
overlay; this is because it was originally designed to fix circularity
issues when merging partial modules for a single target. By having a
Swift overlay module pass through requests for nested types to the
underlying Clang module, we get the fast-path behavior in more cases.
(The one case where it /won't/ kick in is if the overlay has a nested
type that shadows a nested type from the Clang module, but that's
probably pretty rare!)
BCRecordLayout currently assumes that the layout described in source
always matches the layout in the bitstream being read. Since we want
swiftdocs to be a forward-compatible format, avoid using it for
deserialization.
(In the future, we may want to augment BCRecordLayout to handle
records with more fields than expected. For now, though, this is a
sufficient change.)
The functionality change in this commit is that the control block in a
swiftdoc file is validated rather than just being ignored. Tests in
following commit.
Added the 'Module::getPrecedenceGroups' API to separate precedence group lookup
from 'Module::lookupVisibleDecls', which together with 'FileUnit::lookupVisibleDecls',
to which the former is forwarded, are expected to look up only 'ValueDecl'. In particular, this
prevents completions like Module.PrecedenceGroup.
Swift currently checks if an imported module has a deployment target
compatible with what’s currently being compiled. For a resilient
module, though, you really want to know the /oldest/ deployment target
the library supports, not the one it was most recently compiled with,
and we don’t currently save that information. Disable this check for
now when the module is resilient.
(Why not do this on the serialization side? Because the deployment
target you compile with is still relevant when trying to match the
compilation environment as closely as possible, which LLDB tries to
do. It's also just useful information for debugging the compiler.)
rdar://problem/42903218
...instead of std::vector, which (1) will always make separate
allocations, and (2) has features and overhead we don't need
I don't expect this to actually affect performance too much, but it
seems more correct for what Serialization needs anyway.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
We previously shied away from this in order to not /accidentally/
depend on it, but it becomes interesting again with textual
interfaces, which can certainly be read by humans. The cross-file
order is the order of input files, which is at least controllable by
users.
Switch a number of callers of the Type-based lookupQualified() over to
the newer (and preferred) declaration-based lookupQualified(). These are
the easy ones; NFC.
llvm::Expected/llvm::Error require that the error is not just checked
but explicitly handled. Since we're currently recovering as if nothing
happened, we need to use llvm::consumeError to throw the error info
away.
rdar://problem/40738521
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.
