New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-6516] error: reference to invalid associated type 'Context' of type 'S' #49066
Comments
I don't think associated types have ever been able to reference other associated types in their defaults. (There are other bugs about this.) cc @DougGregor |
It's reasonable to want to do this, and IIRC we have code in the associated type inference logic to try to support it. |
@swift-ci create |
update: still the same on 4.1 release:
|
Reproducible for me with this simple code with public struct Foo<A, B> {}
public protocol P {
associatedtype PA
associatedtype PB
associatedtype Context = Foo<PA, PB>
func f2(_ x: Context, _ y: PB)
}
public struct S: P {
public typealias PA = String
public typealias PB = Int
public func f1(_ x: Context, _ y: PA) {
}
public func f2(_ x: Context, _ y: PB) {
}
} Interestingly enough, commenting out public struct Foo<A, B> {}
public protocol P {
associatedtype PA
associatedtype PB
associatedtype Context = Foo<PA, PB>
func f2(_ x: Context, _ y: PB)
}
public struct S: P {
public typealias PA = String
public typealias PB = Int
public func f2(_ x: Context, _ y: PB) {
}
public func f1(_ x: Context, _ y: PA) {
}
} |
still an issue with 5.0.2
|
…request cycle This implements a structural walk over the TypeRepr to catch situations where we attempt to infer `A` from `func f(_: A)`, which references the concrete `A` that will be synthesized in the conforming type. Fixes: - rdar://34956654 / apple#48680 - rdar://38913692 / apple#49066 - rdar://56672411 - apple#50010 - rdar://81587765 / apple#57355 - rdar://117442510
…request cycle This implements a structural walk over the TypeRepr to catch situations where we attempt to infer `A` from `func f(_: A)`, which references the concrete `A` that will be synthesized in the conforming type. Fixes: - rdar://34956654 / apple#48680 - rdar://38913692 / apple#49066 - rdar://56672411 - apple#50010 - rdar://81587765 / apple#57355 - rdar://117442510
…request cycle This implements a structural walk over the TypeRepr to catch situations where we attempt to infer `A` from `func f(_: A)`, which references the concrete `A` that will be synthesized in the conforming type. Fixes: - rdar://34956654 / apple#48680 - rdar://38913692 / apple#49066 - rdar://56672411 - apple#50010 - rdar://81587765 / apple#57355 - rdar://117442510
…request cycle This implements a structural walk over the TypeRepr to catch situations where we attempt to infer `A` from `func f(_: A)`, which references the concrete `A` that will be synthesized in the conforming type. Fixes: - rdar://34956654 / apple#48680 - rdar://38913692 / apple#49066 - rdar://56672411 - apple#50010 - rdar://81587765 / apple#57355 - rdar://117442510
Fixed by #69826 |
…request cycle This implements a structural walk over the TypeRepr to catch situations where we attempt to infer `A` from `func f(_: A)`, which references the concrete `A` that will be synthesized in the conforming type. Fixes: - rdar://34956654 / apple#48680 - rdar://38913692 / apple#49066 - rdar://56672411 - apple#50010 - rdar://81587765 / apple#57355 - rdar://117442510
Attachment: Download
Additional Detail from JIRA
md5: ab85d612bfcfa69795091d50765d64c6
relates to:
Issue Description:
This issue is related to #48118 and the '[swift-evolution] [RFC] Associated type inference' thread that Doug started.
So first of all I must say I'm delighted that there's ongoing work in this area and we seem to be getting closer to fixing this issue which is blocking us pretty badly.
The code below is almost the same as the one in #48118 but I changed the
typealias Context = ...
to anassociatedtype Context = ...
. In Swift 4.0 that doesn't make any difference and crashes the compiler.In a recent (
4.1-dev (LLVM 5b54bd1e96, Clang 03ed64977b, Swift 88a7a55e83)
) Swift 4.1 dev snapshot, however we get a different error which also seems bogus:That's really odd as it just works fine for
f1
but breaks forf2
, I'm confused.Also quite interestingly, in a recent (
LLVM 20c8fee562, Clang b227f55990, Swift 603e5359fd
) Swift master dev snapshot I get the following messages for the code above:very odd, on top of the error that the 4.1 dev snapshot shows too it also gives me a near miss warning that
is almost
to which I'd say that this isn't a near miss but an exact hit?
The text was updated successfully, but these errors were encountered: