On type errors where the difference is expecting an owned type and getting a reference, if the expression is a `.clone()` call and the type is annotated with `#[derive(Clone)]`, we now explain implicit bounds and suggest manually implementing `Clone`.
```
error[E0308]: mismatched types
--> $DIR/derive-implicit-bound-on-clone.rs:10:5
|
LL | fn clone_me<T, K>(x: &ContainsRc<T, K>) -> ContainsRc<T, K> {
| ---------------- expected `ContainsRc<T, K>` because of return type
LL | x.clone()
| ^^^^^^^^^ expected `ContainsRc<T, K>`, found `&ContainsRc<T, K>`
|
= note: expected struct `ContainsRc<_, _>`
found reference `&ContainsRc<_, _>`
note: `ContainsRc<T, K>` does not implement `Clone`, so `&ContainsRc<T, K>` was cloned instead
--> $DIR/derive-implicit-bound-on-clone.rs:10:5
|
LL | x.clone()
| ^
help: `Clone` is not implemented because the some trait bounds could not be satisfied
--> $DIR/derive-implicit-bound-on-clone.rs:5:19
|
LL | #[derive(Clone)]
| ----- in this derive macro expansion
LL | struct ContainsRc<T, K> {
| ^ ^ derive introduces an implicit unsatisfied trait bound `K: Clone`
| |
| derive introduces an implicit unsatisfied trait bound `T: Clone`
= help: consider manually implementing `Clone` to avoid the implict type parameter bounds
```
```
note: required for `B<C>` to implement `Copy`
--> $DIR/deriving-copyclone.rs:9:10
|
LL | #[derive(Copy, Clone)]
| ^^^^ unsatisfied trait bound introduced in this `derive` macro
LL | struct B<T> {
| - would need to be `Copy`
```
When encountering a bound coming from a derive macro, suggest manual impl of the trait.
Use the span for the specific param when adding bounds in builtin derive macros, so the diagnostic will point at them as well as the derive macro itself.
```
error[E0277]: can't compare `SomeNode` with `SomeNode`
--> f29.rs:24:15
|
24 | accept_eq(&node);
| --------- ^^^^^ no implementation for `SomeNode == SomeNode`
| |
| required by a bound introduced by this call
|
= note: -Ztrack-diagnostics: created at compiler/rustc_trait_selection/src/error_reporting/traits/fulfillment_errors.rs:279:39
= help: the trait `PartialEq` is not implemented for `SomeNode`
note: required for `Id<SomeNode>` to implement `PartialEq`
--> f29.rs:3:10
|
3 | #[derive(PartialEq, Eq)]
| ^^^^^^^^^ unsatisfied trait bound introduced in this `derive` macro
4 | pub struct Id<T>(PhantomData<T>);
| -
= help: consider manually implementing `PartialEq` to avoid undesired bounds
note: required by a bound in `accept_eq`
--> f29.rs:15:23
|
15 | fn accept_eq(_: &impl PartialEq) { }
| ^^^^^^^^^ required by this bound in `accept_eq`
help: consider annotating `SomeNode` with `#[derive(PartialEq)]`
|
13 + #[derive(PartialEq)]
14 | struct SomeNode();
|
```
When encountering a value that has a borrow checker error where the type was previously moved, when suggesting cloning verify that it is not already being derived. If it is, explain why the `derive(Clone)` doesn't apply:
```
note: if `TypedAddress<T>` implemented `Clone`, you could clone the value
--> $DIR/derive-clone-implicit-bound.rs:6:1
|
LL | #[derive(Clone, Copy)]
| ----- derived `Clone` adds implicit bounds on type parameters
LL | pub struct TypedAddress<T>{
| ^^^^^^^^^^^^^^^^^^^^^^^^-^
| | |
| | introduces an implicit `T: Clone` bound
| consider manually implementing `Clone` for this type
...
LL | let old = self.return_value(offset);
| ------ you could clone this value
```
Remove the `dep_node` argument from `try_mark_previous_green`
This removes the `dep_node` argument from `try_mark_previous_green`. I think this makes it clearer that it's unused without debug assertions.
Rename `QueryResult` to `ActiveKeyStatus`
Long ago, this enum was also used to hold the cached result of a query evaluation that had completed successfully, so its name made some sense.
Nowadays, successful query evaluation is represented by an entry in the query's in-memory cache, which is a separate data structure.
So this enum only deals with “active” query keys, i.e. those for which query evaluation has started, but has not yet completed successfully.
---
The split between jobs and results was introduced by:
- https://github.com/rust-lang/rust/pull/50102.
---
There should be no change to compiler behaviour.
typeck_root_def_id: improve doc comment
This was initially written to be exhaustive, but one more type that can only be type-checked with its containing item has since been added, and was not mentioned. So, make it future-proof by mentioning just the one example.
Also, a previous refactor left this less readable.
This was initially written to be exhaustive, but one more type that can only be type-checked with its containing item has since been added, and was not mentioned. So, make it future-proof by mentioning just the one example.
Also, a previous refactor left this less readable.
Re-export `hashbrown::hash_table` from `rustc_data_structures`
We don't always re-export shared dependencies, but for `hashbrown::hash_table` I think it makes sense, for a few reasons:
- The lower-level `HashTable` type is already part of the public API of `rustc_data_structures` via the `ShardedHashMap` type alias, and other compiler crates currently depend on being able to access its internal hash tables.
- The `Cargo.toml` entry for `hashbrown` is non-trivial, making it harder to keep in sync and harder to move between crates as needed.
- [And we currently aren't using `[workspace.dependencies]` for various reasons.](https://github.com/rust-lang/rust/pull/146113)
- It's fine for other compiler crates to use `hash_table` specifically (with care), but they probably shouldn't be using the higher-level `hashbrown::HashMap` and `hashbrown::HashSet` types directly, because they should prefer the various map/set aliases defined by `rustc_data_structures`. Re-exporting only `hash_table` helps to discourage use of those other types.
There should be no change to compiler behaviour.
Feature-gate `mut ref` patterns in struct pattern field shorthand
Tracking issue for `mut_ref` (and other parts of Match Ergonomics 2024): https://github.com/rust-lang/rust/issues/123076https://github.com/rust-lang/rust/pull/123080 introduced `mut ref`[^1] patterns (for by-reference bindings where the binding itself is mutable), feature-gated behind the `mut_ref` feature, except for in struct pattern shorthand, where the feature gating was missing. Thus, `mut ref` patterns in struct pattern shorthand has been unintentionally stable for ~18 months (since 1.79.0 ([compiler explorer](https://rust.godbolt.org/z/4WTrvhboT))).
This PR adds feature-gating for `mut ref` patterns in struct pattern shorthand. Since this is reverting an accidental stabilization, this probably needs a crater run and a T-lang FCP?
Some alternative possibilities:
* Do nothing (let the inconsistency exist until `feature(mut_ref)` is stabilized)
* Document the existing behavior
* Do a FCW instead of fully feature-gating
* Stabilize `feature(mut_ref)`
CC https://github.com/rust-lang/rust/pull/123080#issuecomment-3746793632
CC @Nadrieril
[^1]: everything in this description also applies analogously to `mut ref mut` patterns.
GVN: Elide more intermediate transmutes
We already skipped intermediate steps like `u32` or `i32` that support any (initialized) value.
This extends that to also allow skipping intermediate steps whose values are a superset of either the source or destination type. Most importantly, that means that `usize` → `NonZeroUsize` → `ptr::Alignment` and `ptr::Alignment` → `NonZeroUsize` → `usize` can skip the middle because `NonZeroUsize` is a superset of `Alignment`.
Then `Alignment::as_usize` is updated to take advantage of that and let us remove some more locals in a few places.
r? cjgillot
Fix ICE when parsing frontmatter without newline
Fixesrust-lang/rust#151882
we can not add a normal test case for it:
- no newline at the end of file, we can bypass this with change test file name with `ignore-tidy`
- multiple errors in stderr, this conflicts with the previous bypass, seems we can not add multiple error annotations in one line
anyway, I added a `run-make` test for it.
Remove unused method `DroplessArena::contains_slice`
- This method was added for https://github.com/rust-lang/rust/pull/120128.
- It became unused in https://github.com/rust-lang/rust/pull/136593.
Checking whether a particular slice is within an arena is a bit of a sketchy operation, so if there's no pressing need for it then I think we're better off not having it lying around.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#151262 (Introducing clap on tidy)
- rust-lang/rust#151896 (Revert enabling `outline-atomics` on various platforms)
- rust-lang/rust#151849 (refactor: remove `Ty::pinned_ref` in favor of `Ty::maybe_pinned_ref`)
- rust-lang/rust#151892 (Document enum types used as values for E0423)
Document enum types used as values for E0423
### Problem
The E0423 error explanation did not include an example for enum types being used
as values, which is a common source of confusion for users.
For example, the following code:
```rust
fn main() {
let x = Option::<i32>;
}
```
refactor: remove `Ty::pinned_ref` in favor of `Ty::maybe_pinned_ref`
Also returns the `Region` of the reference type in `Ty::maybe_pinned_Ref`.
Part of rust-lang/rust#149130.
r? jackh726
resolve: Remove `force` parameter from `resolve_ident_in_scope`
`force == true` is used for turning `Determinacy::Undetermined` into `Determinacy::Determined` during error recovery.
It's only needed in two places:
- `resolve_macro_or_delegation_path` - the normal case
- `resolve_path_with_ribs` - obscure case, only when resolving visibilities and only for improving diagnostics in `tests\ui\resolve\visibility-indeterminate.rs`, I'm not actually sure if we should keep it
In other cases `Determinacy::Undetermined` is just ignored or can be propagated.
constify `Iterator`, take IV
Like its predecessors (rust-lang/rust#92433, rust-lang/rust#102225, rust-lang/rust#106541), this PR allows one to make `Iterator` implementations `const`, and thus enables the ability to have `for` loops in `const` contexts. I've also included constifying `Option as IntoIterator`, `option::IntoIter as Iterator` as a minimal dogfooding example.
But unlike its predecessors, it uses a new attribute (not unsound anymore!) that prevents any `Iterator` extension methods from being called. This is intentionally made minimal for an initial approval, the fun stuff like `.fold`, `Range as Iterator` could be done later.
cc @rust-lang/wg-const-eval, cc @oli-obk to review the compiler parts
cc rust-lang/rust#92476
Remove redundant `IntoQueryParam` calls from query plumbing
In each of these contexts, the key must have already been converted by the caller, since otherwise it wouldn't have type `Cache::Key`.
There should be no change to compiler behaviour.
Esteban Küber