-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Applicability
-ify suggestions
#50723
Comments
Some would argue that this 40-character method name is ludicrously unwieldy (even ironic), but it's the unique continuation of the precedent set by the other suggestion methods. (And there is some hope that someday we'll just fold `Applicability` into the signature of the "basic" method `span_suggestion`.) This is in support of rust-lang#50723.
Consider this a down payment on rust-lang#50723. To recap, an `Applicability` enum was recently (rust-lang#50204) added, to convey to Rustfix and other tools whether we think it's OK for them to blindly apply the suggestion, or whether to prompt a human for guidance (because the suggestion might contain placeholders that we can't infer, or because we think it has a sufficiently high probability of being wrong even though it's— presumably—right often enough to be worth emitting in the first place). When a suggestion is marked as `MaybeIncorrect`, we try to use comments to indicate precisely why (although there are a few places where we just say `// speculative` because the present author's subjective judgement balked at the idea that the suggestion has no false positives). The `run-rustfix` directive is opporunistically set on some relevant UI tests (and a couple tests that were in the `test/ui/suggestions` directory, even if the suggestions didn't originate in librustc or libsyntax). This is less trivial than it sounds, because a surprising number of test files aren't equipped to be tested as fixed even when they contain successfully fixable errors, because, e.g., there are more, not-directly-related errors after fixing. Some test files need an attribute or underscore to avoid unused warnings tripping up the "fixed code is still producing diagnostics" check despite the fixes being correct; this is an interesting contrast-to/inconsistency-with the behavior of UI tests (which secretly pass `-A unused`), a behavior which we probably ought to resolve one way or the other (filed issue rust-lang#50926). A few suggestion labels are reworded (e.g., to avoid phrasing it as a question, which which is discouraged by the style guidelines listed in `.span_suggestion`'s doc-comment).
add suggestion applicabilities to librustc and libsyntax A down payment on #50723. Interested in feedback on whether my `MaybeIncorrect` vs. `MachineApplicable` judgement calls are well-calibrated (and that we have a consensus on what this means). r? @Manishearth cc @killercup @estebank
Andrew Chin recently pointed out (rust-lang/cargo#5846) that it's surprising that `cargo fix` (now shipping with Cargo itself!) doesn't fix very common lint warnings, which is as good of a reminder as any that we should finish rust-lang#50723.
add rust-lang/rust#50723 as an easy-level call for participation
I might have since added some span_suggestions since you started this work. We should probably take a week soonish and just plow through all cases in the codebase. |
…ebank App-lint-cability @eminence recently pointed out (rust-lang/cargo#5846) that it's surprising that `cargo fix` (now shipping with Cargo itself!) doesn't fix very common lint warnings, which is as good of a reminder as any that we should finish rust-lang#50723. (Previously, we did this on the librustc and libsyntax crates in rust-lang#50724. I filed rust-lang/this-week-in-rust#685 in hopes of recruiting new contributors to do the rest.) r? @estebank
I'm still hopeful that we can recruit a reader of This Week in Rust 246 who's willing to put up with a bit of tedium in exchange for eternal open-source fame and glory. If that's you, dear reader of this comment, here are some mentoring instructions:
|
Hi, I opened a pull request (#53418) to convert some suggestions. My goal is to convert more of them, this is my first time opening a PR for rust so I thought I'd start with something small. |
@ekse I believe it is possible, but it is a bad idea because we prefer to keep the diffs as small as possible. Unless you're actively touching the code, style only changes are slightly frowned upon. My personal rule of thumb is that if it's only affecting a few lines it's fine, if it's affecting the entire file it's not. Anything in between is a grey area that will depend on the reviewer. Keep in mind that the more extensive the diffs are, the more likely it is they will have/cause merge conflicts with other PRs. |
…=estebank Set applicability for more suggestions. Converts a couple more calls to `span_suggestion_with_applicability` (rust-lang#50723). To be on the safe side, I marked suggestions that depend on the intent of the user or that are potentially lossy conversions as MaybeIncorrect. r? @estebank
set applicability Update a few more calls as described in rust-lang#50723 r? @estebank
set applicability Update a few more calls as described in rust-lang#50723 r? @estebank
set applicability Update a few more calls as described in rust-lang#50723 r? @estebank
set applicability Update a few more calls as described in rust-lang#50723 r? @estebank
set applicability Update a few more calls as described in rust-lang#50723 r? @estebank
Btw, I'm willing to mentor folks in doing this! |
…tebank add applicability to span_suggestion call Found another `span_suggestion` call. Issue rust-lang#50723 r? @estebank
…tebank add applicability to span_suggestion call Found another `span_suggestion` call. Issue rust-lang#50723 r? @estebank
…enkov add applicability to remaining suggestions Fixes rust-lang#50723. I noticed that the suggestion methods on `DiagnosticBuilder` weren't actually deprecated due to rust-lang#57679. This PR deprecates them properly and fixes the remaining usages. There's also a PR for clippy at rust-lang/rust-clippy#3667.
#50204 introduced an
Applicability
enum that is used to indicate whether a suggestion is suitable for non-interactive application by tools (notably rustfix), replacing a boolean that was intended for this purpose (#47540, #39254). It looks like we want to do this everywhere, but there didn't seem to be an existing issue to track this.The text was updated successfully, but these errors were encountered: