Skip to content
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

read_line() fails with an unknown error when run in PowerShell (Windows 7 x64) #13590

Closed
rillomas opened this issue Apr 18, 2014 · 3 comments
Closed

Comments

@rillomas
Copy link

The following readline_sample.rs fails with an unknown error when I run it from cmd and PowerShell. The same sample works when I run it from mintty.
I'm using rust 0.10 on Windows 7 x64.

readline_sample.rs

use std::io;

fn main() {
    println!("Enter line.");
    match io::stdin().read_line() {
        Ok(s) => println!("typed {}", s),
        Err(e) => println!("error: {}", e)
    }
}

PowerShell output

PS C:\rust_sample> rustc -v .\readline_sample.rs
C:\Program Files (x86)\Rust\bin\rustc.exe 0.10
host: i686-pc-mingw32
PS C:\rust_sample> .\readline_sample.exe
Enter line.
error: unknown error (OS Error 8 (FormatMessageW() returned error 998))

mintty output

$ rustc -v ./readline_sample.rs
c:\Program Files (x86)\Rust\bin\rustc.exe 0.10
host: i686-pc-mingw32

$ ./readline_sample.exe
Enter line.
aaaaaa
typed aaaaaa
@alexcrichton
Copy link
Member

Closed by 6ac3492, I've confirmed that windows nightlies work ok on mintty/powershell

@rillomas
Copy link
Author

I should've checked the nightly... sorry about the false alarm.

@alexcrichton
Copy link
Member

No worries, thanks for the report!

matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this issue Nov 16, 2022
internal: Add proc-macro dependency to rustc_private crates
flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 28, 2024

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
Closes rust-lang#6947

This changes the lint to allow futures which are not `Send` as a result
of a generic type parameter not having a `Send` bound and only lint
futures that are always `!Send` for any type, which I believe is the
more useful behavior (like the comments in the linked issue explain).

This is still only a heuristic (I'm not sure if there's a more general
way to do this), but it should cover the common cases I could think of
(including the code examples in the linked issue)

changelog: [`future_not_send`]: allow conditional `Send` futures
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants