Mark all structs `non_exhaustive` for 1.0

[tgross35]

There are a handful of structs that users should be able to access but possibly not construct in case fields change in the future. Currently we often do this by having a single private field, but maybe #[non_exhaustive] would be better suited here.

[tgross35]

We talked about this at rustweek; we would like to use #[non_exhaustive] by default, with some very minor exceptions (e.g. iovec)

[tgross35]

For how to implement this: the s! and s_no_extra_traits! macros should be updated to emit #[non_exhaustive] by default. Then the macro should accept something like #[not_non_exhaustive] to opt out.

[tgross35]

Also, as discussed at #t-libs > Questions and polls about `libc` 1.0 @ 💬, we should be able to derive Default.

[dybucc]

Coming from #1324, and seeing how we've had the new usage guidelines for a few
weeks now, is this still necessary? I'm guessing the Default impl still is,
but what about the non_exhaustive attribute annotation?

[dybucc]

If it's worth it, I think I've got the non_exhaustive stuff done here ¹.
The Default impl I'm still looking into.

Edit: tweaked it some and realized the solution was crap. Everything is still a
WIP.

Edit 2: I finally did get an attribute muncher working on s. It should be
fairly simple to extend it to the other s_* macro variants.

Footnotes

1. https://github.com/dybucc/libc/commit/bbe85f40596ea3566dc2c4b5339f1478c411958c ↩

[tgross35]

See #5257 for the Default bit. I think a not_non_exhaustive macro will be easier after that lands because of how it restructures the macro and does some attribute munching already.

Actually using non_exhaustive is blocked on rust-lang/rust#132699, but we could add a __non_exhaustive: ().

[tgross35]

Trying to think of a reasonable migration path here, maybe something like:

1. Update the macros to accept #[exhaustive]. For now #[exhaustive] does nothing, otherwise a field __non_exhaustive: () gets added. (If that Rust issue is fixed, we can change it to just be #[non_exhaustive].)
2. In some semi-automated way (your CLI tool, perhaps?) add #[exhaustive] to all structs that don't have a private field (i.e. those for which adding __non_exhaustive would be technically API-breaking)
3. Merge and backport that
4. Immediately revert the commit adding all the #[exhaustive] on the 1.0 branch

That's going to be noisy with all the #[exhaustive] we need, but I think it's better than needing to specify #[non_exhaustive] when it's going to be the default.

[dybucc]

So, IIUC, this means I have to repurpose the attribute muncher I got working to
both (1) adapt to the new macros that implement Default, and (2) replace the
default non_exhaustive annotation with a private field.

Then to opt out, instead of using the not_non_exhaustive attribute, we use the
exhaustive attribute. This is really just a change in name.

Then I'm supposed to find some way of automatically making all records that
don't have a private field be annotated with exhaustive. My CLI tool is a
no-go, and will continue being so for 1+ year(s) for personal reasons.

The above I can all execute on immediately. Anything else I can worry about
later on. Did I get the plan right?