Make sure we query the constraint system for a type if we have a local
property wrapper in a closure to avoid kicking interface type
computation outside the closure, and make sure we map into context if
we need to.
These methods can be simplified a bunch since the returned decl is
always the input decl and we can refactor the lambdas to just return
the auxiliary variable and have the type computation in the caller.
This test case crashes when prepared overloads are disabled, but passes
when enabled. To avoid messing up tests if we have to turn the flag on
and off, fix the crash.
Move the logic from `FailureDiagnostic::resolveType` into
`Solution::simplifyType` to allow completion to use it too. While
here, also handle cases where the placeholder is from a different
member of the equivalence class to the generic parameter.
This means we now either produce a bare ErrorType, or an ErrorType
with a generic parameter original type for a generic parameter hole.
We ought to further consolidate this logic by sinking the generic
parameter original type replacement into `simplifyType` itself, but
I'm leaving that for a future patch since it affects completion
results and I want to try keep this close to NFC.
Untyped throws depends on existentials (`any Error`), and is therefore
not available in Embedded Swift. Introduce a diagnostic that diagnoses
any use of untyped throws, suggesting that one use typed throws
instead.
Make this an opt-in diagnostic enabled with `-Wwarning
EmbeddedRestrictions`, whether in Embedded Swift or not, using the
"default ignore" flag on these new warnings. Document this new
diagnostic group, and put the existing Embedded Swift error about
weak/unowned references in it as well.
Part of the general push to have the type checker identify code that
will not compile as Embedded Swift earlier, rdar://133874555.
- Introduce a generic requirements opening function for type resolution,
which is used by the constraint system in cases where we need to
impose requirements on opened type variables.
- Refactor `replaceInferableTypesWithTypeVars` to use this function
when opening generic types that contain either placeholder or unbound
generic types.
Together these changes ensure that we don't drop generic requirements
when an unbound generic or placeholder type is used as a generic
argument.
This is a diagnostic that is only really emitted as a fallback when
the constraint system isn't able to better diagnose the expression.
It's not particulary helpful for the user, and can be often be
misleading since the underlying issue might not actually be an
ambiguity, and the user may well already have a type annotation. Let's
instead just emit the fallback diagnostic that we emit in all other
cases, asking the user to file a bug.
Since this is a C++ stdlib type we need make sure that any overloads
that use it are preferred over custom types that also conform to
`ExpressibleByStringLiteral` when argument is a string literal.
This is important for operators like `==` which could be heterogenous
and have a custom C++ type that conforms to `ExpressibleByStringLiteral`
on either side together with `std.string` i.e.
`==(std.string, const CustomString &)`, such overloads should only
be selected if argument passed to `CustomString` is non-literal because
literals are convered by a stdlib `==(std.string, std.string)` overload.
The present approach is not prudent because `@concurrent` synchronous
functions, a natural extension, are a likely-to-happen future direction,
whereas the current inference rule is entirely grounded on `@concurrent`
being exclusive to async functions.
If we were to ship this rule, we would have to keep the promise for
backwards compatibility when implementing the aforementioned future
direction, replacing one inconsistency with another, and possibly
introducing new bug-prone expression checking code.
```swift
func foo(_: () -> Void) {}
func foo(_: () async -> Void) {}
// In a future without this change and `@concurrent` synchronous
// functions accepted, the first call resolves to the first overload,
// and the second call resolves to the second, despite `@concurrent` no
// longer implying `async`.
foo { }
foo { @concurrent in }
```
This change also drops the fix-it for removing `@concurrent` when used
on a synchronous closure. With the inference rule gone, and the
diagnosis delayed until after solution application, this error raises a
fairly balanced choice between removing the attribute and being
explicit about the effect, where a unilateral suggestion is quite
possibly more harmful than useful.
Previously, only conditional unavailability was considered, but setters that
are always unavailable must also make a keypath read-only.
Resolves rdar://155832511.
`TypeSimplifier` may not eliminate type variables from e.g the
pattern types of pattern expansion types since they can remain
unresolved due to e.g having a placeholder count type. Make sure we
eliminate any remaining type variables along with the placeholders.
There's probably a more principled fix here, but this is a quick and
low risk fix we can hopefully take for 6.2.
rdar://154954995
My change 983b75e1cf broke
-warn-long-expression-type-checking because now the
ExpressionTimer is not instantiated by default and that
entire code path is skipped.
Change it so that if -warn-long-expression-type-checking
is passed in, we still start the timer, we just don't
ever consider it to have 'expired'.
Fixes rdar://problem/152998878.
Introduction of `@concurrent` attribute caused an unintended
side-effect in `ClosureEffectsRequest` since the attribute
could only be used on `async` types setting `async` too early
prevented body analysis for `throws` from running.
Resolves: rdar://151421590
Several callers of `AbstractStorageDecl::getAccessStrategy` only cared
about whether the the access would be via physical storage. Before
adding more arguments to `getAccessStrategy` for which such callers
would have to pass a sentinel value, add a convenience method for this.
Fixes a crash when existing logic cannot properly determine whether
argument is resolved or not.
Instead of ad-hoc code that checks `ResolvedOverloads` directly, let's
use a method that would reach of a callee locator to determine whether
argument is a reference to a generic function or not.
Resolves: rdar://137825558
Factor out `ConstraintSystem::getExplicitCaughtErrorType` from
`getCaughtErrorType`. Then use this for the contextual
type for a `throw` syntactic element.
rdar://139000351
