hawkw / sharded-slab

a lock-free concurrent slab (experimental)
MIT License
273 stars 19 forks source link

error when building #92

Open Altanis opened 10 months ago

Altanis commented 10 months ago
error[E0195]: lifetime parameters or bounds on type Target do not match the trait declaration --> /Users/altanis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sharded-slab-0.1.7/src/tid.rs:32:1 32 / lazy_static! { 33 static ref REGISTRY: Registry = Registry { 34 next: AtomicUsize::new(0), 35 free: Mutex::new(VecDeque::new()), 36 }; 37 } _^ lifetimes do not match type in trait

= note: this error originates in the macro __lazy_static_internal which comes from the expansion of the macro lazy_static (in Nightly builds, run with -Z macro-backtrace for more info)

Compiling thread_local v1.1.7 error[E0609]: no field free on type REGISTRY --> /Users/altanis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sharded-slab-0.1.7/src/tid.rs:150:14 150 .free ^^^^ unknown field
= note: available fields are: `__private_field`
error[E0609]: no field next on type REGISTRY --> /Users/altanis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sharded-slab-0.1.7/src/tid.rs:161:35 161 let id = REGISTRY.next.fetch_add(1, Ordering::AcqRel); ^^^^ unknown field
= note: available fields are: `__private_field`
error[E0609]: no field free on type REGISTRY --> /Users/altanis/.cargo/registry/src/index.crates.io-6f17d22bba15001f/sharded-slab-0.1.7/src/tid.rs:191:42 191 let mut free_list = REGISTRY.free.lock().unwrap_or_else(PoisonError::into_inner); ^^^^ unknown field
= note: available fields are: `__private_field`

Some errors have detailed explanations: E0195, E0609. For more information about an error, try rustc --explain E0195. error: could not compile sharded-slab (lib) due to 4 previous errors warning: build failed, waiting for other jobs to finish...

CheesyB commented 9 months ago

I have the same problem. I wanted to use color-eyre 0.6.2 which uses the latest verison here. I really wonder how this does not attract more attention. I'm using rust 1.76 tough, maybe that's the probelm.

hawkw commented 9 months ago

Can you share what RUSTFLAGS you've set and what features are enabled?

CheesyB commented 9 months ago

Hi, I basically tried to build this template repo through cargo-generate: here (which I don't know much about) With a fresh repo and only sharded-slabs as a dependency, it compiles. Again, clean cargo init and color-eyre as my only dependency it fails with the same error. This is the dependency which throws the error in the first place. This is my rustup:

installed toolchains
--------------------

stable-x86_64-apple-darwin (default)
nightly-x86_64-apple-darwin
1.48.0-x86_64-apple-darwin
1.76.0-x86_64-apple-darwin

active toolchain
----------------

stable-x86_64-apple-darwin (default)
rustc 1.75.0 (82e1608df 2023-12-21)

I also tried it with nighlty and rustc 1.78.0 but the same happens. For Rustflags I think I use all the defaults. But I don't know how to doubble check. I also get kind of similar errors when I compile the console crate and they are all related to the lazy_static macro and lifetimes. Hope this helps.

simbleau commented 8 months ago

I'm also having this issue, Rust 1.76 stable, but I'm on M1 (arm) apple, not x86.

I also filed this under lazy_static: https://github.com/rust-lang-nursery/lazy-static.rs/issues/217

Other resources I found: https://stackoverflow.com/questions/77710297/encountered-e0195-lifetime-parameters-or-bounds-on-type-target-do-not-match

pyrrho commented 6 months ago

I just hit this issue on rustc 1.78.0. I tried clearing the cargo registry (rm -rf ~/.cargo/registry/index), and uninstalling + reinstalling rustup/cargo. Neither fix worked for me.

I usually have RUSTC_BOOTSTRAP=1 and __CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS="dev" set in my .*rc, which may be related. Un-setting those allowed the build to succeed, and the build continues to succeed with them re-set, even after a cargo clean && rm -rf ~/.cargo/registry/index. If anyone else hits this issue, I would recommend (un)setting those env vars, and then re-setting to your baseline, see if that helps.

I sincerely hope that no one else has to go looking for advice on this, though.

hawkw commented 6 months ago

Well, that's certainly strange!