about summary refs log tree commit diff
path: root/src/test/debuginfo/function-names.rs
AgeCommit message (Collapse)AuthorLines
2022-01-04Do not hash zero bytes of i64 and u32 in Sip128 hasherJakub Beránek-2/+2
2021-10-11Fix function-names test for GDB 10.1Michael Woerister-15/+16
2021-08-30`feature(const_param_types)` -> `feature(adt_const_params)`lcnr-1/+1
2021-08-30`feature(const_generics)` -> `feature(const_param_types)`lcnr-2/+2
2021-08-24tests: support -Zsymbol-mangling-version=v0 being the default.Eduard-Mihai Burtescu-1/+1
2021-07-15[debuginfo] Make use of spaces and separators in debuginfo names more uniform.Michael Woerister-3/+3
2021-07-14Handle non-integer const generic parameters in debuginfo type names.Michael Woerister-2/+28
2021-06-30Improve debug symbol names to avoid ambiguity and work better with MSVC's ↵Daniel Paoliello-0/+175
debugger 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}}` or `dyn _'`) or dropping qualifications (e.g., for dynamic types). Instead, each debug symbol name should be unique and useful: * Include disambiguators for anonymous `DefPathDataName` (closures and generators), and unify their formatting when used as a path-qualifier vs item being qualified. * Qualify the principal trait for dynamic types. * If there is no principal trait for a dynamic type, emit all other traits instead. * Respect the `qualified` argument when emitting ref and pointer types. * For implementations, emit the disambiguator. * Print const generics when emitting generic parameters or arguments. 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: * Avoid characters with special meaning (`#`, `[`, `"`, `+`). * Never start a name with `<` 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). * Emit function declarations using C/C++ style syntax (e.g., leading return type). * Emit arrays as a synthetic `array$<type, size>` type. * Include a `$` in all synthetic types as this is a legal character for C++, but not Rust (thus we avoid collisions with user types).