WIP: Thread GeneratorKind through to symbol mangling#104333
Closed
Swatinem wants to merge 1 commit intorust-lang:masterfrom
Closed
WIP: Thread GeneratorKind through to symbol mangling#104333Swatinem wants to merge 1 commit intorust-lang:masterfrom
GeneratorKind through to symbol mangling#104333Swatinem wants to merge 1 commit intorust-lang:masterfrom
Conversation
Loading
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The current symbol mangling (legacy and v0) do not differentiate between closures and async fns / blocks, which is suboptimal when looking at debuginfo or stack traces.
This lays the groundwork to eventually add these special kinds of closures to the mangling scheme.
As it is implemented right now, this has a subtle problem when not yet outputting a different mangling for each
GeneratorKind:DefPathData::ClosureExprnowHash-es differently depending on the innerGeneratorKind, so it can potentially reuse the samedisambiguator.I can potentially work around that, though it would be nicer to just have different mangling for each of those types ;-)