default auto traits: use default supertraits instead of `Self: Trait` bounds on associated items
First commit: the motivation has been discussed [here](https://github.com/rust-lang/rust/pull/144679).
Second commit: the only new places where new implicit `DefaultAutoTrait` bounds are generated are supertraits and trait object so `?Trait` syntax should be extended to these places only.
r? `@lcnr`
std: make address resolution weirdness local to SGX
Currently, the implementations of `TcpStream::connect` and its cousins take an `io::Result<&SocketAddr>` as argument, which is very weird, as most of them then `?`-try the result immediately to access the actual address. This weirdness is however necessitated by a peculiarity of the SGX networking implementation:
SGX doesn't support DNS resolution but rather accepts hostnames in the same place as socket addresses. So, to make e.g.
```rust
TcpStream::connect("example.com:80")`
```
work, the DNS lookup returns a special error (`NonIpSockAddr`) instead, which contains the hostname being looked up. When `.to_socket_addrs()` fails, the `each_addr` function used to select an address will pass the error to the inner `TcpStream::connect` implementation, which in SGX's case will inspect the error and try recover the hostname from it. If
that succeeds, it continues with the found hostname.
This is pretty obviously a terrible hack and leads to buggy code (for instance, when users use the result of `.to_socket_addrs()` in their own `ToSocketAddrs` implementation to select from a list of possible URLs, the only URL used will be that of the last item tried). Still, without changes to the SGX usercall ABI, it cannot be avoided.
Therefore, this PR aims to minimise the impact of that weirdness and remove it from all non-SGX platforms. The inner `TcpStream::connect`, et al. functions now receive the `ToSocketAddrs` type directly and call `each_addr` (which is moved to `sys::net::connection`) themselves. On SGX, the implementation uses a special `each_addr` which contains the whole pass-hostname-through-error hack.
As well as making the code cleaner, this also opens up the possibility of reusing newly created sockets even if a connection request fails – but I've left that for another PR.
CC `@raoulstrackx`
Trim paths less in MIR dumping
With this PR, the paths MIR dump filters and that are printed at the start of a dump file are no longer trimmed. They don't include the crate that is being compiled, however.
CI: rfl: move job forward to Linux v6.17-rc5 to remove temporary commits
v6.17-rc5 contains the equivalent of the two commits we had here, thus move the Rust for Linux job forward to that so that we don't need the temporary commits anymore.
r? ```@lqd``` ```@Kobzol```
try-job: x86_64-rust-for-linux
```@rustbot``` label A-rust-for-linux
```@bors``` try
Implement `#[rustc_align_static(N)]` on `static`s
Tracking issue: https://github.com/rust-lang/rust/issues/146177
```rust
#![feature(static_align)]
#[rustc_align_static(64)]
static SO_ALIGNED: u64 = 0;
```
We need a different attribute than `rustc_align` because unstable attributes are tied to their feature (we can't have two unstable features use the same unstable attribute). Otherwise this uses all of the same infrastructure as `#[rustc_align]`.
r? `@traviscross`
We need a different attribute than `rustc_align` because unstable attributes are
tied to their feature (we can't have two unstable features use the same
unstable attribute). Otherwise this uses all of the same infrastructure
as `#[rustc_align]`.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#145463 (Reject invalid literal suffixes in tuple indexing, tuple struct indexing, and struct field name position)
- rust-lang/rust#145929 (fix APITIT being treated as a normal generic parameter in suggestions)
- rust-lang/rust#146001 (Update getopts to remove unicode-width dependency)
- rust-lang/rust#146365 (triagebot: warn about #[rustc_intrinsic_const_stable_indirect])
- rust-lang/rust#146366 (add approx_delta to all gamma tests)
- rust-lang/rust#146373 (fix comments about trait solver cycle heads)
r? `@ghost`
`@rustbot` modify labels: rollup
Reject invalid literal suffixes in tuple indexing, tuple struct indexing, and struct field name position
Tracking issue: rust-lang/rust#60210
Closes rust-lang/rust#60210
## Summary
Bump the ["suffixes on a tuple index are invalid" non-lint pseudo future-incompatibility warning (#60210)][issue-60210][^non-lint] to a **hard error** across all editions, rejecting the remaining carve outs from accidentally accepted invalid suffixes since Rust **1.27**.
- We accidentally accepted invalid suffixes in tuple indexing positions in Rust **1.27**. Originally reported at https://github.com/rust-lang/rust/issues/59418.
- We tried to hard reject all invalid suffixes in https://github.com/rust-lang/rust/pull/59421, but unfortunately it turns out there were proc macros accidentally relying on it: https://github.com/rust-lang/rust/issues/60138.
- We temporarily accepted `{i,u}{32,size}` in https://github.com/rust-lang/rust/pull/60186 (the "*carve outs*") to mitigate *immediate* ecosystem impact, but it came with an FCW warning indicating that we wanted to reject it after a few Rust releases.
- Now (1.89.0) is a few Rust releases later (1.35.0), thus I'm proposing to **also reject the carve outs**.
- `std::mem::offset_of!` stabilized in Rust **1.77.0** happens to use the same "don't expect suffix" code path which has the carve outs, so it also accepted the carve out suffixes. I'm proposing to **reject this case as well**.
## What specifically breaks?
Code that still relied on invalid `{i,u}{32,size}` suffixes being temporarily accepted by rust-lang/rust#60186 as an ecosystem impact mitigation measure (cf. rust-lang/rust#60138). Specifically, the following cases (particularly the construction of these forms in proc macros like reported in rust-lang/rust#60138):
### Position 1: Invalid `{i,u}{32,size}` suffixes in tuple indexing
```rs
fn main() {
let _x = (42,).0invalid; // Already error, already rejected by #59421
let _x = (42,).0i8; // Already error, not one of the #60186 carve outs.
let _x = (42,).0usize; // warning: suffixes on a tuple index are invalid
}
```
### Position 2: Invalid `{i,u}{32,size}` suffixes in tuple struct indexing
```rs
fn main() {
struct X(i32);
let _x = X(42);
let _x = _x.0invalid; // Already error, already rejected by #59421
let _x = _x.0i8; // Already error, not one of the #60186 carve outs.
let _x = _x.0usize; // warning: suffixes on a tuple index are invalid
}
```
### Position 3: Invalid `{i,u}{32,size}` suffixes in numeric struct field names
```rs
fn main() {
struct X(i32, i32, i32);
let _x = X(1, 2, 3);
let _y = X { 0usize: 42, 1: 42, 2: 42 }; // warning: suffixes on a tuple index are invalid
match _x {
X { 0usize: 1, 1: 2, 2: 3 } => todo!(), // warning: suffixes on a tuple index are invalid
_ => {}
}
}
```
### Position 4: Invalid `{i,u}{32,size}` suffixes in `std::mem::offset_of!`
While investigating the warning, unfortunately I noticed `std::mem::offset_of!` also happens to use the "expect no suffix" code path which had the carve outs. So this was accepted since Rust **1.77.0** with the same FCW:
```rs
fn main() {
#[repr(C)]
pub struct Struct<T>(u8, T);
assert_eq!(std::mem::offset_of!(Struct<u32>, 0usize), 0);
//~^ WARN suffixes on a tuple index are invalid
}
```
### The above forms in proc macros
For instance, constructions like (see tracking issue rust-lang/rust#60210):
```rs
let i = 0;
quote! { foo.$i }
```
where the user needs to actually write
```rs
let i = syn::Index::from(0);
quote! { foo.$i }
```
### Crater results
Conducted a crater run (https://github.com/rust-lang/rust/pull/145463#issuecomment-3194920383).
- 256af3c72f: genuine regression; "invalid suffix `usize`" in derive macro. Has a ton of other build warnings, last updated 6 years ago.
- Exactly the kind of intended breakage. Minimized down to 256af3c72f/validates_derive/src/lib.rs (L71-L75), where when interpolation uses `quote`'s `ToTokens` on a `usize` index (i.e. on tuple struct `Tup(())`), the generated suffix becomes `.0usize` (cf. Position 2).
- Notified crate author of breakage in https://github.com/AmlingPalantir/r4/issues/1.
- Other failures are unrelated or spurious.
## Review remarks
- Commits 1-3 expands the test coverage to better reflect the current situation before doing any functional changes.
- Commit 4 is an intentional **breaking change**. We bump the non-lint "suffixes on a tuple index are invalid" warning into a hard error. Thus, this will need a crater run and a T-lang FCP.
## Tasks
- [x] Run crater to check if anyone is still relying on this being not a hard error. Determine degree of ecosystem breakage.
- [x] If degree of breakage seems acceptable, draft nomination report for T-lang for FCP.
- [x] Determine hard error on Edition 2024+, or on all editions.
## Accompanying Reference update
- https://github.com/rust-lang/reference/pull/1966
[^non-lint]: The FCW was implemented as a *non-lint* warning (meaning it has no associated lint name, and you can't `#![deny(..)]` it) because spans coming from proc macros could not be distinguished from regular field access. This warning was also intentionally impossible to silence. See https://github.com/rust-lang/rust/pull/60186#issuecomment-485581694.
[issue-60210]: https://github.com/rust-lang/rust/issues/60210
rename erase_regions to erase_and_anonymize_regions
I find it consistently confusing that `erase_regions` does more than replacing regions with `'erased`. it also makes some code look real goofy to be writing manual folders to erase regions with a comment saying "we cant use erase regions" :> or code that re-calls erase_regions on types with regions already erased just to anonymize all the bound regions.
r? lcnr
idk how i feel about the name being almost twice as long now
v6.17-rc5 contains the equivalent of the two commits we had here, thus
move the Rust for Linux job forward to that so that we don't need the
temporary commits anymore.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Weakly export `platform_version` symbols
The symbols `__isPlatformVersionAtLeast` and `__isOSVersionAtLeast`. This should allow linking both `compiler-rt` and `std`, which fixes https://github.com/rust-lang/rust/pull/138944#issuecomment-3266574582.
r? tgross35
CC ``@zmodem,`` could you please verify that this works for you?
Update books
## rust-lang/nomicon
1 commits in 57ed4473660565d9357fcae176b358d7e8724ebf..f17a018b9989430967d1c58e9a12c51169abc744
2025-09-05 22:46:58 UTC to 2025-09-05 22:46:58 UTC
- Add missing "C" ABI to FFI example code (rust-lang/nomicon#501)
## rust-lang/reference
7 commits in 89f67b3c1b904cbcd9ed55e443d6fc67c8ca2769..b3ce60628c6f55ab8ff3dba9f3d20203df1c0dee
2025-09-05 20:14:36 UTC to 2025-08-26 20:17:24 UTC
- Ensure all lexical elements are SCREAMING_CASE (rust-lang/reference#1990)
- Link out to the notation from grammar summary (rust-lang/reference#1989)
- Or-patterns are extending (rust-lang/reference#1975)
- Specify lifetime extension of `match` arms and `if` consequent/`else` block tail expressions (rust-lang/reference#1981)
- clean up and properly test temporary lifetime extension in doctests (rust-lang/reference#1979)
- Update `cold` and `inline` to use the attribute template (rust-lang/reference#1907)
- Pluralize "syntax diagrams" (rust-lang/reference#1977)
## rust-lang/rust-by-example
1 commits in ad27f82c18464525c761a4a8db2e01785da59e1f..dd26bc8e726dc2e73534c8972d4dccd1bed7495f
2025-09-04 22:33:29 UTC to 2025-09-04 22:33:29 UTC
- Fix drop order explanation in trait > drop (rust-lang/rust-by-example#1953)
simplify the declaration of the legacy integer modules (`std::u32` etc.)
This PR removes some duplicated code from the declaration of the legacy integer modules by expanding the macro which is already used to generate `MIN` and `MAX` to now generate the whole module.
This would also make the remaining steps listed in rust-lang/rust#68490 such as fully deprecating the modules or placing `#[doc(hidden)]` on them easier.
const-eval: disable pointer fragment support
This fixes https://github.com/rust-lang/rust/issues/146291 by disabling pointer fragment support for const-eval. I want to properly fix this eventually, but won't get to it in the next few weeks, so this is an emergency patch to prevent the buggy implementation from landing on stable. The beta cutoff is on Sep 12th so if this PR lands after that, we'll need a backport.
mark `format_args_nl!` as `#[doc(hidden)]`
The `#[unstable]` attribute of the macro already says:
> `format_args_nl` is only for internal language use and is subject to change
It does seem plausible to hide it from the `std` docs accordingly.
The PR also removes the single usage of the macro outside of `std` as it does not seem like the macro is actually needed there.
Implement `Sum` and `Product` for `f16` and `f128`.
Tracking issue: rust-lang/rust#116909.
This PR implements `core::iter::{Sum, Product}` for `f16` and `f128`.
I'm curious as to why these two traits aren't already implemented. I've been unable to find any information about it at all, so if there is anything that currently blocks them, I would appreciate if someone could fill me in.
fix partial urlencoded link support
Hello Rust community.
This is my first contribution, hope is useful.
While translating in Italian the rust book https://github.com/nixxo/rust-lang-book-it I noticed that the linkchecker tool was failing reporting broken links on some pages even if the link worked properly in the browser. Upon inspection I noticed that mdbook basically urlencoded the links, but not urlencoded the heading IDs resulting in a non-identical anchor/IDs pairing that linkchecker reports as non-valid.
looking at the source code for the linkchecker tool I noticed that urlencoding was done by the `small_url_encode` function in a partial way, as the name suggests. Replacing this function with a full urlencoding fixes the issue and the links are properly reported as valid.
- added full urlencoding to properly check urlencoded anchor links against non-urlencoded heading IDs
- added tests
urlecoding provided by https://crates.io/crates/urlencoding
In the rustc_llvm build script, don't consider arm64* to be 32-bit
The build script for `rustc_llvm` needs to detect 32-bit targets so that it links against `libatomics`. To do this, it matches the target architecture against `arm`, unfortunately incorrectly matches Arm64EC, Arm64E, etc.
This change adds a check that the target arch doesn't match `arm64`.
compiler: Include span of too huge array with `-Cdebuginfo=2`
We have a few ui tests to ensure we emit an error if we encounter too big arrays. Before this fix, compiling the tests with `-Cdebuginfo=2` would not include the spans of the instantiation sites, because the error is then emitted from a different code path that does not include the span.
Propagate the span to the error also in the debuginfo case, so the tests passes regardless of debuginfo level.
r? ``@wesleywiser`` since this is a natural continuation of https://github.com/rust-lang/rust/pull/145967 that you approved (thanks!).
cc https://github.com/rust-lang/rust/issues/61117 since this takes is one step closer to increasing `rust.debuginfo-level-tests` to `2` in the **x86_64-gnu-debug** CI job.
## Test failure output without the fix
<details>
<summary>
Here is what the test failures look like if you run the tests without the fix. (Click to expand.)
</summary>
```
$ ./x test --set rust.debuginfo-level-tests=2 tests/ui/limits/huge-array-simple-64.rs tests/ui/limits/huge-array.rs tests/ui/limits/issue-15919-64.rs
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.16s
/home/martin/src/rust/build/x86_64-unknown-linux-gnu/ci-llvm/bin/llvm-strip does not exist; skipping copy
Building stage1 compiler artifacts (stage0 -> stage1, x86_64-unknown-linux-gnu)
Finished `release` profile [optimized + debuginfo] target(s) in 0.40s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 lld-wrapper (stage0 -> stage1, x86_64-unknown-linux-gnu)
Finished `release` profile [optimized + debuginfo] target(s) in 0.08s
Building stage1 library artifacts (stage1 -> stage1, x86_64-unknown-linux-gnu)
Compiling addr2line v0.25.0
Compiling std v0.0.0 (/home/martin/src/rust/library/std)
Compiling rustc-std-workspace-std v1.99.0 (/home/martin/src/rust/library/rustc-std-workspace-std)
Compiling unicode-width v0.2.1
Compiling rustc-literal-escaper v0.0.5
Compiling proc_macro v0.0.0 (/home/martin/src/rust/library/proc_macro)
Compiling getopts v0.2.23
Compiling test v0.0.0 (/home/martin/src/rust/library/test)
Compiling sysroot v0.0.0 (/home/martin/src/rust/library/sysroot)
Finished `release` profile [optimized + debuginfo] target(s) in 14.43s
Building stage1 compiletest (stage0 -> stage1, x86_64-unknown-linux-gnu)
Finished `release` profile [optimized + debuginfo] target(s) in 0.14s
Testing stage2 compiletest suite=ui mode=ui (stage1 -> stage2, x86_64-unknown-linux-gnu)
running 6 tests
[ui] tests/ui/limits/huge-array.rs#full-debuginfo ... F
[ui] tests/ui/limits/issue-15919-64.rs#full-debuginfo ... F
[ui] tests/ui/limits/huge-array-simple-64.rs#full-debuginfo ... F
...
failures:
---- [ui] tests/ui/limits/huge-array.rs#full-debuginfo stdout ----
Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-array.full-debuginfo/huge-array.full-debuginfo.stderr`
diff of stderr:
1 error: values of the type `[[u8; 1518599999]; 1518600000]` are too big for the target architecture
- --> $DIR/huge-array.rs:9:9
- |
- LL | let s: [T; 1518600000] = [t; 1518600000];
- | ^
6
7 error: aborting due to 1 previous error
8
The actual stderr differed from the expected stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args limits/huge-array.rs`
error in revision `full-debuginfo`: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/martin/src/rust/tests/ui/limits/huge-array.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/.cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/src/rust/vendor" "--sysroot" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1" "--target=x86_64-unknown-linux-gnu" "--cfg" "full_debuginfo" "--check-cfg" "cfg(test,FALSE,no_debuginfo,full_debuginfo)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-array.full-debuginfo" "-A" "unused" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Lnative=/home/martin/src/rust/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-Cdebuginfo=2"
stdout: none
--- stderr -------------------------------
error: values of the type `[[u8; 1518599999]; 1518600000]` are too big for the target architecture
error: aborting due to 1 previous error
------------------------------------------
---- [ui] tests/ui/limits/huge-array.rs#full-debuginfo stdout end ----
---- [ui] tests/ui/limits/issue-15919-64.rs#full-debuginfo stdout ----
Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/issue-15919-64.full-debuginfo/issue-15919-64.full-debuginfo.stderr`
diff of stderr:
1 error: values of the type `[usize; usize::MAX]` are too big for the target architecture
- --> $DIR/issue-15919-64.rs:10:9
- |
- LL | let x = [0usize; 0xffff_ffff_ffff_ffff];
- | ^
6
7 error: aborting due to 1 previous error
8
The actual stderr differed from the expected stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args limits/issue-15919-64.rs`
error in revision `full-debuginfo`: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/martin/src/rust/tests/ui/limits/issue-15919-64.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/.cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/src/rust/vendor" "--sysroot" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1" "--target=x86_64-unknown-linux-gnu" "--cfg" "full_debuginfo" "--check-cfg" "cfg(test,FALSE,no_debuginfo,full_debuginfo)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/issue-15919-64.full-debuginfo" "-A" "unused" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Lnative=/home/martin/src/rust/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-Cdebuginfo=2"
stdout: none
--- stderr -------------------------------
error: values of the type `[usize; usize::MAX]` are too big for the target architecture
error: aborting due to 1 previous error
------------------------------------------
---- [ui] tests/ui/limits/issue-15919-64.rs#full-debuginfo stdout end ----
---- [ui] tests/ui/limits/huge-array-simple-64.rs#full-debuginfo stdout ----
Saved the actual stderr to `/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-array-simple-64.full-debuginfo/huge-array-simple-64.full-debuginfo.stderr`
diff of stderr:
1 error: values of the type `[u8; 2305843011361177600]` are too big for the target architecture
- --> $DIR/huge-array-simple-64.rs:12:9
- |
- LL | let _fat: [u8; (1<<61)+(1<<31)] =
- | ^^^^
6
7 error: aborting due to 1 previous error
8
The actual stderr differed from the expected stderr
To update references, rerun the tests and pass the `--bless` flag
To only update this specific test, also pass `--test-args limits/huge-array-simple-64.rs`
error in revision `full-debuginfo`: 1 errors occurred comparing output.
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc" "/home/martin/src/rust/tests/ui/limits/huge-array-simple-64.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/.cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/home/martin/src/rust/vendor" "--sysroot" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/stage1" "--target=x86_64-unknown-linux-gnu" "--cfg" "full_debuginfo" "--check-cfg" "cfg(test,FALSE,no_debuginfo,full_debuginfo)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/home/martin/src/rust/build/x86_64-unknown-linux-gnu/test/ui/limits/huge-array-simple-64.full-debuginfo" "-A" "unused" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Lnative=/home/martin/src/rust/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "-Cdebuginfo=2"
stdout: none
--- stderr -------------------------------
error: values of the type `[u8; 2305843011361177600]` are too big for the target architecture
error: aborting due to 1 previous error
------------------------------------------
---- [ui] tests/ui/limits/huge-array-simple-64.rs#full-debuginfo stdout end ----
failures:
[ui] tests/ui/limits/huge-array.rs#full-debuginfo
[ui] tests/ui/limits/issue-15919-64.rs#full-debuginfo
[ui] tests/ui/limits/huge-array-simple-64.rs#full-debuginfo
test result: FAILED. 3 passed; 3 failed; 0 ignored; 0 measured; 19720 filtered out; finished in 117.18ms
Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-unknown-linux-gnu
Build completed unsuccessfully in 0:00:17
```
</details>
As can be seen, the span info is missing with debuginfo=2 without the fix.
Port limit attributes to the new attribute parsing infrastructure
Doesn't pass tests, to be rebased on https://github.com/rust-lang/rust/pull/145792 which will solve that
r? `@fmease`
compiler: Add Windows resources to rustc-main and rustc_driver
Adds Windows resources with the rust version information to rustc-main.exe and rustc_driver.dll
Invokes `rc.exe` directly, rather than using one of the crates from the ecosystem to avoid adding dependencies.
A new internal `rustc_windows_rc` crate has the common build script machinery for locating `rc.exe` and constructing the resource script
Update tracing and fix binary regression
Previous attempts (rust-lang/rust#127316, rust-lang/rust#134770) saw binary size regressions, this was root caused to <https://github.com/tokio-rs/tracing/pull/2553> which changed the behavior of the `max_level_info` feature flag to match the docs (i.e., that flag only applies for debug builds and `release_max_level_info` applies for release builds).
This change bumps the `tracing` version and sets both `max_level_info` and `release_max_level_info` when to match rustc's own `max_level_info`.
eagerly compute `sub_unification_table` again
Previously called `sub_relations`. We still only using them for diagnostics right now. This mostly reverts rust-lang/rust#119989. Necessary for type inference guidance due to not-yet defined opaque types, cc https://github.com/rust-lang/trait-system-refactor-initiative/issues/182.
We could use them for cycle detection in generalization and it seems desirable to do so in the future. However, this is unsound with the old trait solver as its cache does not track these `sub_unification_table` in any way.
We now properly track the `sub_unification_table` when canonicalizing so using them in the new solver is totally sound and the performance impact is far more manageable than I thought back in rust-lang/rust#119989.
r? `@compiler-errors`
