2013-02-27 12:35:56 -06:00
|
|
|
// Caveats - gdb prints any 8-bit value (meaning rust i8 and u8 values)
|
|
|
|
|
// as its numerical value along with its associated ASCII char, there
|
|
|
|
|
// doesn't seem to be any way around this. Also, gdb doesn't know
|
|
|
|
|
// about UTF-32 character encoding and will print a rust char as only
|
|
|
|
|
// its numerical value.
|
|
|
|
|
|
2014-10-09 09:31:03 -05:00
|
|
|
// min-lldb-version: 310
|
2013-11-04 00:53:01 -06:00
|
|
|
|
Improve debug symbol names to avoid ambiguity and work better with MSVC's 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).
2021-06-24 12:36:28 -05:00
|
|
|
// This fails on lldb 6.0.1 on x86-64 Fedora 28; so ignore Linux for now.
|
|
|
|
|
// ignore-linux
|
2018-09-26 13:58:10 -05:00
|
|
|
|
2014-02-06 21:57:09 -06:00
|
|
|
// compile-flags:-g
|
2014-07-09 07:46:09 -05:00
|
|
|
|
|
|
|
|
// === GDB TESTS ===================================================================================
|
|
|
|
|
|
2014-04-24 04:35:48 -05:00
|
|
|
// gdb-command:run
|
|
|
|
|
// gdb-command:print b
|
|
|
|
|
// gdb-check:$1 = false
|
|
|
|
|
// gdb-command:print i
|
|
|
|
|
// gdb-check:$2 = -1
|
|
|
|
|
// gdb-command:print c
|
2016-10-25 16:32:04 -05:00
|
|
|
// gdbg-check:$3 = 97
|
|
|
|
|
// gdbr-check:$3 = 97 'a'
|
2014-04-24 04:35:48 -05:00
|
|
|
// gdb-command:print/d i8
|
|
|
|
|
// gdb-check:$4 = 68
|
|
|
|
|
// gdb-command:print i16
|
|
|
|
|
// gdb-check:$5 = -16
|
|
|
|
|
// gdb-command:print i32
|
|
|
|
|
// gdb-check:$6 = -32
|
|
|
|
|
// gdb-command:print i64
|
|
|
|
|
// gdb-check:$7 = -64
|
|
|
|
|
// gdb-command:print u
|
|
|
|
|
// gdb-check:$8 = 1
|
|
|
|
|
// gdb-command:print/d u8
|
|
|
|
|
// gdb-check:$9 = 100
|
|
|
|
|
// gdb-command:print u16
|
|
|
|
|
// gdb-check:$10 = 16
|
|
|
|
|
// gdb-command:print u32
|
|
|
|
|
// gdb-check:$11 = 32
|
|
|
|
|
// gdb-command:print u64
|
|
|
|
|
// gdb-check:$12 = 64
|
|
|
|
|
// gdb-command:print f32
|
|
|
|
|
// gdb-check:$13 = 2.5
|
|
|
|
|
// gdb-command:print f64
|
|
|
|
|
// gdb-check:$14 = 3.5
|
Improve debug symbol names to avoid ambiguity and work better with MSVC's 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).
2021-06-24 12:36:28 -05:00
|
|
|
// gdb-command:print s
|
|
|
|
|
// gdbg-check:$15 = {data_ptr = [...] "Hello, World!", length = 13}
|
|
|
|
|
// gdbr-check:$15 = "Hello, World!"
|
2013-02-27 12:35:56 -06:00
|
|
|
|
2014-07-09 07:46:09 -05:00
|
|
|
// === LLDB TESTS ==================================================================================
|
|
|
|
|
|
|
|
|
|
// lldb-command:run
|
|
|
|
|
// lldb-command:print b
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$0 = false
|
|
|
|
|
// lldbr-check:(bool) b = false
|
2014-07-09 07:46:09 -05:00
|
|
|
// lldb-command:print i
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$1 = -1
|
|
|
|
|
// lldbr-check:(isize) i = -1
|
2014-07-09 07:46:09 -05:00
|
|
|
|
2018-10-02 11:13:30 -05:00
|
|
|
// NOTE: only rust-enabled lldb supports 32bit chars
|
|
|
|
|
// lldbr-command:print c
|
|
|
|
|
// lldbr-check:(char) c = 'a'
|
2014-07-09 07:46:09 -05:00
|
|
|
|
|
|
|
|
// lldb-command:print i8
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$2 = 'D'
|
|
|
|
|
// lldbr-check:(i8) i8 = 68
|
2014-07-09 07:46:09 -05:00
|
|
|
// lldb-command:print i16
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$3 = -16
|
|
|
|
|
// lldbr-check:(i16) i16 = -16
|
2014-07-09 07:46:09 -05:00
|
|
|
// lldb-command:print i32
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$4 = -32
|
|
|
|
|
// lldbr-check:(i32) i32 = -32
|
2014-07-09 07:46:09 -05:00
|
|
|
// lldb-command:print i64
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$5 = -64
|
|
|
|
|
// lldbr-check:(i64) i64 = -64
|
2014-07-09 07:46:09 -05:00
|
|
|
// lldb-command:print u
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$6 = 1
|
|
|
|
|
// lldbr-check:(usize) u = 1
|
2014-07-09 07:46:09 -05:00
|
|
|
// lldb-command:print u8
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$7 = 'd'
|
|
|
|
|
// lldbr-check:(u8) u8 = 100
|
2014-07-09 07:46:09 -05:00
|
|
|
// lldb-command:print u16
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$8 = 16
|
|
|
|
|
// lldbr-check:(u16) u16 = 16
|
2014-07-09 07:46:09 -05:00
|
|
|
// lldb-command:print u32
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$9 = 32
|
|
|
|
|
// lldbr-check:(u32) u32 = 32
|
2014-07-09 07:46:09 -05:00
|
|
|
// lldb-command:print u64
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$10 = 64
|
|
|
|
|
// lldbr-check:(u64) u64 = 64
|
2014-07-09 07:46:09 -05:00
|
|
|
// lldb-command:print f32
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$11 = 2.5
|
|
|
|
|
// lldbr-check:(f32) f32 = 2.5
|
2014-07-09 07:46:09 -05:00
|
|
|
// lldb-command:print f64
|
2018-10-02 11:13:30 -05:00
|
|
|
// lldbg-check:[...]$12 = 3.5
|
|
|
|
|
// lldbr-check:(f64) f64 = 3.5
|
2014-07-09 07:46:09 -05:00
|
|
|
|
Improve debug symbol names to avoid ambiguity and work better with MSVC's 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).
2021-06-24 12:36:28 -05:00
|
|
|
// === CDB TESTS ===================================================================================
|
|
|
|
|
|
|
|
|
|
// cdb-command:g
|
|
|
|
|
// cdb-command:dx b
|
|
|
|
|
// cdb-check:b : false [Type: bool]
|
|
|
|
|
// cdb-command:dx i
|
2021-07-02 09:31:22 -05:00
|
|
|
// cdb-check:i : -1 [Type: [...]]
|
2021-10-14 12:26:42 -05:00
|
|
|
// cdb-command:dx c
|
|
|
|
|
// cdb-check:c : 0x61 'a' [Type: char32_t]
|
Improve debug symbol names to avoid ambiguity and work better with MSVC's 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).
2021-06-24 12:36:28 -05:00
|
|
|
// cdb-command:dx i8
|
|
|
|
|
// cdb-check:i8 : 68 [Type: char]
|
|
|
|
|
// cdb-command:dx i16
|
|
|
|
|
// cdb-check:i16 : -16 [Type: short]
|
|
|
|
|
// cdb-command:dx i32
|
|
|
|
|
// cdb-check:i32 : -32 [Type: int]
|
|
|
|
|
// cdb-command:dx i64
|
|
|
|
|
// cdb-check:i64 : -64 [Type: __int64]
|
|
|
|
|
// cdb-command:dx u
|
|
|
|
|
// cdb-check:u : 0x1 [Type: [...]]
|
|
|
|
|
// cdb-command:dx u8
|
|
|
|
|
// cdb-check:u8 : 0x64 [Type: unsigned char]
|
|
|
|
|
// cdb-command:dx u16
|
|
|
|
|
// cdb-check:u16 : 0x10 [Type: unsigned short]
|
|
|
|
|
// cdb-command:dx u32
|
|
|
|
|
// cdb-check:u32 : 0x20 [Type: unsigned int]
|
|
|
|
|
// cdb-command:dx u64
|
|
|
|
|
// cdb-check:u64 : 0x40 [Type: unsigned __int64]
|
|
|
|
|
// cdb-command:dx f32
|
|
|
|
|
// cdb-check:f32 : 2.500000 [Type: float]
|
|
|
|
|
// cdb-command:dx f64
|
|
|
|
|
// cdb-check:f64 : 3.500000 [Type: double]
|
|
|
|
|
// cdb-command:.enable_unicode 1
|
2021-09-10 18:51:10 -05:00
|
|
|
// FIXME(#88840): The latest version of the Windows SDK broke the visualizer for str.
|
Improve debug symbol names to avoid ambiguity and work better with MSVC's 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).
2021-06-24 12:36:28 -05:00
|
|
|
// cdb-command:dx s
|
[debuginfo] Make debuginfo type names for slices and str consistent.
Before this PR, the compiler would emit the debuginfo name `slice$<T>`
for all kinds of slices, regardless of whether they are behind a
reference or not and regardless of the kind of reference. As a
consequence, the types `Foo<&[T]>`, `Foo<[T]>`, and `Foo<&mut [T]>`
would end up with the same type name `Foo<slice$<T> >` in debuginfo,
making it impossible to disambiguate between them by name. Similarly,
`&str` would get the name `str` in debuginfo, so the debuginfo name for
`Foo<str>` and `Foo<&str>` would be the same. In contrast,
`*const [bool]` and `*mut [bool]` would be `ptr_const$<slice$<bool> >`
and `ptr_mut$<slice$<bool> >`, i.e. the encoding does not lose
information about the type.
This PR removes all special handling for slices and `str`. The types
`&[bool]`, `&mut [bool]`, and `&str` thus get the names
`ref$<slice2$<bool> >`, `ref_mut$<slice2$<bool> >`, and
`ref$<str$>` respectively -- as one would expect.
2022-10-25 05:28:03 -05:00
|
|
|
// cdb-check:s : [...] [Type: ref$<str$>]
|
Improve debug symbol names to avoid ambiguity and work better with MSVC's 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).
2021-06-24 12:36:28 -05:00
|
|
|
|
2014-10-27 17:37:07 -05:00
|
|
|
#![allow(unused_variables)]
|
2015-09-19 15:33:47 -05:00
|
|
|
#![feature(omit_gdb_pretty_printer_section)]
|
2014-12-03 16:48:18 -06:00
|
|
|
#![omit_gdb_pretty_printer_section]
|
2013-08-17 10:37:42 -05:00
|
|
|
|
2013-02-27 12:35:56 -06:00
|
|
|
fn main() {
|
|
|
|
|
let b: bool = false;
|
2015-03-25 19:06:52 -05:00
|
|
|
let i: isize = -1;
|
2013-02-27 12:35:56 -06:00
|
|
|
let c: char = 'a';
|
|
|
|
|
let i8: i8 = 68;
|
|
|
|
|
let i16: i16 = -16;
|
|
|
|
|
let i32: i32 = -32;
|
|
|
|
|
let i64: i64 = -64;
|
2015-03-25 19:06:52 -05:00
|
|
|
let u: usize = 1;
|
2013-02-27 12:35:56 -06:00
|
|
|
let u8: u8 = 100;
|
|
|
|
|
let u16: u16 = 16;
|
|
|
|
|
let u32: u32 = 32;
|
|
|
|
|
let u64: u64 = 64;
|
|
|
|
|
let f32: f32 = 2.5;
|
|
|
|
|
let f64: f64 = 3.5;
|
Improve debug symbol names to avoid ambiguity and work better with MSVC's 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).
2021-06-24 12:36:28 -05:00
|
|
|
let s: &str = "Hello, World!";
|
2014-07-09 07:46:09 -05:00
|
|
|
_zzz(); // #break
|
2013-02-27 12:35:56 -06:00
|
|
|
}
|
2013-06-14 14:23:42 -05:00
|
|
|
|
[debuginfo] Make debuginfo type names for slices and str consistent.
Before this PR, the compiler would emit the debuginfo name `slice$<T>`
for all kinds of slices, regardless of whether they are behind a
reference or not and regardless of the kind of reference. As a
consequence, the types `Foo<&[T]>`, `Foo<[T]>`, and `Foo<&mut [T]>`
would end up with the same type name `Foo<slice$<T> >` in debuginfo,
making it impossible to disambiguate between them by name. Similarly,
`&str` would get the name `str` in debuginfo, so the debuginfo name for
`Foo<str>` and `Foo<&str>` would be the same. In contrast,
`*const [bool]` and `*mut [bool]` would be `ptr_const$<slice$<bool> >`
and `ptr_mut$<slice$<bool> >`, i.e. the encoding does not lose
information about the type.
This PR removes all special handling for slices and `str`. The types
`&[bool]`, `&mut [bool]`, and `&str` thus get the names
`ref$<slice2$<bool> >`, `ref_mut$<slice2$<bool> >`, and
`ref$<str$>` respectively -- as one would expect.
2022-10-25 05:28:03 -05:00
|
|
|
fn _zzz() {
|
|
|
|
|
()
|
|
|
|
|
}
|
