Closed astraw closed 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?
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.
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.)
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.
│ │ │ └── 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.
Ohh, TIL cargo tree --edges=features
. Very useful. Thanks.
I look forward to the fix and thanks for your immediate action.
This is fixed in 1.0.10
Yes, that fixes the issue. Thanks once again!
Hi, enumset is depended upon by the
stm32f3xx-hal
crate v0.9.0 under theenumset
feature flag, which is enabled by default. However, the recent 1.0.9 of enumset release broke my builds with the following error:Indeed
stm32f3xx-hal
targetsthumbv7em-none-eabihf
for whichstd
is not available. It looks like the newproc-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:If I update to 6cd9f944098dafb1c0fb9e9a3d9d3fb3fdc625d6, however, I get the error again.