You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a bug in the type system that users can easily hit with Swift's SIMDVector library. I can see where the compiler is incorrect, but I'm not sure what the right fix should be...
// stdlib's SIMDVector does something like this...publicprotocolDummyProtocol {
// Interestingly this protocol might also define:// func abs() -> Self
}
publicprotocolSIMDStorageStub {
associatedtypeScalar : DummyProtocol
}
// Another protocol in SIMDVector.swift introduces a recursive constraint.// That seems ok in itself, but the extra conformance on DummyProtocol breaks// witness method invocation at the SIL level.publicprotocolSIMDScalarStub {
associatedtypeSIMD2Storage : SIMDStorageStubwhereSIMD2Storage.Scalar == Self
}
// Now we have an app that wants to conform to this protocol...// Everything up to here could be replaced by:// import simd// /s/SIMDScalarStub/SIMDScalarpublicprotocolFPScalar: SIMDScalarStub {
funcabs() -> Self
}
publicfunccallAbs<T: FPScalar>(s: T) -> T {
returns.abs() // Are we supposed to call a method on FPScalar or DummyProtocol and does it matter?
}
The SILVerifier checks that witness methods conformances correspond to a single protocol decl:
autoconformsTo = genericSig->getConformsTo(selfGenericParam);
require(conformsTo.size() == 1,
"requirement Self parameter must conform to exactly one protocol");
The generic parameter conforms to three protocols:
FPScalar
SIMDScalarStub
DummyProtocol
ProtocolType::canonicalizeProtocols removes SIMDScalarStub because it is in the inheritance hierarchy. DummyProtocol is not in the inheritance hierarchy.
I assume the SILVerifier check exists for a reason but have no way of knowing where this invariant is assumed throughout the compiler...
This could be fixed by adding a bunch of complexity to canonicalizeProtocols, but is there a simpler solution and does this case have broader implications for the type system?
The text was updated successfully, but these errors were encountered:
It looks like the generic signature is not minimized correctly. Since 'Self == SIMD2Storage.Scalar' can be derived from the protocol's requirement signature, so can 'Self : DummyProtocol', and therefore the generic signature of the protocol requirement should not contain any additional constraints on 'Self'.
If ProtocolType::canonicalizeProtocols is what you mean by "minimizing" the signature, then yes, it's failing to strip 'DummyProtocol' because it's just doing a dumb search up the inheritance chain.
publicprotocolDummyProtocol { }publicprotocolSIMDStorageStub {
associatedtypeScalar : DummyProtocol
}
// Another protocol in SIMDVector.swift introduces a recursive constraint.// That seems ok in itself, but the extra conformance on DummyProtocol breaks// witness method invocation at the SIL level.publicprotocolSIMDScalarStub {
associatedtypeSIMD2Storage : SIMDStorageStubwhereSIMD2Storage.Scalar == Selffuncabs() -> Self
}
publicfunccallAbs<T: SIMDScalarStub>(s: T) -> T {
returns.abs()
}
Additional Detail from JIRA
md5: 311ea4ef0fac73fcbc4fb3e05b2d86e9
Issue Description:
This is a bug in the type system that users can easily hit with Swift's SIMDVector library. I can see where the compiler is incorrect, but I'm not sure what the right fix should be...
The SILVerifier checks that witness methods conformances correspond to a single protocol decl:
The GenericSignatureBuilder considers this the representative potential archetype:
The generic parameter conforms to three protocols:
FPScalar
SIMDScalarStub
DummyProtocol
ProtocolType::canonicalizeProtocols removes SIMDScalarStub because it is in the inheritance hierarchy. DummyProtocol is not in the inheritance hierarchy.
I assume the SILVerifier check exists for a reason but have no way of knowing where this invariant is assumed throughout the compiler...
This could be fixed by adding a bunch of complexity to canonicalizeProtocols, but is there a simpler solution and does this case have broader implications for the type system?
The text was updated successfully, but these errors were encountered: