Skip to content

[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

Merged
merged 1 commit into from
Feb 27, 2025

Conversation

hamishknight
Copy link
Contributor

@hamishknight hamishknight commented Jan 23, 2025

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

@slavapestov
Copy link
Contributor

slavapestov commented Jan 23, 2025

I'm afraid this is not the correct fix. It sounds like there is an issue with lazy variables, and something separate with CursorInfo. Neither of these should require anything resembling a complete rethink of local archetypes to resolve.

@slavapestov
Copy link
Contributor

For lazy vars it appears you need to change appendAccessorEntity() to do the same thing as appendClosureComponents() when the accessor in question is a local function.

@hamishknight
Copy link
Contributor Author

It sounds like there is an issue with lazy variables, and something separate with CursorInfo

It's the same underlying issue; we can't mangle a decl with an interface type that contains a local archetype

Neither of these should require anything resembling a complete rethink of local archetypes to resolve.

Right, I was referring to handling standalone local archetypes for e.g printTypeUSR

For lazy vars it appears you need to change appendAccessorEntity() to do the same thing as appendClosureComponents() when the accessor in question is a local function.

Is there any advantage to doing this over handling it generally for any decl?

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
@hamishknight hamishknight changed the title [Mangler] Handle ElementArchetypeType for decls [Mangler] Handle local archetypes in getDeclTypeForMangling Feb 26, 2025
Comment on lines +4038 to +4041
// Record any captured generic environments we have.
llvm::SmallSetVector<GenericEnvironment *, 4> capturedEnvs;
for (auto *genericEnv : captureInfo.getGenericEnvironments())
capturedEnvs.insert(genericEnv);
Copy link
Contributor Author

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.

@hamishknight
Copy link
Contributor Author

@slavapestov How does this look?

@hamishknight
Copy link
Contributor Author

@swift-ci please test

@hamishknight hamishknight merged commit b52d154 into swiftlang:main Feb 27, 2025
5 checks passed
@hamishknight hamishknight deleted the elemental branch February 27, 2025 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants