nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-26 08:44:35 +00:00
Code Issues Packages Projects Releases Wiki Activity
ca5d25e2c4
rust/tests/debuginfo/pretty-std.rs

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

189 lines
6.5 KiB
Rust
Raw Normal View History

Ignore tidy linelength
2024-02-21 02:12:05 +00:00
// ignore-tidy-linelength
debuginfo: Add GDB pretty printers for slices, Vec<>, and String.
2015-03-12 16:05:44 +00:00
//@ ignore-freebsd: gdb package too new
Fix CDB support tidy check line length failures.
2019-05-20 09:44:26 +00:00
//@ only-cdb // "Temporarily" ignored on GDB/LLDB due to debuginfo tests being disabled, see PR 47155
debuginfo: Add GDB pretty printers for slices, Vec<>, and String.
2015-03-12 16:05:44 +00:00
//@ ignore-android: FIXME(#10381)
//@ compile-flags:-g
Add missing : after min-gdb-version
2020-07-18 03:17:30 +00:00
//@ min-gdb-version: 7.7
debuginfo: Create common debugger pretty printer module. GDB and LLDB pretty printers have some common functionality and also access some common information, such as the layout of standard library types. So far, this information has been duplicated in the two pretty printing python modules. This commit introduces a common module used by both debuggers.
2015-05-09 14:48:36 +00:00
//@ min-lldb-version: 310
Add debug info tests for range, fix-sized array, and cell types.
2021-03-30 17:43:39 +00:00
//@ min-cdb-version: 10.0.18317.1001
debuginfo: Create common debugger pretty printer module. GDB and LLDB pretty printers have some common functionality and also access some common information, such as the layout of standard library types. So far, this information has been duplicated in the two pretty printing python modules. This commit introduces a common module used by both debuggers.
2015-05-09 14:48:36 +00:00
// === GDB TESTS ===================================================================================
debuginfo: Add GDB pretty printers for slices, Vec<>, and String.
2015-03-12 16:05:44 +00:00
// gdb-command: run
// gdb-command: print slice
// gdb-check:$1 = &[i32](len: 4) = {0, 1, 2, 3}
// gdb-command: print vec
Fix debuginfo test for `Vec`
2020-11-19 10:22:53 +00:00
// gdb-check:$2 = Vec<u64, alloc::alloc::Global>(len: 4, cap: [...]) = {4, 5, 6, 7}
debuginfo: Add GDB pretty printers for slices, Vec<>, and String.
2015-03-12 16:05:44 +00:00
// gdb-command: print str_slice
// gdb-check:$3 = "IAMA string slice!"
// gdb-command: print string
// gdb-check:$4 = "IAMA string!"
// gdb-command: print some
// gdb-check:$5 = Some = {8}
// gdb-command: print none
adapt debuginfo tests for gdb with native rust support
2016-10-25 21:32:04 +00:00
// gdbg-check:$6 = None
// gdbr-check:$6 = core::option::Option::None
debuginfo: Add GDB pretty printers for slices, Vec<>, and String.
2015-03-12 16:05:44 +00:00
Pretty-printers tests: gdbr -> gdb
2017-06-09 15:51:28 +00:00
// gdb-command: print os_string
// gdb-check:$7 = "IAMA OS string 😃"
Add GDB pretty-printer for OsString
2017-06-02 13:18:00 +00:00
Pretty-printers tests: gdbr -> gdb
2017-06-09 15:51:28 +00:00
// gdb-command: print some_string
// gdb-check:$8 = Some = {"IAMA optional string!"}
Add test for 'invalid literal for int()' exception in gdb pretty-printers
2017-06-01 18:26:09 +00:00
Implement display_hint in gdb pretty printers A few pretty-printers were returning a quoted string from their to_string method. It's preferable in gdb to return a lazy string and to let gdb handle the display by having a "display_hint" method that returns "string" -- it lets gdb settings (like "set print ...") work, it handles corrupted strings a bit better, and it passes the information along to IDEs.
2017-10-03 19:28:57 +00:00
// gdb-command: set print length 5
// gdb-command: print some_string
// gdb-check:$8 = Some = {"IAMA "...}
debuginfo: Create common debugger pretty printer module. GDB and LLDB pretty printers have some common functionality and also access some common information, such as the layout of standard library types. So far, this information has been duplicated in the two pretty printing python modules. This commit introduces a common module used by both debuggers.
2015-05-09 14:48:36 +00:00
// === LLDB TESTS ==================================================================================
Fix remaining LLDB commands.
2024-03-15 19:30:45 +00:00
// lldb-command:run
debuginfo: Create common debugger pretty printer module. GDB and LLDB pretty printers have some common functionality and also access some common information, such as the layout of standard library types. So far, this information has been duplicated in the two pretty printing python modules. This commit introduces a common module used by both debuggers.
2015-05-09 14:48:36 +00:00
Fix remaining LLDB commands.
2024-03-15 19:30:45 +00:00
// lldb-command:v slice
// lldb-check:[...] slice = &[0, 1, 2, 3]
debuginfo: Create common debugger pretty printer module. GDB and LLDB pretty printers have some common functionality and also access some common information, such as the layout of standard library types. So far, this information has been duplicated in the two pretty printing python modules. This commit introduces a common module used by both debuggers.
2015-05-09 14:48:36 +00:00
Fix remaining LLDB commands.
2024-03-15 19:30:45 +00:00
// lldb-command:v vec
// lldb-check:[...] vec = vec![4, 5, 6, 7]
debuginfo: Create common debugger pretty printer module. GDB and LLDB pretty printers have some common functionality and also access some common information, such as the layout of standard library types. So far, this information has been duplicated in the two pretty printing python modules. This commit introduces a common module used by both debuggers.
2015-05-09 14:48:36 +00:00
Fix remaining LLDB commands.
2024-03-15 19:30:45 +00:00
// lldb-command:v str_slice
// lldb-check:[...] str_slice = "IAMA string slice!"
debuginfo: Create common debugger pretty printer module. GDB and LLDB pretty printers have some common functionality and also access some common information, such as the layout of standard library types. So far, this information has been duplicated in the two pretty printing python modules. This commit introduces a common module used by both debuggers.
2015-05-09 14:48:36 +00:00
Fix remaining LLDB commands.
2024-03-15 19:30:45 +00:00
// lldb-command:v string
// lldb-check:[...] string = "IAMA string!"
debuginfo: Create common debugger pretty printer module. GDB and LLDB pretty printers have some common functionality and also access some common information, such as the layout of standard library types. So far, this information has been duplicated in the two pretty printing python modules. This commit introduces a common module used by both debuggers.
2015-05-09 14:48:36 +00:00
Fix remaining LLDB commands.
2024-03-15 19:30:45 +00:00
// lldb-command:v some
// lldb-check:[...] some = Some(8)
debuginfo: Create common debugger pretty printer module. GDB and LLDB pretty printers have some common functionality and also access some common information, such as the layout of standard library types. So far, this information has been duplicated in the two pretty printing python modules. This commit introduces a common module used by both debuggers.
2015-05-09 14:48:36 +00:00
Fix remaining LLDB commands.
2024-03-15 19:30:45 +00:00
// lldb-command:v none
// lldb-check:[...] none = None
debuginfo: Create common debugger pretty printer module. GDB and LLDB pretty printers have some common functionality and also access some common information, such as the layout of standard library types. So far, this information has been duplicated in the two pretty printing python modules. This commit introduces a common module used by both debuggers.
2015-05-09 14:48:36 +00:00
Fix remaining LLDB commands.
2024-03-15 19:30:45 +00:00
// lldb-command:v os_string
// lldb-check:[...] os_string = "IAMA OS string 😃"[...]
Implement new gdb/lldb pretty-printers Replace old GDB and LLDB pretty-printers with new ones which were originally written for IntelliJ Rust. New LLDB pretty-printers support synthetic children. New GDB/LLDB pretty-printers support all Rust types supported by old pretty-printers, and also support: Rc, Arc, Cell, Ref, RefCell, RefMut, HashMap, HashSet.
2019-05-14 12:50:58 +00:00
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-20 00:10:48 +00:00
// === CDB TESTS ==================================================================================
// cdb-command: g
// cdb-command: dx slice,d
[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 10:28:03 +00:00
// cdb-check:slice,d : { len=4 } [Type: ref$<slice2$<i32> >]
Add debug info tests for range, fix-sized array, and cell types.
2021-03-30 17:43:39 +00:00
// cdb-check: [len] : 4 [Type: [...]]
// cdb-check: [0] : 0 [Type: int]
// cdb-check: [1] : 1 [Type: int]
// cdb-check: [2] : 2 [Type: int]
// cdb-check: [3] : 3 [Type: int]
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-20 00:10:48 +00:00
// cdb-command: dx vec,d
[debuginfo] Adapt CDB tests after changes to whitespace usage in debuginfo type names.
2021-07-19 09:00:21 +00:00
// cdb-check:vec,d [...] : { len=4 } [Type: [...]::Vec<u64,alloc::alloc::Global>]
Improvements to NatVis support NatVis files describe how to display types in some Windows debuggers, such as Visual Studio, WinDbg, and VS Code. This commit makes several improvements: * Adds visualizers for Rc<T>, Weak<T>, and Arc<T>. * Changes [size] to [len], for consistency with the Rust API. Visualizers often use [size] to mirror the size() method on C++ STL collections. * Several visualizers used the PVOID and ULONG typedefs. These are part of the Windows API; they are not guaranteed to always be defined in a pure Rust DLL/EXE. I converted PVOID to `void*` and `ULONG` to `unsigned long`. * Cosmetic change: Removed {} braces around the visualized display for `Option` types. They now display simply as `Some(value)` or `None`, which reflects what is written in source code. * The visualizer for `alloc::string::String` makes assumptions about the layout of `String` (it casts `String*` to another type), rather than using symbolic expressions. This commit changes the visualizer so that it simply uses symbolic expressions to access the string data and string length.
2020-12-22 22:02:07 +00:00
// cdb-check: [len] : 4 [Type: [...]]
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-20 00:10:48 +00:00
// cdb-check: [capacity] : [...] [Type: [...]]
// cdb-check: [0] : 4 [Type: unsigned __int64]
// cdb-check: [1] : 5 [Type: unsigned __int64]
// cdb-check: [2] : 6 [Type: unsigned __int64]
// cdb-check: [3] : 7 [Type: unsigned __int64]
// cdb-command: dx str_slice
[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 10:28:03 +00:00
// cdb-check:str_slice : "IAMA string slice!" [Type: ref$<str$>]
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-20 00:10:48 +00:00
// cdb-command: dx string
// cdb-check:string : "IAMA string!" [Type: [...]::String]
// cdb-check: [<Raw View>] [Type: [...]::String]
Improvements to NatVis support NatVis files describe how to display types in some Windows debuggers, such as Visual Studio, WinDbg, and VS Code. This commit makes several improvements: * Adds visualizers for Rc<T>, Weak<T>, and Arc<T>. * Changes [size] to [len], for consistency with the Rust API. Visualizers often use [size] to mirror the size() method on C++ STL collections. * Several visualizers used the PVOID and ULONG typedefs. These are part of the Windows API; they are not guaranteed to always be defined in a pure Rust DLL/EXE. I converted PVOID to `void*` and `ULONG` to `unsigned long`. * Cosmetic change: Removed {} braces around the visualized display for `Option` types. They now display simply as `Some(value)` or `None`, which reflects what is written in source code. * The visualizer for `alloc::string::String` makes assumptions about the layout of `String` (it casts `String*` to another type), rather than using symbolic expressions. This commit changes the visualizer so that it simply uses symbolic expressions to access the string data and string length.
2020-12-22 22:02:07 +00:00
// cdb-check: [len] : 0xc [Type: [...]]
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-20 00:10:48 +00:00
// cdb-check: [capacity] : 0xc [Type: [...]]
Improvements to NatVis support NatVis files describe how to display types in some Windows debuggers, such as Visual Studio, WinDbg, and VS Code. This commit makes several improvements: * Adds visualizers for Rc<T>, Weak<T>, and Arc<T>. * Changes [size] to [len], for consistency with the Rust API. Visualizers often use [size] to mirror the size() method on C++ STL collections. * Several visualizers used the PVOID and ULONG typedefs. These are part of the Windows API; they are not guaranteed to always be defined in a pure Rust DLL/EXE. I converted PVOID to `void*` and `ULONG` to `unsigned long`. * Cosmetic change: Removed {} braces around the visualized display for `Option` types. They now display simply as `Some(value)` or `None`, which reflects what is written in source code. * The visualizer for `alloc::string::String` makes assumptions about the layout of `String` (it casts `String*` to another type), rather than using symbolic expressions. This commit changes the visualizer so that it simply uses symbolic expressions to access the string data and string length.
2020-12-22 22:02:07 +00:00
// cdb-command: dx -r2 string
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-20 00:10:48 +00:00
// cdb-check: [0] : 73 'I' [Type: char]
// cdb-check: [1] : 65 'A' [Type: char]
// cdb-check: [2] : 77 'M' [Type: char]
// cdb-check: [3] : 65 'A' [Type: char]
// cdb-check: [4] : 32 ' ' [Type: char]
// cdb-check: [5] : 115 's' [Type: char]
// cdb-check: [6] : 116 't' [Type: char]
// cdb-check: [7] : 114 'r' [Type: char]
// cdb-check: [8] : 105 'i' [Type: char]
// cdb-check: [9] : 110 'n' [Type: char]
// cdb-check: [10] : 103 'g' [Type: char]
// cdb-check: [11] : 33 '!' [Type: char]
// cdb-command: dx os_string
Fix debuginfo tests for the latest version of the Windows SDK. - Cdb now correctly visualizes enums. - Cdb doesn't render emoji characters in `OSStr` anymore. - Cdb doesn't always render `str` correctly (#88840)
2021-09-10 23:51:10 +00:00
// NOTE: OSString is WTF-8 encoded which Windows debuggers don't understand. Verify the UTF-8
// portion displays correctly.
// cdb-check:os_string : "IAMA OS string [...]" [Type: std::ffi::os_str::OsString]
Add visualizer for OsString and fixup other string visualizers
2021-07-01 19:57:12 +00:00
// cdb-check: [<Raw View>] [Type: std::ffi::os_str::OsString]
Fix debuginfo tests for the latest version of the Windows SDK. - Cdb now correctly visualizes enums. - Cdb doesn't render emoji characters in `OSStr` anymore. - Cdb doesn't always render `str` correctly (#88840)
2021-09-10 23:51:10 +00:00
// cdb-check: [chars] : "IAMA OS string [...]"
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-20 00:10:48 +00:00
// cdb-command: dx some
Use enum2<_> instead of enum<_> for Cpp-like debuginfo enum type names. And add more comments about niche tag enum encoding.
2022-07-07 13:01:43 +00:00
// cdb-check:some : Some [Type: enum2$<core::option::Option<i16> >]
// cdb-check: [<Raw View>] [Type: enum2$<core::option::Option<i16> >]
Update directly tagged enums to visualize the same as niche-layout enums Previously, directly tagged enums had a `variant$` field which would show the name of the active variant. We now show the variant using a `[variant]` synthetic item just like we do for niche-layout enums.
2021-06-24 20:37:03 +00:00
// cdb-check: [+0x002] __0 : 8 [Type: short]
Add debug info tests for range, fix-sized array, and cell types.
2021-03-30 17:43:39 +00:00
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-20 00:10:48 +00:00
// cdb-command: dx none
Use enum2<_> instead of enum<_> for Cpp-like debuginfo enum type names. And add more comments about niche tag enum encoding.
2022-07-07 13:01:43 +00:00
// cdb-check:none : None [Type: enum2$<core::option::Option<i64> >]
// cdb-check: [<Raw View>] [Type: enum2$<core::option::Option<i64> >]
Add debug info tests for range, fix-sized array, and cell types.
2021-03-30 17:43:39 +00:00
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-20 00:10:48 +00:00
// cdb-command: dx some_string
Use enum2<_> instead of enum<_> for Cpp-like debuginfo enum type names. And add more comments about niche tag enum encoding.
2022-07-07 13:01:43 +00:00
// cdb-check:some_string : Some [Type: enum2$<core::option::Option<alloc::string::String> >]
// cdb-check: [<Raw View>] [Type: enum2$<core::option::Option<alloc::string::String> >]
Fix debuginfo tests for the latest version of the Windows SDK. - Cdb now correctly visualizes enums. - Cdb doesn't render emoji characters in `OSStr` anymore. - Cdb doesn't always render `str` correctly (#88840)
2021-09-10 23:51:10 +00:00
// cdb-check: [+0x000] __0 : "IAMA optional string!" [Type: alloc::string::String]
Add basic CDB support to debuginfo compiletest s, to help catch `*.natvis` regressions, like those fixed in #60687. Several Microsoft debuggers (VS, VS Code, WinDbg, CDB, ...) consume the `*.natvis` files we embed into rust `*.pdb` files. While this only tests CDB, that test coverage should help for all of them. CHANGES src\bootstrap - test.rs: Run CDB debuginfo tests on MSVC targets src\test\debuginfo - issue-13213.rs: CDB has trouble with this, skip for now (newly discovered regression?) - pretty-std.rs: Was ignored, re-enable for CDB only to start with, add CDB tests. - should-fail.rs: Add CDB tests. src\tools\compiletest: - Added "-cdb" option - Added Mode::DebugInfoCdb ("debuginfo-cdb") - Added run_debuginfo_cdb_test[_no_opt] - Renamed Mode::DebugInfoBoth -> DebugInfoGdbLldb ("debuginfo-gdb+lldb") since it's no longer clear what "Both" means. - Find CDB at the default Win10 SDK install path "C:\Program Files (x86)\Windows Kits\10\Debugger\*\cdb.exe" - Ignore CDB tests if CDB not found. ISSUES - `compute_stamp_hash`: not sure if there's any point in hashing `%ProgramFiles(x86)%` - `OsString` lacks any `*.natvis` entries (would be nice to add in a followup changelist) - DSTs (array/string slices) which work in VS & VS Code fail in CDB. - I've avoided `Mode::DebugInfoAll` as 3 debuggers leads to pow(2,3)=8 possible combinations. REFERENCE CDB is not part of the base Visual Studio install, but can be added via the Windows 10 SDK: https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk Installing just "Debugging Tools for Windows" is sufficient. CDB appears to already be installed on appveyor CI, where this changelist can find it, based on it's use here: https://github.com/rust-lang/rust/blob/0ffc57311030a1930edfa721fe57d0000a063af4/appveyor.yml#L227 CDB commands and command line reference: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-reference
2019-05-20 00:10:48 +00:00
Add/improve visualizations for liballoc types
2021-06-30 21:23:44 +00:00
// cdb-command: dx linkedlist
Add support for allocators in LinkedList
2023-03-19 20:15:26 +00:00
// cdb-check:linkedlist : { len=0x2 } [Type: alloc::collections::linked_list::LinkedList<i32,alloc::alloc::Global>]
// cdb-check: [<Raw View>] [Type: alloc::collections::linked_list::LinkedList<i32,alloc::alloc::Global>]
Add/improve visualizations for liballoc types
2021-06-30 21:23:44 +00:00
// cdb-check: [0x0] : 128 [Type: int]
// cdb-check: [0x1] : 42 [Type: int]
// cdb-command: dx vecdeque
Fix failing test
2021-07-25 18:34:08 +00:00
// cdb-check:vecdeque : { len=0x2 } [Type: alloc::collections::vec_deque::VecDeque<i32,alloc::alloc::Global>]
// cdb-check: [<Raw View>] [Type: alloc::collections::vec_deque::VecDeque<i32,alloc::alloc::Global>]
Fix `pretty-std` test
2022-11-27 22:08:14 +00:00
// cdb-check: [len] : 0x2 [Type: unsigned [...]]
Fix tests for i686
2021-07-14 20:50:11 +00:00
// cdb-check: [capacity] : 0x8 [Type: unsigned [...]]
Add/improve visualizations for liballoc types
2021-06-30 21:23:44 +00:00
// cdb-check: [0x0] : 90 [Type: int]
// cdb-check: [0x1] : 20 [Type: int]
#10381: Warnings
2015-04-22 04:53:07 +00:00
#![allow(unused_variables)]
Add/improve visualizations for liballoc types
2021-06-30 21:23:44 +00:00
use std::collections::{LinkedList, VecDeque};
Add GDB pretty-printer for OsString
2017-06-02 13:18:00 +00:00
use std::ffi::OsString;
debuginfo: Add GDB pretty printers for slices, Vec<>, and String.
2015-03-12 16:05:44 +00:00
fn main() {
// &[]
let slice: &[i32] = &[0, 1, 2, 3];
// Vec
let vec = vec![4u64, 5, 6, 7];
// &str
let str_slice = "IAMA string slice!";
// String
let string = "IAMA string!".to_string();
Add GDB pretty-printer for OsString
2017-06-02 13:18:00 +00:00
// OsString
let os_string = OsString::from("IAMA OS string \u{1F603}");
debuginfo: Add GDB pretty printers for slices, Vec<>, and String.
2015-03-12 16:05:44 +00:00
// Option
let some = Some(8i16);
let none: Option<i64> = None;
Add test for 'invalid literal for int()' exception in gdb pretty-printers
2017-06-01 18:26:09 +00:00
let some_string = Some("IAMA optional string!".to_owned());
Add/improve visualizations for liballoc types
2021-06-30 21:23:44 +00:00
// LinkedList
let mut linkedlist = LinkedList::new();
linkedlist.push_back(42);
linkedlist.push_front(128);
// VecDeque
Fix `pretty-std` test
2022-11-27 22:08:14 +00:00
let mut vecdeque = VecDeque::with_capacity(8);
Add/improve visualizations for liballoc types
2021-06-30 21:23:44 +00:00
vecdeque.push_back(20);
vecdeque.push_front(90);
debuginfo: Add GDB pretty printers for slices, Vec<>, and String.
2015-03-12 16:05:44 +00:00
zzz(); // #break
}
debuginfo: Change C++-like encoding for enums. The updated encoding should be able to handle niche layouts where more than one variant has fields.
2022-06-20 15:50:27 +00:00
fn zzz() {
()
}
Reference in New Issue Copy Permalink