The previous 'openModuleFiles' interface in SerializedModuleLoaderBase
still assumed that swiftmodule files and swiftdoc files would be found
next to each other, but that's not true anymore with
swiftinterfaces-built-to-modules. Give up on this assumption (and on
the minor optimization of passing down a scratch buffer) and split out
the interface into the customization point
'findModuleFilesInDirectory' and the implementation 'openModuleFiles'.
The latter now takes two full paths: one for the swiftmodule, one for
the swiftdoc.
- Use the name for the cached module, so that we don't end up with a
zillion "x86_64-XXXXXXXX.swiftmodule" files in the cache when we're
working with architecture-specific swiftmodules.
- Diagnose if the expected name is different from the name specified
in the swiftinterface.
- Emit all diagnostics at the location of the import, instead of
without any location at all.
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.
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.
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.
There's a class of errors in Serialization called "circularity
issues", where declaration A in file A.swift depends on declaration B
in file B.swift, and B also depends on A. In some cases we can manage
to type-check each of these files individually due to the laziness of
'validateDecl', but then fail to merge the "partial modules" generated
from A.swift and B.swift to form a single swiftmodule for the library
(because deserialization is a little less lazy for some things). A
common case of this is when at least one of the declarations is
nested, in which case a lookup to find that declaration needs to load
all the members of the parent type. This gets even worse when the
nested type is defined in an extension.
This commit sidesteps that issue specifically for nested types by
creating a top-level, per-file table of nested types in the "partial
modules". When a type is in the same module, we can then look it up
/without/ importing all other members of the parent type.
The long-term solution is to allow accessing any members of a type
without having to load them all, something we should support not just
for module-merging while building a single target but when reading
from imported modules as well. This should improve both compile time
and memory usage, though I'm not sure to what extent. (Unfortunately,
too many things still depend on the whole members list being loaded.)
Because this is a new code path, I put in a switch to turn it off:
frontend flag -disable-serialization-nested-type-lookup-table
https://bugs.swift.org/browse/SR-3707 (and possibly others)
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
* Pack the bits for IfConfigDecls into Decl
* Don't open symbols into a module when evaluating canImport statements
The module loaders now have API to check whether a given module can be
imported without importing the referenced module. This provides a
significant speed boost to condition resolution and no longer
introduces symbols from the referenced module into the current context
without the user explicitly requesting it.
The definition of ‘canImport’ does not necessarily mean that a full
import without error is possible, merely that the path to the import is
visible to the compiler and the module is loadable in some form or
another.
Note that this means this check is insufficient to guarantee that you
are on one platform or another. For those kinds of checks, use
‘os(OSNAME)’.
What I've implemented here deviates from the current proposal text
in the following ways:
- I had to introduce a FunctionArrowPrecedence to capture the parsing
of -> in expression contexts.
- I found it convenient to continue to model the assignment property
explicitly.
- The comparison and casting operators have historically been
non-associative; I have chosen to preserve that, since I don't
think this proposal intended to change it.
- This uses the precedence group names and higherThan/lowerThan
as agreed in discussion.
Introduce Fix-Its to aid migration from selectors spelled as string
literals ("foo:bar:", which is deprecated), as well as from
construction of Selector instances from string literals
(Selector("foo:bar"), which is still acceptable but not recommended),
to the #selector syntax. Jump through some hoops to disambiguate
method references if there are overloads:
fixits.swift:51:7: warning: use of string literal for Objective-C
selectors is deprecated; use '#selector' instead
_ = "overloadedWithInt:" as Selector
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#selector(Bar.overloaded(_:) as (Bar) -> (Int) -> ())
In the cases where we cannot provide a Fix-It to a #selector
expression, we wrap the string literal in a Selector(...) construction
to suppress the deprecation warning. These are also easily searchable
in the code base.
This also means we're doing more validation of the string literals
that go into Selector, i.e., that they are well-formed selectors and
that we know about some method that is @objc and has that
selector. We'll warn if either is untrue.
Also into a separate file.
Before (swift/Serialization/SerializedModuleLoader.h):
ModuleStatus
SerializedModuleLoader::ValidationInfo
SerializedModuleLoader::ExtendedValidationInfo
SerializedModuleLoader::isSerializedAST
SerializedModuleLoader::validateSerializedAST
After (swift/Serialization/Validation.h):
serialization::Status
serialization::ValidationInfo
serialization::ExtendedValidationInfo
serialization::isSerializedAST
serialization::validateSerializedAST
No functionality change, just a lot of renaming and a bit of reorganizing.
Swift SVN r25226
...so that the debugger has the best possible chance of being able to load
the app properly.
We don't do this for frameworks today because we don't want to leak this
information into the public module; once we have a distinction between
"the module that ships with the framework" and "the module that goes into
the debug info" we can do this for frameworks as well.
Part of rdar://problem/17670778
Swift SVN r25204
Also, erase empty entries from the map once they've been loaded, just in
case we end up registering /more/ buffers later.
No intended functionality change.
Swift SVN r25202
Local type declarations are saved in the source file during parsing,
now serialized as decls. Some of these may be defined in DeclContexts
which aren't Decls and previously weren't serialized. Create four new
record kinds:
* PatternBindingInitializer
* DefaultArgumentInitializer
* AbstractClosureExpr
* TopLevelCodeDecl
These new records are used to only preserve enough information for
remangling in the debugger, and parental context relationships.
Finally, provide a lookup API in the module to search by mangled name.
With the new remangling API, the debugging lifecycle for local types
should be complete.
The extra LOCAL_CONTEXT record will compressed back down in a
subsequent patch.
Swift SVN r24739
This isn't being used for much yet, but it will allow us to tell whether
something is an app target even at the module-merging stage, which is a
better way to tell if something is an app than whether it has a bridging
header.
We'll also need this if we ever take advantage of reusing "partial modules"
(serialized ASTs for other parts of the module that aren't affected by the
current source file) for compiling source files in incremental builds;
unfortunately that's unlikely given our dependency model.
Swift SVN r24531
Refuse to load a module if it was compiled for a different architecture or
OS, or if its minimum deployment target is newer than the current target.
Additionally, provide the target triple as part of pre-loading validation
for clients who care (like LLDB).
Part of rdar://problem/17670778
Swift SVN r24469
Changing the design of this to maintain more local context
information and changing the lookup API.
This reverts commit 4f2ff1819064dc61c20e31c7c308ae6b3e6615d0.
Swift SVN r24432
rdar://problem/18295292
Locally scoped type declarations were previously not serialized into the
module, which meant that the debugger couldn't reason about the
structure of instances of those types.
Introduce a new mangling for local types:
[file basename MD5][counter][identifier]
This allows the demangle node's data to be used directly for lookup
without having to backtrack in the debugger.
Local decls are now serialized into a LOCAL_TYPE_DECLS table in the
module, which acts as the backing hash table for looking up
[file basename MD5][counter][identifier] -> DeclID mappings.
New tests:
* swift-ide-test mode for testing the demangle/lookup/mangle lifecycle
of a module that contains local decls
* mangling
* module merging with local decls
Swift SVN r24426
Include a mapping from Objective-C selectors to the @objc methods that
produce Objective-c methods with those selectors. Use this to lazily
populate the Objective-C method lookup tables in each class. This makes
@objc override checking work across Swift modules, which is part of
rdar://problem/18391046.
Note that we use a single, unified selector table, both because it is
simpler and because it makes global queries ("is there any method with
the given selector?") easier.
Swift SVN r23214
This included a test that failed on case-sensitive filesystems. Test fixed.
(Aside: Why not just have this fail with "no such module"? Why use a different
error? Because even if "import FOO" picks up a module named 'Foo', there may
actually be a module named 'FOO' on the system (in another folder), and we
should be able to find that. Fixing that is tracked by rdar://problem/18691936.)
rdar://problem/15632996 (again)
Swift SVN r22856
Due to case-insensitive filesystems, "import foundation" can result in the
overlay module for Foundation being loaded. Everything is confused later on
because the (wrong) module name is used in manglings, leading to all sorts
of issues.
This is not the right fix for the problem, because a user really is allowed
to have modules named "foundation" and "FOUNDATION" and "Foundation" coexisting
on their system. To do that we'll want to check the actual case of a
.framework bundle or .swiftmodule file on disk and make sure it matches before
even trying to load the file. But this is a good sanity check anyway.
rdar://problem/15632996
Swift SVN r22818
