std::cell::RefCell<regex::exec::ProgramCacheInner> can't be shared between threads

[sophiajt]

Apologies if this is documented and I missed it. I'm currently working with regex in some async stream work, and came across this error:

error[E0277]: `std::cell::RefCell<regex::exec::ProgramCacheInner>` cannot be shared between threads safely
   --> crates/nu-cli/src/commands/parse.rs:155:15
    |
155 |     Ok(stream.to_output_stream())
    |               ^^^^^^^^^^^^^^^^ `std::cell::RefCell<regex::exec::ProgramCacheInner>` cannot be shared between threads safely
    |
    = help: the trait `std::marker::Sync` is not implemented for `std::cell::RefCell<regex::exec::ProgramCacheInner>`

Is it possible to run regex in a mode that won't trip over the RefCell for the inner cache, by chance?

[BurntSushi]

Can you provide a sample reproduction? Regex itself implements both Send and Sync, so it's not clear to me why you're seeing this error.

[sophiajt]

@BurntSushi - apologies for the noise. I managed to work around it using a different approach. I had been using the async_stream! macro to help create an async stream of output, but there was some kind of bad interaction between it and regex. When I rewrote it using the normal stream operators (like .map), the error went away.

[kangalio]

I ran into the same error with Regex 1.3.9 in my project. Updating this crate to the latest 1.4.5 fixed it.

CaptureMatches (which I was using) does not implement Send in that version which can also be seen in its documentation:
https://docs.rs/regex/1.3.9/regex/struct.CaptureMatches.html#impl-Send

Not sure why that is, but in case anyone else is running into this, upgrading to latest version should fix it.

[BurntSushi]

@kangalioo That's interesting. I am myself not even sure why the Send impl changed for the CaptureMatches iterator. There's been some recent work in this area, specifically, #749. But CaptureMatches should have still been Send.

Since regex uses iterior mutability and does some of its own synchronization, a lot of these marker traits are relevant. It's probably a compatibility hazard at this point, which means we probably need to be a bit more rigorous about asserting which marker traits are implemented on each public API type. A tedious endeavor, no doubt.