bootstrap/codegen_ssa: ship llvm-strip and use it for -Cstrip
Fixes#131206.
- Includes `llvm-strip` (a symlink to `llvm-objcopy`) in the compiler dist artifact so that it can be used for `-Cstrip` instead of the system tooling.
- Uses `llvm-strip` instead of `/usr/bin/strip` for macOS. macOS needs a specific linker and the system one is preferred, hence #130781 but that doesn't work when cross-compiling, so use the `llvm-strip` utility instead.
cc #123151
Rollup of 8 pull requests
Successful merges:
- #132259 (rustc_codegen_llvm: Add a new 'pc' option to branch-protection)
- #132409 (CI: switch 7 linux jobs to free runners)
- #132498 (Suggest fixing typos and let bindings at the same time)
- #132524 (chore(style): sync submodule exclusion list between tidy and rustfmt)
- #132567 (Properly suggest `E::assoc` when we encounter `E::Variant::assoc`)
- #132571 (add const_eval_select macro to reduce redundancy)
- #132637 (Do not filter empty lint passes & re-do CTFE pass)
- #132642 (Add documentation on `ast::Attribute`)
r? `@ghost`
`@rustbot` modify labels: rollup
Add documentation on `ast::Attribute`
I was working again with attributes in clippy recently and I often find myself in need to read the source code to ensure it's doing what I want.
Instead, a bit of documentation would allow me (and hopefully others) to skip this step.
Do not filter empty lint passes & re-do CTFE pass
Some structs implement `LintPass` without having a `Lint` associated with them #125116 broke that behaviour by filtering them out. This PR ensures that lintless passes are not filtered out.
Do not filter empty lint passes & re-do CTFE pass
Some structs implement `LintPass` without having a `Lint` associated with them #125116 broke that behaviour by filtering them out. This PR ensures that lintless passes are not filtered out.
add const_eval_select macro to reduce redundancy
I played around a bit with a macro to make const_eval_select invocations look a bit nicer and avoid repeating the argument lists. Here's what I got. What do you think?
I didn't apply this everywhere yet because I wanted to gather feedback first.
The second commit moves the macros from https://github.com/rust-lang/rust/pull/132542 into a more sensible place. It didn't seem worth its own PR and would conflict with this PR if done separately.
Cc ``@oli-obk`` ``@saethlin`` ``@tgross35``
try-job: dist-aarch64-msvc
Properly suggest `E::assoc` when we encounter `E::Variant::assoc`
Use the right span when encountering an enum variant followed by an associated item so we don't lose the associated item in the resulting code.
Do not suggest the thing twice, once as a removal of the associated item and a second time as a typo suggestion.
Suggest fixing typos and let bindings at the same time
Fixes#132483
Currently, a suggestion for adding a let binding won't be shown if we suggest fixing a typo. This changes that behavior to always show both, if possible. Essentially, this turns the suggestion from
```rust
error[E0425]: cannot find value `x2` in this scope
--> src/main.rs:4:5
|
4 | x2 = 2;
| ^^ help: a local variable with a similar name exists: `x1`
For more information about this error, try `rustc --explain E0425`.
```
to
```rust
error[E0425]: cannot find value `x2` in this scope
--> src/main.rs:4:5
|
4 | x2 = 2;
| ^^
|
help: a local variable with a similar name exists
|
4 | x1 = 2;
| ~~
help: you might have meant to introduce a new binding
|
4 | let x2 = 2;
| +++
For more information about this error, try `rustc --explain E0425`.
```
for the following code:
```rust
fn main() {
let x1 = 1;
x2 = 2;
}
```
The original behavior only shows the suggestion for a let binding if a typo suggestion wasn't already displayed. However, this falls apart in the cases like the one above where we have multiple similar variables. I don't think it makes sense to hide this suggestion if there's a similar variable, since that defeats the purpose of this suggestion in that case (it's meant to help those coming from languages like Python).
rustc_codegen_llvm: Add a new 'pc' option to branch-protection
Add a new 'pc' option to -Z branch-protection for aarch64 that enables the use of PC as a diversifier in PAC branch protection code.
When the pauth-lr target feature is enabled in combination with -Z branch-protection=pac-ret,pc, the new 9.5-a instructions (pacibsppc, retaasppc, etc) will be generated.
Swap Visitors to early exit, instead of storing poison flag
I noticed that a bunch of visitors had a `poison` or `success` field, when they could just be returning `ControlFlow`.
changelog: none
mark some target features as 'forbidden' so they cannot be (un)set with -Ctarget-feature
The context for this is https://github.com/rust-lang/rust/issues/116344: some target features change the way floats are passed between functions. Changing those target features is unsound as code compiled for the same target may now use different ABIs.
So this introduces a new concept of "forbidden" target features (on top of the existing "stable " and "unstable" categories), and makes it a hard error to (un)set such a target feature. For now, the x86 and ARM feature `soft-float` is on that list. We'll have to make some effort to collect more relevant features, and similar features from other targets, but that can happen after the basic infrastructure for this landed. (These features are being collected in https://github.com/rust-lang/rust/issues/131799.)
I've made this a warning for now to give people some time to speak up if this would break something.
MCP: https://github.com/rust-lang/compiler-team/issues/780
triagebot: ping wg-const-eval when relevant files change
This adds pings for `@rust-lang/wg-const-eval` when anything in rustc_const_eval changes (in particular, this covers the const checking logic, which was so far not covered by any notifications). I also added pings for things that so far only pinged the Miri group, since those parts are relevant to wg-const-eval as well.
PassWrapper: adapt for new parameter in LLVM
llvm/llvm-project@390300d9f4 added a new parameter to some callbacks, so we have to handle them.
`@rustbot` label: +llvm-main
[core/fmt] Replace checked slice indexing by unchecked to support panic-free code
Fixes#126425
Replace the potentially panicking `[]` indexing with `get_unchecked()` to prevent linking with panic-related code.
Stabilise `const_char_encode_utf16`.
Closes: #130660
This PR stabilises the `const_char_encode_utf16` feature gate (i.e. support for `char::encode_utf16` in constant expressions).
~~Note that the linked tracking issue is as of this writing currently awaiting FCP until 2024-11-02.~~
Remove unnecessary pub enum glob-imports from `rustc_middle::ty`
We used to have an idiom in the compiler where we'd prefix or suffix all the variants of an enum, for example `BoundRegionKind`, with something like `Br`, and then *glob-import* that enum variant directly.
`@noratrieb` brought this up, and I think that it's easier to read when we just use the normal style `EnumName::Variant`.
This PR is a bit large, but it's just naming.
The only somewhat opinionated change that this PR does is rename `BorrowKind::Imm` to `BorrowKind::Immutable` and same for the other variants. I think these enums are used sparingly enough that the extra length is fine.
r? `@noratrieb` or reassign
Remove unnecessary pub enum glob-imports from `rustc_middle::ty`
We used to have an idiom in the compiler where we'd prefix or suffix all the variants of an enum, for example `BoundRegionKind`, with something like `Br`, and then *glob-import* that enum variant directly.
`@noratrieb` brought this up, and I think that it's easier to read when we just use the normal style `EnumName::Variant`.
This PR is a bit large, but it's just naming.
The only somewhat opinionated change that this PR does is rename `BorrowKind::Imm` to `BorrowKind::Immutable` and same for the other variants. I think these enums are used sparingly enough that the extra length is fine.
r? `@noratrieb` or reassign
Improve example of `impl Pattern for &[char]`
The previous version used `['l', 'l']` as pattern, which would suggest that it matches the `ll` of `Hello world` as a whole.
Clippy: Move some attribute lints to be early pass (post expansion)
r? ```@xFrednet```
As a side effect it removes a duplicated warning on line 53 of the `allow_attributes` test. I discussed this with ```@xFrednet``` , and it's mainly to support the attribute rework https://github.com/rust-lang/rust/issues/131229
[rustdoc] Fix `--show-coverage` when JSON output format is used
I realized while looking on the docs.rs page of the `sysinfo` crate that the coverage numbers displayed were wrong:
I realized that it was because `--show-coverage --output-format=json` was relying on the same logic as the JSON output for the doc generation whereas it should not. I fixed it by changing the API for querying `is_json` a bit.
The underlying issue is that JSON output format is stripping reexports of items from private modules.
r? ``@notriddle``
Revert "Avoid nested replacement ranges" from #129346.
It caused a test regression in the `cfg_eval.rs` crate. (The bugfix in #129346 was in a different commit; this commit was just a code simplification.)
r? `@petrochenkov`
remove support for extern-block const intrinsics
This converts all const-callable intrinsics into the "new" form of a regular `fn` with `#[rustc_intrinsic]` attribute. That simplifies some of the logic since those functions can be marked `const fn` like regular functions, so intrinsics no longer need a special case to be considered const-callable at all.
I also added a new attribute `#[rustc_const_stable_intrinsic]` to mark an intrinsic as being ready to be exposed on stable. Previously we used the `#[rustc_const_stable_indirect]` attribute for that, but that attribute had a dual role -- when used on a regular function, it is an entirely safe marker to make this function part of recursive const stability, but on an intrinsic it is a trusted marker requiring special care. It's not great for the same attribute to be sometimes fully checked and safe, and sometimes trusted and requiring special care, so I split this into two attributes.
This also fixes https://github.com/rust-lang/rust/issues/122652 by accepting intrinsics as const-stable if they have a fallback body that is recursively const-stable.
The library changes are best reviewed with whitespace hidden.
r? `@compiler-errors`
More tests for non-exhaustive C-like enums in FFI
Add a few more tests for the `improper_ctypes` lint as found with the [varnish-rs](https://github.com/gquintard/varnish-rs) project.
This follows up on #116831, fixed in #116863 by ``@workingjubilee`` - I have been seeing these fail with the bindgen-generated non-exhaustive enums inside other structs. Seems the issue does not exist in the primary branch, so this PR just makes sure more cases are covered for the future.
