-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Mangler] Handle local archetypes in getDeclTypeForMangling
#78855
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
Conversation
I'm afraid this is not the correct fix. It sounds like there is an issue with |
For |
It's the same underlying issue; we can't mangle a decl with an interface type that contains a local archetype
Right, I was referring to handling standalone local archetypes for e.g
Is there any advantage to doing this over handling it generally for any decl? |
35396ec
to
352ee2f
Compare
352ee2f
to
57fac03
Compare
Element archetypes can occur here when mangling the USR for local variables for e.g SourceKit cursor info, as well as for regular compilation for things like lazy variables. Update `getDeclTypeForMangling` to map local archetypes out of context, using both the captured generic environments and the archetypes present in the type. More work is needed to support lazy variable though (now it crashes in SILGen). This patch doesn't handle mangling standalone element archetypes for e.g `printTypeUSR`, ideally we'd fix the clients there to not pass local archetypes. rdar://143077965
57fac03
to
994848f
Compare
getDeclTypeForMangling
// Record any captured generic environments we have. | ||
llvm::SmallSetVector<GenericEnvironment *, 4> capturedEnvs; | ||
for (auto *genericEnv : captureInfo.getGenericEnvironments()) | ||
capturedEnvs.insert(genericEnv); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In principle I think we could purely rely on gathering them from the type, but I don't think there's any harm in doing this and it's more consistent with the closure logic. I don't feel strongly about it though.
@slavapestov How does this look? |
@swift-ci please test |
Element archetypes can occur here when mangling the USR for local variables for e.g SourceKit cursor info, as well as for regular compilation for things like lazy variables.
Update
getDeclTypeForMangling
to map local archetypes out of context, using both the captured generic environments and the archetypes present in the type. More work is needed to support lazy variable though (now it crashes in SILGen).This patch doesn't handle mangling standalone element archetypes for e.g
printTypeUSR
, ideally we'd fix the clients there to not pass local archetypes.rdar://145737847