Adds support for extracting force unwrapped optionals.
```
let prop: MyType = MyType()!
```
In this case the value kind was being extracted as a Runtime value.
resolves rdar://146046727
Co-authored-by: Deniz Dizman <ddizman@apple.com>
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
As it stands, for extension macros which add protocol conformances, the list of protocols specified on the macro's 'conformances:' parameter gets added in its entirety to the list of a nominal type's protocols in 'ConformanceLookupTable::addMacroGeneratedProtocols'. Whereas the macro itself, may only add *some* of the specified conformances. This means that `getAllProtocols` may contain a super-set of protocols captured in `getAllConformances`, some of which may not actually be generated by the macro.
This change narrowly fixes ConstExtract to query actual generated conformances. Though, potentially we should make 'ConformanceLookupTable::addMacroGeneratedProtocols' behave in a way that reflects the protocols the macro actually adds the conformances to, instead of the ones it may add conformances to.
Resolves rdar://130316531
Matching logic in the ASTPrinter. Otherwise we attempt to mangle types with archetypes in them, which cannot be done, and causes the compiler to crash.
Resolves rdar://113039215
names. It can often be more complex than the code can currently handle (e.g.
properties whose types include archetypes), and we
do not have a good motivating use-case to extract them.
Resolves rdar://113039215
To reduce duplication of logic with other parts of the compiler, instead of destructuring the constraint type, write the requirements in the opaque type declaration's generic signature.
This change adds to the extracted type metadata the following fields:
- Conformances: this is a list of all protocols that the given nominal type conforms to
- associated type aliases: this is a list of all associated types across all conformances that the given nominal type substitutes with concrete types. For a given associated type, we gather:
- Associated type name
- Substituted type's fully-qualified name
- Substituted type's mangled name
- If the substituted type is opaque:
- List of conformance requirements of this opaque type
- List of same-type requirements of this opaque type
