```
error[E0277]: the size for values of type `(dyn Debug + 'static)` cannot be known at compilation time
--> $DIR/dyn-trait-type-alias-return-type.rs:4:11
|
LL | fn f() -> T { loop {} }
| ^ doesn't have a size known at compile-time
|
= help: the trait `Sized` is not implemented for `(dyn Debug + 'static)`
note: this type alias is unsized
--> $DIR/dyn-trait-type-alias-return-type.rs:1:1
|
LL | type T = dyn core::fmt::Debug;
| ^^^^^^
= note: the return type of a function must have a statically known size
```
Retire `opt_str2` from compiletest cli parsing
We have `Option<..>`, we don't need to invent "(none)" as option-at-home.
- More specifically, when some test suite expect certain values to be present, they should `.expect(..)` the value, and not potentially receive some "(none)" in some cases.
r? Zalathar
Subtree sync for rustc_codegen_cranelift
The main highlights this time are a Cranelift update and adding actual support for `-Cdebuginfo=line-tables-only` rather than treating it the same as `-Cdebuginfo=full`.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Move ambient gdb discovery from compiletest to bootstrap
- Follow-up to https://github.com/rust-lang/rust/pull/148099
---
This code takes the compiletest code for discovering an “ambient” `gdb` in the user's path, and moves it to bootstrap.
One of the eventual goals is to allow compiletest to assume that if it has been asked to run the debuginfo-gdb suite, then it *must* have been passed an explicit `--gdb`, though we aren't quite there yet.
r? jieyouxu
Tidying up tests/ui/issues tests [3/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
r? Kivooeo
Add warn-by-default lint for visibility on `const _` declarations
Add a warn-by-default `unused_visibilities` lint for visibility qualifiers on `const _` declarations—e.g. `pub const _: () = ();`. Such qualifiers have no effect.
A [Sourcegraph search](https://sourcegraph.com/search?q=context:global+lang:Rust+pub%5Cs*%28%5C%28.*%5C%29%29%3F%5Cs*const%5Cs%2B_%5Cs*:&patternType=regexp&case=yes&sm=0) suggests that this pattern is relatively rare, and mostly found in tests (with only 3 exceptions). So perhaps this could become an FCW/hard error in the future.
`@rustbot` label T-lang A-lints A-visibility -T-clippy
Add a warn-by-default `unused_visibility` lint for visibility qualifiers
on `const _` declarations - e.g. `pub const _: () = ();`.
These have no effect.
refactor: rename `macos_fbsd_solarish_write_stat_buf` to `write_stat_buf`
refactor: rename `macos_fbsd_solarish_fstat` to `fstat`
feat: support `fstat` in linux
test: testing support of `fstat` in linux
fix: missed add `Os::Linux` for supported OSs in `fstat`
feat: add nanosecond fields to file metadata in `EvalContextExtPrivate`
add `fstat` to foreign items in unix
enhance test of `fstat`
fix the test
`c_variadic`: make `VaList` abi-compatible with C
tracking issue: https://github.com/rust-lang/rust/issues/44930
related PR: rust-lang/rust#144529
On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly.
In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy,
In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang/rust#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct.
Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (https://github.com/rust-lang/rust/issues/141524#issuecomment-3028383594), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms).
Previous discussion: rust-lang/rust#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI)
Tracking issue: https://github.com/rust-lang/rust/issues/44930
r? `@joshtriplett`
interpret: test SNaN handling of float min/max and update comments
Also see https://github.com/rust-lang/rust/pull/149563.
I also renamed these enum variants so they are not almost identical.
Add perma-unstable `--print=backend-has-zstd` for use by compiletest
Tests for `-Zdebuginfo-compression=zstd` need to be skipped if LLVM was built without support for zstd compression.
Currently, compiletest relies on messy and fragile heuristics to detect whether the compiler's LLVM was built with zstd support. But the compiler itself already knows whether LLVM has zstd or not, so it's easier for compiletest to just ask the compiler.
---
Originally I was intending for this to be a `--print=debuginfo-compression` flag that would print out a list of values supported by `-Zdebuginfo-compression=`. I got that working locally, but it was more complex than I was happy with (in both rustc and compiletest), so I decided to cut scope and instead add a very narrow perma-unstable print request instead.
There is always a circularity hazard whenever we ask the compiler-under-test for information about how to test it. But in this case, the underlying compiler code is fairly simple, whereas the previous heuristics were inherently messy and unreliable anyway.
misc coercion cleanups and handle safety correctly
r? lcnr
### "remove normalize call"
Fixesrust-lang/rust#132765
If the normalization fails we would sometimes get a `TypeError` containing inference variables created inside of the probe used by coercion. These would then get leaked out causing ICEs in diagnostics logic
### "leak check and lub for closure<->closure coerce-lubs of same defids"
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/233
```rust
fn peculiar() -> impl Fn(u8) -> u8 {
return |x| x + 1
}
```
the `|x| x + 1` expr has a type of `Closure(?31t)` which we wind up inferring the RPIT to. The `CoerceMany` `ret_coercion` for the whole `peculiar` typeck has an expected type of `RPIT` (unnormalized). When we type check the `return |x| x + 1` expr we go from the never type to `Closure(?31t)` which then participates in the `ret_coercion` giving us a `coerce-lub(RPIT, Closure(?31t))`.
Normalizing `RPIT` gives us some `Closure(?50t)` where `?31t` and `?50t` have been unified with `?31t` as the root var. `resolve_vars_if_possible` doesn't resolve infer vars to their roots so these wind up with different structural identities so the fast path doesn't apply and we fall back to coercing to a `fn` ptr. cc rust-lang/rust#147193 which also fixes this
New solver probably just gets more inference variables here because canonicalization + generally different approach to normalization of opaques. Idk :3
### FCP worthy stuffy
there are some other FCP worthy things but they're in my FCP comment which also contains some analysis of the breaking nature of the previously listed changes in this PR: https://github.com/rust-lang/rust/pull/148602#issuecomment-3503497467
Tests for `-Zdebuginfo-compression=zstd` need to be skipped if LLVM was built
without support for zstd compression.
Currently, compiletest relies on messy and fragile heuristics to detect whether
the compiler's LLVM was built with zstd support. But the compiler itself
already knows whether LLVM has zstd or not, so it's easier for compiletest to
just ask the compiler.
Update cargo submodule
9 commits in bd979347d814dfe03bba124165dbce9554d0b4d8..2c283a9a5c5968eeb9a8f12313f04feb1ff8dfac
2025-12-02 16:03:50 +0000 to 2025-12-04 16:47:28 +0000
- fix(publish): Move `.crate` out of final artifact location (rust-lang/cargo#15915)
- Remove legacy tmpdir support (rust-lang/cargo#16342)
- Run clippy CI on more targets (rust-lang/cargo#16340)
- feat: support for rustdoc mergeable cross-crate info (rust-lang/cargo#16309)
- fix(timings): unlocked -> unblocked (rust-lang/cargo#16337)
- fix(layout): Put examples in their unit dir in new layout (rust-lang/cargo#16335)
- fix(frontmatter): Restrict code fence length (rust-lang/cargo#16334)
- Update resolver.md: fix compile errors in pseudocode (rust-lang/cargo#16333)
- fix(fingerprint): clean doc dirs for only requested targets (rust-lang/cargo#16331)
This is best being merged before beta cutoff because rust-lang/cargo#16337 is a nightly regression.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#147224 (Emscripten: Turn wasm-eh on by default)
- rust-lang/rust#149405 (Recover on misspelled item keyword)
- rust-lang/rust#149443 (Tidying up UI tests [6/N])
- rust-lang/rust#149524 (Move attribute safety checking to attribute parsing)
- rust-lang/rust#149593 (powf, powi: point out SNaN non-determinism)
- rust-lang/rust#149605 (Use branch name instead of HEAD when unshallowing)
- rust-lang/rust#149612 (Apply the `bors` environment also to the `outcome` job)
- rust-lang/rust#149623 (Don't require a normal tool build of clippy/rustfmt when running their test steps)
- rust-lang/rust#149627 (Point to the item that is incorrectly annotated with `#[diagnostic::on_const]`)
r? `@ghost`
`@rustbot` modify labels: rollup
