Clean up collections::EnumSet

[tbu-]

Make EnumSet portable by using a fixed-size unsigned integer, namely u32.
The previous choice of uint creates portability hazards as too high enum
variants are only detected at runtime.

Mark the from_u32 method of the trait CLike as unsafe, as it is supposed to
be implemented without checking, thus being unsafe.

Remove the memory-unsafe Decode implementation for EnumSet.

This is a [breaking-change]. Code using EnumSet needs to be updated to use
u32s.

[Gankra]

I wonder if EnumSet should be generic over an arbitrary UnsignedInt implementor. That way you can have a u8, u32, u64, whatever.

CC @SimonSapin or @sfackler I have no idea what EnumSet is really "for" anymore.

[tbu-]

The only current use is in the compiler, at the position that is changed by this commit as well.

[Gankra]

I believe Servo and others use it.

[tbu-]

This doesn't remove functionality for software that is supposed to run on both 32/64 bit systems. So this change should only affect 64-bit only software (but there's not a lot of that (?)).

[SimonSapin]

EnumSet is not currently used in the Servo repository. (I haven’t checked all the transitive dependencies.) I considered using at some point, but I needed more than 64 bits: #13756.

I don’t really like EnumSet: it requires a custom implementation of CLike for every enum type it’s used with, even though this implementation should always be the same. This feels very fragile. I wouldn’t mind moving it from std into a Cargo package.

[Gankra]

Ah, I see. Okay. I summon @aturon, lord-master of APIs.

[aturon]

Thanks for the PR, @tbu-!

I increasingly agree with @SimonSapin here: I don't think EnumSet as it stands is ready for prime time, and I don't want to sink a lot of effort into it just yet. Same with bitflags. Perhaps both should be moved out of tree? I'm not sure if there's an existing crate that would be a good place for them -- @gankro, would you want to iterate on this in your collects crate?

[Gankra]

Yes I'm happy to adopt this and any other "imperfect" collections in collect-rs. I'm not sure how we want to handle such migrations.

[SimonSapin]

I’ve exported the git history of the ascii module but I’m not sure it’s worth it. You could just include the hash of the Rust commit you copied from in the message for your commit that first imports something, and anyone interested in archaeology can follow the trail manually.

Is that what you meant by handling migrations?

[Gankra]

I was more thinking about the actual political process. e.g. an RFC or a core-team meeting or what. But yeah having a nod to actual commit history would be nice.

[SimonSapin]

Since removing things is a breaking change, probably an RFC. (And whatever the RFC approval process is these days − it’s changing but I haven’t read up on that yet.) But you can have a couple of related things in the same RFC.

[aturon]

@gankro Maybe your collections reform part 2 RFC should also include this migration. If you want to do that, we should talk about the other collections that we don't plan to stabilize in the near future and probably move them as well.

[aturon]

I'm going to close this PR now that EnumSet is on the way out of std. Maybe it should be retargetted to https://github.com/Gankro/collect-rs ?