Allow opaque type declarations to have multiple unique underlying
types if all such types are conditional on availability via
`if #available(...)` and there is only one universally available
substitution. Neither nesting of availability conditions nor other
dynamic conditions are allowed.
For example:
```swift
protocol P {}
@available(iOS 31.337, *)
struct X : P {
}
struct Y : P {
}
func test() -> some P {
if #available(iOS 31.337, *) {
// ... some computation ...
return X()
}
return Y()
}
```
Allows `some P` to refer to `X` instead of `Y` on `iOS 31.337`.
Since opaque result type can reference generic parameters of context,
it cannot reply purely on "index" of the opaque generic parameter
while diagnosing a problem, it needs to perform a type substitution
using a substitution map of a particular candidate to determine the
underlying type.
Resolves: rdar://90456579
Restrict the warning to diagnose only explicit instances of `self` reference
that do not mention the parent type via dot syntax e.g. `MyStruct.self`.
Resolves: SR-15897
Resolves: SR-15691
Resolves: rdar://90624344
https://github.com/apple/swift/pull/37992/ introduced a warning when you
were likely to confuse `self` with `TypeName.self`, this also applied to
enum cases that were named `self`, these cases should not be easily
confused at call sites since their use requires prefixing them with a
`.`. There was also no way to avoid this warning since other syntax such
as `TypeName.self`, which produces the enum type instead, or
`` TypeName.`self` `` which produced the same warning again.
Fixes https://bugs.swift.org/browse/SR-15691
Address small gaps in several places to make named opaque result types
partially work:
* Augment name lookup to look into the generic parameters when inside the
result type, which is used both to create structure and add requirements
via a `where` clause.
* Resolve opaque generic type parameter references to
OpaqueTypeArchetypeType instances, as we do for the "some" types
* Customize some opaque-type-specific diagnostics and type printing to
refer to the opaque generic parameter names specifically
* Fix some minor issues with the constraint system not finding
already-opened opaque generic type parameters and with the handling of
the opaque result type candidate set.
The major limitation on opaque types, where we cannot add requirements
that aren't strictly protocol or superclass requirements on the
generic parameters, remains. Until then, named opaque result types are
no more expressive than structural opaque result types.
Remove the error that prevented the use of multiple opaque result types,
which was the remaining blocker for SE-0328's structural opaque result
types. Add some type checking tests for this feature, and customize
the diagnostics so they describe *which* opaque result type failed to
match when indeed there is a failure.
Opaque opaque types and record them within the "opened types" of the
constraint system, then use that information to compute the set of
substitutions needed for the opaque type declaration using the normal
mechanism of the constraint solver. Record these substitutions within
the underlying-to-opaque conversion.
Use the recorded substitutions in the underlying-to-opaque conversion
to set the underlying substitutions for the opaque type declaration
itself, rather than reconstructing the substitutions in an ad hoc manner
that does not account for structural opaque result types.
This cleans up 90 instances of this warning and reduces the build spew
when building on Linux. This helps identify actual issues when
building which can get lost in the stream of warning messages. It also
helps restore the ability to build the compiler with gcc.
With the argument list refactoring, it's no
longer sufficient to stop walking when we encounter
an explicit tuple or paren. Add an additional
check to stop walking when we encounter an explicit
argument list.
rdar://85343171
Now that placeholder types are preserved, we can open them wherever they appear in positions where they are used as contextual types. Use the checks we already run in the primaries to ban placeholders in top-level positions. Only now, use the inferred type of any associated expressions or statements to present the user with a contextual return type.
For parameters in functions and enum cases, we use any default argument expressions to get the contextual type.
For functions, we use a traversal similar to the opaque result type finder to find the type of any return statements in the program and present those as options.
For a non-public property where the type is defined by an assignment, like
`internal var internalAssigned = NewStruct()`, type-checking the type's
availability is done via checking the initializer expression.
In -check-api-availaiblity-only mode, pass down a flag to not check
availability in expressions for initializer expressions of such
non-public properties.
rdar://84389825
We've always emitted an error if we saw an implicit use of a self
parameter of class type from an escaping closure. In PR #35898, I fixed
this to also emit an error if the reference was to an explicit capture
of self that wasn't made in the current closure. That was causing
some source incompatibilities that we decided were too severe, so in
PR #38947 I weakened that to a warning when the diagnostic walk was
within multiple levels of closures, because I have always thought of
this as a fix to nested closures. However, this was the wrong condition
in two ways.
First, the diagnostic walk does not always start from the outermost
function declaration; it can also start from a multi-statement closure.
In that case, we'll still end up emitting an error when we see uses
of explicit captures from the closure when we walk it, and so we still
have a source incompatibility. That is rdar://82545600.
Second, the old diagnostic did actually fire correctly in nested
closures as long as the code was directly referring to the original
self parameter and not any intervening captures. Therefore, #38947
actually turned some things into warnings that had always been errors.
The fix is to produce a warning exactly when the referenced declaration
was an explicit capture.
Just for convenicence.
* Replace `llvm::isa_and_nonnull` with imported `isa_and_nonnull`
* Repalce some `EXPR && isa<T>(EXPR)` with `isa_and_nonnull<T>(EXPR)`
With the introduction of the ArgumentList type,
argument expressions will be direct decedents of
call expressions, without an intermediate TupleExpr.
As such, we need to tweak isValidTypeExprParent to
consider the child expression such that `T(x)` is
permissible, but `x(T)` is not.
Change isValidTypeExprParent to take a child expr
parameter, and update its use in MiscDiagnostics
and PreCheckExpr. For PreCheckExpr, switch from a
stack to walking the parent directly, as a
stack-based approach would be a bit more fiddly in
this case, and walking the parents shouldn't be
expensive.
This should be NFC, I'm splitting it off from the
ArgumentList refactoring to make the rebasing there
a little more straightforward.
The following regression test added for this feature is not passing:
Swift(linux-x86_64) :: decl/protocol/protocols_with_self_or_assoc_reqs_executable.swift
with a compiler crash happening during SILFunctionTransform "Devirtualizer".
Reverting to unblock CI.
This reverts commit f96057e260, reversing
changes made to 3fc18f3603.
