| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Before this fix, the debuginfo for the fields was generated from the
struct defintion of Box<T>, but (at least at the moment) the compiler
pretends that Box<T> is just a (fat) pointer, so the fields need to be
`pointer` and `vtable` instead of `__0: Unique<T>` and `__1: Allocator`.
This is meant as a temporary mitigation until we can make sure that
simply treating Box as a regular struct in debuginfo does not cause too
much breakage in the ecosystem.
|
|
GDB 11.2 added support for DW_ATE_UTF, which caused some test
failures. This fixes these tests by changing the format that is used,
and adds a new test to verify that characters are emitted as something
that GDB can print in a char-like way.
Fixes #94458
|
|
r=wesleywiser
debuginfo: Fix bug in type name generation for dyn types with associated types but no other generic arguments.
For types like `&dyn Future<Output=bool>` the compiler currently emits invalid types names in debuginfo. This PR fixes this.
Before:
```txt
// DWARF
&dyn core::future::future::Future, Output=bool>
// CodeView
ref$<dyn$<core::future::future::Future,assoc$<Output,bool> > > >
```
After:
```txt
// DWARF
&dyn core::future::future::Future<Output=bool>
// CodeView
ref$<dyn$<core::future::future::Future<assoc$<Output,bool> > > >
```
These syntactically incorrect type names can cause downstream tools (e.g. debugger extensions) crash when trying to parse them.
r? `@wesleywiser`
|
|
test case architecture independent.
|
|
works for them
|
|
This commit
- changes names to use di_node instead of metadata
- uniformly names all functions that build new debuginfo nodes build_xyz_di_node
- renames CrateDebugContext to CodegenUnitDebugContext (which is more accurate)
- moves TypeMap and functions that work directly work with it to a new type_map module
- moves and reimplements enum related builder functions to a new enums module
- splits enum debuginfo building for the native and cpp-like cases, since they are mostly separate
- uses SmallVec instead of Vec in many places
- removes the old infrastructure for dealing with recursion cycles (create_and_register_recursive_type_forward_declaration(), RecursiveTypeDescription, set_members_of_composite_type(), MemberDescription, MemberDescriptionFactory, prepare_xyz_metadata(), etc)
- adds type_map::build_type_with_children() as a replacement for dealing with recursion cycles
- adds many (doc-)comments explaining what's going on
- changes cpp-like naming for C-Style enums so they don't get a enum$<...> name (because the NatVis visualizer does not apply to them)
- fixes detection of what is a C-style enum because some enums where classified as C-style even though they have fields
- changes the position of discriminant debuginfo node so it is consistently nested inside the top-level union instead of, sometimes, next to it
|
|
types but no other generic arguments.
|
|
Rust previously encoded the `char` type as DW_ATE_unsigned_char. The more
appropriate encoding is DW_ATE_UTF.
Clang uses this same debug encoding for char32_t.
This fixes the display of `char` types in Windows debuggers as well as LLDB.
|
|
|
|
Compress amount of hashed bytes for `isize` values in StableHasher
This is another attempt to land https://github.com/rust-lang/rust/pull/92103, this time hopefully with a correct implementation w.r.t. stable hashing guarantees. The previous PR was [reverted](https://github.com/rust-lang/rust/pull/93014) because it could produce the [same hash](https://github.com/rust-lang/rust/pull/92103#issuecomment-1014625442) for different values even in quite simple situations. I have since added a basic [test](https://github.com/rust-lang/rust/pull/93193) that should guard against that situation, I also added a new test in this PR, specialised for this optimization.
## Why this optimization helps
Since the original PR, I have tried to analyze why this optimization even helps (and why it especially helps for `clap`). I found that the vast majority of stable-hashing `i64` actually comes from hashing `isize` (which is converted to `i64` in the stable hasher). I only found a single place where is this datatype used directly in the compiler, and this place has also been showing up in traces that I used to find out when is `isize` being hashed. This place is `rustc_span::FileName::DocTest`, however, I suppose that isizes also come from other places, but they might not be so easy to find (there were some other entries in the trace). `clap` hashes about 8.5 million `isize`s, and all of them fit into a single byte, which is why this optimization has helped it [quite a lot](https://github.com/rust-lang/rust/pull/92103#issuecomment-1005711861).
Now, I'm not sure if special casing `isize` is the correct solution here, maybe something could be done with that `isize` inside `DocTest` or in other places, but that's for another discussion I suppose. In this PR, instead of hardcoding a special case inside `SipHasher128`, I instead put it into `StableHasher`, and only used it for `isize` (I tested that for `i64` it doesn't help, or at least not for `clap` and other few benchmarks that I was testing).
## New approach
Since the most common case is a single byte, I added a fast path for hashing `isize` values which positive value fits within a single byte, and a cold path for the rest of the values.
To avoid the previous correctness problem, we need to make sure that each unique `isize` value will produce a unique hash stream to the hasher. By hash stream I mean a sequence of bytes that will be hashed (a different sequence should produce a different hash, but that is of course not guaranteed).
We have to distinguish different values that produce the same bit pattern when we combine them. For example, if we just simply skipped the leading zero bytes for values that fit within a single byte, `(0xFF, 0xFFFFFFFFFFFFFFFF)` and `(0xFFFFFFFFFFFFFFFF, 0xFF)` would send the same hash stream to the hasher, which must not happen.
To avoid this situation, values `[0, 0xFE]` are hashed as a single byte. When we hash a larger (treating `isize` as `u64`) value, we first hash an additional byte `0xFF`. Since `0xFF` cannot occur when we apply the single byte optimization, we guarantee that the hash streams will be unique when hashing two values `(a, b)` and `(b, a)` if `a != b`:
1) When both `a` and `b` are within `[0, 0xFE]`, their hash streams will be different.
2) When neither `a` and `b` are within `[0, 0xFE]`, their hash streams will be different.
3) When `a` is within `[0, 0xFE]` and `b` isn't, when we hash `(a, b)`, the hash stream will definitely not begin with `0xFF`. When we hash `(b, a)`, the hash stream will definitely begin with `0xFF`. Therefore the hash streams will be different.
r? `@the8472`
|
|
michaelwoerister:fix-generic-closure-and-generator-debuginfo, r=wesleywiser
debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo.
Before this change, closure/generator environments coming from different instantiations of the same generic function were all assigned the same name even though they were distinct types with potentially different data layout. Now we append the generic arguments of the originating function to the type name.
This commit also emits `{closure_env#0}` as the name of these types in order to disambiguate them from the accompanying closure function (which keeps being called `{closure#0}`). Previously both were assigned the same name.
NOTE: Changing debuginfo names like this can break pretty printers and other debugger plugins. I think it's OK in this particular case because the names we are changing were ambiguous anyway. In general though it would be great to have a process for doing changes like these.
|
|
are unique in debuginfo.
Before this change, closure/generator environments coming from different
instantiations of the same generic function were all assigned the same
name even though they were distinct types with potentially different data
layout. Now we append the generic arguments of the originating function
to the type name.
This commit also emits '{closure_env#0}' as the name of these types in
order to disambiguate them from the accompanying closure function
'{closure#0}'. Previously both were assigned the same name.
|
|
|
|
r=davidtwco,oli-obk
Fix debuginfo for pointers/references to unsized types
This PR makes the compiler emit fat pointer debuginfo in all cases. Before, we sometimes got thin-pointer debuginfo, making it impossible to fully interpret the pointed to memory in debuggers. The code is actually cleaner now, especially around generation of trait object pointer debuginfo.
Fixes https://github.com/rust-lang/rust/issues/92718
~~Blocked on https://github.com/rust-lang/rust/pull/92729.~~
|
|
debuginfo tests for old GDB versions and 32-bit targets.
|
|
|
|
|
|
|
|
|
|
The tests checks some pretty-printer output, but pretty-printers are not embedded on windows-gnu
|
|
|
|
|
|
Re-enable the `src/test/debuginfo/mutex.rs` test on Windows
This test required a newer version of cdb than was previously enabled in
CI thus leading to some bitrot in the test since the time it was
originally created. With the update to the `windows-latest` image last
week, we're now running this test in CI and thus uncovered the
regression.
I've updated the test and it now passes.
r? `@ehuss`
|
|
r=oli-obk
Fix debuginfo for parameters passed via the ScalarPair abi on Windows
Mark all of these as locals so the debugger does not try to interpret
them as being a pointer to the value. This extends the approach used
in #81898.
Fixes #88625
|
|
This test required a newer version of cdb than was previously enabled in
CI thus leading to some bitrot in the test since the time it was
originally created. With the update to the `windows-latest` image last
week, we're now running this test in CI and thus uncovered the
regression.
I've updated the test and it now passes.
|
|
Fix debuginfo tests for the latest version of the Windows SDK.
Re-enable the tests that were disabled to fix CI.
Changes:
- Cdb now correctly visualizes enums.
- Cdb doesn't render emoji characters in `OSStr` anymore.
- Cdb doesn't always render `str` correctly (#88840)
|
|
|
|
Mark all of these as locals so the debugger does not try to interpret
them as being a pointer to the value. This extends the approach used in
PR #81898.
|
|
|
|
- Cdb now correctly visualizes enums.
- Cdb doesn't render emoji characters in `OSStr` anymore.
- Cdb doesn't always render `str` correctly (#88840)
|
|
This reverts commit 8059bc1069b88a51ec2dfc2483854b9a854b1994.
|
|
|
|
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- #87832 (Fix debugger stepping behavior with `match` expressions)
- #88123 (Make spans for tuple patterns in E0023 more precise)
- #88215 (Reland #83738: "rustdoc: Don't load all extern crates unconditionally")
- #88216 (Don't stabilize creation of TryReserveError instances)
- #88270 (Handle type ascription type ops in NLL HRTB diagnostics)
- #88289 (Fixes for LLVM change 0f45c16f2caa7c035e5c3edd40af9e0d51ad6ba7)
- #88320 (type_implements_trait consider obligation failure on overflow)
- #88332 (Add argument types tait tests)
- #88340 (Add `c_size_t` and `c_ssize_t` to `std::os::raw`.)
- #88346 (Revert "Add type of a let tait test impl trait straight in let")
- #88348 (Add field types tait tests)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Name the captured upvars for closures/generators in debuginfo
Previously, debuggers print closures as something like
```
y::main::closure-0 (0x7fffffffdd34)
```
The pointer actually references to an upvar. It is not very obvious, especially for beginners.
It's because upvars don't have names before, as they are packed into a tuple. This PR names the upvars, so we can expect to see something like
```
y::main::closure-0 {_captured_ref__b: 0x[...]}
```
r? `@tmandry`
Discussed at https://github.com/rust-lang/rust/pull/84752#issuecomment-831639489 .
|
|
|
|
michaelwoerister:debuginfo-names-dyn-trait-projection-bounds, r=wesleywiser
[debuginfo] Emit associated type bindings in trait object type names.
This PR updates debuginfo type name generation for trait objects to include associated type bindings and auto trait bounds -- so that, for example, the debuginfo type name of `&dyn Iterator<Item=Foo>` and `&dyn Iterator<Item=Bar>` don't both map to just `&dyn Iterator` anymore.
The following table shows examples of debuginfo type names before and after the PR:
| type | before | after |
|------|---------|-------|
| `&dyn Iterator<Item=u32>>` | `&dyn Iterator` | `&dyn Iterator<Item=u32>` |
| `&(dyn Iterator<Item=u32>> + Sync)` | `&dyn Iterator` | `&(dyn Iterator<Item=u32> + Sync)` |
| `&(dyn SomeTrait<bool, i8, Bar=u32>> + Send)` | `&dyn SomeTrait<bool, i8>` | `&(dyn SomeTrait<bool, i8, Bar=u32>> + Send)` |
For targets that need C++-like type names, we use `assoc$<Item,u32>` instead of `Item=u32`:
| type | before | after |
|------|---------|-------|
| `&dyn Iterator<Item=u32>>` | `ref$<dyn$<Iterator> >` | `ref$<dyn$<Iterator<assoc$<Item,u32> > > >` |
| `&(dyn Iterator<Item=u32>> + Sync)` | `ref$<dyn$<Iterator> >` | `ref$<dyn$<Iterator<assoc$<Item,u32> >,Sync> >` |
| `&(dyn SomeTrait<bool, i8, Bar=u32>> + Send)` | `ref$<dyn$<SomeTrait<bool, i8> > >` | `ref$<dyn$<SomeTrait<bool,i8,assoc$<Bar,u32> > >,Send> >` |
The PR also adds self-profiling measurements for debuginfo type name generation (re. https://github.com/rust-lang/rust/issues/86431). It looks like the compiler spends up to 0.5% of its time in that task, so the potential for optimizing it via caching seems limited.
However, the perf run also shows [the biggest regression](https://perf.rust-lang.org/detailed-query.html?commit=585e91c718b0b2c5319e1fffd0ff1e62aaf7ccc2&base_commit=b9197978a90be6f7570741eabe2da175fec75375&benchmark=tokio-webpush-simple-debug&run_name=incr-unchanged) in a test case that does not even invoke the code in question. This suggests that the length of the names we generate here can affect performance by influencing how much data the linker has to copy around.
Fixes https://github.com/rust-lang/rust/issues/86134.
|
|
type names.
|
|
Add or improve natvis definitions for common standard library types
Natvis definitions are used by Windows debuggers to provide a better experience when inspecting a value for types with natvis definitions. Many of our standard library types and intrinsic Rust types like slices and `str` already have natvis definitions.
This PR adds natvis definitions for missing types (like all of the `Atomic*` types) and improves some of the existing ones (such as showing the ref count on `Arc<T>` and `Rc<T>` and showing the borrow state of `RefCell<T>`). I've also added cdb tests to cover these definitions and updated existing tests with the new visualizations.
With this PR, the following types now visualize in a much more intuitive way:
### Type: `NonZero{I,U}{8,16,32,64,128,size}`, `Atomic{I,U}{8,16,32,64,size}`, `AtomicBool` and `Wrapping<T>`
<details><summary>Example:</summary>
```rust
let a_u32 = AtomicU32::new(32i32);
```
```
0:000> dx a_u32
a_u32 : 32 [Type: core::sync::atomic::AtomicU32]
[<Raw View>] [Type: core::sync::atomic::AtomicU32]
```
</details>
### Type: `Cell<T>` and `UnsafeCell<T>`
<details><summary>Example:</summary>
```rust
let cell = Cell::new(123u8);
let unsafecell = UnsafeCell::new((42u16, 30u16));
```
```
0:000> dx cell
cell : 123 [Type: core::cell::Cell<u8>]
[<Raw View>] [Type: core::cell::Cell<u8>]
0:000> dx unsafecell
unsafecell : (42, 30) [Type: core::cell::UnsafeCell<tuple<u16, u16>>]
[<Raw View>] [Type: core::cell::UnsafeCell<tuple<u16, u16>>]
[0] : 42 [Type: unsigned short]
[1] : 30 [Type: unsigned short]
```
</details>
### Type: `RefCell<T>`
<details><summary>Example:</summary>
```rust
let refcell = RefCell::new((123u16, 456u32));
```
```
0:000> dx refcell
refcell : (123, 456) [Type: core::cell::RefCell<tuple<u16, u32>>]
[<Raw View>] [Type: core::cell::RefCell<tuple<u16, u32>>]
[Borrow state] : Unborrowed
[0] : 123 [Type: unsigned short]
[1] : 456 [Type: unsigned int]
```
</details>
### Type: `NonNull<T>` and `Unique<T>`
<details><summary>Example:</summary>
```rust
let nonnull: NonNull<_> = (&(10, 20)).into();
```
```
0:000> dx nonnull
nonnull : NonNull(0x7ff6a5d9c390: (10, 20)) [Type: core::ptr::non_null::NonNull<tuple<i32, i32>>]
[<Raw View>] [Type: core::ptr::non_null::NonNull<tuple<i32, i32>>]
[0] : 10 [Type: int]
[1] : 20 [Type: int]
```
</details>
### Type: `Range<T>`, `RangeFrom<T>`, `RangeInclusive<T>`, `RangeTo<T>` and `RangeToInclusive<T>`
<details><summary>Example:</summary>
```rust
let range = (1..12);
let rangefrom = (9..);
let rangeinclusive = (32..=80);
let rangeto = (..42);
let rangetoinclusive = (..=120);
```
```
0:000> dx range
range : (1..12) [Type: core::ops::range::Range<i32>]
[<Raw View>] [Type: core::ops::range::Range<i32>]
0:000> dx rangefrom
rangefrom : (9..) [Type: core::ops::range::RangeFrom<i32>]
[<Raw View>] [Type: core::ops::range::RangeFrom<i32>]
0:000> dx rangeinclusive
rangeinclusive : (32..=80) [Type: core::ops::range::RangeInclusive<i32>]
[<Raw View>] [Type: core::ops::range::RangeInclusive<i32>]
0:000> dx rangeto
rangeto : (..42) [Type: core::ops::range::RangeTo<i32>]
[<Raw View>] [Type: core::ops::range::RangeTo<i32>]
0:000> dx rangetoinclusive
rangetoinclusive : (..=120) [Type: core::ops::range::RangeToInclusive<i32>]
[<Raw View>] [Type: core::ops::range::RangeToInclusive<i32>]
```
</details>
### Type: `Duration`
<details><summary>Example:</summary>
```rust
let duration = Duration::new(5, 12);
```
```
0:000> dx duration
duration : 5s 12ns [Type: core::time::Duration]
[<Raw View>] [Type: core::time::Duration]
seconds : 5 [Type: unsigned __int64]
nanoseconds : 12 [Type: unsigned int]
```
</details>
### Type: `ManuallyDrop<T>`
<details><summary>Example:</summary>
```rust
let manuallydrop = ManuallyDrop::new((123, 456));
```
```
0:000> dx manuallydrop
manuallydrop : (123, 456) [Type: core::mem::manually_drop::ManuallyDrop<tuple<i32, i32>>]
[<Raw View>] [Type: core::mem::manually_drop::ManuallyDrop<tuple<i32, i32>>]
[0] : 123 [Type: int]
[1] : 456 [Type: int]
```
</details>
### Type: `Pin<T>`
<details><summary>Example:</summary>
```rust
let mut s = "this".to_string();
let pin = Pin::new(&mut s);
```
```
0:000> dx pin
pin : Pin(0x11a0ff6f0: "this") [Type: core::pin::Pin<mut alloc::string::String*>]
[<Raw View>] [Type: core::pin::Pin<mut alloc::string::String*>]
[len] : 4 [Type: unsigned __int64]
[capacity] : 4 [Type: unsigned __int64]
[chars]
```
</details>
### Type: `Rc<T>` and `Arc<T>`
<details><summary>Example:</summary>
```rust
let rc = Rc::new(42i8);
let rc_weak = Rc::downgrade(&rc);
```
```
0:000> dx rc
rc : 42 [Type: alloc::rc::Rc<i8>]
[<Raw View>] [Type: alloc::rc::Rc<i8>]
[Reference count] : 1 [Type: core::cell::Cell<usize>]
0:000> dx rc_weak
rc_weak : 42 [Type: alloc::rc::Weak<i8>]
[<Raw View>] [Type: alloc::rc::Weak<i8>]
```
</details>
r? ```@michaelwoerister```
cc ```@nanguye2496```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Closures in external crates may get compiled in because of
monomorphization. We should store names of captured variables
in `optimized_mir`, so that they are written into the metadata
file and we can use them to generate debuginfo.
- If there are breakpoints inside closures, the names of captured
variables stored in `optimized_mir` can be used to print them.
Now the name is more precise when disjoint fields are captured.
|
