Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#141839 (make rust-analyzer use a dedicated build directory)
- rust-lang/rust#146166 (Implement range support in `//@ edition`)
- rust-lang/rust#147259 (cg_llvm: Use helper methods for all calls to `LLVMMDNodeInContext2`)
- rust-lang/rust#147263 (Disable triagebot auto stable-regression compiler backport nominations pending redesign)
- rust-lang/rust#147268 (add arm-maintainers to various targets)
- rust-lang/rust#147270 (Move doc_cfg-specific code into `cfg.rs`)
r? `@ghost`
`@rustbot` modify labels: rollup
If the `LocalRef` is `LocalRef::Place`, we can refer to it directly,
because the local of place is an indirect pointer.
Such a statement is `_1 = &(_2.1)`.
If the `LocalRef` is `LocalRef::Operand`,
the `OperandRef` should provide the pointer of the reference.
Such a statement is `_1 = &((*_2).1)`.
But there is a special case that hasn't been handled, scalar pairs like `(&[i32; 16], i32)`.
add arm-maintainers to various targets
Add the ``@rust-lang/arm-maintainers`` team as maintainers to the following targets:
- `aarch64-unknown-linux-gnu`
- `aarch64-unknown-none`/`aarch64-unknown-none-softfloat`
- `aarch64-unknown-uefi`
- `armv7-unknown-linux-gnueabi`/`armv7-unknown-linux-gnueabihf`
- `armv7a-none-eabi`/`armv7a-none-eabihf`
- `armv7r-none-eabi`/`armv7r-none-abihf`
- `armv8r-none-eabihf`
- `thumbv7em-none-eabi`/`thumbv7em-none-eabihf`
- `thumbv7m-none-eabi`
- `thumbv8m.base-none-eabi`
- `thumbv8m.main-none-eabi`/`thumbv8m.main-none-eabihf`
cc `@thejpster`
Disable triagebot auto stable-regression compiler backport nominations pending redesign
Current auto compiler stable-regression backport nominations seem to be too aggressive, and seems to unfortunately lower signal-to-noise ratio of the compiler backport channel. So this PR disables the triagebot compiler auto stable-regression backport nominations pending a redesign. Beta-regression auto backport nominations are not modified, we might want to gather some more experience with it.
No prejudice against re-enabling them if the nominations include a bit more context on _why_ it's automatically nominated and _which_ regression(s) are being addressed. Or as proposed, it could also simply become a reminder-to-nominate _comment_.
cf. [#t-compiler/backports > #146919: stable-nominated @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/474880-t-compiler.2Fbackports/topic/.23146919.3A.20stable-nominated/near/540979327)
> I like the idea of rustbot just posting a message that suggests adding the label. That seems like a good compromise between avoiding forgotten nominations and avoiding spurious nominations.
In any case, this was very much worth experimenting!
r? `@apiraino` (or triagebot)
cg_llvm: Use helper methods for all calls to `LLVMMDNodeInContext2`
Originally I was only planning on extracting an `md_node_in_context` method, but then I noticed that all callers of `LLVMMDNodeInContext2` could be covered by a small number of additional helper methods.
There should be no change in compiler output.
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This
follows in the footsteps of the previous `wasm32-wasip2` target and is
used to represent binding to the WASIp3 set of APIs managed by the WASI
subgroup to the WebAssembly Community Group.
As of now the WASIp3 set of APIs are not finalized nor standardized.
They're in the process of doing so and the current trajectory is to have
the APIs published in December of this year. The goal here is to get the
wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the `wasm32-wasip3` target looks exactly the same as
`wasm32-wasip2` except that `target_env = "p3"` is specified. This
indicates to crates in the ecosystem that WASIp3 APIs should be used,
such as the [`wasip3` crate]. Over time this target will evolve as
implementation in guest toolchains progress, notably:
* The standard library will use WASIp3 APIs natively once they're
finalized in the WASI subgroup.
* Support through `wasi-libc` will be updated to use WASIp3 natively
which Rust will then transitively use.
* Longer-term, features such as cooperative multithreading will be added
to the WASIp3-track of targets to enable using `std::thread`, for
example, on this target.
These changes are all expected to be non-breaking changes for users of
this target. Runtimes supporting WASIp3, currently Wasmtime and Jco,
support WASIp2 APIs as well and will work with components whether or not
they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This
means that changing the internal implementation details of libstd over
time is expected to be a non-breaking change.
[`wasip3` crate]: https://crates.io/crates/wasip3
Extending `#[rustc_force_inline]` to be applicable to inherent methods
`#[rustc_force_inline]` is an internal-only attribute similar to `#[inline(always)]` but which emits an error if inlining cannot occur. rustc_force_inline uses the MIR inliner to do this and has limitations on where it can be applied to ensure that an error is always emitted if inlining can't happen (e.g. it can't be applied to trait methods because calls to those can't always be resolved).
`#[rustc_force_inline]` is motivated by AArch64 pointer authentication intrinsics where it is vital for the security properties of these intrinsics that they do not exist in standalone functions that could be used as gadgets in an exploit (if they could, then you could sign whatever pointers you want, for example, which is bad, but if you force inlining, then you can't jump to a reusable function containing only these instructions).
Since its initial implementation, `#[rustc_force_inline]` could only be applied to free functions. This can be relaxed to also allow inherent methods while still preserving the desired properties. In a work-in-progress patch for manual pointer authentication intrinsics, it is useful to introduce types with inherent methods that would need to be force inlined.
r? `@saethlin`
Partially revert a535042e80
Even with non-LLVM codegen backends, we want to allow for annotations
that express dependencies to LLVM-specific parts of the test suite.
This includes `//@ needs-llvm-components`, which just allows checking
that LLVM is built with relevant target support before the test is run.
It does not assert the test cannot work with another codegen backend.
for example, if we're showing `Iterator::next`,
we don't need to also show `Range::next` in the results.
Co-authored-by: Michael Howell <michael@notriddle.com>
The linux backtrace unwinder relies on unwind tables to work properly,
and generating and printing a backtrace is done by for example the
default panic hook.
Begin emitting unwind tables by default again with `-C panic=abort` (see
history below) so that backtraces work.
History
=======
Backtraces with `-C panic=abort` used to work in Rust 1.22 but broke in
Rust 1.23, because in 1.23 we stopped emitting unwind tables with `-C
panic=abort` (see 24cc38e3b0).
In 1.45 (see cda994633e) a workaround in the form
of `-C force-unwind-tables=yes` was added.
`-C panic=abort` was added in [Rust
1.10](https://blog.rust-lang.org/2016/07/07/Rust-1.10/#what-s-in-1-10-stable)
and the motivation was binary size and compile time. But given how
confusing that behavior has turned out to be, it is better to make
binary size optimization opt-in with `-C force-unwind-tables=no` rather
than default since the current default breaks backtraces.
Besides, if binary size is a primary concern, there are many other
tricks that can be used that has a higher impact.
