-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
regression: RefCell<LineWriter<std::io::stdio::StdoutRaw>>
cannot be shared between threads safely
#127340
Comments
Minimized: use std::io::{self, Write};
pub fn open_stdout() -> io::Result<Box<dyn Write + Sync + 'static>> {
let stdout = Box::leak(Box::new(io::stdout()));
let stdout = stdout.lock();
Ok(Box::new(stdout))
} |
cargo-bisect-rustc informs us it is rust-lang-ci@fd225fc This is collateral damage of
...apparently, std said it can have a little bit of unsoundness, as a treat? It seems like exposing #121440 is proving to be a good idea because otherwise we would not have had this actually audited. |
We have the options of
@rustbot label: I-libs-nominated Footnotes |
The other one minimizes to this: use std::io;
fn chunk() -> Result<(), io::Error> {
let stdout = io::stdout();
let mut handle = stdout.lock();
write_csv(&mut handle)
}
pub fn write_csv(_w: &mut (dyn io::Write + Sync)) -> Result<(), io::Error> {
Ok(())
} In both cases, we can see that the problem is only caused if someone deliberately erases the type of the StdoutLock and instead makes it a |
Can we try and see how much of crates break if we do 1? 2 feels like too much effort for little gain and 3 is not very pretty. Disclaimer: Absolute stdlib noob, just offering my first thoughts because it’s brought into my attention |
Based on @Mark-Simulacrum's original post, it seems only 2 crates with no dependents on crates.io, one of which seems to be an abandoned toy project. That strongly suggests people generally aren't doing this. There's lots to recommend taking the "shrug and do nothing" option, I just wanted to be thorough. If 3 ("fix the Guard to be actually-Sync") is doable without sacrificing large parts of ReentrantLock's functionality (or performance?) I would say it's the hands-down winner. I just have given it literally zero thought, though it sounds more like wishful thinking than plausible. |
Changing Fixing Therefore, I strongly prefer option 1: this was a soundness bug in |
Having it not be |
We should relnote this as a soundness fix. |
Wait, did T-libs ever actually discuss this? |
Ah, yes they did on the July 10 meeting, people were like "eh, acceptable". |
This was mentioned in the release notes (currently last line of compat notes):
Closing. |
Fixed in clap-io 0.1.1 |
The error seems probably correct, but it's not clear why this would have started failing now.
The text was updated successfully, but these errors were encountered: