Bump bitflags to v2

[daxpedda]

Changelog: https://github.com/bitflags/bitflags/blob/2.0.0/CHANGELOG.md#200.

This is a breaking change. The API that is implemented by the macro is now different.

I was a bit liberal with deriving std traits on public types, which mimics the behavior of bitflags v1, let me know if we don't need all these traits. Potentially we could at least drop PartialOrd and Ord.

[daxpedda]

CI currently fails on master with the same error as well.

[jimblandy]

Why are the serializations changing?

Why do we have all these new #[derive] attributes?

[daxpedda]

Why are the serializations changing?

It was changed in v2. Now human-readable formats use a string, which contain the name of the flags. JSON is a human-readable format, that's why it's affecting the tests. In bincode for example, it would still just use an integer.

See https://github.com/bitflags/bitflags/blob/2.0.0/CHANGELOG.md#changes-to-serde-serialization.

Why do we have all these new #[derive] attributes?

In v1 the bitflags! macro derived them for us. This isn't the case anymore in v2, now derives need to be added manually.

This was done in a PR like this bitflags/bitflags#282 and is unfortunately not highlighted in the changelog.

[teoxoy]

@daxpedda I fixed the failing CI on master, could you rebase?

[daxpedda]

Done.

[daxpedda]

This error doesn't make a whole lot of sense to me, my PR should have no effect on this. But somehow CI on master succeeds, so what gives?

--- a/tests/out/glsl/force_point_size_vertex_shader_webgl.fs_main.Fragment.glsl
+++ b/tests/out/glsl/force_point_size_vertex_shader_webgl.fs_main.Fragment.glsl
@@ -1,4 +1,5 @@
 #version 300 es
+#extension GL_EXT_texture_shadow_lod : require
 
 precision highp float;
 precision highp int;

Should I just fix it?

[teoxoy]

I'm not sure how much value there is in deriving PartialOrd, Ord for these. @jimblandy thoughts?

[ErichDonGubler]

@teoxoy:

I'm not sure how much value there is in deriving PartialOrd, Ord for these. @jimblandy thoughts?

The only value I can think of for these (and Hash) is if somebody wanted to use these bitflags structures as an ordered set, or as tree keys. I don't think that that's surface we want to support right now, is it?

[jimblandy]

We should derive only the traits we actually need. I believe they contribute to compile time, even if you don't use them, but more importantly, deriving them leads one to wonder what those traits are used for. Seeing that a trait is not derived is actually a helpful hint (of course, there could be impls elsewhere, so it's just a hint, but...).

[teoxoy]

Some of these types are public and they previously had all of those traits automatically derived by bitflags. I imagine we always want Clone, Copy, Debug, I can see people using PartialEq, Eq. PartialOrd, Ord, Hash I'm not sure if are that useful for bitfields.

[teoxoy]

Proposal: remove PartialOrd, Ord, Hash and if people want them back, we can add them back later

[daxpedda]

Done.

[daxpedda]

Some types require Hash as they are used in HashMaps: 89f1425.
PartialOrd and Ord could be removed by removing the requirements from types containing them.

[teoxoy]

LGTM, thanks!