That is, opting to ignore stable `#![feature(..)]`, under my theory
that a reviewer would prefer as much stuff to be bucketed under "ah
another `#![allow(..)]` here." as possible.
that is, I suspect it should be retired because it is testing behavior
(namely a `#[repr(C)] struct Empty;`) that, if I understand correctly,
is undefined.
See also rust-lang/rust#53859.
rustc_typeck: turn `where Type:,` into a WF(Type) predicate, instead of ignoring it.
Fixes#53696, assuming crater doesn't catch anyone using this syntax already.
Allowing an empty list of bounds in the grammar was done for the benefit of macro authors, most of which would *probably* be using it for bounds on type parameters, which are always WF.
r? @nikomatsakis cc @petrochenkov
fix `is_non_exhaustive` confusion between structs and enums
Structs and enums can both be non-exhaustive, with a very different
meaning. This PR splits `is_non_exhaustive` to 2 separate functions - 1
for structs, and another for enums, and fixes the places that got the
usage confused.
Fixes#53549.
r? @eddyb
* When encountering EOF, point at the last opening brace that does not
have the same indentation level as its close delimiter.
* When encountering the wrong type of close delimiter, point at the
likely correct open delimiter to give a better idea of what went
wrong.
Fix of bug introduced by #53762 (tool_lints)
Before implementing backwards compat for tool lints, the `Tool` case when parsing cmdline lints was unreachable. This changed with #53762.
This fix is needed for rls test-pass. (@nrc)
r? @Manishearth
Various small diagnostic and code clean up
- Point at def span on incorrect `panic` or `oom` function
- Use structured suggestion instead of note for `+=` that can be performed on a dereference of the left binding
- Small code formatting cleanup
set cfg(rustdoc) when rustdoc is running on a crate
When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation.
This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs.
To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
