Remove fake borrows of refs that are converted into non-refs in `MakeByMoveBody`
Remove fake borrows of closure captures if that capture has been replaced with a by-move version of that capture.
For example, given an async closure that looks like:
```
let f: Foo;
let c = async move || {
match f { ... }
};
```
... in this pair of coroutine-closure + coroutine, we capture `Foo` in the parent and `&Foo` in the child. We will emit two fake borrows like:
```
_2 = &fake shallow (*(_1.0: &Foo));
_3 = &fake shallow (_1.0: &Foo);
```
However, since the by-move-body transform is responsible for replacing `_1.0: &Foo` with `_1.0: Foo` (since the `AsyncFnOnce` coroutine will own `Foo` by value), that makes the second fake borrow obsolete since we never have an upvar of type `&Foo`, and we should replace it with a `nop`.
As a side-note, we don't actually even care about fake borrows here at all since they're fully a MIR borrowck artifact, and we don't need to borrowck by-move MIR bodies. But it's best to preserve as much as we can between these two bodies :)
Fixes#138501
r? oli-obk
feat: check ARG_MAX on Unix platforms
On Unix the limits can be gargantuan anyway so we're pretty unlikely to hit them, but might still exceed it.
We consult ARG_MAX here to get an estimate.
Fixes#138421
r? `@jieyouxu`
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`
Make `Parser::parse_expr_cond` public
This allows usage in rustfmt and rustfmt forks.
I'm using this for custom macro formatting, see 30c83df9e1/src/parse/macros/html.rs (L57)
It would be great if this could be upstreamed so I don't need to rely on a fork.
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``
Refactor is_snake_case.
I wondered what the definition of this actually was, and found the original hard to read. I believe this change preserves the original behavior, but is hopefully clearer.
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`
On Unix the limits can be gargantuan anyway so we're pretty
unlikely to hit them, but might still exceed it.
We consult ARG_MAX here to get an estimate.
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.
fix: remove the check of lld not supporting @response-file
In LLVM v9, lld has supported `@response-file.`
LLVM v9 was released on 2019-09-19.
The check was added back to 2018-03-14 (1.26.0) via 04442af18b.
It has been more than five years, and we ship our own lld regardlessly.
This should be happily removed.
See also:
* <bb12396f91>
* <https://reviews.llvm.org/D63024>
atomic intrinsics: clarify which types are supported and (if applicable) what happens with provenance
The provenance semantics match what Miri implements and what the `AtomicPtr` API expects.
Sync Fuchsia target spec with clang Fuchsia driver
This updates the Fuchsia target spec with the [Clang Fuchsia driver], which picks up a few changes:
* Adds `-z start-stop-visibility=hidden` and `-z rel` to the pre link arguments.
* Adds `--execute-only` and `--fix-cortex-a53-843419` for `aarch64-unknown-fuchsia`.
* Enables the equivalent cpu features for `x86-64-v2` for `x86_64-unknown-fuchsia`, which is our minimum supported x86_64 platform according to [RFC-0073].
try-job: x86_64-fuchsia
[Clang Fuchsia driver]: 8374d42186/clang/lib/Driver/ToolChains/Fuchsia.cpp
[RFC-0073]: https://fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0073_x86_64_platform_requirement
Allow more top-down inlining for single-BB callees
This means that things like `<usize as Step>::forward_unchecked` and `<PartialOrd for f32>::le` will inline even if
we've already done a bunch of inlining to find the calls to them.
Fixes#138136
~~Draft as it's built atop #138135, which adds a mir-opt test that's a nice demonstration of this. To see just this change, look at <48f63e3be5>~~ Rebased to be just the inlining change, as the other existing tests show it great.
Don't `alloca` just to look at a discriminant
Today we're making LLVM do a bunch of extra work when you match on trivial stuff like `Option<bool>` or `ControlFlow<u8>`.
This PR changes that so that simple types like `Option<u32>` or `Result<(), Box<Error>>` can stay as `OperandValue::ScalarPair` and we can still read the discriminant from them, rather than needing to write them into memory to have a `PlaceValue` just to get the discriminant out.
Fixes#137503
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 `/* */`.
Fix RISC-V VxWorks LLVM target triples
The targets `riscv32-wrs-vxworks` and `riscv64-wrs-vxworks` uses the plain `$ARCH` LLVM triple, which LLVM normalizes to `$ARCH-unknown-unknown`, we should use `$ARCH-unknown-linux-gnu$ABI` which is consistent with the the other VxWorks targets.
Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](https://github.com/rust-lang/cc-rs/issues/1431) is correct.
Alternative: Pass `$ARCH-unknown-none` in the other VxWorks LLVM triples, I don't know anything about VxWorks, so am unsure which is the most correct option.
CC target maintainer `@biabbas.`
r? jieyouxu
minor interpreter cleanups
- remove the `eval_inline_asm` hook that `@saethlin` added; the usage never materialized and he agreed with removing it
- I tried merging `init_alloc_extra` and `adjust_global_allocation` and it didn't work; leave a comment as to why. Also, make the allocation code path a bit more clear by renaming `init_alloc_extra` to `init_local_allocation`.
r? `@oli-obk`
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.
Add a .bss-like scheme for encoded const allocs
This check if all bytes are zero feel like it should be too slow, and instead we should have a flag that we track, but that seems hard. Let's see how this perfs first.
Also we can probably stash the "it's all zero actually" flag inside one of the other struct members that's already not using an entire byte. This optimization doesn't fire all that often, so it's possible that by sticking it in the varint length field, this PR actually makes rmeta size worse.
