[ASTMangler] Fix USR generation/mangling crash in invalid code #27108
Conversation
|
@swift-ci please test |
nathawes
force-pushed
the
r54310026-usr-generation-crash-in-invalid-code
branch
from
f41aca8 to
d201fd1
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
lib/AST/ASTMangler.cpp
Outdated
| if (auto gft = dyn_cast<GenericFunctionType>(type)) { | ||
| Type type = decl->getInterfaceType() | ||
| ->getReferenceStorageReferent(); | ||
| if (type->hasArchetype()) |
There was a problem hiding this comment.
Can you file a radar and assign it to me to fix the underlying problem here? I believe the only decls that are affected by this are ParamDecls (in fact, can you add an assert that if hasArchetype() is true, the decl is a ParamDecl?)
There was a problem hiding this comment.
Thanks Slava! I filed rdar://problem/55268049 and updated this PR with the assertion.
In invalid code a decl may end up with an opened archetype type that the mangler doesn't expect. We still want to be able to generate a USR for these decls so that we can index and rename their occurences successfully. To allow this, this patch calls mapTypeOutOfContext on primary or opened archetype types prior to mangling. Resolves rdar://problem/54310026
nathawes
force-pushed
the
r54310026-usr-generation-crash-in-invalid-code
branch
from
d201fd1 to
d48b620
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
In invalid code it seems decls can end up with an opened archetype type that the mangler doesn't like (hitting this unreachable). We still want to be able to generate a USR for these decls so that we can index and rename their occurrences successfully. To allow this, this patch calls
mapTypeOutOfContexton types that have primary or opened archetype types prior to mangling.This is like the issue @rintaro fixed for sourcekitd's ConformingMethodList request in #25130, but for indexing.
Resolves rdar://problem/54310026