Stabilize const ControlFlow predicates
Tracking issue: rust-lang/rust#148738
Related: rust-lang/rust#140266 (moved the relevant const-unstables to that feature)
r? @dtolnay
Use relative paths for std links in rustc-docs
Fixesrust-lang/rust#151496
This adds `--extern-html-root-url` for each `STD_PUBLIC_CRATES` entry pointing to `../`, so that `rustc-docs` links to the locally installed `rust-docs` via relative paths.
r? @GuillaumeGomez @rami3l
Dont strip const blocks in array lengths
r? oli-obk
mGCA now handles const blocks by *always* handling them during `lower_expr_to_const_arg_direct` instead of *sometimes* stripping them out at parse time. This is just generally a lot clearer/nicer but also means parsing isn't lossy which is just straight up wrong.
We now use `MgcaDisambiguation::Direct` for const blocks because we "directly" represent a const block as `hir::ConstArgKind::Anon` :> The only time that an anon const for const generics uses `MgcaDisambiguation::AnonConst` is for unbraced literals.
Once we properly support literals in `hir::ConstArgKind` (see rust-lang/rust#152139rust-lang/rust#152001) then `MgcaDisambiguation` can be renamed to `AnonConstKind` with `TypeSystem` and `NonTypeSystem` variants. We can also get rid of `mgca_direct_lit_hack`. I expect this to be a very nice cleanup :)
Fixesrust-lang/rustfmt#6788
The diff relating to passing spans around is to avoid a bunch of mGCA diagnostics changing from `const {}` to `{}`. I'm not entirely sure why this was happening.
cc @rust-lang/rustfmt
How do I run the tests in the rustfmt repo from here? `x test rustfmt` only seems to run like 100 tests and doesn't result in a `target/issue-6788.rs` getting created. I've verified locally that this formats correctly though
MGCA: require #[type_const] on free consts too
When investigating another issue, I discovered that following ICEs (the `const_of_item` query doesn't support non-type_const-marked constants and does a `span_delayed_bug`):
```rust
#![feature(min_generic_const_args)]
#![allow(incomplete_features)]
const N: usize = 4;
fn main() {
let x = [(); N];
}
```
My initial thought of "only require `#[type_const]` on places that stable doesn't currently accept" ran into the issue of this compiling on stable today:
```rust
trait Trait {
const N: usize;
}
impl<const PARAM: usize> Trait for [(); PARAM] {
const N: usize = PARAM;
}
fn main() {
let x = [(); <[(); 4] as Trait>::N];
}
```
Figuring out which specific cases are not currently accepted by stable is quite hairy.
Upon discussion with @BoxyUwU, she suggested that *all* consts, including free consts, should require `#[type_const]` to be able to be referred to. This is what this PR does.
---
~~The change to `tests/ui/const-generics/generic_const_exprs/non-local-const.rs` is unfortunate, reverting the fix in https://github.com/rust-lang/rust/pull/143106 no longer fails the test. Any suggestions to test it more appropriately would be most welcome!~~
edit: never mind, figured out how compiletests work :) - verified that the new test setup correctly ICEs when that PR's fix is reverted.
r? @BoxyUwU
bootstrap: Remove `ShouldRun::paths`
Split out from https://github.com/rust-lang/rust/pull/151930. I've copied my comment in https://github.com/rust-lang/rust/pull/151930#discussion_r2750409129 into the commit description.
r? @Zalathar cc @Mark-Simulacrum @Kobzol
---
Some history about `paths()`. The original intent @Mark-Simulacrum had
when he introduced PathSet in f104b12059, to my knowledge, was that multiple paths
could be aliases for the same step. That's what rustdoc is doing; both
paths for rustdoc run exactly the same Step, regardless of whether one
or both are present.
That never really caught on. To my knowledge, rustdoc is the only usage
of paths() there's ever been.
Later, in rust-lang/rust#95503, I repurposed PathSet to mean "each crate in this set
should be passed to Step::make_run in RunConfig". That was not the
previous meaning.
Rustdoc never looks at run.paths in make_run, so it's safe to just treat
it as an alias, like elsewhere in bootstrap. Same for all the other tool
steps.
Always use Xcode-provided Clang in macOS CI
Most of our macOS CI runners use the Xcode-provided Clang. `dist-apple-various` still downloads Clang from LLVM's prebuilt sources, which is a bit problematic, because we're still using the Xcode-provided _headers_.
As a concrete example, using Xcode's Clang is required by https://github.com/rust-lang/rust/pull/152013, as otherwise updating to Xcode 26 headers fails with an obscure `fatal error: 'net/route.h' file not found`, see [this build log](https://github.com/rust-lang/rust/pull/152013#issuecomment-3838801617). I suspect this is because building the new headers isn't officially supported with the older LLVM/Clang 15.
This PR removes that functionality, so that we instead always build with the Xcode-provided Clang. This is effectively the same as setting `USE_XCODE_CLANG=1` on `dist-apple-various` as well, but I thought I'd clean things up while I'm at it.
I didn't find the reason why we did this in first place, maybe because the Xcode Clang at the time was too out of date to build LLVM? It doesn't seem to be a problem anymore though.
r? t-infra
Fix ICE in normalizing inherent associated consts with `#[type_const]`
Fixesrust-lang/rust#151027Fixesrust-lang/rust#138089Fixesrust-lang/rust#138226Fixesrust-lang/rust#150960
When an inherent associated const is marked with `#[type_const]`, its generics expect args in the format `[Self, own_params...]`, similar to inherent associated types. However, HIR typeck's `instantiate_value_path` was constructing args in the regular associated const format `[impl_params..., own_params...]`. This mismatch caused ICEs when the `args` were later used in contexts expecting the IAC format, such as user type annotations and `borrowck`'s type ascription.
feat: Add `NonZero::<T>::from_str_radix`
- Accepted ACP: rust-lang/libs-team#548
- Tracking issue: rust-lang/rust#152193
This pull request adds a method to `NonZero<T>` that parses a non-zero integer from a string slice with digits in a given base.
When using the combination of `int::from_str_radix` and `NonZero::<T>::new`, [`IntErrorKind::Zero`](https://doc.rust-lang.org/core/num/enum.IntErrorKind.html#variant.Zero) cannot be returned as an error. When using `NonZero::<T>::from_str`, `IntErrorKind::Zero` can be returned as an error, but this method cannot parse non-decimal integers.
`NonZero::<T>::from_str_radix` can return `IntErrorKind::Zero` as an error, and can parse both decimal integers and non-decimal integers.
Update wasi-sdk used in CI/releases
This is similar to prior updates such as rust-lang/rust#149037 in that this is just updating a URL. This update though has some technical updates accompanying it as well, however:
* The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this target, even for startup. This means that the final binary no longer has an "adapter" which can help making instantiation of a component a bit more lean.
* In rust-lang/rust#147572 libstd was updated to use wasi-libc more often on the `wasm32-wasip2` target. This uncovered a number of bugs in wasi-libc such as rust-lang/rust#149864, rust-lang/rust#150291, and rust-lang/rust#151016. These are all fixed in wasi-sdk-30 so the workarounds in the standard library are all removed.
Overall this is not expected to have any sort of major impact on users of WASI targets. Instead it's expected to be a normal routine update to keep the wheels greased and oiled.
Some history about `paths()`. The original intent Mark-Simulacrum had
when he introduced PathSet, to my knowledge, was that multiple paths
could be aliases for the same step. That's what rustdoc is doing; both
paths for rustdoc run exactly the same Step, regardless of whether one
or both are present.
That never really caught on. To my knowledge, rustdoc is the only usage
of paths() there's ever been.
Later, in 95503, I repurposed PathSet to mean "each crate in this set
should be passed to Step::make_run in RunConfig". That was not the
previous meaning.
Rustdoc never looks at run.paths in make_run, so it's safe to just treat
it as an alias, like elsewhere in bootstrap. Same for all the other tool
steps.
Co-authored-by: Tshepang Mbambo <hopsi@tuta.io>
update openmp/offload builds to LLVM 22, Part 1
This part of the update of OpenMP/Offload to LLVM 22 does not depend on a backport in the future LLVM release candidate 3. Let's therefore merge it first, to unblock existing users/developers.
r? @jieyouxu
Port rustc_abi to the attribute parser
Tracking issue: https://github.com/rust-lang/rust/issues/131229
This attribute either dumps the abi info for functions (debug arg)
or if you put it on a pair of fn ptr's it checks they match (assert_eq arg)
r? @JonathanBrouwer
Consolidate type const checks on `tcx.is_type_const`
A little bit of cleanup; explanation can be found in the reporting issue.
Fixesrust-lang/rust#152124
r? BoxyUwU
Mark match arms in try and for as being from desugarings.
Some of the arms created by these desugarings have an expression which isn't marked as coming from the desugaring. e.g. try generates `Continue(val) => val` where the expression has the span of the original parameter (done for diagnostic purposes). Since the arm created just used that span they end up without a desugaring mark unnecessarily.
This is only a minor annoyance with some work I'm doing in clippy.
