Rollup of 3 pull requests
Successful merges:
- #132106 (Pass Ident by reference in ast Visitor)
- #132130 (remove `change-id` from CI script)
- #132137 (library: consistently use American spelling for 'behavior')
r? `@ghost`
`@rustbot` modify labels: rollup
Then we can rename the _raw functions to drop their suffix, and instead
explicitly use is_stable_const_fn for the few cases where that is really what
you want.
Run the full stage 2 `run-make` test suite in `x86_64-gnu-debug`
Run the full `run-make` test suite in the `x86_64-gnu-debug` CI job. This is currently the *only* CI job where `//@ needs-force-clang-based-test` will be satisfied, so some `run-make` tests will literally never be run otherwise. Before this PR, the CI job only ran `run-make` tests which contains the substring `clang` in its test name, which is both (1) a footgun because it's very easy to forget and (2) it masks tests that would otherwise fail (even failing to compile) because the test is skipped if doesn't have a `clang` in its test name.
With the environment of `x86_64-gnu-debug`, two `run-make` tests failed before this PR:
1. `tests/run-make/issue-84395-lto-embed-bitcode/rmake.rs`: this was broken for a long time because `objcopy` in llvm bin tools was renamed to `llvm-objcopy`. This test was converted into a rmake.rs test, rather straight forward.
2. `tests/run-make/cross-lang-lto-riscv-abi/rmake.rs`: this was broken for a long time and never worked. The old version inspected human-readable output of `llvm-readobj --file-header` looking for substring `EF_RISCV_FLOAT_ABI_DOUBLE`, but the human-readable output will only contain something like `Flags: 0x5, RVC, double-float ABI`, hence it will never match. This test was fixed by instead using the `object` crate to actually decode the ELF headers looking for the specific `e_flags` based on reading the RISCV ELF psABI docs.
This PR is best reviewed commit-by-commit, two commits setup the support library for functionality and two commits are for each of the failing `run-make` tests.
I had to bump the `x86_64-gnu-debug` job to be ran with a runner with larger disk space.
Part of #132034.
try-job: x86_64-gnu-debug
library: consistently use American spelling for 'behavior'
We use "behavior" a lot more often than "behaviour", but some "behaviour" have even snuck into user-facing docs. This makes the spelling consistent.
Pass Ident by reference in ast Visitor
`MutVisitor`'s version of `visit_ident` passes around `&Ident`, but `Visitor` copies `Ident`. This PR changes that
r? `@petrochenkov`
related to #128974
Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features
This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.
Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.
The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.
Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.
Because `note_obligation_cause_code` is recursive, if multiple types are too
long to print to the terminal, a `long_ty_file` will be created. Before, one was
created *per recursion*. Now, it is passed in so it gets printed only once.
Part of #132013.
When printing
```
= help: the trait `chumsky::private::ParserSealed<'_, &'a str, ((), ()), chumsky::extra::Full<EmptyErr, (), ()>>` is implemented for `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>`
= help: for that trait implementation, expected `((), ())`, found `()`
```
Highlight only the `expected` and `found` types, instead of the full type in the first `help`.
Emit future-incompatibility lint when calling/declaring functions with vectors that require missing target feature
On some architectures, vector types may have a different ABI depending on whether the relevant target features are enabled. (The ABI when the feature is disabled is often not specified, but LLVM implements some de-facto ABI.)
As discussed in https://github.com/rust-lang/lang-team/issues/235, this turns out to very easily lead to unsound code.
This commit makes it a post-monomorphization error to declare or call functions using those vector types in a context in which the corresponding target features are disabled, if using an ABI for which the difference is relevant. This ensures that these functions are always called with a consistent ABI.
See the [nomination comment](https://github.com/rust-lang/rust/pull/127731#issuecomment-2288558187) for more discussion.
r? RalfJung
Part of https://github.com/rust-lang/rust/issues/116558
ci: aarch64-gnu-debug job
- Adds a new CI job which checks that the compiler builds with `--enable-debug` and tests that `needs-force-clang-based-tests` pass (where cross-language LTO is tested).
- Add a test confirming that `-Zbranch-protection=pac-ret` and cross-language LTO work together.
r? `@Mark-Simulacrum`
try-job: aarch64-gnu-debug
On some architectures, vector types may have a different ABI when
relevant target features are enabled.
As discussed in https://github.com/rust-lang/lang-team/issues/235, this
turns out to very easily lead to unsound code.
This commit makes it an error to declare or call functions using those
vector types in a context in which the corresponding target features are
disabled, if using an ABI for which the difference is relevant.
coverage: Emit LLVM intrinsics using the normal helper method
Codegen already has convenient ways to declare and emit LLVM intrinsics, so there's no need for coverage instrumentation to jump through hoops to emit them manually.
Add support for `~const` item bounds
Supports the only missing capability of `~const` associated types that I can think of now (this is obviously excluding `~const` opaques, which I see as an extension to this; I'll probably do that next).
r? ``@lcnr`` mostly b/c it changes candidate assembly, or reassign
cc ``@fee1-dead``
Expand `ptr::fn_addr_eq()` documentation.
* Describe more clearly what is (not) guaranteed, and de-emphasize the description of rustc implementation details.
* Explain what you *can* reliably use it for.
Tracking issue for `ptr_fn_addr_eq`: #129322
The motivation for this PR is that I just learned that `ptr::fn_addr_eq()` exists, read the documentation, and thought: “*I* know what this means, but someone not already familiar with how `rustc` works could be left wondering whether this is even good for anything.” Fixing that seems especially important if we’re going to recommend people use it instead of `==` (as per #118833).
[rustdoc] Do not consider nested functions as main function even if named `main` in doctests
Fixes#131893.
If a nested function is called `main`, it is not considered as the entry point of the program. Therefore, doctests should not consider such functions as such either.
r? `@notriddle`
Thanks to the observation (supported by counting) that the vast majority paths have neither generics no type anchors, and thanks to a new datastructure `ThinVecWithHeader` that is essentially `(T, Box<[U]>)` but with the size of a single pointer, we are able to reach this feat.
This (together with `ThinVecWithHeader`) makes the possibility to shrink `TypeRef`, because most types are paths.
Add a separate markdown file containing the settings.json snippet from
the "Useful Setup Tips". This fixes the rendering and also makes the
text selectable.
Also use double-backticks for `code` rendering.
