All but 7 tests now passing. Those 7 tests either do not refer to these circumstances or do not seem to pass even when modified to accept type specifications.
Updates the message to use the type or ValueDecl instead of this on previous 'Found this candidate' messages
Note: doees not yet change all test cases so more tests are failing
Improve Diagnostic message on overload ambiguitiy
Remove messages that say 'found this candidate' in favour of providing the type for the candidate to aid in selection when the candidates are presented in a dialogue window.
Fix more tests
Previously we would skip type-checking the result expression of a
`return` or the initialization expression of a binding if the contextual
type had an error, but that misses out on useful diagnostics and
prevents code completion and cursor info from working. Change the logic
such that we open ErrorTypes as holes and continue to type-check.
- Introduce a generic requirements opening function for type resolution,
which is used by the constraint system in cases where we need to
impose requirements on opened type variables.
- Refactor `replaceInferableTypesWithTypeVars` to use this function
when opening generic types that contain either placeholder or unbound
generic types.
Together these changes ensure that we don't drop generic requirements
when an unbound generic or placeholder type is used as a generic
argument.
Requirement opening relies on being able to query the opened type to
allow requirement fix coalescing to work. Record the opened type before
we open requirements to ensure we don't duplicate requirement fixes on
the base type with requirement fixes for the member.
Resolving only a structural type meant we weren't checking generic
constraints, allowing invalid extensions to get past the type-checker.
Change to resolve an interface type.
This is a diagnostic that is only really emitted as a fallback when
the constraint system isn't able to better diagnose the expression.
It's not particulary helpful for the user, and can be often be
misleading since the underlying issue might not actually be an
ambiguity, and the user may well already have a type annotation. Let's
instead just emit the fallback diagnostic that we emit in all other
cases, asking the user to file a bug.
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.
The previous message was just suggesting unchecked Sendable, but instead
we should be suggesting to add final to the class. We also don't
outright suggest using unchecked Sendable -- following
https://github.com/swiftlang/swift/pull/81738 precedent.
Resolves rdar://155790695
This check had two problems. First, it would assert upon encountering
a layout requirement, due to an unimplemented code path.
A more fundamental issue is that the logic wasn't fully sound, because
it would miss certain cases, for example:
protocol P {
associatedtype A
func run<B: Equatable>(_: B) where B == Self.A
}
Here, the reduced type of `Self.A` is `B`, and at first glance, the
requirement `B: Equatable` appears to be fine. However, this
is actually a new requirement on `Self`, and the protocol be rejected.
Now that we can change the reduction order by assigning weights to
generic parameters, this check can be implemented in a better way,
by building a new generic signature first, where all generic
parameters introduced by the protocol method, like 'B' above, are
assigned a non-zero weight.
With this reduction order, any type that is equivalent to
a member type of `Self` will have a reduced type rooted in `Self`,
at which point the previous syntactic check becomes sound.
Since this may cause us to reject code we accepted previously,
the type checker now performs the check once: first on the original
signature, which may miss certain cases, and then again on the new
signature built with the weighted reduction order.
If the first check fails, we diagnose an error. If the second
check fails, we only diagnose a warning.
However, this warning will become an error soon, and it really
can cause compiler crashes and miscompiles to have a malformed
protocol like this.
Fixes rdar://116938972.
Returning the unsubstituted superclass type is not correct,
because it may contain type parameters. Let's form a new
UnboundGenericType instead.
- Fixes https://github.com/swiftlang/swift/issues/82160.
- Fixes rdar://152989888.
The concrete nesting limit, which defaults to 30, catches
things like A == G<A>. However, with something like
A == (A, A), you end up with an exponential problem size
before you hit the limit.
Add two new limits.
The first is the total size of the concrete type, counting
all leaves, which defaults to 4000. It can be set with the
-requirement-machine-max-concrete-size= frontend flag.
The second avoids an assertion in addTypeDifference() which
can be hit if a certain counter overflows before any other
limit is breached. This also defaults to 4000 and can be set
with the -requirement-machine-max-type-differences= frontend flag.
The problem detection logic currently expects `generic argument #<N>`
location to always be associated with two generic types, but that
is not always the case, this locator element is sometimes used for
i.e. optional object types and pointer `Pointee` type when types
appear in argument positions. This needs to be handled specifically.
Resolves: rdar://82971941
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.
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.
