Lint on fn pointers comparisons in external macros
This PR extends the recently stabilized `unpredictable_function_pointer_comparisons` lint ~~to also lint on `Option<{function pointer}>` and~~ as well as linting in external macros (as to catch `assert_eq!` and others).
```rust
assert_eq!(Some::<FnPtr>(func), Some(func as unsafe extern "C" fn()));
//~^ WARN function pointer comparisons
#[derive(PartialEq, Eq)]
struct A {
f: fn(),
//~^ WARN function pointer comparisons
}
```
Fixes https://github.com/rust-lang/rust/issues/134527
Add `ParseMode::Diagnostic` and fix multiline spans in diagnostic attribute lints
Best viewed commit by commit.
The first commit is a test, the commits following that are small refactors to `rustc_parse_format`. Originally I wanted to do a much larger change (doing these smaller fixes first would have that made easier to review), but ended up doing something else instead.
An observable change from this is that the diagnostic attribute no longer tries to parse align/fill/width/etc parameters. For an example (see also test changes), a string like `"{Self:!}"` no longer says "missing '}'", instead it says that format parameters are not allowed. It'll now also format the string as if the user wrote just `"{Self}"`
refactor `AttributeGate` and `rustc_attr!` to emit notes during feature checking
First commit changes the following:
- `AttributeGate ` from an enum with (four) tuple fields to (five) named fields
- adds a `notes` fields that is emitted as notes in the `PostExpansionVisitor` pass
- removes the `this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date` note if the feature gate is `rustc_attrs`.
- various phrasing changes and touchups
- and finally, the reason why I went down this path to begin with: tell people they can use the diagnostic namespace when they hit the rustc_on_unimplemented feature gate 🙈
Second commit removes unused machinery for deprecated attributes
Apply nested goals certainty to `InspectGoals` for normalizes-to
...so that normalizes-to goals don't have `Certainty::Yes` even if they have nested goals which don't hold.
r? lcnr
It collects data about macro expansions and prints them in a table after
expansion finishes. It's very useful for detecting macro bloat,
especially for proc macros.
Details:
- It measures code snippets by pretty-printing them and then measuring
lines and bytes. This required a bunch of additional pretty-printing
plumbing, in `rustc_ast_pretty` and `rustc_expand`.
- The measurement is done in `MacroExpander::expand_invoc`.
- The measurements are stored in `ExtCtxt::macro_stats`.
`tests/ui`: A New Order [11/N]
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@jieyouxu`
`tests/ui`: A New Order [10/N]
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `@jieyouxu`
rustc_resolve: Improve `resolve_const_param_in_non_trivial_anon_const` wording
In some contexts, const expressions are OK. Add a `here` to the error message to clarify this.
Closesrust-lang/rust#79429 which has 15 x 👍
More simple 2015 edition test decoupling
This should be the last of these PRs for now. The remaining tests that do not work on other editions than 2015 either need the range support (so blocked on the MCP), need normalization rules (which needs discussions first/same MCP) or revisions.
r? compiler-errors
transmutability: shift abstraction boundary
Previously, `rustc_transmute`'s layout representations were genericized over `R`, a reference. Now, it's instead genericized over representations of type and region. This allows us to move reference transmutability logic from `rustc_trait_selection` to `rustc_transmutability` (and thus unit test it independently of the compiler), and — in a follow-up PR — will make it possible to support analyzing function pointer transmutability with minimal surgery.
r? `@compiler-errors`
Implement `//@ needs-target-std` compiletest directive
Closesrust-lang/rust#141863.
Needed to unblock rust-lang/rust#139244 and rust-lang/rust#141856.
### Summary
This PR implements a `//@ needs-target-std` compiletest directive that gates test execution based on whether the target supports std or not. For some cases, this should be preferred over e.g. some combination of `//@ ignore-none`, `//@ ignore-nvptx` and more[^none-limit].
### Implementation limitation
Unfortunately, since there is currently [no reliable way to determine from metadata whether a given target supports std or not](https://github.com/rust-lang/rust/issues/142296), we have to resort to a hack. Bootstrap currently determines whether or not a target supports std by a naive target tuple substring comparison: a target supports std if its target tuple does *not* contain one of `["-none", "nvptx", "switch"]` substrings. This PR simply pulls that hack out into `build_helpers` to avoid reimplementing the same hack in compiletest, and uses that logic to inform `//@ needs-target-std`.
### Auxiliary changes
This PR additionally changes a few run-make tests to use `//@ needs-target-std` over an inconsistent combination of target-based `ignore`s. This should help with rust-lang/rust#139244.
---
r? bootstrap
[^none-limit]: Notably, `target_os = "none"` is **not** a sufficient condition for "target does not support std"
tests: Change ABIs in tests to more future-resilient ones
Eventually we're going to make these tests not work as they are currently written on HEAD, so change them now to get ahead of that.
r? aDotInTheVoid
Remove check_mod_loops query and run the checks per-body instead
This analysis is older than my first rustc contribution I believe. It was never querified. Ideally we'd merge it into the analysis happening within typeck anyway (typeck just uses span_delayed_bug instead of erroring), but I didn't want to do that within this PR that also moves things around and subtly changes diagnostic ordering.
compiler: fn ptrs should hit different lints based on ABI
I was looking closer at the code for linting on ABIs and realized a mistake was probably made during rebase or review. I think that for function pointers in the HIR, the lint that fires should probably depend on the ABI we encountered, e.g. if it's on the newly-deprecated set of ABIs or not. This will be slightly confusing for a little bit, but I think we can do more to reduce that confusion by switching `unsupported_fn_ptr_calling_conventions` to a hard error.
r? ``@RalfJung``
deduplicate the rest of AST walker functions
After this, we can tidy things up and deduplicate the visitor traits themselves too.
Fixesrust-lang/rust#139825, apparently
r? ``@oli-obk``
Note the version and PR of removed features when using it
Fixesrust-lang/rust#141619
I added the diagnostic information. Since all the current version information is present, it prints the version information anyway, as shown in tests/ui. And PR will not print if it is None, we can gradually add the PR links.
Split into two commits for easier review.
r? compiler
cc ``@jyn514`` Since you're on vocation in the review list, I can't r? you.
Stabilize keylocker
This PR stabilizes the feature flag `keylocker_x86` (tracking issue rust-lang/rust#134813).
# Public API
The 2 `x86` target features `kl` and `widekl`, and the associated intrinsics in stdarch.
These target features are very specialized, and are only used to signal the presence of the corresponding CPU instruction. They don't have any nontrivial interaction with the ABI (contrary to something like AVX), and serve the only purpose of enabling 11 stdarch intrinsics, all of which have been implemented and propagated to rustc via a stdarch submodule update.
Also, these were added way back in LLVM12, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!
# Associated PRs
- rust-lang/rust#134814
- rust-lang/stdarch#1706
- rust-lang/rust#136831 (stdarch submodule update)
- rust-lang/stdarch#1795 (stabilizing the runtime detection and intrinsics)
- rust-lang/rust#141964 (stdarch submodule update for the stabilization of the runtime detection and intrinsics)
As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now.
cc ````@rust-lang/lang````
cc ````@rust-lang/libs-api```` for the intrinsics and runtime detection
I don't think anyone else worked on this feature, so no one else to ping, maybe cc ````@Amanieu.```` I will send the reference pr soon.
mir-opt: Do not create storage marks in EarlyOtherwiseBranch
Fixes#141212.
The first commit add `StorageDead` by creating new indirect BB that makes CFG more complicated, but I think it's better to just not create storage marks.
r? mir-opt
