allow clippy::bad_bit_mask in generated Debug impl #373
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi @ComputerDruid 👋 Thanks for the PR! Unless there's some critical safety issue that requires patching I don't think we'll make any more releases of |
stefano-garzarella
added a commit
to stefano-garzarella/svsm
that referenced
this pull request
Aug 25, 2023
Commit a94d48d ("SVSM/sev/utils: Suppress clippy::bad_bit_mask errors") was necessary because we use an older version of bitflags. As suggested in this [1] bitflags issue, let's switch to the latest version available. In this way we can avoid to suppress clippy::bad_bit_mask. Just minor adjustments needed to support bitflags 2.4.0. [1] bitflags/bitflags#373 Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
stefano-garzarella
added a commit
to stefano-garzarella/svsm
that referenced
this pull request
Aug 25, 2023
Commit a94d48d ("SVSM/sev/utils: Suppress clippy::bad_bit_mask errors") was necessary because we use an older version of bitflags. As suggested in this [1] bitflags issue, let's switch to the latest version available. In this way we can avoid to suppress clippy::bad_bit_mask. Just minor adjustments are needed to support bitflags 2.4.0. [1] bitflags/bitflags#373 Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
asomers
added a commit
to asomers/nix
that referenced
this pull request
Aug 28, 2023
This reverts commit 0c3afc2. This rolls back the version of bitflags used to 1.1. Upgrading bitflags to 2.0 inadvertently caused breaking changes in the r0.26 branch, by virtue of the methods that the bitflags! macro adds. Also, mask the bad_bit_mask lint, triggered by bitflags's generated code. That lint was the motivation for upgrading bitflags in the first place. The bitflags maintainers have decided not to fix those warnings in the 1.x release series. bitflags/bitflags#373 Fixes nix-rust#2112
stefano-garzarella
added a commit
to stefano-garzarella/svsm
that referenced
this pull request
Aug 29, 2023
Commit a94d48d ("SVSM/sev/utils: Suppress clippy::bad_bit_mask errors") was necessary because we use an older version of bitflags. As suggested in this [1] bitflags issue, let's switch to the latest version available. In this way we can avoid to suppress clippy::bad_bit_mask. Just minor adjustments are needed to support bitflags 2.4.0. [1] bitflags/bitflags#373 Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
vlovich
added a commit
to vlovich/glommio
that referenced
this pull request
Oct 5, 2023
Resolves clippy errors that are now caught: bitflags/bitflags#373
vlovich
added a commit
to vlovich/glommio
that referenced
this pull request
Oct 5, 2023
Resolves clippy errors that are now caught: bitflags/bitflags#373
glommer
pushed a commit
to DataDog/glommio
that referenced
this pull request
Oct 6, 2023
* fix CI: Bump minimum version to 1.65 backtrace picked up a new addr2line in a patch release that depends on 1.65. * Fix Cargo warning about resolver ``` warning: some crates are on edition 2021 which defaults to `resolver = "2"`, but virtual workspaces default to `resolver = "1"` note: to keep the current resolver, specify `workspace.resolver = "1"` in the workspace root's manifest note: to use the edition 2021 resolver, specify `workspace.resolver = "2"` in the workspace root's manifest ``` * Fix clippy warnings in newer Rust compilers. * Upgrade to bitflags 2 Resolves clippy errors that are now caught: bitflags/bitflags#373 * Add test highlighting the problem * Fix background thread pool unbound placement Any threads we spawn inherit our affinity. This means that background thread pools for any executors that don't have an affinity of "Unbound" will only ever run on the executor's CPU rather than distributing work across many CPUs. This seems undesirable given that the background thread pool placement can be set independent of the executor it's associated with. Additionally, the background thread pool placement by default uses the pool placement so this has no impact on background threads that didn't have a custom placement set (& if the placement was set, it was likely the wrong thing happening).
MarijnS95
added a commit
to MarijnS95/libv4l-rs
that referenced
this pull request
Nov 9, 2023
CI throws an `clippy::bad_bit_mask` that has been fixed in `bitflags 2` [1], and it is always a good idea to stay up to date with the latest crate releases. The major change is an internal restructuring into _two_ types, that require the user to now re-expose default traits implemented on the inner type to the outer type by `#[derive]`'ing them. [1]: bitflags/bitflags#373
5 tasks
facebook-github-bot
pushed a commit
to facebook/ocamlrep
that referenced
this pull request
Jan 16, 2024
Summary: ## Motivation Since the latest compiler update, we are getting `clippy::bad_bit_mask` errors at the callsites of `bitflags!` macros where one of the variant is zero. [Upstream won't address it in the `1.x` branch](bitflags/bitflags#373) and recommends upgrading to the `2.x` branch. We are very close to reaching **zero clippy lints** in [Mononoke and other servers](https://fburl.com/code/pd76yn5e), which would feel nice. ## Specific categories of changes (in case it helps with the code review) The change from `1.x` to `2.x` introduces a number of backward compatibility breakages which I had to workaround in our codebase. See [the release notes for 2.0](https://github.com/bitflags/bitflags/releases/tag/2.0.0) for the explanation for the manual fixes I had to perform at each call site. --- **Adding traits to derive:** ``` #[derive(PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Clone, Copy)] ``` > Generated flags types now derive fewer traits. If you need to maintain backwards compatibility, you can derive the following yourself: --- **Replacing read uses of `.bits` with `.bits()`** > You can now use the .bits() method instead of the old .bits. > The representation of generated flags types has changed from a struct with the single field bits to a newtype. --- **Replacing raw setting of `.bits` with `.from_bits_retain()`** Due to the point above, the representation of the type is not exposed anymore. From [the documentation](https://docs.rs/bitflags/latest/bitflags/example_generated/struct.Flags.html#method.from_bits_retain), `from_bits_retain` "convert from a bits value exactly", which matches the old behaviour --- **Replacing the unsafe `from_bits_unchecked` method with `from_bits_retain`** > The unsafe from_bits_unchecked method is now a safe from_bits_retain method. --- **Extracting some structs outside of the `bitflags!` macro** Apart from the derives that `bitflags` knows about, such as `serde`, `bitflags` now can't deal with custom derives in macros with the previous syntax. I followed the recommendation from [their documentation](https://docs.rs/bitflags/latest/bitflags/index.html#custom-derives) to declare the `struct` ahead of of the macro call and only declare the `impl` block inside the macro. --- **Changes to test output** This does not stand out in the release notes, but as of [this upstream PR](bitflags/bitflags#297), the `Debug` output of generated bitflags has changed. This means any tests that rely on this (and of course, there are a few) needed updating. In particular, the `vespa` tests rely on that output in a non-obvious way. You might have to trust me (and CI) on these ones... Reviewed By: dtolnay Differential Revision: D49742979 fbshipit-source-id: c818c37af45f0964e8fdb7ec6173ad66bb982c00
facebook-github-bot
pushed a commit
to facebookexperimental/reverie
that referenced
this pull request
Jan 16, 2024
Summary: ## Motivation Since the latest compiler update, we are getting `clippy::bad_bit_mask` errors at the callsites of `bitflags!` macros where one of the variant is zero. [Upstream won't address it in the `1.x` branch](bitflags/bitflags#373) and recommends upgrading to the `2.x` branch. We are very close to reaching **zero clippy lints** in [Mononoke and other servers](https://fburl.com/code/pd76yn5e), which would feel nice. ## Specific categories of changes (in case it helps with the code review) The change from `1.x` to `2.x` introduces a number of backward compatibility breakages which I had to workaround in our codebase. See [the release notes for 2.0](https://github.com/bitflags/bitflags/releases/tag/2.0.0) for the explanation for the manual fixes I had to perform at each call site. --- **Adding traits to derive:** ``` #[derive(PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Clone, Copy)] ``` > Generated flags types now derive fewer traits. If you need to maintain backwards compatibility, you can derive the following yourself: --- **Replacing read uses of `.bits` with `.bits()`** > You can now use the .bits() method instead of the old .bits. > The representation of generated flags types has changed from a struct with the single field bits to a newtype. --- **Replacing raw setting of `.bits` with `.from_bits_retain()`** Due to the point above, the representation of the type is not exposed anymore. From [the documentation](https://docs.rs/bitflags/latest/bitflags/example_generated/struct.Flags.html#method.from_bits_retain), `from_bits_retain` "convert from a bits value exactly", which matches the old behaviour --- **Replacing the unsafe `from_bits_unchecked` method with `from_bits_retain`** > The unsafe from_bits_unchecked method is now a safe from_bits_retain method. --- **Extracting some structs outside of the `bitflags!` macro** Apart from the derives that `bitflags` knows about, such as `serde`, `bitflags` now can't deal with custom derives in macros with the previous syntax. I followed the recommendation from [their documentation](https://docs.rs/bitflags/latest/bitflags/index.html#custom-derives) to declare the `struct` ahead of of the macro call and only declare the `impl` block inside the macro. --- **Changes to test output** This does not stand out in the release notes, but as of [this upstream PR](bitflags/bitflags#297), the `Debug` output of generated bitflags has changed. This means any tests that rely on this (and of course, there are a few) needed updating. In particular, the `vespa` tests rely on that output in a non-obvious way. You might have to trust me (and CI) on these ones... Reviewed By: dtolnay Differential Revision: D49742979 fbshipit-source-id: c818c37af45f0964e8fdb7ec6173ad66bb982c00
facebook-github-bot
pushed a commit
to facebook/errpy
that referenced
this pull request
Jan 16, 2024
Summary: ## Motivation Since the latest compiler update, we are getting `clippy::bad_bit_mask` errors at the callsites of `bitflags!` macros where one of the variant is zero. [Upstream won't address it in the `1.x` branch](bitflags/bitflags#373) and recommends upgrading to the `2.x` branch. We are very close to reaching **zero clippy lints** in [Mononoke and other servers](https://fburl.com/code/pd76yn5e), which would feel nice. ## Specific categories of changes (in case it helps with the code review) The change from `1.x` to `2.x` introduces a number of backward compatibility breakages which I had to workaround in our codebase. See [the release notes for 2.0](https://github.com/bitflags/bitflags/releases/tag/2.0.0) for the explanation for the manual fixes I had to perform at each call site. --- **Adding traits to derive:** ``` #[derive(PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Clone, Copy)] ``` > Generated flags types now derive fewer traits. If you need to maintain backwards compatibility, you can derive the following yourself: --- **Replacing read uses of `.bits` with `.bits()`** > You can now use the .bits() method instead of the old .bits. > The representation of generated flags types has changed from a struct with the single field bits to a newtype. --- **Replacing raw setting of `.bits` with `.from_bits_retain()`** Due to the point above, the representation of the type is not exposed anymore. From [the documentation](https://docs.rs/bitflags/latest/bitflags/example_generated/struct.Flags.html#method.from_bits_retain), `from_bits_retain` "convert from a bits value exactly", which matches the old behaviour --- **Replacing the unsafe `from_bits_unchecked` method with `from_bits_retain`** > The unsafe from_bits_unchecked method is now a safe from_bits_retain method. --- **Extracting some structs outside of the `bitflags!` macro** Apart from the derives that `bitflags` knows about, such as `serde`, `bitflags` now can't deal with custom derives in macros with the previous syntax. I followed the recommendation from [their documentation](https://docs.rs/bitflags/latest/bitflags/index.html#custom-derives) to declare the `struct` ahead of of the macro call and only declare the `impl` block inside the macro. --- **Changes to test output** This does not stand out in the release notes, but as of [this upstream PR](bitflags/bitflags#297), the `Debug` output of generated bitflags has changed. This means any tests that rely on this (and of course, there are a few) needed updating. In particular, the `vespa` tests rely on that output in a non-obvious way. You might have to trust me (and CI) on these ones... Reviewed By: dtolnay Differential Revision: D49742979 fbshipit-source-id: c818c37af45f0964e8fdb7ec6173ad66bb982c00
facebook-github-bot
pushed a commit
to facebookincubator/antlir
that referenced
this pull request
Jan 16, 2024
Summary: ## Motivation Since the latest compiler update, we are getting `clippy::bad_bit_mask` errors at the callsites of `bitflags!` macros where one of the variant is zero. [Upstream won't address it in the `1.x` branch](bitflags/bitflags#373) and recommends upgrading to the `2.x` branch. We are very close to reaching **zero clippy lints** in [Mononoke and other servers](https://fburl.com/code/pd76yn5e), which would feel nice. ## Specific categories of changes (in case it helps with the code review) The change from `1.x` to `2.x` introduces a number of backward compatibility breakages which I had to workaround in our codebase. See [the release notes for 2.0](https://github.com/bitflags/bitflags/releases/tag/2.0.0) for the explanation for the manual fixes I had to perform at each call site. --- **Adding traits to derive:** ``` #[derive(PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Clone, Copy)] ``` > Generated flags types now derive fewer traits. If you need to maintain backwards compatibility, you can derive the following yourself: --- **Replacing read uses of `.bits` with `.bits()`** > You can now use the .bits() method instead of the old .bits. > The representation of generated flags types has changed from a struct with the single field bits to a newtype. --- **Replacing raw setting of `.bits` with `.from_bits_retain()`** Due to the point above, the representation of the type is not exposed anymore. From [the documentation](https://docs.rs/bitflags/latest/bitflags/example_generated/struct.Flags.html#method.from_bits_retain), `from_bits_retain` "convert from a bits value exactly", which matches the old behaviour --- **Replacing the unsafe `from_bits_unchecked` method with `from_bits_retain`** > The unsafe from_bits_unchecked method is now a safe from_bits_retain method. --- **Extracting some structs outside of the `bitflags!` macro** Apart from the derives that `bitflags` knows about, such as `serde`, `bitflags` now can't deal with custom derives in macros with the previous syntax. I followed the recommendation from [their documentation](https://docs.rs/bitflags/latest/bitflags/index.html#custom-derives) to declare the `struct` ahead of of the macro call and only declare the `impl` block inside the macro. --- **Changes to test output** This does not stand out in the release notes, but as of [this upstream PR](bitflags/bitflags#297), the `Debug` output of generated bitflags has changed. This means any tests that rely on this (and of course, there are a few) needed updating. In particular, the `vespa` tests rely on that output in a non-obvious way. You might have to trust me (and CI) on these ones... Test Plan: dall_e_sandcastle_mondrian_style Reviewed By: dtolnay Differential Revision: D49742979 fbshipit-source-id: c818c37af45f0964e8fdb7ec6173ad66bb982c00
facebook-github-bot
pushed a commit
to facebookexperimental/hermit
that referenced
this pull request
Jan 16, 2024
Summary: ## Motivation Since the latest compiler update, we are getting `clippy::bad_bit_mask` errors at the callsites of `bitflags!` macros where one of the variant is zero. [Upstream won't address it in the `1.x` branch](bitflags/bitflags#373) and recommends upgrading to the `2.x` branch. We are very close to reaching **zero clippy lints** in [Mononoke and other servers](https://fburl.com/code/pd76yn5e), which would feel nice. ## Specific categories of changes (in case it helps with the code review) The change from `1.x` to `2.x` introduces a number of backward compatibility breakages which I had to workaround in our codebase. See [the release notes for 2.0](https://github.com/bitflags/bitflags/releases/tag/2.0.0) for the explanation for the manual fixes I had to perform at each call site. --- **Adding traits to derive:** ``` #[derive(PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Clone, Copy)] ``` > Generated flags types now derive fewer traits. If you need to maintain backwards compatibility, you can derive the following yourself: --- **Replacing read uses of `.bits` with `.bits()`** > You can now use the .bits() method instead of the old .bits. > The representation of generated flags types has changed from a struct with the single field bits to a newtype. --- **Replacing raw setting of `.bits` with `.from_bits_retain()`** Due to the point above, the representation of the type is not exposed anymore. From [the documentation](https://docs.rs/bitflags/latest/bitflags/example_generated/struct.Flags.html#method.from_bits_retain), `from_bits_retain` "convert from a bits value exactly", which matches the old behaviour --- **Replacing the unsafe `from_bits_unchecked` method with `from_bits_retain`** > The unsafe from_bits_unchecked method is now a safe from_bits_retain method. --- **Extracting some structs outside of the `bitflags!` macro** Apart from the derives that `bitflags` knows about, such as `serde`, `bitflags` now can't deal with custom derives in macros with the previous syntax. I followed the recommendation from [their documentation](https://docs.rs/bitflags/latest/bitflags/index.html#custom-derives) to declare the `struct` ahead of of the macro call and only declare the `impl` block inside the macro. --- **Changes to test output** This does not stand out in the release notes, but as of [this upstream PR](bitflags/bitflags#297), the `Debug` output of generated bitflags has changed. This means any tests that rely on this (and of course, there are a few) needed updating. In particular, the `vespa` tests rely on that output in a non-obvious way. You might have to trust me (and CI) on these ones... Reviewed By: dtolnay Differential Revision: D49742979 fbshipit-source-id: c818c37af45f0964e8fdb7ec6173ad66bb982c00
facebook-github-bot
pushed a commit
to facebook/hhvm
that referenced
this pull request
Jan 16, 2024
Summary: ## Motivation Since the latest compiler update, we are getting `clippy::bad_bit_mask` errors at the callsites of `bitflags!` macros where one of the variant is zero. [Upstream won't address it in the `1.x` branch](bitflags/bitflags#373) and recommends upgrading to the `2.x` branch. We are very close to reaching **zero clippy lints** in [Mononoke and other servers](https://fburl.com/code/pd76yn5e), which would feel nice. ## Specific categories of changes (in case it helps with the code review) The change from `1.x` to `2.x` introduces a number of backward compatibility breakages which I had to workaround in our codebase. See [the release notes for 2.0](https://github.com/bitflags/bitflags/releases/tag/2.0.0) for the explanation for the manual fixes I had to perform at each call site. --- **Adding traits to derive:** ``` #[derive(PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Clone, Copy)] ``` > Generated flags types now derive fewer traits. If you need to maintain backwards compatibility, you can derive the following yourself: --- **Replacing read uses of `.bits` with `.bits()`** > You can now use the .bits() method instead of the old .bits. > The representation of generated flags types has changed from a struct with the single field bits to a newtype. --- **Replacing raw setting of `.bits` with `.from_bits_retain()`** Due to the point above, the representation of the type is not exposed anymore. From [the documentation](https://docs.rs/bitflags/latest/bitflags/example_generated/struct.Flags.html#method.from_bits_retain), `from_bits_retain` "convert from a bits value exactly", which matches the old behaviour --- **Replacing the unsafe `from_bits_unchecked` method with `from_bits_retain`** > The unsafe from_bits_unchecked method is now a safe from_bits_retain method. --- **Extracting some structs outside of the `bitflags!` macro** Apart from the derives that `bitflags` knows about, such as `serde`, `bitflags` now can't deal with custom derives in macros with the previous syntax. I followed the recommendation from [their documentation](https://docs.rs/bitflags/latest/bitflags/index.html#custom-derives) to declare the `struct` ahead of of the macro call and only declare the `impl` block inside the macro. --- **Changes to test output** This does not stand out in the release notes, but as of [this upstream PR](bitflags/bitflags#297), the `Debug` output of generated bitflags has changed. This means any tests that rely on this (and of course, there are a few) needed updating. In particular, the `vespa` tests rely on that output in a non-obvious way. You might have to trust me (and CI) on these ones... Reviewed By: dtolnay Differential Revision: D49742979 fbshipit-source-id: c818c37af45f0964e8fdb7ec6173ad66bb982c00
facebook-github-bot
pushed a commit
to facebookincubator/below
that referenced
this pull request
Jan 16, 2024
Summary: ## Motivation Since the latest compiler update, we are getting `clippy::bad_bit_mask` errors at the callsites of `bitflags!` macros where one of the variant is zero. [Upstream won't address it in the `1.x` branch](bitflags/bitflags#373) and recommends upgrading to the `2.x` branch. We are very close to reaching **zero clippy lints** in [Mononoke and other servers](https://fburl.com/code/pd76yn5e), which would feel nice. ## Specific categories of changes (in case it helps with the code review) The change from `1.x` to `2.x` introduces a number of backward compatibility breakages which I had to workaround in our codebase. See [the release notes for 2.0](https://github.com/bitflags/bitflags/releases/tag/2.0.0) for the explanation for the manual fixes I had to perform at each call site. --- **Adding traits to derive:** ``` #[derive(PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Clone, Copy)] ``` > Generated flags types now derive fewer traits. If you need to maintain backwards compatibility, you can derive the following yourself: --- **Replacing read uses of `.bits` with `.bits()`** > You can now use the .bits() method instead of the old .bits. > The representation of generated flags types has changed from a struct with the single field bits to a newtype. --- **Replacing raw setting of `.bits` with `.from_bits_retain()`** Due to the point above, the representation of the type is not exposed anymore. From [the documentation](https://docs.rs/bitflags/latest/bitflags/example_generated/struct.Flags.html#method.from_bits_retain), `from_bits_retain` "convert from a bits value exactly", which matches the old behaviour --- **Replacing the unsafe `from_bits_unchecked` method with `from_bits_retain`** > The unsafe from_bits_unchecked method is now a safe from_bits_retain method. --- **Extracting some structs outside of the `bitflags!` macro** Apart from the derives that `bitflags` knows about, such as `serde`, `bitflags` now can't deal with custom derives in macros with the previous syntax. I followed the recommendation from [their documentation](https://docs.rs/bitflags/latest/bitflags/index.html#custom-derives) to declare the `struct` ahead of of the macro call and only declare the `impl` block inside the macro. --- **Changes to test output** This does not stand out in the release notes, but as of [this upstream PR](bitflags/bitflags#297), the `Debug` output of generated bitflags has changed. This means any tests that rely on this (and of course, there are a few) needed updating. In particular, the `vespa` tests rely on that output in a non-obvious way. You might have to trust me (and CI) on these ones... Reviewed By: dtolnay Differential Revision: D49742979 fbshipit-source-id: c818c37af45f0964e8fdb7ec6173ad66bb982c00
facebook-github-bot
pushed a commit
to facebook/sapling
that referenced
this pull request
Jan 16, 2024
Summary: ## Motivation Since the latest compiler update, we are getting `clippy::bad_bit_mask` errors at the callsites of `bitflags!` macros where one of the variant is zero. [Upstream won't address it in the `1.x` branch](bitflags/bitflags#373) and recommends upgrading to the `2.x` branch. We are very close to reaching **zero clippy lints** in [Mononoke and other servers](https://fburl.com/code/pd76yn5e), which would feel nice. ## Specific categories of changes (in case it helps with the code review) The change from `1.x` to `2.x` introduces a number of backward compatibility breakages which I had to workaround in our codebase. See [the release notes for 2.0](https://github.com/bitflags/bitflags/releases/tag/2.0.0) for the explanation for the manual fixes I had to perform at each call site. --- **Adding traits to derive:** ``` #[derive(PartialEq, Eq, PartialOrd, Ord, Hash, Debug, Clone, Copy)] ``` > Generated flags types now derive fewer traits. If you need to maintain backwards compatibility, you can derive the following yourself: --- **Replacing read uses of `.bits` with `.bits()`** > You can now use the .bits() method instead of the old .bits. > The representation of generated flags types has changed from a struct with the single field bits to a newtype. --- **Replacing raw setting of `.bits` with `.from_bits_retain()`** Due to the point above, the representation of the type is not exposed anymore. From [the documentation](https://docs.rs/bitflags/latest/bitflags/example_generated/struct.Flags.html#method.from_bits_retain), `from_bits_retain` "convert from a bits value exactly", which matches the old behaviour --- **Replacing the unsafe `from_bits_unchecked` method with `from_bits_retain`** > The unsafe from_bits_unchecked method is now a safe from_bits_retain method. --- **Extracting some structs outside of the `bitflags!` macro** Apart from the derives that `bitflags` knows about, such as `serde`, `bitflags` now can't deal with custom derives in macros with the previous syntax. I followed the recommendation from [their documentation](https://docs.rs/bitflags/latest/bitflags/index.html#custom-derives) to declare the `struct` ahead of of the macro call and only declare the `impl` block inside the macro. --- **Changes to test output** This does not stand out in the release notes, but as of [this upstream PR](bitflags/bitflags#297), the `Debug` output of generated bitflags has changed. This means any tests that rely on this (and of course, there are a few) needed updating. In particular, the `vespa` tests rely on that output in a non-obvious way. You might have to trust me (and CI) on these ones... Reviewed By: dtolnay Differential Revision: D49742979 fbshipit-source-id: c818c37af45f0964e8fdb7ec6173ad66bb982c00
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Nightly clippy seems to have learned to be able to see 0 values in fields of const structs. This is causing a bunch of warnings in bitflags usages which have consts defined as 0.
I only see this issue on the 1.0 branch.
Example reproducing the issue: