-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Simpler diagnostic when passing arg to closure and missing borrow #102813
Simpler diagnostic when passing arg to closure and missing borrow #102813
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @estebank (or someone else) soon. Please see the contribution instructions for more information. |
compiler/rustc_trait_selection/src/traits/error_reporting/suggestions.rs
Outdated
Show resolved
Hide resolved
I'll review in full soon, but I notice that the only case that is unacounted for are generators, otherwise the bug calls seem like reasonable invariant holding. From a cursory look, I'd like it if we could move this logic to its own function to make skimming the code easier. |
|
||
if found_ty == expected_ty { | ||
let hint = if found_refs < expected_refs { | ||
"consider borrowing here:" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"consider borrowing here:" | |
"consider borrowing the argument" |
} else if found_refs == expected_refs { | ||
continue; | ||
} else { | ||
"consider removing the borrow:" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"consider removing the borrow:" | |
"do not borrow the argument" |
☔ The latest upstream changes (presumably #102896) made this pull request unmergeable. Please resolve the merge conflicts. |
Two questions:
|
Yeah that 'd be better, because even if that method has a bug for generators, it'll be eventually fixed for all of its callers.
That suggestion regression is acceptable. |
for ((found_arg, expected_arg), arg_span) in found_args.zip(expected_args).zip(arg_spans) { | ||
let (found_ty, found_refs) = get_deref_type_and_refs(*found_arg); | ||
let (expected_ty, expected_refs) = get_deref_type_and_refs(*expected_arg); | ||
|
||
if found_ty == expected_ty { | ||
let hint = if found_refs < expected_refs { | ||
"consider borrowing the argument" | ||
} else if found_refs == expected_refs { | ||
continue; | ||
} else { | ||
"do not borrow the argument" | ||
}; | ||
err.span_suggestion_verbose( | ||
arg_span, | ||
hint, | ||
expected_arg.to_string(), | ||
Applicability::MaybeIncorrect, | ||
); | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only thing I'd like changed is to make this a single suggestion for all arguments, but we can land as is.
@bors r+ |
…stic_when_passing_arg_to_closure_and_missing_borrow, r=estebank Simpler diagnostic when passing arg to closure and missing borrow fixes rust-lang#64915 I followed roughly the instructions and the older PR rust-lang#76362. The number of references for the expected and the found types will be compared and depending on which has more the diagnostic will be emitted. I'm not quite sure if my approach with the many `span_bug!`s is good, it could lead to some ICEs. Would it be better if those errors are ignored? As far as I know the following code works similarly but in a different context. Is this probably reusable since it looks like it would emit better diagnostics? https://github.com/rust-lang/rust/blob/a688a0305fad9219505a8f2576446510601bafe8/compiler/rustc_hir_analysis/src/check/demand.rs#L713-L1061 When running the tests locally, a codegen test failed. Is there something I can/ should do about that? If you have some improvements/ corrections please say so and I will happily include them. r? `@estebank` (as you added the mentoring instructions to the issue)
@bors r- fails CI |
Please rebase. |
I added a tidy-ignore for the file-length. I don't know what the best idea would be to split this long file. Additionally I tried to combine all similar suggestions, but I'm not sure if this is the preferred way to do that with the diagnostics. Happy to make improvements :) |
☔ The latest upstream changes (presumably #104902) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #105644) made this pull request unmergeable. Please resolve the merge conflicts. |
Apologies, I'd missed that you'd rebased and re-pushed. r=me after rebasing :) |
This checks the number of references for the given and expected type and shows hints to the user if the numbers don't match.
@bors r+ |
☀️ Test successful - checks-actions |
Finished benchmarking commit (0f529f0): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
These benchmarks are currently noisy. |
fixes #64915
I followed roughly the instructions and the older PR #76362.
The number of references for the expected and the found types will be compared and depending on which has more the diagnostic will be emitted.
I'm not quite sure if my approach with the many
span_bug!
s is good, it could lead to some ICEs. Would it be better if those errors are ignored?As far as I know the following code works similarly but in a different context. Is this probably reusable since it looks like it would emit better diagnostics?
rust/compiler/rustc_hir_analysis/src/check/demand.rs
Lines 713 to 1061 in a688a03
When running the tests locally, a codegen test failed. Is there something I can/ should do about that?
If you have some improvements/ corrections please say so and I will happily include them.
r? @estebank (as you added the mentoring instructions to the issue)