Skip to content
This repository has been archived by the owner on Nov 24, 2023. It is now read-only.

rustfix should handle multi-span suggestions #141

Closed
zackmdavis opened this issue Aug 12, 2018 · 3 comments
Closed

rustfix should handle multi-span suggestions #141

zackmdavis opened this issue Aug 12, 2018 · 3 comments

Comments

@zackmdavis
Copy link
Member

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.

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
@estebank
Copy link

CC rust-lang/rust#56220

@pietroalbini
Copy link
Member

Fixed by #155

@killercup killercup reopened this Dec 9, 2018
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.)
@ehuss
Copy link
Collaborator

ehuss commented Nov 22, 2023

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.

@ehuss ehuss closed this as completed Nov 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants