Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger#85269
Merged
bors merged 3 commits intorust-lang:masterfrom Jul 2, 2021
Merged
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
There are several cases where names of types and functions in the debug info are either ambiguous, or not helpful, such as including ambiguous placeholders (e.g.,
{{impl}},{{closure}}ordyn _') or dropping qualifications (e.g., for dynamic types).Instead, each debug symbol name should be unique and useful:
DefPathDataName(closures and generators), and unify their formatting when used as a path-qualifier vs item being qualified.qualifiedargument when emitting ref and pointer types.Additionally, when targeting MSVC, its debugger treats many command arguments as C++ expressions, even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly:
#,[,",+).<or{as this is treated as an operator.>>is always treated as a right-shift, even when parsing generic arguments (so add a space to avoid this).array$<type, size>type.$in all synthetic types as this is a legal character for C++, but not Rust (thus we avoid collisions with user types).