Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework "point at arg" suggestions to be more accurate #100654

Merged
merged 16 commits into from
Aug 22, 2022

Conversation

compiler-errors
Copy link
Member

@compiler-errors compiler-errors commented Aug 16, 2022

Fixes #100560

Introduce a new set of ObligationCauseCodes which have additional bookeeping for what expression caused the obligation, and which predicate caused the obligation. This allows us to look at the unsubstituted signature to find out which parameter or generic type argument caused an obligaton to fail.

This means that (in most cases) we significantly improve the likelihood of pointing out the right argument that causes a fulfillment error. Also, since this logic isn't happening in just the select_where_possible_and_mutate_fulfillment() calls in the argument checking code, but instead during all trait selection in FnCtxt, we are also able to point out the correct argument even if inference means that we don't know whether an obligation has failed until well after a call expression has been checked.

r? @ghost

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Aug 16, 2022
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@compiler-errors
Copy link
Member Author

compiler-errors commented Aug 17, 2022

I think this is ready for review. I am happy to talk over zulip or meet with anyone to discuss the main changes in this PR if interested.

I am also happy to explain any cases where diagnostics have changed, to help weigh the benefits over the shortcomings over this PR. In general, though, I think this is a major improvement over the old logic.

r? diagnostics

@compiler-errors compiler-errors marked this pull request as ready for review August 17, 2022 16:22
@compiler-errors compiler-errors added the A-diagnostics Area: Messages for errors, warnings, and lints label Aug 17, 2022
Copy link
Contributor

@estebank estebank left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to finish looking at checks.rs, but I'm comfortable landing as is so far.

compiler/rustc_middle/src/ty/generics.rs Show resolved Hide resolved
) =
(self.tcx.sess.source_map().span_to_snippet(span), obligation.cause.code())
} else if let Ok(snippet) = &self.tcx.sess.source_map().span_to_snippet(span)
&& let ObligationCauseCode::BindingObligation(def_id, _) | ObligationCauseCode::ExprBindingObligation(def_id, ..)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeing the proliferation of these kind of checks, we might want to start adding methods to the ObligationCauseCode to deduplicate them.

Comment on lines 679 to 680
let Some(arg_ty) = typeck_results.node_type_opt(*arg_hir_id)
else { return false };
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC there's a separate more appropriate method along the lines of resolved_node_type_opt. I believe this method gives you the type before inference. It's still useful, but not maximally so. (Unless I'm wrong and I'm misremembering things.)

Copy link
Member Author

@compiler-errors compiler-errors Aug 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you mean expr_ty_adjusted?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes!

Comment on lines +7 to +14
| _____|_____________within this `[closure@$DIR/no-send-res-ports.rs:25:19: 25:25]`
| | |
| | required by a bound introduced by this call
LL | |
LL | | let y = x;
LL | | println!("{:?}", y);
LL | | });
| |_____^ `Rc<()>` cannot be sent between threads safely
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should special case closures like we do for the within this to customize the output here.

|
LL | f_unpin(static || { yield; });
| ^^^^^^^ the trait `Unpin` is not implemented for `[static generator@$DIR/issue-84973-blacklist.rs:17:13: 17:22]`
| ------- ^^^^^^^^^^^^^^^^^^^^ the trait `Unpin` is not implemented for `[static generator@$DIR/issue-84973-blacklist.rs:17:13: 17:22]`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized that in cases where the closure would be the only label, and it's pointing at the closure itself, we can customize the output and refer to "this closure" instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a bit difficult since I'm walking over the unsubstituted predicate here. I'm gonna leave that as a follow-up, since it's not technically a regression I think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, yeah, this was more of a general observation, not part of the review.

| ------------ ^^^^^ expected an `FnMut<(char,)>` closure, found `u8`
| |
| required by a bound introduced by this call
| ^^^^^^^^^^^^ expected an `FnMut<(char,)>` closure, found `u8`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know why we might have this regression? (We should also modify the main message to talk about Pattern, like we did with the help.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also not part of the review.

src/test/ui/traits/issue-71136.stderr Outdated Show resolved Hide resolved
src/test/ui/traits/issue-71136.stderr Outdated Show resolved Hide resolved
span,
traits::SizedArgumentType(None),
traits::SizedArgumentType(arg_span),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think here is where we could keep around the info about the Sized argument requirement coming from a call.

Comment on lines 1745 to 1746
match hir.get(hir_id) {
hir::Node::Expr(hir::Expr { kind: hir::ExprKind::Path(qpath), hir_id, .. }) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we move all of this to its own method?

@estebank
Copy link
Contributor

r=me

@rust-log-analyzer

This comment has been minimized.

@compiler-errors
Copy link
Member Author

I'm gonna fix CI, then land this and work on a couple of easy follow-ups like those weird closure overlapping spans.

@compiler-errors
Copy link
Member Author

Rebased, will wait until CI is green.

@compiler-errors
Copy link
Member Author

@bors r=estebank rollup=never

(kinda bitrotty probably)

@bors
Copy link
Contributor

bors commented Aug 18, 2022

📌 Commit cb7a2ec40879726ec47c777e128e0c0de5f4e6dd has been approved by estebank

It is now in the queue for this repository.

@compiler-errors
Copy link
Member Author

Actually, I think I overestimated the difficulty of rebasing this. The fix was to just add an extra match for ExprItemObligation seen in the last commit. Sorry for the ping, I'm actually totally fine here.

@bors r=estebank

@bors
Copy link
Contributor

bors commented Aug 21, 2022

📌 Commit 4045a268443bed3a3688340e8550d1c7b03cf78d has been approved by estebank

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 21, 2022
@rust-log-analyzer

This comment has been minimized.

@compiler-errors
Copy link
Member Author

Tidy is the bane of my existence.

@compiler-errors
Copy link
Member Author

@bors r=estebank

@bors
Copy link
Contributor

bors commented Aug 21, 2022

📌 Commit d577eb0 has been approved by estebank

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Aug 21, 2022

⌛ Testing commit d577eb0 with merge 0b71ffc...

@bors
Copy link
Contributor

bors commented Aug 22, 2022

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

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 22, 2022
@bors bors merged commit 0b71ffc into rust-lang:master Aug 22, 2022
@rustbot rustbot added this to the 1.65.0 milestone Aug 22, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (0b71ffc): comparison url.

Instruction count

  • Primary benchmarks: ✅ relevant improvement found
  • Secondary benchmarks: no relevant changes found
mean1 max count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.9% -0.9% 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -0.9% -0.9% 1

Max RSS (memory usage)

Results
  • Primary benchmarks: ✅ relevant improvement found
  • Secondary benchmarks: mixed results
mean1 max count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.8% 1.8% 2
Improvements ✅
(primary)
-2.3% -2.3% 1
Improvements ✅
(secondary)
-3.8% -3.8% 1
All ❌✅ (primary) -2.3% -2.3% 1

Cycles

Results
  • Primary benchmarks: ✅ relevant improvement found
  • Secondary benchmarks: no relevant changes found
mean1 max count2
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-6.0% -6.0% 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -6.0% -6.0% 1

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

  1. the arithmetic mean of the percent change 2 3

  2. number of relevant changes 2 3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

E0277 focuses on the wrong part of the line.
7 participants