When encountering struct fn call literal with private fields, suggest all builders#117683
When encountering struct fn call literal with private fields, suggest all builders#117683bors merged 14 commits intorust-lang:masterfrom
Conversation
|
r? @cjgillot (rustbot has picked a reviewer for you, use r? to override) |
|
|
c7623f5 to
4fc13d4
Compare
|
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
WaffleLapkin
left a comment
There was a problem hiding this comment.
Couple nits.
Also, are all those sorts required? A bit surprising we have so much non-determinism...
This comment has been minimized.
This comment has been minimized.
| } | ||
| }) | ||
| .collect::<Vec<_>>(); | ||
| items.sort_by_key(|(order, _, _)| *order); |
There was a problem hiding this comment.
Should we give higher priority to methods with fewer inputs?
There was a problem hiding this comment.
I feel like definition order is a more reliable heuristic
| .join(".") | ||
| }) | ||
| .collect::<Vec<_>>(); | ||
| candidate_fields.sort(); |
There was a problem hiding this comment.
Could you add a FIXME so we don't forget to track down the non determinism?
- all places where you had to call sort.
There was a problem hiding this comment.
I sorted in all these to maintain the current behavior, I haven't validated that all of them needed to be sorted.
| true | ||
| } | ||
|
|
||
| fn suggest_alternative_construction_methods( |
There was a problem hiding this comment.
I'm not fond of having twice (almost) identical code in two parts of the compiler. Which version has the most effect? The two tests I see exercise the non-local version, so iiuc this one.
There was a problem hiding this comment.
Yeah, it's not ideal, but we have different amount of context on each stage.
There was a problem hiding this comment.
This one affects only the first cases in tests/ui/privacy/suggest-box-new.rs, while the other affects the latter cases in that file. We have no way of knowing what the prevalence of these errors are in the wild. I you'd prefer I moved the logic to a central place I can do that. I didn't because there was no natural place where these wouldn't feel out of place.
|
☔ The latest upstream changes (presumably #117875) made this pull request unmergeable. Please resolve the merge conflicts. |
75b0f08 to
9959160
Compare
|
☔ The latest upstream changes (presumably #118046) made this pull request unmergeable. Please resolve the merge conflicts. |
… all builders When encountering code like `Box(42)`, suggest `Box::new(42)` and *all* other associated functions that return `-> Box<T>`.
9959160 to
ac56b06
Compare
|
Let's go with this version, to be refactored later. |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (9a66e44): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 675.906s -> 676.7s (0.12%) |
| span.shrink_to_hi().with_hi(expr_span.hi()), | ||
| format!("you might have meant to use the `{name}` associated function"), | ||
| suggestion(name, *args), | ||
| Applicability::MaybeIncorrect, |
There was a problem hiding this comment.
shouldn't this be if args.len() > 0 { HasPlaceholders } else { MaybeIncorrect }? I was under the impression that was more severe than MaybeIncorrect
There was a problem hiding this comment.
MaybeIncorrect is actually more severe than HasPlaceholders
When encountering code like
Box(42), suggestBox::new(42)and all other associated functions that return-> Box<T>.Add a way to give pre-sorted suggestions.