Crash when accessing generic property wrapper's some type-using wrappedValue
#78405
Comments
lukaskollmer
added
bug
|
I tried to debug this issue: void SILGenModule::useConformance(ProtocolConformanceRef conformanceRef) {
// If the conformance is invalid, crash deterministically even in noassert
// builds.
if (conformanceRef.isInvalid()) {
// When lazy type checking is enabled, a conformance may only be diagnosed
// as invalid during SILGen. Ignore it instead of asserting.
auto &ctx = getASTContext();
if (ctx.TypeCheckerOpts.EnableLazyTypecheck && ctx.hadError())
return;
llvm::report_fatal_error("Invalid conformance in type-checked AST");
}Seems like the underlying structure is a union with this form: typedef llvm::PointerUnion<ProtocolDecl *, ProtocolConformance *, PackConformance *> UnionType;In the Xcode debugger, this seems to be empty ( protocol P {}Even though the code compiles as mentioned in the description of the issue, this debug statement shows there is an invalid conformance: bool PackConformance::isInvalid() const {
return llvm::any_of(getPatternConformances(),
[&](const auto ref) {
if (ref.isInvalid())
llvm::errs() << "An invalid conformance exists." << "\n";
return ref.isInvalid();
});
}../build/Ninja-RelWithDebInfoAssert/swift-macosx-arm64/bin/swiftc -sdk /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk debug.swift
An invalid conformance exists.
An invalid conformance exists.
|
|
@AnthonyLatsis protocol P: AnyObject where Self: Base {}Any thoughts? |
AnthonyLatsis
added
compiler
|
Which conformance do you think is invalid and why? We are crashing because we should not be lowering an AST containing an invalid conformance. It is the job of semantic analysis to diagnose invalid conformances and compute conformances correctly. I don’t see anything wrong with the code, so I think we are incorrectly computing this conformance somewhere. |
|
Reduction: class Base: P {}
protocol P: Base {}
struct Query<T: P> {
var foo: some RandomAccessCollection {
Array<T>()
}
}
func test(q: Query<Base>) -> Int {
q.foo.count
} |
|
I see, I thought this had something to do with SIL, will look into Sema. |
|
What type of protocol conformance would the snippet you shared be with respect to the codebase? I see a lot of them like specialised, derived, existential. In general, is conformance lookup the probable place to see for the checks that verify the validity of a certain protocol? |
|
Presumably a normal conformance. There are a lot of things that could have gone wrong here, do not guess. Try reproducing the crash and tracing the conformance back to where it came from with the debugger. |
|
I had already reproduced the crash and had been exploring the codebase since weeks looking into the implementations. It probably has something to do with substitution map. Let's see, I feel the stack trace can be much better though, maybe I am missing out on some debugging tools, but it looks like the Swift compiler doesn't show the trace back in depth but only diagnostics? For example, when debugging llvm issues or any other compiler, one can get to the very root of it and know it's exactly here (or at least close enough) from where it came. |
Description
The program below crashes the compiler.
Changing the type of
wrappedValueto a non-sometype, or removing thewhere T: Pconstraint from the property wrapper type makes it work fine.Additionally, it seems like the crash is caused by the fact that the program is accessing a property on the
wrappedValue. If we changehmmmto returnelementsinstead ofelements.count(and adjust its type accordingly), the program compiles without issues.Alternatively, removing the
where Self: Baseconstraint from thePprotocol also makes it compile.Reproduction
Stack dump
Expected behavior
the code should compile
Environment
swift-driver version: 1.115.1 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1)
Target: arm64-apple-macosx14.0
Additional information
No response
The text was updated successfully, but these errors were encountered: