[Sema] When resolving type declarations, if there is an error with a typealias,... #19830
Conversation
…as, check to see if it refers to associated types to maybe display a bad conformance diagnostic.
|
@swift-ci Please smoke test. |
|
Tests? |
|
@slavapestov Yep, will do! Have any opinion on the TypeRepr members? |
|
@gregomni After looking at the test case, this feels like a workaround for a bug in associated type inference. I'd rather not add complexity to the type resolution code, which is already very complex, to deal with this particular issue. |
lib/Sema/TypeCheckType.cpp
Outdated
| foundDC->getDeclaredInterfaceType(), | ||
| loc, associatedTypeDecl); | ||
| } | ||
| if (auto aliasDecl = dyn_cast<TypeAliasDecl>(typeDecl)) { |
There was a problem hiding this comment.
Perhaps we can call maybeDiagnoseBadConformanceRef() unconditionally, if its a typealias in a protocol. It's a hack anyway, so limiting it to direct associated type references isn't necessary.
There was a problem hiding this comment.
Yep, that sounds reasonable.
|
@swift-ci Please smoke test. |
|
@swift-ci Please smoke test. |
|
This is much better, thanks! It looks like you fixed compiler_crashers_2/0127-sr5546.swift as well, do you mind moving it to compiler_crashers_2_fixed? I'll dupe the SRs too. |
|
@swift-ci Please smoke test. |
... check to see if the type alias refers to any associated types to maybe display a bad conformance diagnostic.
Partially resolves SR-8813. (Arguably, we should be inferring a valid witness for
Valuehere, but since we aren't, we should definitely be diagnosing it.)Rather than put the ASTWalker here, would it be better to move it into TypeRepr.cpp via adding a member
TypeRepr::visitTypeReprs(llvm::function_ref<void(TypeRepr *)>visitor)?Relatedly, I noticed that
TypeRepr::visitTopLevelTypeReprs()currently has no callers. Should I remove it in this or separate PR?