2018-10-12 21:34:14 +08:00
|
|
|
// Some versions of the non-rust-enabled LLDB print the wrong generic
|
|
|
|
|
// parameter type names in this test.
|
2023-04-14 17:40:07 +08:00
|
|
|
// needs-rust-lldb
|
2013-11-04 14:53:01 +08:00
|
|
|
|
2014-02-07 11:57:09 +08:00
|
|
|
// compile-flags:-g
|
2014-07-09 20:46:09 +08:00
|
|
|
|
|
|
|
|
// === GDB TESTS ===================================================================================
|
|
|
|
|
|
2014-04-24 17:35:48 +08:00
|
|
|
// gdb-command:run
|
|
|
|
|
|
|
|
|
|
// gdb-command:print int_int
|
2016-10-26 05:32:04 +08:00
|
|
|
// gdbg-check:$1 = {key = 0, value = 1}
|
|
|
|
|
// gdbr-check:$1 = generic_struct::AGenericStruct<i32, i32> {key: 0, value: 1}
|
2014-04-24 17:35:48 +08:00
|
|
|
// gdb-command:print int_float
|
2016-10-26 05:32:04 +08:00
|
|
|
// gdbg-check:$2 = {key = 2, value = 3.5}
|
|
|
|
|
// gdbr-check:$2 = generic_struct::AGenericStruct<i32, f64> {key: 2, value: 3.5}
|
2014-04-24 17:35:48 +08:00
|
|
|
// gdb-command:print float_int
|
2016-10-26 05:32:04 +08:00
|
|
|
// gdbg-check:$3 = {key = 4.5, value = 5}
|
|
|
|
|
// gdbr-check:$3 = generic_struct::AGenericStruct<f64, i32> {key: 4.5, value: 5}
|
2014-04-24 17:35:48 +08:00
|
|
|
// gdb-command:print float_int_float
|
2016-10-26 05:32:04 +08:00
|
|
|
// gdbg-check:$4 = {key = 6.5, value = {key = 7, value = 8.5}}
|
|
|
|
|
// gdbr-check:$4 = generic_struct::AGenericStruct<f64, generic_struct::AGenericStruct<i32, f64>> {key: 6.5, value: generic_struct::AGenericStruct<i32, f64> {key: 7, value: 8.5}}
|
2013-08-13 22:31:42 +08:00
|
|
|
|
2014-07-09 20:46:09 +08:00
|
|
|
// === LLDB TESTS ==================================================================================
|
|
|
|
|
|
|
|
|
|
// lldb-command:run
|
|
|
|
|
|
|
|
|
|
// lldb-command:print int_int
|
2018-10-03 00:13:30 +08:00
|
|
|
// lldbg-check:[...]$0 = AGenericStruct<i32, i32> { key: 0, value: 1 }
|
|
|
|
|
// lldbr-check:(generic_struct::AGenericStruct<i32, i32>) int_int = AGenericStruct<i32, i32> { key: 0, value: 1 }
|
2014-07-09 20:46:09 +08:00
|
|
|
// lldb-command:print int_float
|
2018-10-03 00:13:30 +08:00
|
|
|
// lldbg-check:[...]$1 = AGenericStruct<i32, f64> { key: 2, value: 3.5 }
|
|
|
|
|
// lldbr-check:(generic_struct::AGenericStruct<i32, f64>) int_float = AGenericStruct<i32, f64> { key: 2, value: 3.5 }
|
2014-07-09 20:46:09 +08:00
|
|
|
// lldb-command:print float_int
|
2018-10-03 00:13:30 +08:00
|
|
|
// lldbg-check:[...]$2 = AGenericStruct<f64, i32> { key: 4.5, value: 5 }
|
|
|
|
|
// lldbr-check:(generic_struct::AGenericStruct<f64, i32>) float_int = AGenericStruct<f64, i32> { key: 4.5, value: 5 }
|
2014-07-09 20:46:09 +08:00
|
|
|
|
|
|
|
|
// lldb-command:print float_int_float
|
2018-10-03 00:13:30 +08:00
|
|
|
// lldbg-check:[...]$3 = AGenericStruct<f64, generic_struct::AGenericStruct<i32, f64>> { key: 6.5, value: AGenericStruct<i32, f64> { key: 7, value: 8.5 } }
|
|
|
|
|
// lldbr-check:(generic_struct::AGenericStruct<f64, generic_struct::AGenericStruct<i32, f64>>) float_int_float = AGenericStruct<f64, generic_struct::AGenericStruct<i32, f64>> { key: 6.5, value: AGenericStruct<i32, f64> { key: 7, value: 8.5 } }
|
2014-07-09 20:46:09 +08: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-25 01:36:28 +08:00
|
|
|
// === CDB TESTS ===================================================================================
|
|
|
|
|
|
|
|
|
|
// cdb-command:g
|
|
|
|
|
|
|
|
|
|
// cdb-command:dx int_int
|
2021-07-19 17:00:21 +08:00
|
|
|
// cdb-check:int_int [Type: generic_struct::AGenericStruct<i32,i32>]
|
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-25 01:36:28 +08:00
|
|
|
// cdb-check:[...]key : 0 [Type: int]
|
|
|
|
|
// cdb-check:[...]value : 1 [Type: int]
|
|
|
|
|
// cdb-command:dx int_float
|
2021-07-19 17:00:21 +08:00
|
|
|
// cdb-check:int_float [Type: generic_struct::AGenericStruct<i32,f64>]
|
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-25 01:36:28 +08:00
|
|
|
// cdb-check:[...]key : 2 [Type: int]
|
|
|
|
|
// cdb-check:[...]value : 3.500000 [Type: double]
|
|
|
|
|
// cdb-command:dx float_int
|
2021-07-19 17:00:21 +08:00
|
|
|
// cdb-check:float_int [Type: generic_struct::AGenericStruct<f64,i32>]
|
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-25 01:36:28 +08:00
|
|
|
// cdb-check:[...]key : 4.500000 [Type: double]
|
|
|
|
|
// cdb-check:[...]value : 5 [Type: int]
|
|
|
|
|
// cdb-command:dx float_int_float
|
2021-07-19 17:00:21 +08:00
|
|
|
// cdb-check:float_int_float [Type: generic_struct::AGenericStruct<f64,generic_struct::AGenericStruct<i32,f64> >]
|
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-25 01:36:28 +08:00
|
|
|
// cdb-check:[...]key : 6.500000 [Type: double]
|
2021-07-19 17:00:21 +08:00
|
|
|
// cdb-check:[...]value [Type: generic_struct::AGenericStruct<i32,f64>]
|
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-25 01:36:28 +08:00
|
|
|
|
2014-12-04 06:48:18 +08:00
|
|
|
|
2015-09-20 04:33:47 +08:00
|
|
|
#![feature(omit_gdb_pretty_printer_section)]
|
2014-12-04 06:48:18 +08:00
|
|
|
#![omit_gdb_pretty_printer_section]
|
|
|
|
|
|
2013-08-13 22:31:42 +08:00
|
|
|
struct AGenericStruct<TKey, TValue> {
|
|
|
|
|
key: TKey,
|
|
|
|
|
value: TValue
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn main() {
|
|
|
|
|
|
2015-01-26 05:05:03 +08:00
|
|
|
let int_int = AGenericStruct { key: 0, value: 1 };
|
|
|
|
|
let int_float = AGenericStruct { key: 2, value: 3.5f64 };
|
|
|
|
|
let float_int = AGenericStruct { key: 4.5f64, value: 5 };
|
2014-06-28 03:30:25 +08:00
|
|
|
let float_int_float = AGenericStruct {
|
|
|
|
|
key: 6.5f64,
|
2015-01-26 05:05:03 +08:00
|
|
|
value: AGenericStruct { key: 7, value: 8.5f64 },
|
2014-06-28 03:30:25 +08:00
|
|
|
};
|
2013-08-13 22:31:42 +08:00
|
|
|
|
2014-07-09 20:46:09 +08:00
|
|
|
zzz(); // #break
|
2013-08-13 22:31:42 +08:00
|
|
|
}
|
|
|
|
|
|
2014-07-09 20:46:09 +08:00
|
|
|
fn zzz() { () }
|