the internal representation of `std::sync::Mutex` depends on the compilation target. due to this,
the compiler produces different number of errors for UI test
`issue-17431-6.rs` depending on the compilation target.
for example, when compiling the UI test to an `*-apple-*` or `*-qnx7*` target, the "cycle detected"
error is not reported
``` console
$ cat src/lib.rs
use std::sync::Mutex;
enum Foo {
X(Mutex<Option<Foo>>),
}
impl Foo {
fn bar(self) {}
}
fn main() {}
$ cargo check --target x86_64-apple-ios 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
```
whereas rustc produces two errors for other OSes, like Linux, which is what the UI test expects
``` console
$ cargo check --target x86_64-unknown-linux-gnu 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
error[E0391]: cycle detected when computing when `Foo` needs drop
```
this commit replaces the problematic `Mutex` with `UnsafeCell`, which has the same internal
representation regardless of the compilation target. with that change, rustc reports two errors for
all compilation targets.
``` console
$ cat src/lib.rs
use std::cell::UnsafeCell;
enum Foo {
X(UnsafeCell<Option<Foo>>),
}
impl Foo {
fn bar(self) {}
}
fn main() {}
$ cargo check --target x86_64-apple-ios 2>&1 | rg '^error\['
error[E0072]: recursive type `Foo` has infinite size
error[E0391]: cycle detected when computing when `Foo` needs drop
```
with this change, we can remove the `ignore-apple` directive as the UI test now also passes on apple
targets.
[AIX] Add crate "unwind" to link with libunwind
The Rust on IBM AIX uses LLVM's `libunwind`. Since crate `unwind` is a dependency of crate `std` and `#![no_std]` is specified in the test case, `libunwind` is not included in the link command by default. As a result, the test case fails to link with the error "Undefined symbol: ._Unwind_Resume" on AIX. This PR explicitly adds crate `unwind` for AIX, along with feature `panic_unwind`, which is required to include the `unwind` crate.
borrowck diagnostics: suggest borrowing function inputs in generic positions
# Summary
This generalizes borrowck's existing suggestions to borrow instead of moving when passing by-value to a function that's generic in that input. Previously, this was special-cased to `AsRef`/`Borrow`-like traits and `Fn`-like traits. This PR changes it to test if, for a moved place with type `T`, that the callee's signature and clauses don't break if you substitute in `&T` or `&mut T`. For instance, it now works with `Read`/`Write`-like traits.
Fixes https://github.com/rust-lang/rust/issues/131413
# Incidental changes
- No longer spuriously suggests mutable borrows of closures in some situations (see e.g. the tests in [tests/ui/closures/2229_closure_analysis/](https://github.com/rust-lang/rust/compare/master...dianne:rust:suggest-borrow-generic?expand=1#diff-8dfb200c559f0995d0f2ffa2f23bc6f8041b263e264e5c329a1f4171769787c0)).
- No longer suggests cloning closures that implement `Fn`, since they can be borrowed (see e.g. [tests/ui/moves/borrow-closures-instead-of-move.stderr](https://github.com/rust-lang/rust/compare/master...dianne:rust:suggest-borrow-generic?expand=1#diff-5db268aac405eec56d099a72d8b58ac46dab523cf013e29008104840168577fb)).
This keeps the behavior to suppress suggestions of `fn_once.clone()()`. I think it might make sense to suggest it with a "but this might not be your desired behavior" caveat, as is done when something is used after being consumed as the receiver for a method call. That's probably out of the scope of this PR though.
# Limitations and possible improvements
- This doesn't work for receivers of method calls. This is a small change, and I have it implemented locally, but I'm not sure it's useful on its own. In most cases I've found borrowing the receiver would change the call's output type (see below). In other cases (e.g. `Iterator::sum`), borrowing the receiver isn't useful since it's consumed.
- This doesn't work when it would change the call's output type. In general, I figure inserting references into the output type is an unwanted change. However, this also means it doesn't work in cases where the new output type would be effectively the same as the old one. For example, from the rand crate, the iterator returned by [`Rng::sample_iter`](https://docs.rs/rand/latest/rand/trait.Rng.html#method.sample_iter) is effectively the same (modulo regions) whether you borrow or consume the receiver `Rng`, so common usage involves borrowing it. I'm not sure whether the best approach is to add a more complex check of approximate equivalence, to forego checking the call's output type and give spurious suggestions, or to leave it as-is.
- This doesn't work when it would change the call's other input types. Instead, it could suggest borrowing any others that have the same parameter type (but only when suggesting shared borrows). I think this would be a pretty easy change, but I don't think it's very useful so long as the normalized output type can't change.
I'm happy to implement any of these (or other potential improvements to this), but I'm not sure which are common enough patterns to justify the added complexity. Please let me know if any sound worthwhile.
PassWrapper: disable UseOdrIndicator for Asan Win32
As described in https://reviews.llvm.org/D137227 UseOdrIndicator should be disabled on Windows since link.exe does not support duplicate weak definitions.
Fixes https://github.com/rust-lang/rust/issues/124390.
Credits also belong to `@1c3t3a` who worked with me on this.
We are currently testing this on a Windows machine.
Handle infer vars in anon consts on stable
Fixes#132955
Diagnostics will sometimes try to replace generic parameters with inference variables in failing goals. This means that if we have some failing goal with an array repeat expr count anon const in it, we will wind up with some `ty::ConstKind::Unevaluated(anon_const_def, [?x])` during diagnostics which will then ICE if we do not handle inference variables correctly on stable when normalizing type system consts.
r? ```@compiler-errors```
This subsumes the suggestions to borrow arguments with `AsRef`/`Borrow` bounds and those to borrow
arguments with `Fn` and `FnMut` bounds. It works for other traits implemented on references as well,
such as `std::io::Read`, `std::io::Write`, and `core::fmt::Write`.
Incidentally, by making the logic for suggesting borrowing closures general, this removes some
spurious suggestions to mutably borrow `FnMut` closures in assignments, as well as an unhelpful
suggestion to add a `Clone` constraint to an `impl Fn` argument.
This is setup for unifing the logic for suggestions to borrow arguments in generic positions.
As of this commit, it's still special cases for `AsRef`/`Borrow`-like traits and `Fn`-like traits.
This also downgrades its applicability to MaybeIncorrect. Its suggestion can result in ill-typed
code when the type parameter it suggests providing a different generic argument for appears
elsewhere in the callee's signature or predicates.
As described here UseOdrIndicator should be disabled on Windows
since link.exe does not support duplicate weak definitions
(https://reviews.llvm.org/D137227).
Co-Authored-By: Bastian Kersting <bkersting@google.com>
Make precise capturing suggestion machine-applicable only if it has no APITs
cc https://github.com/rust-lang/rust/issues/132932
The only case where this suggestion is not machine-applicable is when we suggest turning arg-position impl trait into type parameters, which may expose type parameters that were not turbofishable before.
Proper support for cross-crate recursive const stability checks
~~Stacked on top of https://github.com/rust-lang/rust/pull/132492; only the last three commits are new.~~
In a crate without `staged_api` but with `-Zforce-unstable-if-unmarked`, we now subject all functions marked with `#[rustc_const_stable_indirect]` to recursive const stability checks. We require an opt-in so that by default, a crate can be built with `-Zforce-unstable-if-unmarked` and use nightly features as usual. This property is recorded in the crate metadata so when a `staged_api` crate calls such a function, it sees the `#[rustc_const_stable_indirect]` and allows it to be exposed on stable. This, finally, will let us expose `const fn` from hashbrown on stable.
The second commit makes const stability more like regular stability: via `check_missing_const_stability`, we ensure that all publicly reachable functions have a const stability attribute -- both in `staged_api` crates and `-Zforce-unstable-if-unmarked` crates. To achieve this, we move around the stability computation so that const stability is computed after regular stability is done. This lets us access the final result of the regular stability computation, which we use so that `const fn` can inherit the regular stability (but only if that is "unstable"). Fortunately, this lets us get rid of an `Option` in `ConstStability`.
This is the last PR that I have planned in this series.
r? `@compiler-errors`
Make sure to ignore elided lifetimes when pointing at args for fulfillment errors
See the comment I left in the code.
---
If we have something like:
```
fn foo<'a, T: 'a + BoundThatIsNotSatisfied>() {}
```
And the user turbofishes just the type args:
```
foo::<()>();
```
Then if we try pointing at `()` (i.e. the type argument for `T`), we don't actually consider the possibility that the lifetimes may have been left out of the turbofish. We try indexing incorrectly into the HIR args, and bail on the suggestion.
Consolidate type system const evaluation under `traits::evaluate_const`
Part of #130704Fixes#128232Fixes#118545
Removes `ty::Const::{normalize_internal, eval_valtree}` and `InferCtxt::(try_)const_eval_resolve`, consolidating the associated logic into `evaluate_const` in `rustc_trait_selection`. This results in an API for `ty::Const` that is free of any normalization/evaluation functions that would be incorrect to use under `min_generic_const_args`/`associated_const_equality`/`generic_const_exprs` or, more generally, that would be incorrect to use in the presence of generic type system constants.
Moving this logic to `rustc_trait_selection` and out of `rustc_middle` is also a pre-requisite for ensuring that we do not evaluate constants whose where clauses do not hold.
From this point it should be relatively simple (hah) to implement more complex normalization of type system constants such as: checking wf'ness before invoking CTFE machinery, or being able to normalize const aliases that still refer to generic parameters.
r? `@compiler-errors`
Feature gate yield expressions not in 2024
This changes it so that yield expressions are no longer allowed in the 2024 edition without a feature gate. We are currently only reserving the `gen` keyword in the 2024 edition, and not allowing anything else to be implicitly enabled by the edition.
In practice this doesn't have a significant difference since yield expressions can't really be used outside of coroutines or gen blocks, which have their own feature gates. However, it does affect what is accepted pre-expansion, and I would feel more comfortable not allowing yield expressions.
I believe the stabilization process for gen blocks or coroutines will not need to check the edition here, so this shouldn't ever be needed.
Remove attributes from generics in built-in derive macros
Related issue #132561
Removes all attributes from generics in the expanded implementations of built-in derive macros.
Make sure that we suggest turbofishing the right type arg for never suggestion
I had a bug where rust would suggest the wrong arg to turbofish `()` if there were any early-bound lifetimes...
r? WaffleLapkin
Don't use `maybe_unwrap_block` when checking for macro calls in a block expr
Fixes#131915
Using `maybe_unwrap_block` to determine if we are looking at a `{ mac_call!{} }` will fail sometimes as `mac_call!{}` could be a `StmtKind::MacCall` not a `StmtKind::Expr`. This caused the def collector to think that `{ mac_call!{} }` was a non-trivial const argument and create a definition for it even though it should not.
r? `@compiler-errors` cc `@camelid`
Provide placeholder generics for traits in "no method found for type parameter" suggestions
In the diagnostics for the error ``no method named `method` found for type parameter `T` in the current scope [E0599]``, the compiler will suggest adding bounds on `T` for traits that define a method named `method`. However, these suggestions didn't include any generic arguments, so applying them would result in a `missing generics for trait` or `missing lifetime specifier` error. This PR adds placeholder arguments to the suggestion in such cases. Specifically, I tried to base the placeholders off of what's done in suggestions for when generics are missing or too few are provided:
- The placeholder for a parameter without a default is the name of the parameter.
- Placeholders are not provided for parameters with defaults.
Placeholder arguments are enclosed in `/*` and `*/`, and the applicability of the suggestion is downgraded to `Applicability::HasPlaceholders` if any placeholders are provided.
Fixes#132407
Ensure that tail expr receive lifetime extension
cc `@jieyouxu` `@traviscross`
It just came to me that we should add a test to make sure that we honor the contract from the temporary lifetime rule #121346. We should continue to implement this rule in Edition 2021 onward and shorter tail expression lifetime should not override it.
This is a small PR to improve our assurance and establish a stronger contract.
Tracked by rust-lang/rust#123739
Stabilize WebAssembly `multivalue`, `reference-types`, and `tail-call` target features
For the `multivalue` and `reference-types` features this commit is
similar to https://github.com/rust-lang/rust/pull/117457 in that it's stabilizing target features specific to
WebAssembly targets. The previous PR left out these two features because
they weren't expected to change much about compiled code so it was
unclear what the rationale was. It has [since been discovered][blog]
that `reference-types` can be useful as it changes the binary format of
the `call_indirect` instruction. Additionally [on Zulip][zulip] there's
a use case of detecting these features at compile time and generating a
compile error to better warn users about features not supported on
engines.
This PR then additionally adds the `tail-call` feature which corresponds
to the [tail-call] proposal to WebAssembly. This feature advanced to
"phase 4" in the WebAssembly CG awhile back and has been supported in
LLVM for quite some time now. Engines are finishing up implementations
or have already shipped implementations, so while this is a bit of a
late addition to Rust itself it reflects the current status of
WebAssembly's state of the feature.
A test has been added here not only for these features but other
WebAssembly features as well to showcase that they're usable without
feature gates in stable Rust.
[blog]: https://blog.rust-lang.org/2024/09/24/webassembly-targets-change-in-default-target-features.html
[zulip]: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/wasm32.20reference-types.20.2F.20multivalue.20in.201.2E82-beta.20not.20enabled/near/473893987
[tail-call]: https://github.com/webassembly/tail-call
Prefer `pub(super)` in `unreachable_pub` lint suggestion
This PR updates the `unreachable_pub` lint suggestion to prefer `pub(super)` instead of `pub(crate)` when possible.
cc `@petrochenkov`
r? `@nnethercote`
Stabilize Arm64EC inline assembly
This stabilizes inline assembly for Arm64EC ("Emulation Compatible").
Corresponding reference PR: https://github.com/rust-lang/reference/pull/1653
---
From the requirements of stabilization mentioned in https://github.com/rust-lang/rust/issues/93335
> Each architecture needs to be reviewed before stabilization:
> - It must have clobber_abi.
Done in https://github.com/rust-lang/rust/pull/131332.
> - It must be possible to clobber every register that is normally clobbered by a function call.
This is possible from the time of the initial implementation.
> - Generally review that the exposed register classes make sense.
The registers available in this target are a subset of those available in the AArch64 inline assembly which is already stable.
The following registers cannot be used in Arm64EC compared to AArch64:
- `x13`, `x14`, `x23`, `x24`, `x28` (register class: `reg`)
- `v[16-31]` (register class: `vreg`)
- `p[0-15]`, `ffr` (clobber-only register class `preg`)
These are disallowed by the ABI (see also [abi docs](https://learn.microsoft.com/en-us/cpp/build/arm64ec-windows-abi-conventions?view=msvc-170#register-mapping) for `reg`/`vreg` and https://github.com/rust-lang/rust/pull/131332#issuecomment-2401189142 for `preg`).
Although not listed in the above requirements, preserves_flags is also implemented and the same as AArch64.
---
cc `@dpaoliello`
r? `@Amanieu`
`@rustbot` label O-windows O-AArch64 +A-inline-assembly +T-lang -T-compiler +needs-fcp
For the `multivalue` and `reference-types` features this commit is
similar to #117457 in that it's stabilizing target features specific to
WebAssembly targets. The previous PR left out these two features because
they weren't expected to change much about compiled code so it was
unclear what the rationale was. It has [since been discovered][blog]
that `reference-types` can be useful as it changes the binary format of
the `call_indirect` instruction. Additionally [on Zulip][zulip] there's
a use case of detecting these features at compile time and generating a
compile error to better warn users about features not supported on
engines.
This PR then additionally adds the `tail-call` feature which corresponds
to the [tail-call] proposal to WebAssembly. This feature advanced to
"phase 4" in the WebAssembly CG awhile back and has been supported in
LLVM for quite some time now. Engines are finishing up implementations
or have already shipped implementations, so while this is a bit of a
late addition to Rust itself it reflects the current status of
WebAssembly's state of the feature.
A test has been added here not only for these features but other
WebAssembly features as well to showcase that they're usable without
feature gates in stable Rust.
[blog]: https://blog.rust-lang.org/2024/09/24/webassembly-targets-change-in-default-target-features.html
[zulip]: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/wasm32.20reference-types.20.2F.20multivalue.20in.201.2E82-beta.20not.20enabled/near/473893987
[tail-call]: https://github.com/webassembly/tail-call
