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.

[nikomatsakis]

@tinaun just checking in -- did those instructions help? Still got questions? =)

UPDATE: @tinaun responded on Gitter.

[davidtwco]

Hoping to take a stab at this after speaking with @nikomatsakis in Gitter. @tinaun are you still working on this?

Update: @tinaun replied on Gitter.

[davidtwco]

@nikomatsakis @eddyb @arielb1 @pnkfelix (I'm not sure who I should be pinging about this, apologies)

So far I've implemented most of the mentoring instructions but there are a few things I've run into issues with.

In this section where I require .. (as per the first mentoring instruction) - this seems to work, except that it doesn't take into account whether the struct/enum is within the crate (and therefore should be able to match without a wildcard) - this causes issues with the run-pass/rfc-2008-non-exhaustive/struct_within_crate.rs test (and the similar enum test). I'm not sure what I should be checking to do that.

I've also not made changes to the visibilities in encode_enum_variant_info and build_reduced_graph_for_variant as when I did so, I found that I was no longer able to access the variants of a enum in order to match them from outside of a crate - similarly to the previous question, I wasn't sure how to have the change apply only outside of a crate.

I hope this is on the right track and I'd appreciate any feedback.

[arielb1]

@davidtwco

To check whether an ADT is within the same crate as the crate you are type-checking, find the def-id of the ADT and check whether it's local - e.g. if you have an adt: &AdtDef, you can check adt.did.is_local().

[arielb1]

For the visibility, you can ask @petrochenkov but I think you want to set the visibility to pub(crate) aka ty::Visibility::Restricted(DefId::local(CRATE_DEF_INDEX))

[arielb1]

If you can find me, feel free to ping me on IRC.

[davidtwco]

Thanks, that's super helpful.

With regards to the visibility, that's what I was setting the visibility to, but I'll take another stab at it and see what I can come up with.

[nikomatsakis]

@davidtwco glad to see that @arielb1 got you unblocked! Looking forward to seeing the PR. =) Let us know if you hit any other problems (are here or on gitter)

[davidtwco]

@nikomatsakis @arielb1

Apologies for how long this is taking and for a further query.

Since my previous comment here I think I've got it working with structs and after speaking with @nikomatsakis in Gitter earlier today, I've added a bunch more tests for cases that I hadn't considered. There are only five tests that still don't pass:

The first of which is related to instantiating a tuple struct, I think I've went wrong with the visibility somewhere for this so I'm going to look into that. The second of which is similar but for instantiating a unit struct.

The rest of which are all related to a lack of errors for things that should fail on enums with the attribute. @nikomatsakis mentioned that there are two cases with enums, handling new variants and new fields to existing variants - I do believe that the new fields case is handled by the existing structs code but I'm not 100% sure. However, I don't think the new variants case is handled. The function mentioned in the first bullet point of the mentoring instructions doesn't seem to apply for this case and I've not been able to figure out where the equivalent is. As the edited mentoring instructions now mention, there aren't any instructions for handling enums so I've been struggling to pinpoint where I need to make changes. I'd appreciate some pointers as to where I should be working for that.

All the help so far as been fantastic so I appreciate that.

[nikomatsakis]

@yodaldevoid I think the recording (and minutes) are available here

[Nemo157]

@Kixunil that is how the feature works already.

[Kixunil]

@Nemo157 ah I missed that, awesome! Thank you!

[Centril]

This is not the place to discuss this. Please file a new issue for any problems you might have.