While trying to infer type for pattern always take result of
`getTypeForPattern` and `resolveTypeInExpressionContext` with
a grain of salt because both of these methods produce empty type
if type as-written or one of the sub-pattern types is incorrect.
Resolves: rdar://problem/60534522
that allows arbitrary `label: {}` suffixes after an initial
unlabeled closure.
Type-checking is not yet correct, as well as code-completion
and other kinds of tooling.
Currently we always generate a new type variable for any pattern
(represented as `_` in the source), but in cases where it's a
sub-pattern of a typed pattern e.g. `let _: Foo = ...` it makes
more sense to pass a type to it directly otherwise type variable
allocated for any pattern gets disconnected from the rest of
the constraint system.
Now that these are stored in the TypeResolution object itself, and all callers that mutate flags create a new resolution object, this data can be derived from the resolution itself.
Add the appropriate assertions to ensure that the now-redundant options parameters are being kept in sync so they can be retracted.
The eventual goal is to have TypeResolution requestified.
All callers can trivially be refactored to use ModuleDecl::lookupConformance()
instead. Since this was the last flag in ConformanceCheckOptions, we can remove
that, too.
Previously we were only connecting a closure
constraint to type variables from param decls that
it referenced. This worked fine up until we
started type-checking for-in statements entirely
in the constraint system, meaning that closures
can now reference type variables from the element
pattern.
Tweak the collection logic to consider vars too.
Resolves rdar://62339835
Remove duplication in the modeling of TypeExpr. The type of a TypeExpr
node is always a metatype corresponding to the contextual
type of the type it's referencing. For some reason, the instance type
was also stored in this TypeLoc at random points in semantic analysis.
Under the assumption that this instance type is always going to be the
instance type of the contextual type of the expression, introduce
a number of simplifications:
1) Explicit TypeExpr nodes must be created with a TypeRepr node
2) Implicit TypeExpr nodes must be created with a contextual type
3) The typing rules for implicit TypeExpr simply opens this type
When a type (class, enum, or struct) is annotated @main, it is required
to provide a function with the following signature:
static func main() -> ()
That function will be called when the executable the type is defined
within is launched.
wrapped value placeholder in an init(wrappedValue:) call that was previously
injected as an OpaqueValueExpr. This commit also restores the old design of
OpaqueValueExpr.
Pull the entirety of type checking for for-each statement headers (i.e., not the
body) into the constraint system, using the normal SolutionApplicationTarget-based
constraint generation and application facilities. Most of this was already handled
in the constraint solver (although the `where` filtering condition was not), so
this is a smaller change than it looks like.
Instead of setting empty closure (`{}`) result type to be `Void`
while generating constraints, let's allocate a new type variable
instead and let it be bound to `Void` once the body is opened.
This way we can support an interaction with function builders which
would return a type different from `Void` even when applied to empty closure.
Resolves: rdar://problem/61347993
Like switch cases, a catch clause may now include a comma-
separated list of patterns. The body will be executed if any
one of those patterns is matched.
This patch replaces `CatchStmt` with `CaseStmt` as the children
of `DoCatchStmt` in the AST. This necessitates a number of changes
throughout the compiler, including:
- Parser & libsyntax support for the new syntax and AST structure
- Typechecking of multi-pattern catches, including those which
contain bindings.
- SILGen support
- Code completion updates
- Profiler updates
- Name lookup changes
Unfortunately we still need this performance hack because otherwise
e.g. if initializer returns a tuple its type is going to be connected
to a type variable representing a pattern type, which means all of the
tuple element types are going to form a single constraint system component.
Resolves: rdar://problem/60961087
In each of the following situations `getTypeForPattern` would
add a new pattern element to the path:
- Element of a tuple pattern
- Sub-pattern of a typed pattern
- Sub-pattern of optional .some
Problems related to incorrect use of `_` where previously diagnosed
by syntactic diagnostics which meant that it could only happen on
type-checked AST. This is no longer a case so we don't have to allow
incorrect uses of `_` to form solution without any fixes.
`_` or discard assignment expression should only be used on the left-hand
side of the assignment expression. Incorrect uses are easy to detect during
constraint generation which also allows us to avoid complications related
to other diagnostics when `_` is used incorrectly.
