Only copy, rename and link `llvm-objcopy` if llvm tools are enabled
Fixes#132719.
cc `@bjorn3` who reported the bootstrapping problem for cg_clif.
cc `@davidtwco` in case this might be problematic for linux -> macOS cross-compile builds, but seems very unlikely.
cc `@albertlarsan68` (co-reviewed #131405)
r? bootstrap
Remove `rustc_session::config::rustc_short_optgroups`
Follow-up to https://github.com/rust-lang/rust/pull/132754#discussion_r1835427349.
The name `rustc_short_optgroups` has always been confusing, because it is unrelated to the distinction between short and long options (i.e. `-s` vs `--long`), and instead means something like “the subset of command-line options that are printed by `rustc --help` without `-v`”.
So let's merge that function into the main `rustc_optgroups`, and store the relevant bit of information in a boolean field in `RustcOptGroup` instead.
---
This PR also modifies `RustcOptGroup` to store its various strings directly, instead of inside a boxed `apply` closure. That turned out to not be necessary for the main change, but is a worthwhile cleanup in its own right.
Implement file_lock feature
This adds lock(), lock_shared(), try_lock(), try_lock_shared(), and unlock() to File gated behind the file_lock feature flag
This is the initial implementation of https://github.com/rust-lang/rust/issues/130994 for Unix and Windows platforms. I will follow it up with an implementation for WASI preview 2
Ensure that tail expr receive lifetime extension
cc `@jieyouxu` `@traviscross`
It just came to me that we should add a test to make sure that we honor the contract from the temporary lifetime rule #121346. We should continue to implement this rule in Edition 2021 onward and shorter tail expression lifetime should not override it.
This is a small PR to improve our assurance and establish a stronger contract.
Tracked by rust-lang/rust#123739
query/plumbing: adjust comment to reality
The limit for the query key size got changed recently in f51ec110a7 but the comment was not updated.
Though maybe it is time to intern `CanonicalTypeOpAscribeUserTypeGoal` rather than copying it everywhere?
r? `@lcnr`
triagebot: Assign rustdoc tests to T-rustdoc.
Should avoid situations like #132871, which got assigned to mark (via fallback) despite being a rustdoc change.
For now, I've assigned all our testsuites to the rustdoc group (whoever from T-Rustdoc is on review rotation), except the json one which is assigned to me.
CC `@rust-lang/rustdoc`
r? `@GuillaumeGomez`
Stabilize WebAssembly `multivalue`, `reference-types`, and `tail-call` target features
For the `multivalue` and `reference-types` features this commit is
similar to https://github.com/rust-lang/rust/pull/117457 in that it's stabilizing target features specific to
WebAssembly targets. The previous PR left out these two features because
they weren't expected to change much about compiled code so it was
unclear what the rationale was. It has [since been discovered][blog]
that `reference-types` can be useful as it changes the binary format of
the `call_indirect` instruction. Additionally [on Zulip][zulip] there's
a use case of detecting these features at compile time and generating a
compile error to better warn users about features not supported on
engines.
This PR then additionally adds the `tail-call` feature which corresponds
to the [tail-call] proposal to WebAssembly. This feature advanced to
"phase 4" in the WebAssembly CG awhile back and has been supported in
LLVM for quite some time now. Engines are finishing up implementations
or have already shipped implementations, so while this is a bit of a
late addition to Rust itself it reflects the current status of
WebAssembly's state of the feature.
A test has been added here not only for these features but other
WebAssembly features as well to showcase that they're usable without
feature gates in stable Rust.
[blog]: https://blog.rust-lang.org/2024/09/24/webassembly-targets-change-in-default-target-features.html
[zulip]: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/wasm32.20reference-types.20.2F.20multivalue.20in.201.2E82-beta.20not.20enabled/near/473893987
[tail-call]: https://github.com/webassembly/tail-call
Break from review rotation
Spending ~a week to focus on:
- Digesting remaining `Makefile`s (so close yet so far).
- 2024 Q3 T-compiler P-high issues review pre-triage.
- Some docs for rustc-dev-guide.
r? `@ghost`
Prefer `pub(super)` in `unreachable_pub` lint suggestion
This PR updates the `unreachable_pub` lint suggestion to prefer `pub(super)` instead of `pub(crate)` when possible.
cc `@petrochenkov`
r? `@nnethercote`
Stabilize Arm64EC inline assembly
This stabilizes inline assembly for Arm64EC ("Emulation Compatible").
Corresponding reference PR: https://github.com/rust-lang/reference/pull/1653
---
From the requirements of stabilization mentioned in https://github.com/rust-lang/rust/issues/93335
> Each architecture needs to be reviewed before stabilization:
> - It must have clobber_abi.
Done in https://github.com/rust-lang/rust/pull/131332.
> - It must be possible to clobber every register that is normally clobbered by a function call.
This is possible from the time of the initial implementation.
> - Generally review that the exposed register classes make sense.
The registers available in this target are a subset of those available in the AArch64 inline assembly which is already stable.
The following registers cannot be used in Arm64EC compared to AArch64:
- `x13`, `x14`, `x23`, `x24`, `x28` (register class: `reg`)
- `v[16-31]` (register class: `vreg`)
- `p[0-15]`, `ffr` (clobber-only register class `preg`)
These are disallowed by the ABI (see also [abi docs](https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-abi-conventions?view=msvc-170#register-mapping) for `reg`/`vreg` and https://github.com/rust-lang/rust/pull/131332#issuecomment-2401189142 for `preg`).
Although not listed in the above requirements, preserves_flags is also implemented and the same as AArch64.
---
cc `@dpaoliello`
r? `@Amanieu`
`@rustbot` label O-windows O-AArch64 +A-inline-assembly +T-lang -T-compiler +needs-fcp
Update minifer version to `0.3.2`
This version fixes a few lints but the main change is that it makes `clap` dependency optional since it's only used for the binary.
r? `@notriddle`
coverage: Restrict empty-span expansion to only cover `{` and `}`
Coverage instrumentation has some tricky code for converting a coverage-relevant `Span` into a set of start/end line/byte-column coordinates that will be embedded in the CGU's coverage metadata.
A big part of this complexity is special code for handling empty spans, which are expanded into non-empty spans (if possible) because LLVM's coverage reporter does not handle empty spans well.
This PR simplifies that code by restricting it to only apply in two specific situations: when the character after the empty span is `{`, or the character before the empty span is `}`.
(As an added benefit, this means that the expanded spans no longer extend awkwardly beyond the end of a physical line, which was common under the previous implementation.)
Along the way, this PR also removes some unhelpful code for dealing with function source code spread across multiple files. Functions currently can't have coverage spans in multiple files, and if that ever changes (e.g. to properly support expansion regions) then this code will need to be completely overhauled anyway.
For the `multivalue` and `reference-types` features this commit is
similar to #117457 in that it's stabilizing target features specific to
WebAssembly targets. The previous PR left out these two features because
they weren't expected to change much about compiled code so it was
unclear what the rationale was. It has [since been discovered][blog]
that `reference-types` can be useful as it changes the binary format of
the `call_indirect` instruction. Additionally [on Zulip][zulip] there's
a use case of detecting these features at compile time and generating a
compile error to better warn users about features not supported on
engines.
This PR then additionally adds the `tail-call` feature which corresponds
to the [tail-call] proposal to WebAssembly. This feature advanced to
"phase 4" in the WebAssembly CG awhile back and has been supported in
LLVM for quite some time now. Engines are finishing up implementations
or have already shipped implementations, so while this is a bit of a
late addition to Rust itself it reflects the current status of
WebAssembly's state of the feature.
A test has been added here not only for these features but other
WebAssembly features as well to showcase that they're usable without
feature gates in stable Rust.
[blog]: https://blog.rust-lang.org/2024/09/24/webassembly-targets-change-in-default-target-features.html
[zulip]: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/wasm32.20reference-types.20.2F.20multivalue.20in.201.2E82-beta.20not.20enabled/near/473893987
[tail-call]: https://github.com/webassembly/tail-call
Revert #132772 to fix unknown git commit hash
Reverts #132772 to address #132845, we seem to have unintentionally omitted commit hash.
r? `@onur-ozkan`
Dont suggest `use<impl Trait>` when we have an edition-2024-related borrowck issue
#131186 implements some machinery to detect in borrowck when we may have RPIT overcaptures due to edition 2024, and suggests adding `+ use<'a, T>` to go back to the edition 2021 capture rules. However, we weren't filtering out cases when there are APITs in scope.
This PR implements a more sophisticated diagnostic where we will suggest turning any APITs in scope into type parameters, and applies this to both the borrowck error note, and to the `impl_trait_overcaptures` migration lint.
cc #132809
