This repository has been archived by the owner on Nov 24, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 62
rustfix should handle multi-span suggestions #141
Comments
This was referenced Aug 12, 2018
zackmdavis
added a commit
to zackmdavis/rust
that referenced
this issue
Sep 28, 2018
RFC 2093 (tracking issue rust-lang#44493) lets us leave off commonsensically inferable `T: 'a` outlives requirements. (A separate feature-gate was split off for the case of 'static lifetimes, for which questions still remain.) Detecting these was requested as an idioms-2018 lint. It turns out that issuing a correct, autofixable suggestion here is somewhat subtle in the presence of other bounds and generic parameters. Basically, we want to handle these three cases: • One outlives-bound. We want to drop the bound altogether, including the colon— MyStruct<'a, T: 'a> ^^^^ help: remove this bound • An outlives bound first, followed by a trait bound. We want to delete the outlives bound and the following plus sign (and hopefully get the whitespace right, too)— MyStruct<'a, T: 'a + MyTrait> ^^^^^ help: remove this bound • An outlives bound after a trait bound. We want to delete the outlives lifetime and the preceding plus sign— MyStruct<'a, T: MyTrait + 'a> ^^^^^ help: remove this bound This gets (slightly) even more complicated in the case of where clauses, where we want to drop the where clause altogether if there's just the one bound. Hopefully the comments are enough to explain what's going on! A script (in Python, sorry) was used to generate the hopefully-sufficiently-exhaustive UI test input. Some of these are split off into a different file because rust-lang/rustfix#141 (and, causally upstream of that, rust-lang#53934) prevents them from being `run-rustfix`-tested. We also make sure to include a UI test of a case (copied from RFC 2093) where the outlives-bound can't be inferred. Special thanks to Niko Matsakis for pointing out the `inferred_outlives_of` query, rather than blindly stripping outlives requirements as if we weren't a production compiler and didn't care. This concerns rust-lang#52042.
bors
added a commit
to rust-lang/rust
that referenced
this issue
Nov 4, 2018
single life * structured ~~autofixable~~ (well, pending #53934 and rust-lang/rustfix#141) suggestions for the single-use-lifetimes lint in the case of function and method reference args * don't consider the anonymous lifetime `'_` as "single-use" (it's intended for exactly this sort of thing) ![single_life](https://user-images.githubusercontent.com/1076988/47613227-3b2b6400-da48-11e8-8efd-cb975ddf537d.png) r? @nikomatsakis
Fixed by #155 |
zackmdavis
added a commit
to zackmdavis/rustfix
that referenced
this issue
Feb 6, 2019
This is meant to be the resolution to rust-lang#141 (and, in a way, rust-lang/rust#53934). We add two test fixtures demonstrating usage and correctness. The JSON comes from a locally-built non-master compiler featuring the change to the JSON emitter to support this. (Actually, one is from `--error-format pretty-json` and the other is from `--error-format json` and subsequent auto-formatting, but the difference in inter-string-literal newlines doesn't seem to matter.)
I think in a sense this is resolved by #195. There is still an outstanding consideration that there is no way to distinguish between a diagnostic that has multiple spans, and one that has multiple variants. I think that is tracked in rust-lang/rust#53934. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Here:
https://github.com/rust-lang-nursery/rustfix/blob/89217428c130b62c7ddaa0734eb4ebaa33673a86/src/lib.rs#L191-L198
This issue concerns the matter of a single suggestion that happens to replace multiple spans (functionality that is not used often, but which does exist). This is not to be confused with multiple suggestions that happen to touch the same code, which (if I understand correctly while reading quickly) was what #140 was about.
I'm happy to work on this because I need it for rust-lang/rust#53013.
The text was updated successfully, but these errors were encountered: