Previously for-in target was actually an expression target, which means
certain type-checking behavior. These changes make it a standalone target
with custom behavior which would allow solver to introduce implicit
`makeIterator` and `next` calls and move some logic from SILGen.
For all of the `build*` calls, let's use a special variable declaration
`$builderSelf` which refers to a type of the builder used. This allows
us to remove hacks related to use of `TypeExpr`. Reference to `$builderSelf`
is replaced with `TypeExpr` during solution application when the builder
type is completely resolved.
We record fixes while solving normal expressions for code completion and we should do the same when solving result builders if we are reporting the solutions to completion callbacks.
Enables SE-0348 `buildPartialBlock` feature by default. The frontend flag is kept for compatibility with existing clients, but is now ineffective.
Also includes some improved error messages for invalid result builder call sites.
This hooks up call argument position completion to the typeCheckForCodeCompletion API to generate completions from all the solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any).
Co-authored-by: Nathan Hawes <nathan.john.hawes@gmail.com>
This PR implements support for `buildPartialBlock` as proposed in https://forums.swift.org/t/pitch-buildpartialblock-for-result-builders/55561. This is similar to the existing support for `buildBlock(combining:into:)` except that it also checks for availability when deciding whether to fall back to plain old `buildBlock`.
> In the result builder transform, the compiler will look for static members `buildPartialBlock(first:)` and `buildPartialBlock(accumulated:next:)` in the builder type. If the following conditions are met:
> - Both methods `buildPartialBlock(first:)` and `buildPartialBlock(accumulated:next:)` exist.
> - The availability of the enclosing declaration is greater than or equal to the availability of `buildPartialBlock(first:)` and `buildPartialBlock(accumulated:next:)`.
When there's no available `buildPartialBlock` to call and there's no `buildBlock`, emit a diagnostic:
```console
result builder 'Builder' does not implement any 'buildBlock' or a combination of 'buildPartialBlock(first:)' and 'buildPartialBlock(accumulated:next:)' with sufficient availability for this call site
```
Allow a user-defined `buildBlock(combining:into:)` to combine subexpressions in a block pairwise top to bottom. To use `buildBlock(_combining:into:)`, the user also needs to provide a unary `buildBlock(_:)` as a base case. The feature is being gated under frontend flag `-enable-experimental-pairwise-build-block`.
This will enable use cases in `RegexBuilder` in experimental declarative string processing, where we need to concatenate tuples and conditionally skip captureless regexes. For example:
```swift
let regex = Regex {
"a" // Regex<Substring>
OneOrMore("b").capture() // Regex<(Substring, Substring)>
"c" // Regex<Substring>
Optionally("d".capture()) // Regex<(Substring, Substring?)>
} // Regex<Tuple3<Substring, Substring, Substring?>>
let result = "abc".firstMatch(of: regex)
// MatchResult<(Substring, Substring, Substring?)>
```
In this example, patterns `"a"` and `"c"` have no captures, so we need to skip them. However with the existing result builder `buildBlock()` feature that builds a block wholesale from all subexpressions, we had to generate `2^arity` overloads accounting for any occurrences of captureless regexes. There are also other complexities such as having to drop-first from the tuple to obtain the capture type. Though these features could in theory be supported via variadic generics, we feel that allowing result builders to pairwise combine subexpressions in a block is a much simpler and potentially more useful approach.
With `buildBlock(_combining:into:)`, the regex builders can be defined as the following, assuming we have variadic generics:
```swift
enum RegexBuilder {
static func buildBlock() -> Regex<Substring>
static func buildBlock<Match>(_ x: Regex<Match>) -> Regex<Match>
static func buildBlock<
ExistingWholeMatch, NewWholeMatch, ExistingCaptures..., NewCaptures...
>(
_combining next: Regex<(NewWholeMatch, NewCaptures...)>,
into combined: Regex<(ExistingWholeMatch, ExistingCaptures...)>
) -> Regex<Substring, ExistingCaptures..., NewCaptures...>
}
```
Before we have variadic generics, we can define overloads of `buildBlock(_combining:into:)` for up to a certain arity. These overloads will be much fewer than `2^arity`.
* [ConstraintSystem] NFC: Rename `openOpaqueTypeRec` and make `openOpaqueType` private for individual types
* [ConstraintSystem] Require a contextual purpose for `openOpaqueType(Type, ...)`
Some of the contexts require special handling e.g. return type of a function
can only open directly declared opaque result type(s), this would be
implemented in a follow-up commit.
* [ConstraintSystem] Open only directly declared opaque types related to return statements
Re-establish a check which would only open opaque types directly
declared in the return type of a function/accessor declaration,
otherwise constraint system would end up with type variables it
has no context for if the type had generic parameters.
Resolves: rdar://81531010
* [TypeResolver][TypeChecker] Add support for structural opaque result types
* [TypeResolver][TypeChecker] Clean up changes that add structural opaque result types
There were a couple of places where we weren't
handling a nullptr return from one of the visitor
methods. Change the methods to return NullablePtr
and add the missing null checks.
rdar://81228221
While determining whether result builder body is correct, allow
pre-check phase to look into single-statement closures because
their bodies participate in type-check and would fail constraint
generation if they contain `ErrorExpr`s, so it's better to determine
that the body is invalid early and skip result builder application.
Resolves: rdar://79746785
Merge together several helpers and code patterns for “diagnose/fix-it/invalidate bad attribute” into helper functions in TypeChecker.h.
This requires minor test changes in some places where we’re testing ObjC interop without importing Foundation; it’s otherwise NFC.
Not all of the pre-check errors could be diagnosed by re-running
`PreCheckExpression` e.g. key path expressions are mutated to
a particular form after an error has been produced.
To make the behavior consistent, let's allow pre-check to emit
diagnostics and unify pre-check and constraint generation fixes.
Resolves: rdar://77466241
Having purpose attached to the contextual type element makes it much
easier to diagnose contextual mismatches without involving constraint
system state.
We assume that presence of `ErrorExpr` means that the problem has
been diagnosed early (i.e. by parser), so the fix is going to return
`true` if diagnostic engine has emitted an error.
Resolves: rdar://76246526
..when typechecking for code completion.
They were disallowed to give better diagnostics, but code completion suppresses
diagnostics and can't provide any completions at all when the transform fails as
it doesn't get any types.
Resolves rdar://problem/74028722
We would previously reject properties without an initializer expression,
but this is not quite sufficient, because of 'lazy', property wrappers,
and observers.
We could probably support all three in result builder contexts, but
for now, let's diagnose them like other computed properties, instead of
crashing.
Fixes part of <rdar://problem/73545981>.
* Initial draft of async sequences
* Adjust AsyncSequence associated type requirements
* Add a draft implementation of AsyncSequence and associated functionality
* Correct merge damage and rename from GeneratorProtocol to AsyncIteratorProtocol
* Add AsyncSequence types to the cmake lists
* Add cancellation support
* [DRAFT] Implementation of protocol conformance rethrowing
* Account for ASTVerifier passes to ensure throwing and by conformance rethrowing verifies appropriately
* Remove commented out code
* OtherConstructorDeclRefExpr can also be a source of a rethrowing kind function
* Re-order the checkApply logic to account for existing throwing calculations better
* Extract rethrowing calculation into smaller functions
* Allow for closures and protocol conformances to contribute to throwing
* Add unit tests for conformance based rethrowing
* Restrict rethrowing requirements to only protocols marked with @rethrows
* Correct logic for gating of `@rethrows` and adjust the determinates to be based upon throws and not rethrows spelling
* Attempt to unify the async sequence features together
* Reorder try await to latest syntax
* revert back to the inout diagnosis
* House mutations in local scope
* Revert "House mutations in local scope"
This reverts commit d91f1b25b59fff8e4be107c808895ff3f293b394.
* Adjust for inout diagnostics and fall back to original mutation strategy
* Convert async flag to source locations and add initial try support to for await in syntax
* Fix case typo of MinMax.swift
* Adjust rethrowing tests to account for changes associated with @rethrows
* Allow parsing and diagnostics associated with try applied to for await in syntax
* Correct the code-completion for @rethrows
* Additional corrections for the code-completion for @rethrows this time for the last in the list
* Handle throwing cases of iteration of async sequences
* restore building XCTest
* First wave of feedback fixes
* Rework constraints checking for async sequence for-try-await-in checking
* Allow testing of for-await-in parsing and silgen testing and add unit tests for both
* Remove async sequence operators for now
* Back out cancellation of AsyncIteratorProtocols
* Restructure protocol conformance throws checking and cache results
* remove some stray whitespaces
* Correct some merge damage
* Ensure the throwing determinate for applying for-await-in always has a valid value and adjust the for-await-in silgen test to reflect the cancel changes
* Squelch the python linter for line length
