We don't consider it a bug that users can't break on initialization of
some non-zero sized types (see comment on `maximally-steppable` at the
top of the file), so it does not make sense to consider it a bug that
users can't break on initialization of some zero-sized types.
Some optimization passes _improve_ compile times [1]. So we want to run
some passes even with `-Copt-level=0`. That means that some of the lines
in the test can be optimized away. To make regression testing more
robust, we also want to run the test with such passes disabled. The
solution is to use two revisions. One with default `-Copt-level=0`
passes, and one "even less optimized", with enough optimization passes
disabled to keep the maximum number of lines steppable.
[1]: https://github.com/rust-lang/compiler-team/issues/319
Box in `ValTreeKind::Branch(Box<[I::Const]>)` changed to `List`
This is related to trait system refactoring. It fixes the FIXME in `ValTreeKind`
```
// FIXME(mgca): Use a `List` here instead of a boxed slice
Branch(Box<[I::Const]>),
```
It introduces `Interner::Consts`, changes `Branch(Box<[I::Const]>)` to `Branch(I::Consts)`, and updates all relevant places.
r? lcnr
Revert, but without type const.
Update symbol for feature err, then update suggestion output, and lastly update tests that change because of those.
Update these new tests with the correct syntax, and few existing tests with the new outputs the merge with main added.
Fix for tidyfmt and some errors when manually resolving a merge conflicts.
Update these tests to use update error messages and type const syntax.
Update comments and error message to use new syntax instead of old type_const attribute.
Remove the type_const attribute
update some more tests to use the new syntax.
Update these test cases.
update feature gate test
Change gate logic for `mgca_type_const_syntax` to work also if `min_generic_const_args` is enabled.
Create a new feature gate that checks for the feature before expansion.
Make rustfmt handle the `type const` syntax correctly.
Add a convience method to check if a RhsKind is type const.
Rename `Const` discriminant to `Body` for `ConstItemRhsKind`
Give the `TraitItemKind` flag an enum instead of a simple bool to better describe what the flag is for.
Update formatting for these match statements.
Update clippy test to use type const syntax.
Update test to use type const syntax.
update rustfmt to match ast items.
Update clippy to match ast and hir items.
Few more test cases that used old attribute, instead of 'type const'
Update to match the output from the feature gate checks.
tidyfmt adjustments.
Update the is_type_const, so I can constrain record!(..) in encoder.rs
Update conditional compilation test.
Move the feature gate to after expansion to allow for cfg(...) to work.
Update some more tests to use the new syntax.
Update type const tests in associated-const-bindings to use new syntax.
Don't check based off the attribute, but the item here.
Update some tests outside of the const_generics folder that were using #[type_const]
update the tests in associated consts that use #[type_const] to use type const
Update these mgca tests with the type const syntax.
Add a flag to TraitItemKind for detecting type const for now. Maybe later change ItemConstRhs to have optional consts but that touches a lot more lines of code.
Don't need into for these now that it's a query.
Add is_type_const query to handle foreign def ids.
update this test to use type const syntax.
Fix logic here, we only want to lower if there is expression in this case.
Update built-in macros to use ConstItemRhsKind
Update more instance of the old ConstItemRhs.
Rename ConstItemKind to ConstItemRhsKind, I noticed there is a typed called ConstantItemKind, so add the Rhs to the name to avoid confusion.
Update lower to use ConstItemKind
Add an other helper method to check if the rhs kinda has an expr.
Update item parse to use ConstItemKind enum.
Felt the field name could a be little clear when editing a few other things.
Change the ConstItem struct see know if we have a type const or regular const.
Make sure this syntax is properly feature gated.
We only run LLDB 1500 in CI. Any test with a min-lldb-version above that
is currently ignored. It's not clear any of these tests actually work
with that LLDB version, and they definitely don't work on LLDB ~2100.
So, ignore them until we fix debuginfo testing.
mGCA: Make trait object types with type-level associated consts dyn compatible
Under feature `min_generic_const_args` (mGCA) (rust-lang/rust#132980), render traits with non-parametrized type-level associated constants (i.e., `#[type_const]` ones) dyn compatible but force the user to specify all type-level associated consts in the trait object type via bindings (either directly, via supertrait bounds and/or behind trait aliases) just like associated types, their sibling.
Fixesrust-lang/rust#130300 (feature request).
Fixesrust-lang/rust#136063 (bug).
Fixesrust-lang/rust#137260 (bug).
Fixesrust-lang/rust#137514 (bug).
While I'm accounting for most illegal `Self` references via const projections & params, I'm intentionally ignoring RUST-123140 (and duplicates) in this PR which is to be tackled some other time.
Additional context: Crate `rustc-demangle` had to be updated to fix v0 demangling. I've patched it in PR https://github.com/rust-lang/rustc-demangle/pull/87 which was was released in version 0.1.27 via PR https://github.com/rust-lang/rustc-demangle/pull/88.
So that when we later add support for revisions we can use the same
syntax for revisions as elsewhere.
This also prevents people from making typos for commands since
`src/tools/compiletest/src/directives/directive_names.rs` will catch such
typos now.
Note that we one FIXME for a non-trivial change for later:
```
// FIXME(148097): Change `// cdb-checksimple_closure` to `//@ cdb-check:simple_closure`
```
Rust's current mangling scheme depends on compiler internals; loses
information about generic parameters (and other things) which makes for
a worse experience when using external tools that need to interact with
Rust symbol names; is inconsistent; and can contain `.` characters
which aren't universally supported. Therefore, Rust has defined its own
symbol mangling scheme which is defined in terms of the Rust language,
not the compiler implementation; encodes information about generic
parameters in a reversible way; has a consistent definition; and
generates symbols that only use the characters `A-Z`, `a-z`, `0-9`, and
`_`.
Support for the new Rust symbol mangling scheme has been added to
upstream tools that will need to interact with Rust symbols (e.g.
debuggers).
This commit changes the default symbol mangling scheme from the legacy
scheme to the new Rust mangling scheme.
Signed-off-by: David Wood <david.wood@huawei.com>
To make debugger stepping intuitive with `-Copt-level=0`. See the
adjusted `basic-stepping.rs` test.
This is kind of a revert of bd0aae92dc, except we don't revert it,
we just make it conditional on `opt-level`. That commit regressed
`basic-stepping.rs`, but it was not noticed since that test did not
exist back then. I have retroactively bisected to find that out.
It seems messy to sprinkle if-cases inside of the
`write_operand_repeatedly()` so make the whole function conditional.
The test that bd0aae92dc added in
`tests/codegen/issues/issue-111603.rs` already use `-Copt-level=3`, so
we don't need to adjust the compiler flags for it to keep passing.
While looking at the pretty-printers, I found a few minor oddities in
StdNonZeroNumberProvider.
First, gdb.Type.fields() already returns a sequence, so there's no
need to call list().
Second, it's more idiomatic for the (somewhat misnamed) to_string
method to simply return the underlying gdb.Value. This also lets gdb
apply whatever formats were passed to `print`, as the new test shows.
Third, there's no need to use the field's name when looking up a field
in a value, the gdb.Field itself can be used.
tests: activate misspelled `gdb-check` in `function-arg-initialization.rs`
In 9253e1206e a bunch of `gdbr-check` (for `rust-gdb`) directives and `gdbg-check` (for plain `gdb`) directives were added. But in two places the author accidentally wrote `gdbt-check` instead (`t` is next to `r` on the keyboard). This commit fixes that typo.
rust-lang/rust#129218 later renamed `gdbr-check` to just `gdb-check` which is why we rename to `gdb-check` directly.
The test still passes locally for me after the change, but fails if I change the `gdb-check` checks to check for some other string, so the check seems to still perform its intended function.
Note that we need to add a `std::hint::black_box()` to avoid
$4 = <optimized out>
prints on at least `aarch64-gnu-llvm-20-1`.
After this there are no more instances of the string `gdbt` in the code base:
```console
$ git grep gdbt
```
try-job: dist-i586-gnu-i586-i686-musl
In 9253e1206e a bunch of `gdbr-check` (for `rust-gdb`) and
`gdbg-check` (for plain `gdb`) was added. But in two places the author
accidentally wrote `gdbt-check` instead. This commit fixes this typo.
[Debuginfo] improve enum value formatting in LLDB for better readability
> TL;DR: When debugging with CodeLLDB, I noticed enum values were often hard to read because LLDB lists every possible variant, resulting in a verbose and cluttered view, even though only one variant is actually valid. Interestingly, raw enum types display nicely. After some investigation, I found that `&enum` values get classified as `Other`, so it falls back to `DefaultSyntheticProvider`, which causes this verbose output.
## What does this PR do?
This PR contains 2 commits:
1. change the enum value formatting from showing 2 separate fields (`value` for attached data and `$discr$` for the discriminator) to a concise `<readable variant name>: <attached data>` format
2. dereference pointer types in `classify_rust_type` so that it can return more accurate type for reference type
## Self-test proof
Before:
<img width="1706" height="799" alt="before" src="https://github.com/user-attachments/assets/b66c7e22-990a-4da5-9036-34e3f9f62367" />
After:
<img width="1541" height="678" alt="after" src="https://github.com/user-attachments/assets/36db32e2-f822-4883-8f17-cb8067e509f6" />
fix(debuginfo): handle false positives in overflow check
Fixesrust-lang/rust#144636.
Duplicate wrappers and normal recursive types can lead to false positives.
```rust
struct Recursive {
a: Box<Box<Recursive>>,
}
```
The ADT stack can be:
- `Box<Recursive>`
- `Recursive`
- `Box<Box<Recursive>>` (`Box` now detected as expanding)
We can filter them out by tracing the generic arg back through the stack, as true expanding recursive types must have their expanding arg used as generic arg throughout.
r? ````@wesleywiser````
Instead of collecting pretty printers transitively when building
executables/staticlibs/cdylibs, let the debugger find each crate's
pretty printers via its .debug_gdb_scripts section. This covers the case
where libraries defining custom pretty printers are loaded dynamically.
Disabling loading of pretty printers in the debugger itself is more
reliable. Before this commit the .gdb_debug_scripts section couldn't be
included in dylibs or rlibs as otherwise there is no way to disable the
section anymore without recompiling the entire standard library.
Martin Nordholts