https://github.com/swiftlang/swift/pull/72659 turned out to have some
source compatibility fallout that we need to fix. Instead of introducing
yet another brittle compatibility hack, stop emitting errors about a
missing `any` altogether until a future language mode.
Besides resolving the compatibility issue, this will encourage
developers to adopt any sooner and grant us ample time to gracefully
address any remaining bugs before the source compatibility burden
resurfaces.
A subsequent commit adds a diagnostic group that will allow users to
escalate these warnings to errors with `-Werror ExistentialAny`.
This workaround is no longer needed because `TypeAliasType` is now
modeled using generic arguments (as opposed to a substitution map).
Previously, computing the substitution map in `StructuralTypeRequest` to
construct the resulting `TypeAliasType` could cause a request cycle
around generic signature computation.
Instead of making an undo() do an infer(), let's record fine-grained
changes about what was retracted, and directly re-insert the same
elements into the data structures.
Also stop suggesting a '?' fix-it for casts, where it is not likely to
be helpful because the common intention is either to force the optional
or declare an IUO.
Recent refactoring fixed a bug that previously caused `f()` to be checked as if
it were unavailable only on macOS in the following example:
```
@available(macOS, unavailable)
struct Outer {
@available(*, unavailable)
func f() {
someFunctionUnavailableOnMacOS()
}
}
```
Unfortunately, fixing that bug made a different existing availability checking
rule more problematic. References to declarations that are unavailable on the
current platform have been diagnosed as unavailable even in contexts that are
universally unavailable. This long standing behavior is overly strict but it
rarely had consequences. However, now that the example above is modeled
correctly, this overly strict behavior is causing some source compatibility
issues. The easiest solution is to relax the overly strict checking.
Resolves rdar://141124478.
Just because the type of the initializer expression is an opaque return type,
does not mean it is the opaque return type *for the variable being initialized*.
It looks like there is a bit of duplicated logic and layering violations going
on so I only fixed one caller of openOpaqueType(). This addresses the test case
in the issue. For the remaining calls I added FIXMEs to investigate what is
going on.
Fixes https://github.com/swiftlang/swift/issues/73245.
Fixes rdar://127180656.
Previously we would check if we have a SwitchStmt,
and apply diagnostics such as `checkExistentialTypes`
to the CaseStmts individually. This however would
have been missed for `catch` statements. The change
to consistently call `performStmtDiagnostics` in
closures fixed this for `do-catch`'s in closures,
this commit fixes it for those outside of closures.
Because this is source breaking, the existential
diagnostic is downgraded to a warning until Swift
7 for catch statements specifically.
While here, also apply the ambiguous where clause
diagnostic to `catch` statements.
A function declaration cannot have an opaque parameter type appearing in
consuming position:
func f(_: (some P) -> ()) {}
However, we should skip this check for a closure, because if the
closure's parameter list references an opaque parameter declaration,
it means something else: namely, the inferred type of the closure
refers to an opaque parameter from an outer scope. That's allowed.
This unnecessary prohibition has been there ever since the check was
added, but only for multi-statement closures, so nobody seemed to
notice.
When https://github.com/swiftlang/swift/pull/76473 made it so we always
call TypeChecker::checkParameterList(), this exposed the problem in a
single-expression closure in an existing project.
Fixes rdar://139237671.
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
During the lifecycle of a feature, it may start as an experimental feature and
then graduate to become an upcoming feature. To preserve compatibility with
projects that adopted the feature when it was experimental,
`-enable-experimental-feature` ought to be able to enable upcoming features,
too.
Since projects may use `-enable-experimental-feature` for compatibility with an
older toolchain that does not have the feature as an upcoming feature, there is
no warning when the flag is used to enable an upcoming feature.
Note that if the semantics of a feature change when it graduates from
experimental to upcoming, then the feature must be renamed so that projects
using the experimental feature have an opportunity opt-in to the new semantics
of the upcoming feature.
Resolves rdar://134276783.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
The checking for ExistentialAny diagnostics needed to be updated to both
handle the new Copyable/Escapable protocols that appear in the Any and
AnyObject existential layouts.
resolves rdar://123332844
We used to disallow pack expansions in generic argument lists of
protocols, but allow them for all other nominal types. However,
we only actually checked that the pack expansions match up if
the type itself was variadic.
Fix this by repurposing Context::ProtocolGenericArgument into
Context::ScalarGenericArgument, and using that when the type does
not have a parameter pack.
Context::GenericArgument is now Context::VariadicGenericArgument,
and we only use it if the type has a parameter pack, in which case
we use the PackMatcher, so any pack expansions in the wrong place
are caught there.
Fixes rdar://116716014 and https://github.com/apple/swift/issues/69088.
When using an experimental feature that is not available
in production, a test needs to have `REQUIRES: asserts`
so that non-assert builds don't unexpectedly fail.
We already had a separate TypeResolverContext::ProtocolGenericArgument that
did not allow PackExpansionTypes, but it was never used.
Fixes rdar://problem/115538574.
