Open suaviloquence opened 2 months ago
Nice catch!
Similarly to the #[non_exhaustive]
case, if the variant was #[doc(hidden)]
we probably don't want to lint on it since the variant isn't meant to be constructed by downstream code.
For a piece of code like:
pub enum Example {
Plain,
Tuple(),
Struct {},
}
Note that #[non_exhaustive]
tuple variants can't be constructed by an external crate, so witness (proof-of-breakage) code can't rely on constructing the variant.
We want the following lints:
#[non_exhaustive]
changes to another kind: #894
let _: Example = Example::Plain
only works for unit variants#[non_exhaustive]
changes to another kind: #906
let _: Example = Example::Tuple(...)
only works for tuple variants, nothing else can use parens#[non_exhaustive]
tuple variant that has at least one public API field changes to another kind
.0
work#[non_exhaustive]
to this lint to ensure the two lints are completely disjoint.0
) so plain and tuple structs can't have the same field{}
-like instantiation is allowed for all variant kindsRemaining questions:
#[non_exhaustive]
unit variant changes to another kind?
Describe your use case
We have lints for when a
struct
changes "kind":tuple_struct_to_plain_struct
unit_struct_changed_kind
However, currently
cargo-semver-checks
does not check when an enum variant changes kind like this.from:
to:
the first three variants would break with:
the second three also have breakage in a similar fashion, and
cargo-semver-checks
currently does not catch the fields_missing/removed lints because these variants changed kindDescribe the solution you'd like
Thus, it would be helpful to have lint(s) that detect this change for constructible enum variants - if a tuple/struct variant is marked
#[non_exhaustive]
in the baseline version, this is not a breaking change because it was not possible to construct these variants in the baseline version.Alternatives, if applicable
No response
Additional Context
No response