This means two things:
- transformed closures behave just like regular multi-statement closures
- It's now possible to pass partially resolved parameter types into
the closure which helps with diagnostics.
where `MO` is a move-only type.
turns out it was being allowed because the cast is represented as a
disjunction in the constraint solver:
- `MO conv AnyObject`
- `MO bridge conv AnyObject`
I caught the first one but missed the second, which was unconditionally
being allowed.
Since values of generic type are currently assumed to always
support copying, we need to prevent move-only types from
being substituted for generic type parameters.
This approach leans on a `_Copyable` marker protocol to which
all generic type parameters implicitly must conform.
A few other changes in this initial implementation:
- Now every concrete type that can conform to Copyable will do so. This fixes issues with conforming to a protocol that requires Copyable.
- Narrowly ban writing a concrete type `[T]` when `T` is move-only.
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.
associated failure diagnostic.
This constraint fix is unused now that MacroExpansionExpr always has an
argument list, and goes through the AddMissingArguments constraint fix for
this error.
Member chains with leading-dot syntax can infer the base type
only from context, so optionality mismatch with the contextual
type should propagate object type down the chain.
If base type of the leading-dot syntax expression has been determined
to be a placeholder, this could only mean that `.<name>` couldn't be
resolved in the current context.
Resolves: rdar://104302974
If a placeholder appears on one of the side of tuple element matching
conversion, consider that conversion to be solved, because the actual
error is related to the placeholder.
It's ok to drop the global-actor qualifier `@G` from a function's type if:
- the cast is happening in a context isolated to global-actor `G`
- the function value will not be `@Sendable`
- the function value is not `async`
It's primarily safe to drop the attribute because we're already in the
same isolation domain. So it's OK to simply drop the global-actor
if we prevent the value from later leaving that isolation domain.
This means we no longer need to warn about code like this:
```
@MainActor func doIt(_ x: [Int], _ f: @MainActor (Int) -> ()) {
x.forEach(f)
// warning: converting function value of type '@MainActor (Int) -> ()' to '(Int) throws -> Void' loses global actor 'MainActor'
}
```
NOTE: this implementation is a bit gross in that the constraint solver
might emit false warnings about casts it introduced that are actually
safe. This is mainly because closure isolation is only fully determined
after constraint solving. See the FIXME's for more details.
resolves rdar://94462333
* [CSSimplify] fix pattern matching logic which is as part of the enum element for closure
* add test
* Fixed logic to apply to N levels of nesting
* update tests that take into account N levels of nesting.
* fix indentation
* use dynamic variables and uppdate some logic
* Revert "use dynamic variables and uppdate some logic"
This reverts commit 279dc4fe6b.
* fix logic to only see pattern matches
* clean up unnecessary logic
Co-authored-by: Luciano Almeida <passos.luciano@outlook.com>
* Clean up unnecessary logic(2)
* remove dropping
* Fix documentation comments to match current context
* clean up unnecessary logic
* remove comments
Co-authored-by: Luciano Almeida <passos.luciano@outlook.com>
constraints, vend potential bindings through PotentialBindings::infer.
This allows for bidirectional binding inference from the pack type to the
element type and vice versa.
The lexer will be responsible for knowing whether we have a code completion token, everything else will also work for other IDE inspection features.
The changes start to really make sense once I rename CodeCompletion -> IDEInspection in a lot of places.
SE-0110 allows tuple slat between function types. The solver needs to
account for that when trying to infer parameter types from context
while resolving a closure in order to propagate types and speed up
type-checking.
Resolves: https://github.com/apple/swift/issues/62390
Enable type checking support for explicitly specifying generic arguments to
a macro, e.g., `#stringify<Double>(1 + 2)`. To do so, introduce a new
kind of constraint that performs explicit argument matching against the
generic parameters of a macro only after the overload is chosen.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
