* Use fancy arrows (`→`) because they are distinct from and shorter than `->`,
and fancier.
* We have two ways of demarcating locators: `@ <locator>` and `[[<locator>]];`.
Stick to the first, which is shorter and clearer.
* 'attempting type variable' → 'attempting binding'. *Bindings* are attempted,
not type variables.
* `considering ->` → `considering:`. I think a colon is semantically more fit
and makes things easier to read if the considered constraint has arrows in its
description or types. It’s also shorter this way.
In Swift 5 and earlier initializer references are handled in a special
way that uses a type variable to represent a type of the parameter
list. Such type variables should be allowed to bind to a pack expansion
type to support cases where initializer has a single unlabeled variadic
generic parameter - `init(_ data: repeat each T)`.
Delay constraint generation for capture list until body of
the associated closure is resolved. This means that we can
unify capture checking with that of regular pattern bindings
for multi-statement closures.
element environments.
This allows the constraint system to ensure that for a given pack expansion locator,
the given shape class is always the same when requesting the element environment.
If the shape class differs, it means there's a same-shape requirement failure, which
will be diagnosed via the ShapeOf constraint simplification.
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
`addExplicitConversionConstraint` generates a disjunction to check
whether type could be coerced via bridging. That is not useful for
literal initialization which could use direct equality if the type
of cast is valid because necessary conformance checks have been
performed before the transformation.
It's possible for out-of-scope type variable to be the type of
declaration if such declaration is recursively referenced in
the body of a closure located in its initializer expression.
In such cases type of the variable declaration cannot be connected
to the closure because its not known in advance (determined by the
initializer itself).
Resolves: https://github.com/apple/swift/issues/63455
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
Describe attached macros with the `@attached` attribute, providing the
macro role and affected names as arguments to the macro. The form of
this macro will remain the same as it gains other kinds of attached
macro roles beyond "accessor".
Remove the "accessors" role from `@declaration`, which will be going
away.
Add support for freestanding declaration macros.
- Parse `@declaration` attribute.
- Type check and expand `MacroExpansionDecl`.
Known issues:
- Generic macros are not yet handled.
- Expansion does not work when the parent decl context is `BraceStmt`. Need to parse freestanding declaration macro expansions in `BraceStmt` as `MacroExpansionDecl`, and add expanded decls to name lookup.
