Evaluating LifetimeDependence changes the order that the declarations are
diagnosed. Fix this test output by flipping the order of two declarations. The
new order actually makes more sense to me.
(cherry picked from commit c40fd2a0cce97d8983c9f23206ba89b4c06a4158)
In b30006837e, I changed the `if`
condition here to check for the absence of type variables as well
as type parameters. This is incorrect; the type variables come up
in ValueWitnessRequest, and the type parameters come up in
associated type inference. We want the matching to be more lax
in the former case.
Fixes rdar://149438520.
Print diagnostic groups as part of the LLVM printer in the same manner as the
Swift one does, always. Make `-print-diagnostic-groups` an inert option, since we
always print diagnostic group names with the `[#GroupName]` syntax.
As part of this, we no longer render the diagnostic group name as part
of the diagnostic *text*, instead leaving it up to the diagnostic
renderer to handle the category appropriately. Update all of the tests
that were depending on `-print-diagnostic-groups` putting it into the
text to instead use the `{{documentation-file=<file name>}}`
diagnostic verification syntax.
A protocol conformance can be ill-formed due to isolation mismatches
between witnesses and requirements, or with associated conformances.
Previously, such failures would be emitted as a number of separate
errors (downgraded to warnings in Swift 5), one for each witness and
potentially an extra for associated conformances. The rest was a
potential flood of diagnostics that was hard to sort through.
Collect all of the isolation-related problems for a given conformance
together and produce a single error (downgraded to a warning when
appropriate) that describes the overall issue. That error will have up
to three notes suggesting specific courses of action:
* Isolating the conformance (when the experimental feature is enabled)
* Marking the witnesses as 'nonisolated' where needed
*
The diagnostic also has notes to point out the witnesses/associated
conformances that have isolation problems. There is a new educational
note that also describes these options.
We give the same treatment to missing 'distributed' on witnesses to a
distributed protocol.
When diagnosing an isolation mismatch between a requirement and witness,
we would produce notes on the requirement itself suggesting the addition of
`async`. This is almost never what you want to do, and is often so far
away from the actual conforming type as to be useless. Remove this note,
and the non-function fallback that just points at the requirement, because
they are unhelpful.
This is staging for a rework of the way we deal with conformance-level
actor isolation problems.
The attribute makes the declaration unavailable from the perspective of clients
of the module's public interface and was creating a loophole that admitted
inappropriate unavailability.
Implement lookup of availability domains for identifiers on
`AvailabilityDomainOrIdentifier`. Add a bit to that type which represents
whether or not lookup has already been attempted. This allows both
`AvailableAttr` and `AvailabilitySpec` to share a common implementation of
domain lookup.
An `AvailableAttr` written in source with an unrecognized availability domain
is now only marked invalid after type-checking the attribute. This resulted in a
regression where `CaseIterable` synthesis was blocked incorrectly under the
following very narrow circumstances:
1. Every `@available` attribute on the elements of the enum is invalid.
2. The module is being emitted and lazy type-checking is enabled.
3. The enum is public and the only top-level declaration in the file.
Type-checking the attribute was delayed just enough that it would not be
considered invalid by the type the `CaseIterable` conformance was being
synthesized, resulting in a spurious error.
There were zero tests exercising `CaseIterable` synthesis for enums with
elements that have availability requirements, so I added some.
Resolves rdar://144897917.
Selectively revert 36683a804c to resolve
a source compatibility regression. See inline comment for use case. We
are going to consider acknowledging this use case in the rules in a
future release.
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`.
When a function declaration has a body, its source range ends at the
closing curly brace, so it includes the `throws(E)`. However, a
protocol requirement doesn't have a body, and due to an oversight,
getSourceRange() was never updated to include the extra tokens
that appear after `throws` when the function declares a thrown
error type. As a result, unqualified lookup would fail to find a
generic parameter type, if that happened to be the thrown type.
Fixes rdar://problem/143950572.
A protocol conformance witness must be as available as its requirement. In
Swift 6.1 and earlier, the conformance checker failed to note that witnesses in
unavailable extensions are unavailable. That bug was fixed by a previous
change, but there was no test case covering it so the difference in behavior
was not acknowledged.
Related to rdar://143466010.
`x declared here` is not helpful and clear enough, especially when there
are other notes attached. Swap it for a new note that says
`requirement x declared here`.
The non-metatype case was never supported. The same should hold for the
existential metatype case, which used to miscompile and now crashes
because the invariant reference is deemed OK but the erasure expectedly
fails to handle it:
```swift
class C<T> {}
protocol P {
associatedtype A
func f() -> any P & C<A>
func fMeta() -> any (P & C<A>).Type
}
do {
let p: any P
let _ = p.f() // error
let _ = p.fMeta() // crash
}
```
Previously only some random decl attributes were included in the dump
with the source spelling (e.g. @objc), or some affected how the decl is
dumped. But the full attribute list has not been dumped. Dumping
attributes are useful for debugging attribute handling.
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.
Use the `%target-swift-5.1-abi-triple` substitution to compile the tests for
deployment to the minimum OS versions required for use of _Concurrency APIs,
instead of disabling availability checking.
`resolveOverload` introduces a conversion if there were any adjustments
to a member type on existential base. This conversion exists only to
check adjustments in the member type, so the fact that adjustments also
cause a function conversion is unrelated.
Resolves: rdar://135974645
'type' and 'missingType' are contextual types in the generic environment
of the witness thunk. We cannot simply map them into the environment of
the conformance, because if the conforming type is a class, the witness
thunk has an extra generic parameter at depth=0, index=0 and all other
generic parameters are shifted down by one depth.
It should not be possible to mark an associated type declaration unavailable
since doing so does not have an effect on how a conformance interacts with its
associated types.
Only constrain the availability of the synthesized typealias for an inferred
type witness by the availability of the associated type if the associated type
is less available than its protocol. Without this, source compatibility is
broken for some conformances. For example:
```
struct IdentifiableValue: Identifiable {
let id = 42
}
extension IdentifiableValue {
// error: 'ID' is only available in macOS 10.15 or newer
var nextID: ID {
return id + 1
}
}
```
Fixes a regression introduced by https://github.com/swiftlang/swift/pull/71496.
Resolves rdar://134584323
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
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
