The basic concept here was previously laid out in the metadata
system commits adding ExtendedExistentialTypeShape, but to recap,
we want to produce (for any existential type, but we're really
only going to use it for constrained or otherwise generalized
existentials) a "shape" signature and type that will be agreed
upon by all possible abstractions of the type. In this
signature+type pair, any substitutable position in the original
type is abstracted as a parameter in the signature, which the
original type is a concrete application of. This permits
agreement on the type in the face of runtime generic execution.
I have made every effort to support protocol compositions in
the code I've written, but of course until you're allowed to
actually write them, that's all untested.
I have not yet implemented signature minimization of the
generalization signature. I think this will be necessary in order
to ensure that there are no non-redundant parameters, especially
for compositions, which is something the runtime currently assumes
and is better for code size anyway. But it can wait a few days,
I think.
The final step in minimization is building Requirements and
ProtocolTypeAliases from the minimal Rules in the RewriteSystem.
Move this to a new file and refactor it a bit to handle
Requirements and ProtocolTypeAliases more consistently.
See the comment at the top of ConcreteContraction.cpp for a detailed explanation.
This can be turned off with the -disable-requirement-machine-concrete-contraction
pass, mostly meant for testing. A few tests now run with this pass both enabled
and disabled, to exercise code paths which are otherwise trivially avoided by
concrete contraction.
Fixes rdar://problem/88135912.
When looking for a Swift module on disk, we were scanning all module search paths if they contain the module we are searching for. In a setup where each module is contained in its own framework search path, this scaled quadratically with the number of modules being imported. E.g. a setup with 100 modules being imported form 100 module search paths could cause on the order of 10,000 checks of `FileSystem::exists`. While these checks are fairly fast (~10µs), they add up to ~100ms.
To improve this, perform a first scan of all module search paths and list the files they contain. From this, create a lookup map that maps filenames to the search paths they can be found in. E.g. for
```
searchPath1/
Module1.framework
searchPath2/
Module1.framework
Module2.swiftmodule
```
we create the following lookup table
```
Module1.framework -> [searchPath1, searchPath2]
Module2.swiftmodule -> [searchPath2]
```
Introduce the ArgumentList type, which represents
a set of call arguments for a function or
subscript. This will supersede the use of tuple
and paren exprs as argument lists.
Also move a all headers other than RequirementMachine.h there, since
I don't expect they will be used outside of the rewrite system
implementation itself.
Otherwise we set it on all targets/languages in a subdirectory (I forgot if it
propagates up). Regardless, this type of viral stuff is something we want to
move away from since it creates a code that is a "forall" piece of code rather
than a piece of code that only effects a single target.
I also conditionalized the actual definitions being added on the compiled file's
language being C,CXX,OBJC,OBJCXX since as we add Swift sources to the host side
of the compiler, we will not want these flags to propagate to Swift sources.
This follows the design of how we handled this with
sil-verify-all. Specifically, the default behavior is to run only in asserts
builds, but one can use the two flags: enable-ast-verifier and
disable-ast-verifier to override the default behavior.
The reason why this is interesting is that this means that when compiling
normally, we will not run the verifier, so we won't have a perf hit. But we can
now ask the user to run with this flag (or in a future maybe a re-run in the
driver would do this for them), saving us time when screening bugs by avoiding
the need to build an asserts compiler to triage if the ASTVerifier would catch
the bug.
Create a new diagnostics serialization library, splitting out of
swiftAST to reduce the overheads for building the tooling for
cross-compiling the toolchain. This should reduce the build time for
swift-serialize-diagnostics to enable cross-compilation.
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.
