Repository navigation
rustc::lint-API: Distinguish directly applicable from colloquial code suggestions #33691
Description
There has been some inquiry into a "quick fix" IDE feature for Rust. Given that lints (including clippy) already generate suggestions based on code, a quick win could be made by allowing the lints to distinguish directly applicable suggestions and perhaps somehow flag those for tools using rustc's JSON output. Then IDEs could weave the suggestions into the code based on the reported span.
Reacted by Martin Carton
Activity
Manishearth commentedon May 17, 2016
IMO such a feature would probably be more involved than just span_suggestion, with hooks for replacing individual bits of code (instead of text substitution) in a typed fashion. But if not, a distinguishing span_help_code would be nice.
nrc commentedon May 18, 2016
span_suggestionprobably needs an overhaul, but would be a good starting point. The suggestion JSON should be able to be nested in JSON errors or emitted individually (e.g., Clippy would do the latter, although perhaps it could just emit JSON errors when requested with the embedded suggestion).@Manishearth what does "in a typed fashion" mean? I would expect that all the hard processing would be done by the tool generating the suggestion (rustc, clippy) and the suggestion is just a set of spans and replacement text (where the replacement text might be the empty string for deletions and the span to be replaced might be zero-length for insertions).
We might also want to let the replacing tool format the text, so the suggestion text could be some kind of reification of the AST. That has horrible problems. Alternatively the suggestion could be unformatted source code and if the replacement tool wants to reformat, it can re-parse and reformat.
Manishearth commentedon May 18, 2016
Currently clippy takes
span_to_snippets and splices them together to get suggestions. It would be nicer if we could take the typed AST objects and splice them together (e.g. moving an expression from an if block to the outside by appending it to the outer block) and print them, while retaining formatting and macros. There's no way to do that currently, and we have to do random hacks to get indentation to work.But yeah, splice-and-feed-to-rustfmt sort of works too.
oli-obk commentedon May 18, 2016
Related internals post: https://internals.rust-lang.org/t/rustcs-json-output-format/3446/11?u=ker
if things like
unresolved name xyz, did you mean xyz1are changed to use suggestions, we'd need a way to distinguish between guaranteed correct suggestions like changing!(a == b)intoa != bagainst heuristic suggestions like changingxyzintoxyz1or like adding newuse x::X;items whenXis not found in the scope.Manishearth commentedon May 18, 2016
Yeah, I think in that case we don't want to output code in the first place
oli-obk commentedon May 18, 2016
Not sure I understand? If there's an ambiguity, the user can decide, but often it's still possible to provide sensible choices, so the user can click on a choice and the IDE inserts that one.
Are you suggesting to never provide snippets if there are ambiguities or heuristics involved?
Manishearth commentedon May 18, 2016
I guess? We'd need a clear distinction then, right.
sanxiyn commentedon May 18, 2016
I think it is enough to simply clarify that
span_suggestionis only for directly applicable suggestions. In fact, have we ever usedspan_suggestionwhen it is not directly applicable?Manishearth commentedon May 18, 2016
Yeah, that was my point -- we don't do it now and we can continue not doing it.
llogiq commentedon May 18, 2016
I think we have two interesting distinctions to make:
oli-obk commentedon Aug 17, 2018
I think this has been resolved by the
Applicabilityannotations