Hidden suggestion support
Add way to hide suggestion snippet window from cli output to avoid cluttered spans that don't enhance understanding.
r? @pietroalbini CC @zackmdavis
add a lint group for lints emitted by rustdoc
As rustdoc adds more lints that it specifically manages, it would be nice to be able to lump them all together. This gives us a new group just for that.
I deliberately didn't include `missing_docs` because this is kind of a stepping stone for moving our lints into tool lints (i.e. `#![warn(rustdoc::private_doc_tests)]`), since all of these are specifically emitted by rustdoc. If we want to move `missing_docs` out of the compiler, that's also an option, but it would create a surprising change of behavior.
I also took the chance to rewrite the lint descriptions of these lints to better match the style of the other lints. `>_>`
add coherence future-compat warnings for marker-only trait objects
The future-compat warnings break code that assumes that `dyn Send + Sync !=
dyn Sync + Send`, and are the first step in making them equal. cc #33140.
Note: this lint should be made to default-warn before we merge. It is deny only for the crater run.
r? @nikomatsakis / @scalexm . cc @Centril & @alexreg.
* Update bootstrap compiler
* Update version to 1.33.0
* Remove some `#[cfg(stage0)]` annotations
Actually updating the version number is blocked on updating Cargo
This seemed like a good way to kick the tires on the
elided-lifetimes-in-paths lint (#52069)—seems to work! This was also
pretty tedious—it sure would be nice if `cargo fix` worked on this
codebase (#53896)!
RFC 2093 (tracking issue #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-nursery/rustfix#141
(and, causally upstream of that, #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 #52042.
This adds a suggestion to the `invalid_crate_types` lint.
The suggestion is based on the Levenshtein distance to existing crate
types. If no suggestion is found it will show the lint without any
suggestions.
