Format heterogeneous try blocks
The tracking issue for `try_blocks_heterogeneous` is https://github.com/rust-lang/rust/issues/149488.
This follows the formatting of homogeneous try blocks (feature `try_blocks`) by considering `try bikeshed <type>` to be the equivalent of `try` (in particular a single "token").
An alternative would be to permit breaking between `bikeshed` and `<type>`, but given that those 2 elements are an explicitly temporary part of the syntax, it doesn't seem worth it. There also doesn't seem to be any existing precedent breaking between a keyword and a type. It also doesn't seem to be useful in practice, given that the type itself doesn't break (which is how it works for the return type of closures) and has more chances to dominate the length in case a break is necessary.
Happy to adapt anything in case this formatting is not optimal.
The test is also copied from homogeneous try blocks with 2 additional test cases to demonstrate the behavior with long types.
See [#t-lang > try blocks @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/try.20blocks/near/572387493) for context.
Remove `SubdiagMessage` in favour of the identical `DiagMessage`
For https://github.com/rust-lang/rust/issues/151366
Just some more cleanup :)
SubdiagMessage is now identical to DiagMessage, so there's no point in having both of them
Update to Xcode 26.2
Update our CI to run with Xcode 26.
This means that:
- LLVM will be built with a newer Clang version (before Apple Clang 15, now Apple Clang 17).
- Our binaries (e.g. `rustc` and `libstd*.dylib`) will have their SDK version raised (before macOS 14.5, now 26.2).
- Our binaries will be built with a newer linker (before 1053.12, now 1230.1).
The last two points can be observed with:
```sh
$ vtool -show-build ./build/host/stage1/bin/rustc
Load command 10
cmd LC_BUILD_VERSION
cmdsize 32
platform MACOS
minos 11.0
sdk 26.2
ntools 1
tool LD
version 1230.1
$ vtool -show-build ./build/host/stage1/lib/rustlib/aarch64-apple-darwin/lib/libstd*.dylib
Load command 9
cmd LC_BUILD_VERSION
cmdsize 32
platform MACOS
minos 11.0
sdk 26.2
ntools 1
tool LD
version 1230.1
```
This shouldn't have much of an effect, but things like `dyld` is known to inspect the SDK version, so it _might_ expose some latent bugs (I really don't expect it to though).
This also updates the macOS runners to run on macOS 15 (the macOS 14 runners only have up to Xcode 16.2 available). That is desirable anyhow, as [the macOS 14 runners will be deprecated in July](https://github.com/actions/runner-images/issues/13518). This is probably also required for https://github.com/rust-lang/rust/pull/147192.
r? shepmaster
Add `s390x-unknown-none-softfloat` with `RustcAbi::Softfloat`
followup on rust-lang/rust#150766
add an `s390x-unknown-none-softfloat` target to use for kernel compilation, as the Linux kernel does not wish to pay the overhead of saving float registers by default on kernel switch. this target's `extern "C"` ABI is unspecified, so it is unstable and subject to change between versions, just like the Linux intrakernel ABI and `extern "Rust"` ABIs are unstable.
enforce target feature incompatibility by adding `RustcAbi::Softfloat`. this is itself just a rename of `RustcAbi::X86Softfloat`, accepting both "x86-softfloat" and "softfloat" as valid strings in the target.json format. the target-features of `"soft-float"` and `"vector"` are incompatible for s390x, so issue a compatibility warning if they are combined.
Update mgca to use `type const` syntax instead of the `#[type_const]` attribute.
This PR changes the `#[type_const]` attribute to the `type const` syntax for https://github.com/rust-lang/rust/issues/132980.
This will fixes https://github.com/rust-lang/rust/issues/151273 and similar issues, since we need to check `type const` of items before expansion. The move to add a syntax was mentioned here: https://github.com/rust-lang/rust/pull/151289#issuecomment-3765241397
The first part of this PR adds support by allowing `type const <IDENT>: <TYPE> { = <EXPR> };` syntax in `rustc_parse/src/parser/item.rs`.
The next part since the AST item does not contain enough information to determine if we have a `type const` was rework `ConstItemRhs` into `ConstItemRhsKind` to store the information since we no longer have the attribute acting as a source of extra data/metadata.
The hir node `ConstItemRhsKind` current shape mostly works, except in the case of `TraitItemKind` where it is an option. I initially went about giving `hir::ConstItemRhsKind` a similar form the AST, but it touches a lot more lines of code and files so because of that, the less invasive option was to add a simple boolean flag to `TraitItemKind`.
The forth part of this PR includes adding a query I called `is_rhs_type_const` so that we can handle both local and foreign def_ids.
The fifth aspect of the PR is adding a `mgca_type_const_syntax` feature gate that is checked before expansion. The standard mgca feature gate is ran after expansion. This feature gate allows for conditional compilation (e.g #[cfg(..)]) of the `type const` syntax in nightly without `min_generic_const_args` being enabled.
The last bit is updating all the the tests that used the `#[type_const]` attribute to use the new syntax that failed because of the changes. This is the bulk of touched/edited files in the PR.
r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args
Set crt_static_allow_dylibs to true for Emscripten target
And add a test. This is followup work to rust-lang/rust#151704. It introduced a regression where cargo is now unwilling to build cdylibs for Emscripten because `crt_static_default` is `true` but `crt_static_allows_dylibs` is `false`. Unfortunately the added test does not fail without the change because the validation logic is in Cargo, not in rustc. But it's good to have some coverage of this anyways.
Revert, but without type const.
Update symbol for feature err, then update suggestion output, and lastly update tests that change because of those.
Update these new tests with the correct syntax, and few existing tests with the new outputs the merge with main added.
Fix for tidyfmt and some errors when manually resolving a merge conflicts.
Update these tests to use update error messages and type const syntax.
Update comments and error message to use new syntax instead of old type_const attribute.
Remove the type_const attribute
update some more tests to use the new syntax.
Update these test cases.
update feature gate test
Change gate logic for `mgca_type_const_syntax` to work also if `min_generic_const_args` is enabled.
Create a new feature gate that checks for the feature before expansion.
Make rustfmt handle the `type const` syntax correctly.
Add a convience method to check if a RhsKind is type const.
Rename `Const` discriminant to `Body` for `ConstItemRhsKind`
Give the `TraitItemKind` flag an enum instead of a simple bool to better describe what the flag is for.
Update formatting for these match statements.
Update clippy test to use type const syntax.
Update test to use type const syntax.
update rustfmt to match ast items.
Update clippy to match ast and hir items.
Few more test cases that used old attribute, instead of 'type const'
Update to match the output from the feature gate checks.
tidyfmt adjustments.
Update the is_type_const, so I can constrain record!(..) in encoder.rs
Update conditional compilation test.
Move the feature gate to after expansion to allow for cfg(...) to work.
Update some more tests to use the new syntax.
Update type const tests in associated-const-bindings to use new syntax.
Don't check based off the attribute, but the item here.
Update some tests outside of the const_generics folder that were using #[type_const]
update the tests in associated consts that use #[type_const] to use type const
Update these mgca tests with the type const syntax.
Add a flag to TraitItemKind for detecting type const for now. Maybe later change ItemConstRhs to have optional consts but that touches a lot more lines of code.
Don't need into for these now that it's a query.
Add is_type_const query to handle foreign def ids.
update this test to use type const syntax.
Fix logic here, we only want to lower if there is expression in this case.
Update built-in macros to use ConstItemRhsKind
Update more instance of the old ConstItemRhs.
Rename ConstItemKind to ConstItemRhsKind, I noticed there is a typed called ConstantItemKind, so add the Rhs to the name to avoid confusion.
Update lower to use ConstItemKind
Add an other helper method to check if the rhs kinda has an expr.
Update item parse to use ConstItemKind enum.
Felt the field name could a be little clear when editing a few other things.
Change the ConstItem struct see know if we have a type const or regular const.
Make sure this syntax is properly feature gated.
This target is intended to be used for kernel development. Becasue on s390x
float and vector registers overlap we have to disable the vector extension.
The default s390x-unknown-gnu-linux target will not allow use of
softfloat.
Co-authored-by: Jubilee <workingjubilee@gmail.com>
bootstrap: always propagate `CARGO_TARGET_{host}_LINKER`
We were already setting `CARGO_TARGET_{target}_LINKER` when there is a
setting in `bootstrap.toml`, and when the host and target are the same,
this is also used for build scripts and proc-macros.
However, the host value wasn't set when building for any other target,
and Cargo would see that as a fingerprint change for those build
artifacts, rebuilding them.
If we always set the `CARGO_TARGET_{host}_LINKER`, then those build
scripts will keep a consistent Cargo fingerprint, so they'll remain
cached no matter how we're alternating targets.
Fix `SourceFile::normalized_byte_pos`
This method was broken by 258ace6, which changed `self.normalized_pos` to use relative offsets however this method continued to compare against an absolute offset.
Also adds a regression test for the issue that this method was originally introduced to fix.
Closesrust-lang/rust#149568
Fixes regression of rust-lang/rust#110885
r? cjgillot (as author of the breaking commit)
Introduce helper `ty::Generics::has_own_self`
The pattern `generics.has_self && generics.parent.is_none()` only occurs 5 times in rustc+rustdoc at the time of writing but I keep getting reminded/annoyed that there doesn't exist a nice wrapper fn that abstracts it & immediately clarifies the intent. Most recently that happened when working on my open PR RUST-129543 in which I add yet another occurrence of it ([via](https://github.com/fmease/rust/blob/ae8c0a5a46364b0d0bca349cba544adb762e7c0a/compiler/rustc_hir_analysis/src/collect/resolve_bound_vars.rs#L1771-L1773)).
For context, `generics.has_self` indicates that there is a `Self` type parameter (at position 0) in the "oldest" / "root" generic parameter list in the chain of generic parameter lists (rephrased: it's true if the chain *as a whole* has a `Self` type parameter). `has_own_self` on the other hand indicates that the `own_params` contain a `Self` type parameter which is sometimes needed for offsetting the own parameters or arguments.
Convert to inline diagnostics in `rustc_lint`
For https://github.com/rust-lang/rust/issues/151366
r? @jdonszelmann
This was a big one! Second to last one, `rustc_parse` is the last one and even bigger :P
Linker-plugin-based LTO: give an explanation how to use linker-plugin-lto with full LTO
Closesrust-lang/rust#138910
The existing linker-plugin-based LTO documentation does not describe the correct usage of full LTO. Specifically, when invoking `rustc` with full LTO, the `-C lto` flag must be passed in addition to `-C linker-plugin-lto`.
Also, this PR documents the use of full LTO when linking Rust with Fortran. Unfortunately, LLVM `flang` does not currently support ThinLTO, so full LTO is the only viable option in this case.
Toolchain combinations were slightly updated.
TODO:
- [x] check swiftc compiler. Almost unusable.
- [x] check how std lib is actually compiled
- [x] add note about LLD and bitcode
- [x] report bug to LLVM: https://github.com/llvm/llvm-project/issues/179800
<details>
<summary>Swiftc is unusable</summary>
https://www.swift.org/install/ gave me LLVM-17. During playing with swift main + rust static library, LLVM-23 removed main :D
```console
# thin LTO Rust:
rustc --crate-type=staticlib -Clinker-plugin-lto -Copt-level=3 ./ftn.rs
# full LTO swift:
swiftc -static libftn.a main.swift -lto=llvm-full -O -use-ld=/tmp/test/llvm-project/install/bin/ld.lld -Xlinker --gc-sections -Xlinker --as-needed -o sr
./sr
> ftn() returned: 77
# thin LTO swift:
swiftc -static libftn.a main.swift -lto=llvm-thin -O -use-ld=/tmp/test/llvm-project/install/bin/ld.lld -Xlinker --gc-sections -Xlinker --as-needed -o sr
./sr
> No output
```
</details>
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 https://github.com/llvm/llvm-project/commit/2a528760bf20004066effcf8f91fedaabd261903)
- 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
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
Jonathan Brouwer