Uh oh!
There was an error while loading. Please reload this page.
Rollup of 7 pull requests - #95662
Conversation
When encountering an unsatisfied trait bound, if there are no other
suggestions, mention all the types that *do* implement that trait:
```
error[E0277]: the trait bound `f32: Foo` is not satisfied
--> $DIR/impl_wf.rs:22:6
|
LL | impl Baz<f32> for f32 { }
| ^^^^^^^^ the trait `Foo` is not implemented for `f32`
|
= help: the following other types implement trait `Foo`:
Option<T>
i32
str
note: required by a bound in `Baz`
--> $DIR/impl_wf.rs:18:31
|
LL | trait Baz<U: ?Sized> where U: Foo { }
| ^^^ required by this bound in `Baz`
```
Mention implementers of traits in `ImplObligation`s.
Do not mention other `impl`s for closures, ranges and `?`.…ied-trait, r=davidtwco
Mention implementers of unsatisfied trait
When encountering an unsatisfied trait bound, if there are no other
suggestions, mention all the types that *do* implement that trait:
```
error[E0277]: the trait bound `f32: Foo` is not satisfied
--> $DIR/impl_wf.rs:22:6
|
LL | impl Baz<f32> for f32 { }
| ^^^^^^^^ the trait `Foo` is not implemented for `f32`
|
= help: the trait `Foo` is implemented for `i32`
note: required by a bound in `Baz`
--> $DIR/impl_wf.rs:18:31
|
LL | trait Baz<U: ?Sized> where U: Foo { }
| ^^^ required by this bound in `Baz`
```
```
error[E0277]: the trait bound `u32: Foo` is not satisfied
--> $DIR/associated-types-path-2.rs:29:5
|
LL | f1(2u32, 4u32);
| ^^ the trait `Foo` is not implemented for `u32`
|
= help: the trait `Foo` is implemented for `i32`
note: required by a bound in `f1`
--> $DIR/associated-types-path-2.rs:13:14
|
LL | pub fn f1<T: Foo>(a: T, x: T::A) {}
| ^^^ required by this bound in `f1`
```
Suggest dereferencing in more cases.
Fixrust-lang#87437, fixrust-lang#90970.explicitly distinguish pointer::addr and pointer::expose_addr ``@bgeron`` pointed out that the current docs promise that `ptr.addr()` and `ptr as usize` are equivalent. I don't think that is a promise we want to make. (Conceptually, `ptr as usize` might 'escape' the provenance to enable future `usize as ptr` casts, but `ptr.addr()` dertainly does not do that.) So I propose we word the docs a bit more carefully here. ``@Gankra`` what do you think?
Fix late-bound ICE in `dyn` return type suggestion
This fixes the root-cause of the attached issues -- the root problem is that we're using the return type from a signature with late-bound instead of early-bound regions. The change on line 1087 (`let Some(liberated_sig) = typeck_results.liberated_fn_sigs().get(fn_hir_id) else { return false; };`) makes sure we're grabbing the _right_ return type for this suggestion to check the `dyn` predicates with.
Fixesrust-lang#91801Fixesrust-lang#91803
This fix also includes some drive-by changes, specifically:
1. Don't suggest boxing when we have `-> dyn Trait` and are already returning `Box<T>` where `T: Trait` (before we always boxed the value).
2. Suggestion applies even when the return type is a type alias (e.g. `type Foo = dyn Trait`). This does cause the suggestion to expand to the aliased type, but I think it's still beneficial.
3. Split up the multipart suggestion because there's a 6-line max in the printed output...
I am open to splitting out the above changes, if we just want to fix the ICE first.
cc: ```@terrarier2111``` and rust-lang#92289interpret: remove MemoryExtra in favor of giving access to the Machine The Miri PR for this is upcoming. r? ``@oli-obk``
…Jung Update `NonNull` pointer provenance methods' documentation - Add links to equivalent methods on raw pointers
…locks, r=davidtwco Refactor: remove unnecessary nested blocks
`CandidateSource::XCandidate` -> `CandidateSource::X`
Dylan-DPC
commented
Apr 4, 2022
@bors r+ rollup=never p=5 |
bors
commented
Apr 4, 2022
📌 Commit b3c3eda has been approved by |
bors
commented
Apr 5, 2022
⌛ Testing commit b3c3eda with merge c4b0e69efdf3ee0b46e722e8353a4daa83045899... |
bors
commented
Apr 5, 2022
bors
commented
Apr 5, 2022
☀️ Test successful - checks-actions |
rust-timer
commented
Apr 5, 2022
Finished benchmarking commit (a22cf2a): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
rylev
commented
Apr 5, 2022
@Dylan-DPC this unfortunately causes some pretty concerning regression in real world crates (an average of 0.8% regression across 20 different impacted test cases). I ran cachegrind and it seems that Here's what I ran locally from my rustc-perf checkout: I got the following output: https://gist.github.com/rylev/50efc253c7538ee6125b01357dbe2196 |
It doesn't feel like #91873 would cause that (for code that compiles successfully), but I can't rule it out. Edit: looking at #95603 it seems even less likely (there're multiple predicates being checked, but they only happen in suggestion code and they already existed). Edit 2: having said that, I am not surprised that it'd be Diesel that got affected by more predicates being registered :) |
compiler-errors
commented
Apr 5, 2022
Same for #95603, it should only affect code paths that end in errors... |
estebank
commented
Apr 5, 2022
@rylev can we run perf on the merged PRs directly so that we don't have to informed-guess that much? |
compiler-errors
commented
Apr 5, 2022
@estebank: since this is merged, I will put up a perf revert experiment for our two PRs. If they show a performance gain, then I think we can continue to investigate. |
Dylan-DPC
commented
Apr 5, 2022
@compiler-errors i'm already working on reverting #91873 |
compiler-errors
commented
Apr 5, 2022
Agh, just committed a branch for it. |
rylev
commented
Apr 5, 2022
@estebank as an FYI we do have some experimental support for automatically reverting rollup PRs and running perf on them, but it's unfortunately pretty buggy. |
estebank
commented
Apr 8, 2022
So neither revert PR yielded useful info? |
It seems not 🙁. None of the other PRs really make sense. The only other ones that touch compiler code are #95642 (which refactors an enum's variant names), #95620 (which touches const eval), and #95631 (which refactors some nested if/let blocks to use if let && if let syntax). Given it seems that the main offended is in trait selection, none of the remaining candidates seem to make much sense.... (FYI: there was discussion in Zulip and a lot of head scratching) |
Successful merges:
dynreturn type suggestion #95603 (Fix late-bound ICE indynreturn type suggestion)NonNullpointer provenance methods' documentation #95630 (UpdateNonNullpointer provenance methods' documentation)CandidateSource::XCandidate->CandidateSource::X#95642 (CandidateSource::XCandidate->CandidateSource::X)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup