debuginfo: Generalize C++-like encoding for enums.
The updated encoding should be able to handle niche layouts where more than one variant has fields (as introduced in https://github.com/rust-lang/rust/pull/94075).
The new encoding is more uniform as there is no structural difference between direct-tag, niche-tag, and no-tag layouts anymore. The only difference between those cases is that the "dataful" variant in a niche-tag enum will have a `(start, end)` pair denoting the tag range instead of a single value.
The new encoding now also supports 128-bit tags, which occur in at least some standard library types. These tags are represented as `u64` pairs so that debuggers (which don't always have support for 128-bit integers) can reliably deal with them. The downside is that this adds quite a bit of complexity to the encoding and especially to the corresponding NatVis.
The new encoding seems to increase the size of (x86_64-pc-windows-msvc) debuginfo by 10-15%. The size of binaries is not affected (release builds were built with `-Cdebuginfo=2`, numbers are in kilobytes):
EXE | before | after | relative
-- | -- | -- | --
cargo (debug) | 40453 | 40450 | +0%
ripgrep (debug) | 10275 | 10273 | +0%
cargo (release) | 16186 | 16185 | +0%
ripgrep (release) | 4727 | 4726 | +0%
PDB | before | after | relative
-- | -- | -- | --
cargo (debug) | 236524 | 261412 | +11%
ripgrep (debug) | 53140 | 59060 | +11%
cargo (release) | 148516 | 169620 | +14%
ripgrep (release) | 10676 | 11804 | +11%
Given that the new encoding is more general, this is to be expected. Only platforms using C++-like debuginfo are affected -- which currently is only `*-pc-windows-msvc`.
*TODO*
- [x] Properly update documentation
- [x] Add regression tests for new optimized enum layouts as introduced by #94075.
r? `@wesleywiser`
Visit attributes in more places.
This adds 3 loosely related changes (I can split PRs if desired):
- Attribute checking on pattern struct fields.
- Attribute checking on struct expression fields.
- Lint level visiting on pattern struct fields, struct expression fields, and generic parameters.
There are still some lints which ignore lint levels in various positions. This is a consequence of how the lints themselves are implemented. For example, lint levels on associated consts don't work with `unused_braces`.
rustc_target: Update some old naming around self contained linking
The "fallback" naming pre-dates introduction of `-Clink-self-contained`.
Noticed when reviewing https://github.com/rust-lang/rust/pull/99500.
This PR doesn't break any json target spec, but supporting per-linker-flavor startup objects needed by https://github.com/rust-lang/rust/pull/99500 will break them, so maybe next time I'll remove the compatibility names.
orphan check: rationalize our handling of constants
cc `@rust-lang/types` `@rust-lang/project-const-generics` on whether you agree with this reasoning.
r? types
Argument type error improvements
Motivated by this interesting code snippet:
```rust
#[derive(Copy, Clone)]
struct Wrapper<T>(T);
fn foo(_: fn(i32), _: Wrapper<i32>) {}
fn f(_: u32) {}
fn main() {
let w = Wrapper::<isize>(1isize);
foo(f, w);
}
```
Which currently errors like:
```
error[E0308]: arguments to this function are incorrect
--> src/main.rs:10:5
|
10 | foo(f, w);
| ^^^ - - expected `i32`, found `isize`
| |
| expected `i32`, found `u32`
|
= note: expected fn pointer `fn(i32)`
found fn item `fn(u32) {f}`
= note: expected struct `Wrapper<i32>`
found struct `Wrapper<isize>`
note: function defined here
--> src/main.rs:4:4
|
4 | fn foo(_: fn(i32), _: Wrapper<i32>) {}
| ^^^ ---------- ---------------
```
Specifically, that double `expected .. found ..` which is very difficult to correlate to the types in the arguments. Also, the fact that "expected `i32`, found `isize`" and the other argument mismatch label don't even really explain what's going on here.
After this PR:
```
error[E0308]: arguments to this function are incorrect
--> $DIR/two-mismatch-notes.rs:10:5
|
LL | foo(f, w);
| ^^^
|
note: expected fn pointer, found fn item
--> $DIR/two-mismatch-notes.rs:10:9
|
LL | foo(f, w);
| ^
= note: expected fn pointer `fn(i32)`
found fn item `fn(u32) {f}`
note: expected struct `Wrapper`, found a different struct `Wrapper`
--> $DIR/two-mismatch-notes.rs:10:12
|
LL | foo(f, w);
| ^
= note: expected struct `Wrapper<i32>`
found struct `Wrapper<isize>`
note: function defined here
--> $DIR/two-mismatch-notes.rs:4:4
|
LL | fn foo(_: fn(i32), _: Wrapper<i32>) {}
| ^^^ ---------- ---------------
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
```
Yeah, it's a bit verbose, but much clearer IMO.
---
Open to discussions about how this could be further improved. Motivated by `@jyn514's` [tweet](https://mobile.twitter.com/joshuayn514/status/1558042020601634816) here.
wf: correctly `shallow_resolve` consts
`shallow_resolve` on `InferConst` is always a noop. this is mostly irrelevant as inference vars should already be resolved at most - if not all - call sites. Haven't actually looked too deeply into whether this was a problem.
Erase regions better in `promote_candidate`
Use `tcx.erase_regions` instead of manually walking through the substs.... this also makes the code slightly simpler 🙈Fixes#100360Fixes#89851
Rollup of 9 pull requests
Successful merges:
- #100022 (Optimize thread ID generation)
- #100030 (cleanup code w/ pointers in std a little)
- #100229 (add -Zextra-const-ub-checks to enable more UB checking in const-eval)
- #100247 (Generalize trait object generic param check to aliases.)
- #100255 (Adding more verbose documentation for `std::fmt::Write`)
- #100366 (errors: don't fail on broken primary translations)
- #100396 (Suggest const and static for global variable)
- #100409 (rustdoc: don't generate DOM element for operator)
- #100443 (Add two let else regression tests)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
errors: don't fail on broken primary translations
If a primary bundle doesn't contain a message then the fallback bundle is used. However, if the primary bundle's message is broken (e.g. it refers to a interpolated variable that the compiler isn't providing) then this would just result in a compiler panic. While there aren't any primary bundles right now, this is the type of issue that could come up once translation is further along.
r? ```@compiler-errors``` (since this comes out of a in-person discussion we had at RustConf)
Generalize trait object generic param check to aliases.
The current algorithm only checks that `Self` does not appear in defaults for traits. This is not sufficient for trait aliases.
This PR moves the check to trait object elaboration, which sees through trait aliases.
Fixes https://github.com/rust-lang/rust/issues/82927.
Fixes https://github.com/rust-lang/rust/issues/84789.
passes: load `defined_lib_features` query less
Hopefully addresses the perf regressions from #99212 (see #99905).
Re-structure the stability checks for library features to avoid calling `defined_lib_features` for any more crates than necessary for each of the implications or local feature attributes that need validation.
r? `@ghost` (just checking perf at first)
This was incorrectly inserting the ExprField as a sibling of the struct
expression.
This required adjusting various parts which were looking at parent node
of a field expression to find the struct.
