about summary refs log tree commit diff
path: root/src/test/debuginfo
AgeCommit message (Collapse)AuthorLines
2021-07-08Add natvis for cell typesWesley Wiser-15/+68
2021-07-08Add natvis for Atomic typesWesley Wiser-2/+66
2021-07-08Add natvis for NonZero and Wrapping typesWesley Wiser-0/+142
2021-07-08Auto merge of #85363 - EFanZh:gdb-pretty-print-slices, r=michaelwoeristerbors-1/+47
Support pretty printing slices using GDB Support pretty printing `&[T]`, `&mut [T]` and `&mut str` types using GDB. Support pretty printing `&mut [T]` and `&mut str` types using LLDB. Fixes #85219.
2021-07-08Ignore Windows debugger pretty-printing testsEFanZh-0/+1
2021-07-07Ignore Android debugger pretty-printing testsEFanZh-1/+1
2021-07-06Fix failing test on i686-pc-windows-msvcWesley Wiser-1/+1
2021-07-03Support pretty printing slices using GDBEFanZh-1/+46
2021-07-02Respond to review feedbackWesley Wiser-1/+5
2021-07-02Show the variant name for univariant enumsWesley Wiser-0/+8
Previously, only the fields would be displayed with no indication of the variant name. If you already knew the enum was univariant, this was ok but if the enum was univariant because of layout, for example, a `Result<T, !>` then it could be very confusing which variant was the active one.
2021-07-02Update directly tagged enums to visualize the same as niche-layout enumsWesley Wiser-5/+23
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-07-02Fix type name difference between i686 and x86_64 for testWesley Wiser-1/+1
2021-07-01Update cdb tests for expected outputWesley Wiser-66/+70
Also an fix issue with tuple type names where we can't cast to them in natvis (required by the visualizer for `HashMap`) because of peculiarities with the natvis expression evaluator.
2021-06-30Improve debug symbol names to avoid ambiguity and work better with MSVC's ↵Daniel Paoliello-185/+504
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-25Add debug info tests for range, fix-sized array, and cell types.Nam Nguyen-5/+337
2021-06-02Respond to review feedbackWesley Wiser-16/+8
2021-06-02Change the type name from `_enum<..>` to `enum$<..>`Wesley Wiser-37/+37
This makes the type name inline with the proposed standard in #85269.
2021-06-02Make tidy happyWesley Wiser-2/+4
2021-06-02Add/update testsWesley Wiser-3/+107
2021-05-07Rollup merge of #84500 - tmandry:compiletest-run-flag, r=Mark-SimulacrumDylan DPC-0/+1
Add --run flag to compiletest This controls whether run-* tests actually get run. r? ```@Mark-Simulacrum```
2021-04-30Remove artificial flag from generator variantslrh2000-5/+9
- Literally, variants are not artificial. We have `yield` statements, upvars and inner variables in the source code. - Functionally, we don't want debuggers to suppress the variants. It contains the state of the generator, which is useful when debugging. So they shouldn't be marked artificial. - Debuggers may use artificial flags to find the active variant. In this case, marking variants artificial will make debuggers not work properly. Fixes #79009.
2021-04-30Move outer fields of enums into variant parts in debuginfolrh2000-10/+10
All fields except the discriminant (including `outer_fields`) should be put into structures inside the variant part, which gives an equivalent layout but offers us much better integration with debuggers.
2021-04-30Add needs-run-enabled directive for should-fail testsTyler Mandry-0/+1
I was wary of doing any automatic disabling here, since should-fail is how we test compiletest itself.
2021-04-27Fix failed tests related to pointer printing when using GDB 10lrh2000-8/+7
As mentioned in #79009, there are four failed debuginfo test cases when using GDB 10. This commit fixes two of them, which fail because GDB 10 won't print pointers as string anymore. We can use `printf` as a workaround. It should work regardless of the version of GDB. Refer this [comment] for more details. [comment]: https://github.com/rust-lang/rust/issues/79009#issuecomment-826952708
2021-04-18Auto merge of #83799 - crlf0710:stablize_non_ascii_idents, r=Manishearthbors-2/+0
Stablize `non-ascii-idents` This is the stablization PR for RFC 2457. Currently this is waiting on fcp in [tracking issue](https://github.com/rust-lang/rust/issues/55467). r? `@Manishearth`
2021-04-08Fix closed over variables not available in debuginfo for Windows MSVCWesley Wiser-0/+91
The issue was that the resulting debuginfo was too complex for LLVM to translate into CodeView records correctly. As a result, it simply ignored the debuginfo which meant Windows debuggers could not display any closed over variables when stepping inside a closure. This fixes that by spilling additional variables to the stack so that the resulting debuginfo is simple (just `*my_variable.dbg.spill`) and LLVM can generate the correct CV records.
2021-04-08Stablize `non_ascii_idents` feature.Charles Lew-2/+0
2021-04-03Remove redundant `ignore-tidy-linelength` annotationsSimon Jakobi-47/+0
This is step 2 towards fixing #77548. In the codegen and codegen-units test suites, the `//` comment markers were kept in order not to affect any source locations. This is because these tests cannot be automatically `--bless`ed.
2021-01-13Update tests for extern block lintingMark Rousskov-26/+32
2020-12-28Improvements to NatVis supportArlie Davis-10/+12
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-11-21Auto merge of #78461 - TimDiekmann:vec-alloc, r=Amanieubors-2/+2
Add support for custom allocators in `Vec` This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections. r? `@Amanieu` This pull request requires a crater run. ### Prior work: - #71873: Crater-test to solve rust-lang/wg-allocators#1 - [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate
2020-11-20Auto merge of #78104 - ssomers:btree_root_redux, r=Mark-Simulacrumbors-2/+2
BTreeMap: replace Root with NodeRef<Owned, ...> `NodeRef<marker::Owned, …>` already exists as a representation of root nodes, and it makes more sense to alias `Root` to that than to reuse the space-efficient `BoxedNode` that is oblivious to height, where height is required. r? `@Mark-Simulacrum`
2020-11-19Fix debuginfo test for `Vec`Tim Diekmann-2/+2
2020-11-18BTreeMap: reuse NodeRef as Root, keep BoxedNode for edges only, ban UniqueStein Somers-2/+2
2020-11-16Add //ignore-macos to pretty-std-collections.rsest31-0/+1
On macOS the test is flaky and sometimes fails, sometimes succeeds on CI.
2020-10-14BTreeMap: improve gdb introspection of BTreeMap with ZST keys or valuesStein Somers-8/+20
2020-10-10BTreeMap: fix gdb introspection of BTreeMap with ZST keys or valuesStein Somers-5/+11
2020-09-05debuginfo: Ignore HashMap tests before cdb 10.0.18362.1MaulingMonkey-0/+4
cdb chokes on the cast and reports "Unable to find type 'tuple<u64,u64> *' for cast."
2020-08-11Revert "Suppress debuginfo on naked function arguments"Nathaniel McCallum-42/+0
This reverts commit 25670749b44a9c7a4cfd3fbf780bbe3344a9a6c5. This commit does not actually fix the problem. It merely removes the name of the argument from the LLVM output. Even without the name, Rust codegen still spills the (nameless) variable onto the stack which is the root cause. The root cause is solved in the next commit.
2020-08-08Rollup merge of #75224 - Aaron1011:fix/function-arguments-naked, r=AmanieuYuki Okushi-4/+6
Don't call a function in function-arguments-naked.rs Fixes #75096 It's U.B. to use anything other than inline assmebling in a naked function. Fortunately, the `#break` directive works fine without anything in the function body.
2020-08-07Apply `extern "C"` calling conventionAaron Hill-1/+1
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
2020-08-07Only test function-arguments-naked.rs on x86_64Aaron Hill-1/+5
We need to use inline assembly, which is inherently platform-specific.
2020-08-07Fix natvis testsAmanieu d'Antras-15/+15
2020-08-06Don't call a function in function-arguments-naked.rsAaron Hill-3/+1
Fixes #75096 It's U.B. to use anything other than inline assmebling in a naked function. Fortunately, the `#break` directive works fine without anything in the function body.
2020-08-02tests: Ignore src/test/debuginfo/rc_arc.rs on WindowsVadim Petrochenkov-0/+1
It requires loading pretty-printers, but GDB doesn't load them on Windows
2020-07-27Suppress debuginfo on naked function argumentsNathaniel McCallum-0/+40
A function that has no prologue cannot be reasonably expected to support debuginfo. In fact, the existing code (before this patch) would generate invalid instructions that caused crashes. We can solve this easily by just not emitting the debuginfo in this case. Fixes https://github.com/rust-lang/rust/issues/42779 cc https://github.com/rust-lang/rust/issues/32408
2020-07-19Add missing : after min-gdb-versionLzu Tao-5/+5
2020-06-24Modify type names on MSVC to make tuples .natvis compatible.MaulingMonkey-0/+109
- Mangles (T0, T1) as tuple<T0, T1>, possibly unblocking rust-lang/rust#70052 "Update hashbrown to 0.8.0" - Prettifies Rust tuples similar to VS2017's std::tuple - Improves debuginfo test coverage
2020-06-09Implement new gdb/lldb pretty-printersortem-302/+392
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.
2020-05-16`ret` has been optimized away in debuginfo testDylan MacKenzie-30/+9
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-22 14:18:06 +0000