Tracking issue for RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute

[scottmcm]

This is a tracking issue for the RFC "Future-proofing enums/structs with #[non_exhaustive] attribute" (rust-lang/rfcs#2008).

Steps:

• Implement the RFC (mentoring instructions below) -- done in PR RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute #45394
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Issues to be resolved prior to stabilization

• #[non_exhaustive] is not yet implemented for enum variants.
• Current behavior on unions. The current implementation (Tracking issue for RFC 2008: Future-proofing enums/structs with #[non_exhaustive] attribute #44109) sometimes ignores non_exhaustive on unions, sometimes reports an error.
• In addition, the attribute is not currently validated (neither syntactic form nor location), so it can be written in weird forms (#[non_exhaustive(foo)]) and in arbitrary locations, including suspicious ones like traits (#[non_exhaustive] trait Trait {}).
• Fix [nightly regression] E0639 + adding #[non_exhaustive] to io::ErrorKind is a breaking change #53549

[eddyb]

I'd cc @rust-lang/compiler instead.

[tinaun]

im working on a pr for this. how should tests be structured?

[tinaun]

also: should there be a lint for #[non_exhaustive] on non public items, since it doesn't really do anything crate-locally?

[clarfonthey]

@tinaun shouldn't they all go under the useless_attribute lint? That includes both on non-pub items and structs with private fields.

[nikomatsakis]

@tinaun I would expect tests for this to be scattered about in the run-pass and compile-fail and ui directories:

• run-pass would be used to test things that should compile
• ui is usually used to test for things that don't compile (compile-fail can also be used, but I prefer ui personally)
  • if you want to test that a lint is issued, you can use #[deny] to convert the warning into an error

Just to keep things organized, I would make a subdirectory like src/test/run-pass/nonexhaustive-rfc2008 (and same for ui) to contain the tests.

So I would imagine using ui tests to check for:

• Errors when exhaustively matching (without _) something from another crate that is tagged #[nonexhaustive]

The run-pass might be used to test that an exhaustive match within the same crate compiles just fine.

[nikomatsakis]

@tinaun any progress? need any tips?

[tinaun]

I'm currently away for the weekend but I would love to have some help with understanding the implementation of privacy in the complier. sorry for forgetting about this!

[petrochenkov]

So, this feature shouldn't require too many changes to implement.

• First, we need to require .. in patterns, this needs to be done in fn check_struct_pat_fields in librustc_typeck/check/_match.rs
• Then we need to prohibit any struct expressions (with .. or not, doesn't matter), this needs to be done in fn check_expr_struct in librustc_typeck/check/mod.rs
• After that we need to tweak visibilities for struct constructors. This currently requires changes to three places - 1) fn build_reduced_graph_for_item/ItemKind::Struct + fn build_reduced_graph_for_variant in librustc_resolve 2) fn encode_struct_ctor and fn encode_enum_variant_info in librustc_metadata and 3) fn def_id_visibility in librustc_privacy.
  I all cases visibility of a struct/variant with non_exhaustive attribute should be lowered to pub(crate) if it was pub.
  EDIT: Separating visibilities for enum variants and their constructors may potentially require some larger infrastructural changes because they share DefId currently, so non_exhaustive on tuple/unit variants can be omitted from initial implementation.
• Test everything! In this case it's probably better to write failing tests before doing anything else and then make them pass gradually.
• EDIT: I completely forgot about non_exhaustive on enums and match exhaustiveness checks.