This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
warning.
These diagnostics are stricter in the RequirementMachine than in the GSB,
and there's code that relies on the more relaxed diagnostics in the source
compatibility suite. Downgrade these diagnostics to a warning using
warnUntilSwiftVersion(6).
- Don't pass 'verify' since it's now the default
- Update tests where diagnostics changed in a correct way to pass 'on' instead
- Delete compiler_scale/explicit_requirements_perf.swift since it's not testing anything with the requirement machine
When emitting a diagnostic, mark the TypeRepr as invalid and
return an ErrorType to ensure that the diagnostic is not
emitted again, and to muffle downstream diagnostics.
Always parse `async` and `await`, allowing the definition and use of
asynchronous functions without the "experimental concurrency" flag.
Note that, at present, use of asynchronous functions requires one to
explicitly import or link against the `_Concurrency` library. We'll
sort this out in a follow-up change.
Tracked by rdar://73455330.
* [Diagnostics] Update 'does not override' diagnostic message to include protocol context as well
* [Sema] Check whether the override context is a class or a protocol for diagnostic purposes
* [Test] Update tests with new diagnostic message for overrides in protocol context
* [Sema] Adjust diagnostic for overrides in structs and enums to use the existing 'override_nonclass_decl' diagnostic
Clean up a few general patterns that are now obviated by canImport
This aligns more generally with the cleanup that the Swift Package
Manager has already done in their automated XCTest-plumbing tool in
apple/swift-package-manager#1826.
Previously, the protocol refinement access control error
would always assume a protocol was being refined. Change it
to instead refer to the appropriate declaration kind.
Resolves SR-9195
There is a small chance that codegen and everything works fine, but the
generated code is wrong because of mismatched expectations on two sides,
so we have some tests to catch that.
Instead of always requiring a call to be made to pass argument
to `@autoclosure` parameter, it should be allowed to pass argument
by value to `@autoclosure` parameter which can return a function
type.
```swift
func foo<T>(_ fn: @autoclosure () -> T) {}
func bar(_ fn: @autoclosure @escaping () -> Int) { foo(fn) }
```
Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
Expression patterns (and cast patterns) don't actually contribute to
the exhaustivity of a switch statement---if you're matching against a
String, matching "abc" doesn't meaningfully reduce the full space of
the values you have to match. This was already handled, but didn't do
the right thing in a particular case involving a tuple payload in an
enum after the Space Engine (exhaustivity checker) optimizations that
went out in Swift 5.
https://bugs.swift.org/browse/SR-10301
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
Back when SE-0110 was implemented we decided that passing a function value
taking multiple parameters would be allowed where a function value taking
a single tuple argument was expected.
Due to quirks in the old function type representation, the "splat" in the
other direction sometimes worked too. When we redid the function type
representation we added a simulation of the old quirk for -swift-version 4
mode.
However this simulation was itself problematic because it only worked when
the function value being passed was a non-overloaded declaration reference.
Slightly broaden the hack to the overloaded case, to prevent user
confusion when adding or removing overloads.
If the access level of a protocol witness does not satisfies a requirement,
the compiler suggests marking it as the required level. This is not suitable
when the witness is in an extension whose specified access level is less than
the required level, since the fixit fights with other warnings in this case.
This patch identifies such case and produces improved diagnostics.
Resolves: SR-9793
This is reasonable to diagnose with a warning, but dropping the 'open'
down to 'public' isn't the right fix, because now it's not a valid
override. The declaration has to get moved to another extension instead,
or the extension has to not set a default access level.
This turned out to be a source compat issue because the same logic
that emits the fix-it also updates the access of the member, which
then resulted in "must be as accessible as the declaration it
overrides" in the /same/ build. It's not immediately clear what caused
this; probably something's just being validated in a different order
than it was before. The change makes sense either way.
Stepping back, it's weird that a warning would change how the compiler
saw the code, and while we could check for 'override' explicitly, we
can't know if the member might be satisfying a protocol requirement.
Better to just not guess at the right answer here.
rdar://problem/47557376&28493971
Try to fix constraint system in a way where member
reference is going to be defined in terms of its use,
which makes it seem like parameters match arguments
exactly. Such helps to produce solutions and diagnose
failures related to missing members precisely.
These changes would be further extended to diagnose use
of unavailable members and other structural member failures.
Resolves: rdar://problem/34583132
Resolves: rdar://problem/36989788
Resolved: rdar://problem/39586166
Resolves: rdar://problem/40537782
Resolves: rdar://problem/46211109
