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.
Extensions to implementation-only types are accepted at type-checking
only if they don't define any public members. However if they declared a
conformance to a public type they were also printed in the
swiftinterface, making it unparsable because of an unknown type.
Still accept such extensions but don't print them.
rdar://problem/67516588
In diagnostics, we print wrapped ErrorTypes as their original type.
This is confusing when debugging SIL issues though, where we don't
expect to see ErrorTypes. Print them as '@error_type <origtype>'
instead.
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`
We have landed support for serialization Clang function types, but there is
still work to be done here.
Moreover, we should use a consistent style with `[(FIXME|TODO|NOTE): label]`,
instead of using different styles throughout the code.
VarPattern is today used to implement both 'let' and 'var' pattern bindings, so
today is already misleading. The reason why the name Var was chosen was done b/c
it is meant to represent a pattern that performs 'variable binding'. Given that
I am going to add a new 'inout' pattern binding to this, it makes sense to
give it now a better fitting name before I make things more confusing.
Extracts the list of magic identifier literal kinds into a separate file and updates a lot of code to use macro metaprogramming instead of naming half a dozen cases manually. This is a complicated change, but it should be NFC.
SILType and SILDeclRef do not actually need anything from SIL/*.h. Also,
a few dependencies can be pushed out of the headers into cpp files to
speed up incremental rebuilds.
