Instead of using `UnresolvedType` as a placeholder for a type hole,
let's switch over to a dedicated "rich" `HoleType` which is capable
of storing "originator" type - type variable or dependent member
type which couldn't be resolved.
This makes it easier for the solver to determine origins of
a hole which helps to diagnose certain problems better. It also
helps code completion to locate "expected type" of the context
even when it couldn't be completely resolved.
Swift class deinit decl can be implicitly synthesized when emitting
swiftmodule, so swiftmodule always have deinit decl. So resolution of
x-refs to deinit of swift class always success.
But when x-refs points deinit of clang imported class, it always failed
because clang importer doesn't force to synthesize deinit before looking
up.
x-refs to deinit decl appears in only deinit of its subclasses, so it's
serialized only when deinit have body. And deinit has body only on SIB
because deinit is always non-inlinable. It means that this missing of
deinit creation can be problem only on SIB
This commit changes to force to synthesize class deinit
decl before looking up members.
In the fast dependency scanner, depending on whether a module intrface was found via the import search path or framework search path, encode into the dependency graph Swift module details, whether a given module is a framework.
In theory, we shouldn't need to deserialize @_implementationOnly dependencies. However,
potential decl recovery issues may bring down lldb if we insist on not importing these
dependencies, resulting in bad user experience as a result. This patch adds an internal
option to allow importing them and it should only be set by lldb and other tools.
rdar://65570721
subclassScope was always set as NotApplicable when deserialized but we
need to serialize and deserialize it to keep correct linkage when using
SIB
```swift
open class Visitor {
public func visit() {
visitExprImpl()
}
@_optimize(none)
private func visitExprImpl() {
}
}
```
In this case, `visitExprImpl` is private but subclassScope is External.
So it should be lowered as an external function at LLVM IR level.
But once it's serialized into SIB, subclassScope of `visitExprImpl` was
deserialized as NotApplicable because it was not serialized. This
mismatch makes `visitExprImpl` lowered as an internal function at LLVM
IR level.
So `subclassScope` should be serialized.
When there are sil_property and sil_differentiability_witness at once,
serialized file couldn't be deserialized because it's index table is
serialized un-sortedly but deserializer assumes that contents of table
index are sorted.
This patch fixes the un-sorted serialization and adds test case to
ensure that table index contents can be deserialized
In #30614, we started consuming XRefNonLoadedModuleErrors while loading
conformances, since a conformance to a type we cannot load usually
indicates we're trying to load a protocol that was declared in an
@_implementationOnly imported module.
We should also consume TypeErrors that we see where the underlying reason
is an XRefNonLoadedModuleError, since they're likely indicators of the
same thing.
Some implicitly imported modules aren't printed in the textual interface file as explicit import,
e.g. SwiftOnoneSupport. We should check implicit imports and add them to the dependency graph.
Since the two ExtInfos share a common ClangTypeInfo, and C++ doesn't let us
forward declare nested classes, we need to hoist out AnyFunctionType::ExtInfo
and SILFunctionType::ExtInfo to the top-level.
We also add some convenience APIs on (AST|SIL)ExtInfo for frequently used
withXYZ methods. Note that all non-default construction still goes through the
builder's build() method.
We do not add any checks for invariants here; those will be added later.
Add `async` to the type system. `async` can be written as part of a
function type or function declaration, following the parameter list, e.g.,
func doSomeWork() async { ... }
`async` functions are distinct from non-`async` functions and there
are no conversions amongst them. At present, `async` functions do not
*do* anything, but this commit fully supports them as a distinct kind
of function throughout:
* Parsing of `async`
* AST representation of `async` in declarations and types
* Syntactic type representation of `async`
* (De-/re-)mangling of function types involving 'async'
* Runtime type representation and reconstruction of function types
involving `async`.
* Dynamic casting restrictions for `async` function types
* (De-)serialization of `async` function types
* Disabling overriding, witness matching, and conversions with
differing `async`
