Also duplicate `#[expect]` attribute in `#[derive]`-ed code
This PR updates our derive logic to also duplicate any `#[expect]` attribute in the `#[derive]`-ed code, as we already do for all the other lint attribute (`#[allow]`, `#[warn]`, `#[deny]`, ...).
The original and duplicated attribute share the same attribute id, which due to the way [`check_expectations`](56aaf58ec0/compiler/rustc_lint/src/expect.rs (L28-L46)) is implemented makes the expectation fulfilled if the lint is either trigger in the original code or the derived code.
This was discussed by T-lang in https://github.com/rust-lang/rust/issues/150553#issuecomment-3780810363.
cc @rust-lang/lang-ops (in case you want to do an FCP)
Fixesrust-lang/rust#150553
Add avr_target_feature
This adds the following unstable target features (tracking issue: https://github.com/rust-lang/rust/issues/146889):
- The following two are particularly important for properly supporting inline assembly:
- `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also https://github.com/rust-lang/rust/pull/146901)
- `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also 2a528760bf)
- The followings help recognizing whether specific instructions are available:
- `addsubiw`
- `break`
- `eijmpcall`
- `elpm`
- `elpmx`
- `ijmpcall`
- `jmpcall`
- `lpm`
- `lpmx`
- `movw`
- `mul`
- `rmw`
- `spm`
- `spmx`
Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure.
- Report future-incompatible warning (https://github.com/rust-lang/rust/issues/116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM.
- See https://github.com/rust-lang/rust/pull/146900#issuecomment-3323558005 for details.
LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something.
(The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).)
cc @Patryk27 @Rahix
r? workingjubilee
@rustbot label +O-AVR +A-target-feature
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>
