Past me thought this code was clever because it avoided a redundant lookup
of the conformance we're checking. But present me thinks this is
over-engineered, and deleting it is the easiest way to fix a crash.
This actually doesn't fix the root cause of the crash, which is
that getSuperclass() and getSuperclassDecl() might return different
results, with the former failing to resolve even when the latter
returns a valid Decl, because the latter goes via a simpler lookup
mechanism.
However, I think simplifying this code is good regardless.
Fixes rdar://177691260.
When applying a constraint system solution to a pattern binding initialization,
the type stamped onto the pattern was derived from the initializer expression
rather than from the type the solver assigned to the pattern itself. When an
explicit annotation and the initializer share a canonical type but differ in
sugar, coercing the initializer to the annotation type is a no-op that leaves
the initializer's own sugar in place, so the pattern and the VarDecl printed
into the .swiftinterface ended up with the initializer's sugar instead of the
written annotation.
This is mostly cosmetic, but it turns into a correctness problem when the
initializer's sugar names a typealias that isn't visible at the interface's
access level. For example, a public stored property annotated with a public
alias but initialized from an expression of an internal alias would print the
internal alias in the interface, producing a declaration that references a type
the interface can't see and breaking interface verification.
For typed patterns, use the pattern's solved type instead of the type derived
from the init. Assuming type checking is successful, the two types must share a
canonical type so this change only affects the printed sugar.
A better fix would be to unconditionally use the pattern's solved type,
regardless of whether the pattern is typed or not. Doing so causes some
regressions elsewhere, though, because the constraint solver does not currently
preserve typealias sugar on constructors everywhere it ought to. Using the
solved type for other kinds of patterns can therefore end up causing desugared
types to show up in more places where they aren't desirable.
Resolves rdar://178091149.
It was originally introduced as an upcoming feature, but there isn't any
precedent for using upcoming features as a way to opt-in to type checking fixes
without an associated Swift Evolution proposal. Rather than using a "feature" to
control this behavior, it would probably be better to offer a way to use
`-Werror` to upgrade these warnings to errors.
A requirement defines the maximal effects that a witness can have.
In some cases, we'd fail to properly reject such a witness with more
effects, when that witness is valid for another requirement within that
protocol. Thus, we'd hit an assertion failure in that case rather than
permitting the valid program to compile.
In a non-asserts compiler, we could end up failing to diagnose an invalid
chosen witness and crash in IRGen.
https://github.com/apple/swift/issues/73479
rdar://127669069
Private member witnessing a public constraint should be deprecated.
Previously existing workaround is checked and compiler emits a warning
when strict access check is not passed. Test files were fixed to expect
the corresponding warning.
rdar://74904373
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
The bug tracked by rdar://158172056 was already fixed by
https://github.com/swiftlang/swift/pull/83607 but this additional test case is
needed to ensure that conformances to Obj-C protocols with obsolete
requirements imported under legacy spellings not regress again.
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.
When generating a stub fix-it for a protocol conformance or implementation extension, Swift will now evaluate whether the context allows the declaration of stored properties and, if so, will suggest one. It will also use the `let` keyword instead of `var` if the property has no setter.
Changes the diagnostics emitted when an `@objc @implementation` extension is missing some of the members required by the extension:
• We now emit one error on the extension, plus a note for each missing member.
• Where possible, we also emit a note with a fix-it adding stubs.
For example:
```
9 | @objc @implementation extension ObjCClass {
| |- error: extension for main class interface does not provide all required implementations
| |- note: missing instance method 'method(fromHeader3:)'
| |- note: missing instance method 'method(fromHeader4:)'
| |- note: missing property 'propertyFromHeader7'
| |- note: missing property 'propertyFromHeader8'
| |- note: missing property 'propertyFromHeader9'
| |- note: missing instance method 'extensionMethod(fromHeader2:)'
| `- note: add stubs for missing '@implementation' requirements
```
With a fix-it on the last note to insert the following after the open brace:
```
@objc(methodFromHeader3:)
open func method(fromHeader3 param: Int32) {
<#code#>
}
@objc(methodFromHeader4:)
open func method(fromHeader4 param: Int32) {
<#code#>
}
@objc(propertyFromHeader7)
open var propertyFromHeader7: Int32 {
get {
<#code#>
}
set {
<#code#>
}
}
@objc(propertyFromHeader8)
open var propertyFromHeader8: Int32 {
get {
<#code#>
}
set {
<#code#>
}
}
@objc(propertyFromHeader9)
open var propertyFromHeader9: Int32 {
get {
<#code#>
}
set {
<#code#>
}
}
@objc(extensionMethodFromHeader2:)
open func extensionMethod(fromHeader2 param: Int32) {
<#code#>
}
```
Fixes rdar://130038221.
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.
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.
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
a warning.
Previous compiler versions allowed this, so we should stage the change in as
a warning. This was already a warning across modules, so this change only impacts
redundant conformances to marker protocols within a module. This code also isn't
particularly harmful, because marker protocols don't have requirements, so there
isn't the same risk of unexpected behavior as other redundant conformances.
I'm not really convinced that this shouldn't be done by introducing a new
kind of constraint rather than hacking in what are essentially conversions
as "bind" constraints, but this is the most direct path for now.
Fixes rdar://125394096
Extend an existing source compatibility hack that allows a typed
throws-using function that *looks* like a rethrows function to be
treated like a rethrows function. Here, do so when a typed-throws
function is witnessing a rethrows requirement.
Fixes rdar://122588459.
Our tentative witness might have weird concrete DependentMemberTypes
in it. In that case, perform a more relaxed check that can succeed
as long as the witness is not completely invalid.
This problem was exposed by existing test cases starting to fail
once implicit Copyable requirements were introduced, because these
concrete DependentMemberTypes do not conform to protocols. This now
postpones the check until all witnesses have been fully substituted.
This also fixes a long-standing bug with superclass requirements on
associated types.
Fixes https://github.com/apple/swift/issues/48770,
https://github.com/apple/swift/issues/51772,
rdar://95729075.
When comparing a requirement that uses typed throws and uses an
associated type for the thrown error type against a potential witness,
infer the associated type from the thrown error of the
witness---whether explicitly specified, untyped throws (`any Error`),
or non-throwing (`Never`).
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.
Operator function witnesses are looked up globally. However, an additional, qualified lookup is warranted if the conforming type is declared in a local context.
Slava Pestov
Allan Shortlidge
Aidan Hall
Kavon Farvardin
Sam Pyankov
Henrik G. Olsson
Becca Royal-Gordon
Doug Gregor
Dmitrii Galimzianov
Ben Langmuir
Alex Hoppen
Holly Borla
John McCall
Harlan Haskins
Nishith Shah
Ellie Shin
Anthony Latsis