Closed ilyvion closed 2 years ago
Thanks for the report!
What does rustup show say and which is used by default just off curiosity ?
There is some logic going how the used rustc etc. gets selected. Manifest parsing is more involved.
We had ~this before: https://github.com/rust-secure-code/cargo-geiger/issues/181 so it may be related.
We are currently on latest cargo dependency which I think was 0.63
I will need to replicate and see what is going on.
@alexschrod Could you share your Cargo.toml please or the relevant bit re: what it is complaining is fine. Thanks!
❯ rustup show
Default host: x86_64-pc-windows-msvc
rustup home: C:\Users\alexs\.rustup
installed toolchains
--------------------
stable-x86_64-pc-windows-msvc
nightly-2022-04-05-x86_64-pc-windows-msvc
nightly-2022-07-08-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc
1.56-x86_64-pc-windows-msvc
1.60-x86_64-pc-windows-msvc
1.42.0-x86_64-pc-windows-msvc
installed targets for active toolchain
--------------------------------------
wasm32-unknown-unknown
x86_64-pc-windows-msvc
active toolchain
----------------
stable-x86_64-pc-windows-msvc (default)
rustc 1.62.1 (e092d0b6b 2022-07-16)
I'm using the stable, default toolchain as my default, and there are no overrides active in my project as far as I can tell:
❯ rustc --version
rustc 1.62.1 (e092d0b6b 2022-07-16)
❯ cargo --version
cargo 1.62.1 (a748cf5a3 2022-06-08)
You can clone the repo I'm getting this behavior on if that helps: https://github.com/alexschrod/nombytes
EDIT: I should have realised straight off it was the cargo (as a library) dependency :D I had a brainfreeze :rofl:
I have a that itchy feeling this is some rust target specific thing.. namedly windows
I have to investigate but I don't have windows machine so have to figure MS ISO or VM
It works fine for me on both rustup default stable and nightly in Ubuntu and docker
$ uname -av
Linux foobar-MS-7C77 5.11.0-46-generic #51~20.04.1-Ubuntu SMP Fri Jan 7 06:51:40 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ rustup show Default host: x86_64-unknown-linux-gnu rustup home: /home/foobar/.rustup
stable-x86_64-unknown-linux-gnu (default) nightly-2022-01-17-x86_64-unknown-linux-gnu nightly-x86_64-unknown-linux-gnu 1.46-x86_64-unknown-linux-gnu 1.47-x86_64-unknown-linux-gnu 1.48-x86_64-unknown-linux-gnu 1.49-x86_64-unknown-linux-gnu 1.51-x86_64-unknown-linux-gnu 1.52-x86_64-unknown-linux-gnu stage1 1.62.1-x86_64-unknown-linux-gnu
wasm32-unknown-unknown wasm32-wasi x86_64-unknown-linux-gnu
stable-x86_64-unknown-linux-gnu (default) rustc 1.61.0 (fe5b13d68 2022-05-18)
Oh, I just noticed something; not sure if it matters, but both on my Windows and my WSL2 Ubuntu installs, I'm getting
...
Compiling cargo v0.60.0
...
when doing cargo install cargo-geiger
. Now 1.60 was when the feature was stabilized, so if cargo's version stays in line with that, then it still should've supported it, but it's not 0.63 in any case.
Oh yeah :woman_facepalming: ... I should have released our 0.63 dependency change
Did you pull the release from crates.io or main from github ? I should really push a release out ! thnaks for reminding :purple_heart:
I've just done cargo install cargo-geiger
like the README says. 😅
yeah it pulls it from the crates.io.. this is my neglect of forgetting to release. I will do one now. Thank you so much :purple_heart:
I have a feeling we solved #181 as well :partying_face:
@alexschrod fyi the release is out :partying_face:
Which is odd, because namespaced features has been stable since 1.60 and none of the other cargo tools I have are choking on my Cargo.toml.