rewrite error handling for unresolved inference vars #89862

lcnr · 2021-10-13T21:43:24Z

Pretty much completely rewrites fn emit_inference_failure_err.

This new setup should hopefully be easier to extend and is already a lot better when looking for generic arguments.
Because this is a rewrite there are still some parts which are lacking, these are tracked in #94483 and will be fixed in later PRs.

r? @estebank @petrochenkov

estebank · 2021-10-14T09:39:43Z

src/test/ui/suggestions/fn-needing-specified-return-type-param.stderr

+error[E0282]: type annotations needed
  --> $DIR/fn-needing-specified-return-type-param.rs:3:13
   |
 LL |     let _ = f;
-   |         -   ^ cannot infer type for type parameter `A` declared on the function `f`
-   |         |
-   |         consider giving this pattern the explicit type `fn() -> A`, where the type parameter `A` is specified
+   |             ^ cannot infer type of the type parameter `A` declared on the function `f`
+   |
+help: consider specifying the generic argument
+   |
+LL |     let _ = f::<A>;
+   |              +++++


I'm happy with most of the results, but we do lose the special casing of assignments, where the stylistic solution is to give the binding a type, instead of leveraging the turbofish.

That shouldn't be a big problem, and we could remove a bunch of suggestion code by only relying on the new logic, but idealy it'd be nice if we could keep that.

I'll take a closer look at the logic later.

yeah, prioritizing assignments seems like the right choice, I am a bit torn however, because for
let x = returns_complex_type() i would prefer to suggest let x = returns_complex_type::<T>() instead of let x: SomeComplex<Type<T>, T>> = returns_complex_type(). Maybe adding weights to each option, and prioritizing locals and closure parameters over generic arguments which are prioritized over closure return types or sth 🤔

src/test/ui/issues/issue-12187-2.stderr

estebank · 2021-10-14T09:45:06Z

src/test/ui/inference/cannot-infer-closure.stderr

+help: consider specifying the generic arguments
   |
-LL |     let x = |a: (), b: ()| -> Result<(), _> {
-   |                            ++++++++++++++++
+LL |         Ok::<T, E>(b)
+   |           ++++++++


This is another case of what I was mentioning: The current suggestion is closer to what I'd want to recommend users do, and T is already figured out (thanks to b), the E is the one that needs clarification.

I quite dislike explicitly mentioning closure return types, so I would use Ok::<(); u32> here.

I considered (at least partially) using the inferred generic args for the suggestion, but i don't think we always want to do this because sometimes the inferred types can be quite large. There's definitely quite a few possible improvements here however ^^ took me a while to understand how this code works and think that there are some pretty big wins here.

With the changes I'm making in #89427, we might be able to be explicit about the potentially usable types because we'll know all the impls that apply. And we already know that E is the problematic one, so we can suggest Ok::<_, SomeE>. Having said that, that doesn't need to be addressed yet, I think.

JohnCSimon · 2022-01-30T04:01:09Z

ping from triage:
@lcnr what is the status of this PR?

lcnr · 2022-01-31T07:11:27Z

it's blocked on me taking a full day to work on this, should happen at some point during february 😆

src/test/ui/issues/issue-16966.stderr

src/test/ui/issues/issue-25368.stderr

src/test/ui/issues/issue-51116.stderr

src/test/ui/issues/issue-69455.stderr

src/test/ui/suggestions/suggest-closure-return-type-1.stderr

bors · 2022-06-03T03:27:32Z

⌛ Testing commit b343a46 with merge c5fda9cb3b4a0952fd3db63a3552dde0a1cba9b8...

bors · 2022-06-03T03:36:43Z

💔 Test failed - checks-actions

rust-log-analyzer · 2022-06-03T04:24:28Z

The job x86_64-gnu-nopt failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

lcnr · 2022-06-03T08:10:32Z

@bors retry

bors · 2022-06-03T12:37:20Z

⌛ Testing commit b343a46 with merge e40d5e8...

bors · 2022-06-03T15:26:00Z

☀️ Test successful - checks-actions
Approved by: estebank
Pushing e40d5e8 to master...

rust-timer · 2022-06-03T16:43:20Z

Finished benchmarking commit (e40d5e8): comparison url.

Instruction count

Primary benchmarks: 😿 relevant regressions found
Secondary benchmarks: 😿 relevant regressions found

	mean¹	max	count²
Regressions 😿 (primary)	0.2%	0.3%	7
Regressions 😿 (secondary)	0.4%	1.0%	23
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	0.2%	0.3%	7

Max RSS (memory usage)

Results

Primary benchmarks: 😿 relevant regressions found
Secondary benchmarks: no relevant changes found

	mean¹	max	count²
Regressions 😿 (primary)	3.6%	4.4%	2
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	3.6%	4.4%	2

Cycles

This benchmark run did not return any relevant results for this metric.

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-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

the arithmetic mean of the percent change ↩ ↩²
number of relevant changes ↩ ↩²

rylev · 2022-06-07T14:13:44Z

@lcnr @estebank looks like this caused a perf regression. It's minor enough in primary benchmarks, but still worth looking into.

I ran cache grind diff and saw that ObligationForest::process_obligations is getting called a lot more. I'm very unfamiliar with trait resolution, so I'm unsure if this is a red herring or not. In any case, here is the full diff.

lcnr · 2022-06-08T07:54:27Z

compiler/rustc_middle/src/hir/map/mod.rs

+            Node::PathSegment(seg) => {
+                let ident_span = seg.ident.span;
+                ident_span
+                    .with_hi(seg.args.map_or_else(|| ident_span.hi(), |args| args.span_ext.hi()))
+            }


I would guess that the only thing which may impact the amount of process_obligations would be this.

We now use a different span from seg.ident which may mean that we don't dedup obligations as readily as they now have different spans? Can try to take a deeper look at this in the near future

rust-highfive assigned estebank Oct 13, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 13, 2021

This comment has been minimized.

Sign in to view

lcnr force-pushed the path-generics-diagnostics branch from 5c814f9 to 8d53486 Compare October 14, 2021 09:31

estebank reviewed Oct 14, 2021

View reviewed changes

src/test/ui/issues/issue-12187-2.stderr Outdated Show resolved Hide resolved

estebank reviewed Oct 14, 2021

View reviewed changes

apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 14, 2021

This comment has been minimized.

Sign in to view

lcnr force-pushed the path-generics-diagnostics branch 4 times, most recently from 78d5028 to d42c7ab Compare October 16, 2021 09:27

JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 31, 2021

JohnCSimon added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 5, 2021

pnkfelix added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 6, 2022

JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 30, 2022

lcnr mentioned this pull request Feb 14, 2022

pre #89862 cleanup #93990

Merged

lcnr force-pushed the path-generics-diagnostics branch from fd6f822 to 411d565 Compare February 15, 2022 13:31