nix doesn't compile with bitflags-1.3.1 on rustc-1.45

[soenkehahn]

bitflags version 1.3.1 was recently released. nix specifies a dependency on bitflags with version constraint "1.1". Without a previously working Cargo.lock file cargo is now free to choose bitflags version 1.3.1 to satisfy nix's dependency. However, with that bitflags version, nix doesn't compile on rustc version 1.45. Here is one of the many errors I get:

error[E0658]: `if` is not allowed in a `const fn`
  --> src/fcntl.rs:28:1
   |
28 | / libc_bitflags! {
29 | |     pub struct AtFlags: c_int {
30 | |         AT_REMOVEDIR;
31 | |         AT_SYMLINK_FOLLOW;
...  |
39 | |     }
40 | | }
   | |_^
   |
   = note: see issue #49146 <https://github.com/rust-lang/rust/issues/49146> for more information
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

Since nix claims to build on rustc-1.41 and upwards, I think this is a bug/misconfiguration.

[soenkehahn]

Here's a related issue on the bitflags repo: bitflags/bitflags#255

[asomers]

Thanks for reporting this. I'll try to fix it and publish a new release soon.

[asomers]

Ok, I released v0.20.1, v0.21.1, and v0.22.1 to fix the issue. I'm not planning to make new releases for older branches, because we switched CI providers beginning with v0.20.0. To those of you still using Nix 0.19.1 or older, upgrade! Either upgrade Nix, or rustc.

[lopopolo]

@asomers when will this restricted dependency version constraint be relaxed? nix has now made the decision for me that I can't update to the newest version of bitflags, despite my project always building with the latest version of rustc.

I believe an acceptable workaround for folks not having a Cargo.lock is to generate one with cargo +nightly -Z minimal-versions generate-lockfile.

[asomers]

For now, you can use put nix = "=0.22.0" in your Cargo.toml file, if you don't care about older rustc versions. Or, wait a few more days and I'll release Nix 0.23.0 that uses bitflags-1.3.0.

[lopopolo]

Thank you!

[jcape]

Any word on the 0.23 release?

[asomers]

libc made a release a few days ago. There's just one more PR that needs to get finished before we can release 0.23: #1504 .

[asomers]

Just released 0.23.0.

[autumnontape]

@asomers This doesn't affect me personally, but you might want to know that the "< 1.3.0" bound on the bitflags dependency is forcing nix 0.20, 0.21, and 0.22 to resolve to the vulnerable versions 0.20.0, 0.21.0, and 0.22.0 when they appear in a dependency graph that also includes bitflags >= 1.3.0.

This is a worrying behavior of Cargo's dependency resolver that I personally didn't know about until I ran cargo audit in one of my workspaces today. If you want, you might be able to fix it by publishing versions 0.{20,21,22}.3 that are mostly identical to their respective .2 versions but with the bitflags version bound removed, followed by versions 0.{20,21,22}.4 that are identical to their respective .2 versions.

[asomers]

Sigh, this stupid bitflags problem has caused me more trouble than anything else in the history of this crate. But I think I've got a better solution. PR #1560 will get rid of the bitflags dependency entirely, and #1561 will permanently fix the problem for users of Cargo 1.56.0 and up. I'm just waiting on somebody to test 1560, then I'll publish a new release that includes it.

[jplatte]

Because of this, I can no longer just cargo update in a work project because I'm somewhat stuck with a dependency that pulls in nix 0.21.x. It just got worse after a vulnerability in tower-http (also used in that workspace) was found that affects 0.2.0; 0.2.1 fixes this but pulls in bitflags 1.3, so I have to ignore either advisory. That works since the tower-http dep only affects windows so isn't high severity or relevant right now, but it is super annoying.

I think it is a mistake for nix to regard MSRV bumps as breaking changes. It should be the exception that you have to fiddle with your dependency versions to get things to work securely. Currently, nix optimizes for compatibility with older Rust versions that aren't maintained (at least by upstream) while degrading the experience (and possibly exposing vulnerabilities) for people who are using the latest, upstream-supported compiler.