build(deps): bump bitflags from 2.2.1 to 2.3.1

[dependabot]

Bumps bitflags from 2.2.1 to 2.3.1.

Release notes

Sourced from bitflags's releases.

2.3.1

What's Changed

• Fix Self in flags value expressions by @​KodrAus in bitflags/bitflags#355
• Prepare for 2.3.1 release by @​KodrAus in bitflags/bitflags#358

Full Changelog: bitflags/bitflags@2.3.0...2.3.1

2.3.0

Major changes

BitFlags trait deprecated in favor of Flags trait

This release introduces the Flags trait and deprecates the BitFlags trait. These two traits are semver compatible so if you have public API code depending on BitFlags you can move to Flags without breaking end-users. This is possible because the BitFlags trait was never publicly implementable, so it now carries Flags as a supertrait. All implementations of Flags additionally implement BitFlags.

The Flags trait is a publicly implementable version of the old BitFlags trait. The original BitFlags trait carried some macro baggage that made it difficult to implement, so a new Flags trait has been introduced as the One True Trait for interacting with flags types generically. See the the macro_free and custom_derive examples for more details.

Bits trait publicly exposed

The Bits trait for the underlying storage of flags values is also now publicly implementable. This lets you define your own exotic backing storage for flags. See the custom_bits_type example for more details.

What's Changed

• Use explicit hashes for actions steps by @​KodrAus in bitflags/bitflags#350
• Support ejecting flags types from the bitflags macro by @​KodrAus in bitflags/bitflags#351

Full Changelog: bitflags/bitflags@2.2.1...2.3.0

Changelog

Sourced from bitflags's changelog.

2.3.1

What's Changed

• Fix Self in flags value expressions by @​KodrAus in bitflags/bitflags#355

Full Changelog: bitflags/bitflags@2.3.0...2.3.1

2.3.0

What's Changed

• Support ejecting flags types from the bitflags macro by @​KodrAus in bitflags/bitflags#351

Full Changelog: bitflags/bitflags@2.2.1...2.3.0

Commits

• cf01ab0 Merge pull request #358 from KodrAus/cargo/2.3.1
• 3d0c558 prepare for 2.3.1 release
• 32d406a Merge pull request #355 from KodrAus/fix/self-in-flags
• 64fc276 fix up example feature
• 8872a64 fix up clippy in CI
• 748d88c fix up clippy lints and flag exprs referring to Self
• a4b8c99 fix up custom bits test
• 4aa03b8 add regression test for Self in flags values
• 31d3e4a Merge pull request #352 from KodrAus/cargo/2.3.0
• 51e8197 prepare for 2.3.0 release
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[phip1611]

Are you sure that this is the right thing to do: always updating the feature version of our dependencies? I do not necessarily see a benefit in using the latest library version except there are essential security or feature enhancements. With our current strategy, we probably bloat the binaries of all users that in some cases might need the same library multiple times but at different versions (as they are on older versions), don't we?

[nicholasbishop]

You're quite right, I didn't think that through. Opened a PR to relax the requirement to any 2.x release: #815