bitflags v2.2 incompatibility with mysql_common

glueball commented

2023-04-19 04:56:49 -05:00

(Migrated from github.com)

Originally posted on mysql_common repo (https://github.com/blackbeam/rust_mysql_common/issues/87), but the maintainer there seems to think this is an issue with bitflags, so just letting you know. I don't know whether this is a bug on bitflags itself or on how mysql_common uses it, but at the very least might be a compatibility break on 2.2.

Trying to compile the last version of the mysql_common crate with bitflags 2.2 gives a compilation error.

Minimal example:

Cargo.toml

[package]
name = "minimal-bitfields"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
mysql_common = "0.30.3"

main.rs

fn main() {
    println!("Hello, world!");
}

Compilation output:

error: recursion limit reached while expanding `__declare_bitflags!`
   --> C:\Users\jaumelopez\.cargo\registry\src\github.com-1ecc6299db9ec823\mysql_common-0.30.3\src\constants.rs:78:1
    |
78  | / my_bitflags! {
79  | |     CapabilityFlags,
80  | |     #[error("Unknown flags in the raw value of CapabilityFlags (raw={:b})", _0)]
81  | |     UnknownCapabilityFlags,
...   |
357 | |     }
358 | | }
    | |_^
    |
    = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`mysql_common`)
    = note: this error originates in the macro `__declare_bitflags` which comes from the expansion of the macro `my_bitflags` (in Nightly builds, run with -Z macro-backtrace for more info)

"Pinning" bitflags to 2.1 fixes the compilation error.

"Fixed" Cargo.toml

[package]
name = "minimal-bitfields"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
bitflags = "=2.1"
mysql_common = "0.30.3"

Originally posted on mysql_common repo (https://github.com/blackbeam/rust_mysql_common/issues/87), but the maintainer there seems to think this is an issue with bitflags, so just letting you know. I don't know whether this is a bug on bitflags itself or on how mysql_common uses it, but at the very least might be a compatibility break on 2.2. Trying to compile the last version of the mysql_common crate with bitflags 2.2 gives a compilation error. Minimal example: Cargo.toml ``` [package] name = "minimal-bitfields" version = "0.1.0" edition = "2021" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html [dependencies] mysql_common = "0.30.3" ``` main.rs ``` fn main() { println!("Hello, world!"); } ``` Compilation output: ``` error: recursion limit reached while expanding `__declare_bitflags!` --> C:\Users\jaumelopez\.cargo\registry\src\github.com-1ecc6299db9ec823\mysql_common-0.30.3\src\constants.rs:78:1 | 78 | / my_bitflags! { 79 | | CapabilityFlags, 80 | | #[error("Unknown flags in the raw value of CapabilityFlags (raw={:b})", _0)] 81 | | UnknownCapabilityFlags, ... | 357 | | } 358 | | } | |_^ | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`mysql_common`) = note: this error originates in the macro `__declare_bitflags` which comes from the expansion of the macro `my_bitflags` (in Nightly builds, run with -Z macro-backtrace for more info) ``` "Pinning" bitflags to 2.1 fixes the compilation error. "Fixed" Cargo.toml ``` [package] name = "minimal-bitfields" version = "0.1.0" edition = "2021" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html [dependencies] bitflags = "=2.1" mysql_common = "0.30.3" ```

KodrAus commented

2023-04-19 06:23:19 -05:00

(Migrated from github.com)

Hi @glueball 👋

That looks like a bug in bitflags so I'll take a look 👀 That __declare_bitflags macro is new so it might have a recursion bug in it somewhere.

Hi @glueball :wave: That looks like a bug in `bitflags` so I'll take a look :eyes: That `__declare_bitflags` macro is new so it might have a recursion bug in it somewhere.

KodrAus commented

2023-04-19 06:25:38 -05:00

(Migrated from github.com)

I've yanked 2.2.0 until we know what's going on to avoid too many spurious reports of the same issue in upstream repositories.

I've yanked `2.2.0` until we know what's going on to avoid too many spurious reports of the same issue in upstream repositories.

👍 1

KodrAus commented

2023-04-19 06:43:54 -05:00

(Migrated from github.com)

This is caused by #341

It's not infinitely recursing, just doing a lot more recursion than before. That code was introduced to work around an issue with some attributes like #[doc(alias)] not being allowed on expressions. We use a tt-muncher to sift through those attributes and only apply #[cfg]s to expressions internally that refer to flags.

I think we've got a few ways forward:

Tell everyone to add #[recursion_limit] if they run into it. I don't think that's really tenable because it's likely pretty widespread.
Try reformulate our code so that the only places we use flags types are also places we can call a macro. That way, instead of the max depth of our stack being each attribute on each flag, it becomes max attributes on any one flag.

I think option 2 is probably the best.

This is caused by #341 It's not infinitely recursing, just doing a lot more recursion than before. That code was introduced to work around an issue with some attributes like `#[doc(alias)]` not being allowed on expressions. We use a tt-muncher to sift through those attributes and only apply `#[cfg]`s to expressions internally that refer to flags. I think we've got a few ways forward: 1. Tell everyone to add `#[recursion_limit]` if they run into it. I don't think that's really tenable because it's likely pretty widespread. 2. Try reformulate our code so that the only places we use flags types are also places we can call a macro. That way, instead of the max depth of our stack being each attribute on each flag, it becomes max attributes on any one flag. I think option 2 is probably the best.

Rows
Columns

bitflags v2.2 incompatibility with mysql_common #343