Lymia / enumset

A library for compact bit sets containing enums.
Apache License 2.0
91 stars 35 forks source link

regression: proc-macro-crate dependency introduced in 1.0.9 breaks no_std use #34

Closed astraw closed 2 years ago

astraw commented 2 years ago

Hi, enumset is depended upon by the stm32f3xx-hal crate v0.9.0 under the enumset feature flag, which is enabled by default. However, the recent 1.0.9 of enumset release broke my builds with the following error:

error[E0463]: can't find crate for `std`
  |
  = note: the `thumbv7em-none-eabihf` target may not support the standard library
  = note: `std` is required by `serde` because it does not declare `#![no_std]`

For more information about this error, try `rustc --explain E0463`.
error: could not compile `serde` due to previous error

Caused by:
  process didn't exit successfully: `rustc --crate-name serde C:\Users\drand\.cargo\registry\src\github.com-1ecc6299db9ec823\serde-1.0.136\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=s -C linker-plugin-lto -C debuginfo=2 --cfg "feature=\"default\"" --cfg "feature=\"std\"" -C metadata=4f4c1def9fa00289 -C extra-filename=-4f4c1def9fa00289 --out-dir C:\Users\drand\Documents\src\rust-cam\camtrig-firmware\target\thumbv7em-none-eabihf\release\deps --target thumbv7em-none-eabihf -L dependency=C:\Users\drand\Documents\src\rust-cam\camtrig-firmware\target\thumbv7em-none-eabihf\release\deps -L dependency=C:\Users\drand\Documents\src\rust-cam\camtrig-firmware\target\release\deps --cap-lints allow -C link-arg=-Tlink.x -C link-arg=-Tdefmt.x --cfg no_std_atomic64 --cfg no_std_atomic` (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: build failed

Indeed stm32f3xx-hal targets thumbv7em-none-eabihf for which std is not available. It looks like the new proc-macro-crate dependency introduced in 6cd9f944098dafb1c0fb9e9a3d9d3fb3fdc625d6 somehow causes this regression. I have not dug further.

Forcing the build to use b318bf1aaa69c863c7ec26475782cf4f69e0468b with the following in my Cargo.toml worksaround the error:

[patch.crates-io]
enumset = { git="https://github.com/Lymia/enumset", rev="b318bf1aaa69c863c7ec26475782cf4f69e0468b" }

If I update to 6cd9f944098dafb1c0fb9e9a3d9d3fb3fdc625d6, however, I get the error again.

Lymia commented 2 years ago

... That is extremely strange. proc_macro_crate should only be depended on at build-time, in which case it should be built for the host, not the target when cross-compiling. Do you have your Cargo.lock on-hand?

astraw commented 2 years ago

I hit the error in our internal gitlab CI server for the camtrig-firmware crate in this big mono-repo. The workaround-enumset-109 branch adds

[patch.crates-io]
enumset = { git="https://github.com/Lymia/enumset", rev="45cef9d8b1733d43c717153eea98ebedb41537f8" }

to Cargo.toml and the build then passes.

The Cargo.lock is present in the repo but I tend not to update it unless absolutely necessary. Perhaps that is the case here. I will run another CI build with this and report the outcome.

astraw commented 2 years ago

So, updating Cargo.lock does not magically solve the problem. With this lock file I still get the same error. (Tested on my local dev PC.)

Lymia commented 2 years ago

I can reproduce both the issue in the camtrig-firmware crate, and the fix. I'll look into this. If I don't find anything obvious, might just need to revert that change or put it behind a feature flag.

Lymia commented 2 years ago
│   │   │                   └── proc-macro-crate v1.1.3
[...]
│   │   │                       └── toml feature "default"
│   │   │                           └── toml v0.5.8
│   │   │                               └── serde feature "default"
│   │   │                                   ├── serde v1.0.136
│   │   │                                   └── serde feature "std"
│   │   │                                       └── serde v1.0.136

aggh. proc-macro-crate pulls toml which seems to be the root of it since it enables the std feature in serde. This is... not ideal. Adding resolver = "2" to Cargo.toml will fix this issue (because it allows the serde on the host side and target side to use different features) as a workaround for now.

I'll have to consider putting proc-macro-crate behind a feature flag too.

astraw commented 2 years ago

Ohh, TIL cargo tree --edges=features. Very useful. Thanks.

I look forward to the fix and thanks for your immediate action.

Lymia commented 2 years ago

This is fixed in 1.0.10

astraw commented 2 years ago

Yes, that fixes the issue. Thanks once again!