Improve upvar analysis for deref of child capture
Two fixes to the heuristic I implemented in #123660. As I noted in the code:
> Luckily, if this function is not correct, then the program is not unsound, since we still borrowck and validate the choices made from this function -- the only side-effect is that the user may receive unnecessary borrowck errors.
This indeed fixes unnecessary borrowck errors.
r? oli-obk
---
The heuristic is only valid if we deref a `&T`, not a `&mut T` or `Box<T>`, so make sure to check the type. This fixes:
```rust
struct Foo { precise: i32 }
fn mut_ref_inside_mut(f: &mut Foo) {
let x: impl AsyncFn() = async move || {
let y = &f.precise;
};
}
```
Since the capture from `f` to `&f.precise` needs to be treated as a lending borrow from the parent coroutine-closure to the child coroutine.
---
The heuristic is also valid if *any* deref projection in the child capture's projections is a `&T`, but we were only looking at the last one. This ensures that this function is considered not to be lending:
```rust
struct Foo { precise: i32 }
fn ref_inside_mut(f: &mut &Foo) {
let x: impl Fn() -> _ = async move || {
let y = &f.precise;
};
}
```
(Specifically, checking that `impl Fn() -> _` is satisfied is exercising that the coroutine is not considered to be lending.)
Misc print request handling cleanups + a centralized test for print request stability gating
I was working on implementing `--print=supported-crate-types`, then I noticed some things that were mildly annoying me, so I pulled out these changes. In this PR:
- First commit adds a centralized test `tests/ui/print/stability.rs` that is responsible for exercising stability gating of the print requests.
- AFAICT we didn't have any test that systematically checks this.
- I coalesced `tests/ui/feature-gates/feature-gate-print-check-cfg.rs` (for `--print=check-cfg`) into this test too, since `--print=check-cfg` is only `-Z unstable-options`-gated like other unstable print requests, and is not additionally feature-gated. cc ``@Urgau`` in case you have any concerns.
- Second commit alphabetically sorts the `PrintKind` enum for consistency because the `PRINT_KINDS` list (using the enum) is *already* alphabetically sorted.
- Third commit pulls out two helpers:
1. A helper `check_print_request_stability` for checking stability of print requests and the diagnostics for using unstable print requests without `-Z unstable-options`, to avoid repeating the same logic over and over.
2. A helper `emit_unknown_print_request_help` for the unknown print request diagnostics to make print request collection control flow more obvious.
- Fourth commit renames `PrintKind::{TargetSpec,AllTargetSpecs}` to `PrintKind::{TargetSpecJson,AllTargetSpecsJson}` to better reflect their actual print names, `--print={target-spec-json,all-target-specs-json}`.
r? ``@nnethercote`` (or compiler/reroll)
I can't find any dedicated tests that actually exercises the stability
gating (via `-Z unstable-options`) of print requests, so here's a
dedicated one.
I coalesced `tests/ui/feature-gates/feature-gate-print-check-cfg.rs`
into this test, because AFAICT that print request is not feature gated,
but only `-Z unstable-options`-gated just like other unstable print
requests.
Enforce type of const param correctly in MIR typeck
Properly intercepts and then annotates the type for a `ConstKind::Param` in the MIR.
This code should probably be cleaned up, it's kinda spaghetti, but no better structure really occurred to me when writing this case.
We could probably gate this behind the feature gate or add a fast path when the args have no free regions if perf is bad.
r? `@BoxyUwU`
Do not suggest using `-Zmacro-backtrace` for builtin macros
For macros that are implemented on the compiler, or that are annotated with `rustc_diagnostic_item`, which have arbitrary implementations from the point of view of the user and might as well be intrinsics, we do *not* mention the `-Zmacro-backtrace` flag. This includes `derive`s and standard macros like `panic!` and `format!`.
This PR adds a field to every `Span`'s `ExpnData` stating whether it comes from a builtin macro. This is determined by the macro being annotated with either `#[rustc_builtin_macro]` or `#[rustc_diagnostic_item]`. An alternative to using these attributes that already exist for other uses would be to introduce another attribute like `#[rustc_no_backtrace]` to have finer control on which macros are affected (for example, an error within `vec![]` now doesn't mention the backtrace, but one could make the case that it should). Ideally, instead of carrying this information in the `ExpnData` we'd instead try to query the `DefId` of the macro (that is already stored) to see if it is annotated in some way, but we do not have access to the `TyCtxt` from `rustc_errors`.
r? `@petrochenkov`
Fix HIR printing of parameters
HIR pretty printing does the wrong thing for anonymous parameters, and there is no test coverage for it. This PR remedies both of those things.
r? ``@lcnr``
rustc_target: Add target features for LoongArch v1.1
This patch adds new target features for LoongArch v1.1:
* div32
* lam-bh
* lamcas
* ld-seq-sa
* scq
Provide helpful diagnostics for shebang lookalikes
When `[` is not found after a `#!`, a note will be added to the exisiting error
```
error: expected `[`, found `/`
--> src/main.rs:2:3
|
2 | #!/usr/bin/env -S cargo +nightly -Zscript
| ^ expected `[`
|
= note: the token sequence `#!` here looks like the start of a shebang interpreter directive but it is not
= help: if you meant this to be a shebang interpreter directive, move it to the very start of the file
```
Fixes#137249
r? `@fmease`
Remove an outdated line from a test comment
They *used* to not work, however this was fixed in the PR that added the test. I forgot to remove this line or possibly lost its removal while rebasing.
r? `@ehuss`
EUV: fix place of deref pattern's interior's scrutinee
The place previously used here was that of the temporary holding the reference returned by `Deref::deref` or `DerefMut::deref_mut`. However, since the inner pattern of `deref!(inner)` expects the deref-target type itself, this would ICE when that type was inspected (e.g. by the EUV case for slice patterns). This adds a deref projection to fix that.
Since current in-tree consumers of EUV (upvar inference and clippy) don't care about Rvalues, the place could be simplified to `self.cat_rvalue(pat.hir_id, self.pat_ty_adjusted(subpat)?)` to save some cycles. I personally find EUV to be a bit fragile, so I've opted for pedantic correctness. Maybe a `HACK` comment would suffice though?
Fixes#125059
r? `@compiler-errors`
Visit `PatField` when collecting lint levels
Fixes#138428
Side-note, I vaguely skimmed over the other nodes we could be visiting here and it doesn't *seem* to me that we're missing anything, though I may be mistaken given recent(?) support for attrs in where clauses(??). Can be fixed in a follow-up PR.
Currently (PatKind::Wild` (i.e. `_`) gets turned by
`lower_fn_params_to_names` into an empty identifier, which means it is
printed incorrectly by HIR pretty printing.
And likewise for `lower_fn_params_to_names`, which affects some error
messages.
This commit fixes them. This requires a slight tweak in a couple of
places to continue using parameter numbers in some error messages. And
it improves the output of `tests/ui/typeck/cyclic_type_ice.rs`:
`/* _ */` is a better suggestion than `/* */`.
They *used* to not work, however this was fixed in the PR that added the
test. I forgot to remove this line or possibly lost its removal while
rebasing.
Add an opt-out in pretty printing for RTN rendering
Today, we render RPITIT types like `impl Sized { T::method(..) }` when RTN is enabled. This is very useful for diagnostics, since it's often not clear what the `impl Sized` type means by itself, and it makes it clear that that's an RPITIT that can be bounded using RTN syntax. See #115624.
However, since we don't distinguish types that are rendered for the purposes of printing messages vs suggestions, this representation leaks into suggestions and turns into code that can't be parsed. This PR adds a new `with_types_for_suggestion! {}` and `with_types_for_signature! {}` options to the pretty printing architecture to make it clear that we're rendering a type for code suggestions.
This can be applied later as we find that we need it.
The place previously used here was that of the temporary holding the
reference returned by `Deref::deref` or `DerefMut::deref_mut`. However,
since the inner pattern of `deref!(inner)` expects the deref-target type
itself, this would ICE when that type was inspected (e.g. by the EUV
case for slice patterns). This adds a deref projection to fix that.
Since current in-tree consumers of EUV (upvar inference and clippy)
don't care about Rvalues, the place could be simplified to
`self.cat_rvalue(pat.hir_id, self.pat_ty_adjusted(subpat)?)` to save
some cycles. I personally find EUV to be a bit fragile, so I've opted
for pedantic correctness. Maybe a `HACK` comment would suffice though?
Do not register `Self: AutoTrait` when confirming auto trait (in old solver)
Every built-in auto impl for a trait goal like `Ty: Auto` immediately registers another obligation of `Ty: Auto` as one of its nested obligations, leading to us stressing the cycle detection machinery a lot more than we need to. This is because all traits have a `Self: Trait` predicate.
To fix this, remove the call to `impl_or_trait_obligations` in `vtable_auto_impl`, since auto traits do not have where clauses.
r? lcnr
Use sa_sigaction instead of sa_union.__su_sigaction for AIX
Revert test cases to use `sa_sigaction` instead of `sa_union.__su_sigaction`, now that the `libc` crate implementation for AIX defines `sa_sigaction` as a direct member of `struct sigaction`, aligning it with implementations on other similar platforms. ([[AIX] Use sa_sigaction instead of the union](https://github.com/rust-lang/libc/pull/4250)).
