Compilation errors due to missing atomics even though `atomic` feature is not enabled about bitvec HOT 3 CLOSED

Hi! I apologize for the long delay; I have had a very stressful winter and have not had the time or energy to check this repository in a timely manner. I'm trying to catch up now.

Thank you for your time investigating this, and for duplicating effort in the monorepo. radium is a really annoying project to manage. Being able to punt to the compiler as of Rust 1.60 is a huge relief, and I have already migrated to radium 1 in my working copy.

I suspect that the reason for your initial error is just that radium 0 requires that we manually process target definitions taken from the compiler, and I don't think we collected BPF targets last time we did that.

I am pretty sure I can migrate to radium 1 without a major-version bump, so I intend to do so in bitvec 1.1.

If you require a Send bound, then Nucleus is failing as expected when your final target doesn't have the requisite atomic. It silently falls back to Cell, which isn't threadsafe. You'd have to either #[cfg]-guard your type on the presence of the needed atomic, or do exactly what you did: remove the bound here, and then encounter compiler errors when you attempt to do multithreading on a target without proper atomics.

The advantage is that now your errors occur at the use site, not at the declaration site: thread::spawn will fail, instead of your typedecl.

I think the fact that Cell<*mut T> isn't Send is an irritating discrepancy: AtomicPtr is Send, and Cells are Send when their interior is. The reason that Cell<*mut T> isn't Send is that the pointer might become invalid to dereference if a foreign thread has a time delay between receipt and use. This, however, is equally true of the pointer value stored inside an AtomicPtr!

Unfortunately, I'm pretty sure impl<T> Send for Cell<*mut T> collides with impl<T: Send> Send for Cell<T> (pointers aren't fundamental types like references are), and removing the Send impl on atomic pointers is a breaking change, so we're just left with it.

I hope this helps!

from bitvec.

As suggested in ferrilab/ferrilab#1, I tried to (naively) update bitvec to radium 1.0.0 here: https://github.com/arctic-alpaca/bitvec
The bitvec tests seem to pass as before the update but when using the updated version in my project, I encountered this error from radium:

error[E0277]: `*mut T` cannot be sent between threads safely
   --> /home/arctic-alpaca/.cargo/registry/src/github.com-1ecc6299db9ec823/radium-1.0.0/src/types.rs:201:19
    |
201 |               type Nucleus = $radium$(<$t>)?;
    |                              ^^^^^^^^^^^^^ `*mut T` cannot be sent between threads safely
...
223 | / alias! {
224 | |     "8" => {
225 | |         bool => RadiumBool => AtomicBool;
226 | |         i8 => RadiumI8 => AtomicI8;
...   |
249 | |     }
250 | | }
    | |_- in this macro invocation
    |
    = help: the trait `Send` is not implemented for `*mut T`
    = help: the trait `Send` is implemented for `&T`
    = note: required for `Cell<*mut T>` to implement `Send`
note: required by a bound in `marker::Nuclear::Nucleus`
   --> /home/arctic-alpaca/.cargo/registry/src/github.com-1ecc6299db9ec823/radium-1.0.0/src/marker.rs:45:38
    |
45  |     type Nucleus: Radium<Item = Self> + Send;
    |                                         ^^^^ required by this bound in `Nuclear::Nucleus`
    = note: this error originates in the macro `alias` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0277`.

After removing the Send bound (https://github.com/arctic-alpaca/ferrilab), I was able to use bitvec in my project. I do not know what the implication/effect of removing the Send bound is or if my simple update of bitvec has any side effects. If desired, I'd be happy to create a PR.

EDIT: After realizing you are migrating to a monorepo, I pushed the bitvec changes to the monorepo fork: https://github.com/arctic-alpaca/ferrilab

from bitvec.

Hello @myrrlyn thanks for the amazing library. However, I think this issue has not been solved, the main branch still refers to radium v0.7.

from bitvec.