- 26 6月, 2015 1 次提交
-
-
由 Guillaume Gomez 提交于
-
- 25 6月, 2015 2 次提交
-
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
- 24 6月, 2015 4 次提交
-
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
- 23 6月, 2015 24 次提交
-
-
由 bors 提交于
r? @Manishearth
-
由 bors 提交于
-
由 bors 提交于
This pull request removes `ParamBounds` a old holdover in the type checker that we (@nikomatsakis and I) had wanted to remove. I'm not sure if the current form is the best possible refactor but I figured we can use this as a place to discuss it. r? @nikomatsakis
-
由 bors 提交于
-
由 bors 提交于
Closes #26420 r? @nikomatsakis
-
由 Oliver Schneider 提交于
-
由 bors 提交于
I'm currently reading the rust book and this variable name tripped me up. Because it was called "input", I thought at first it might contain the line read by read_line(). This new variable name will be more instructive to rust beginners.
-
由 Jared Roesch 提交于
-
由 Guillaume Gomez 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
Regressed by #26326
-
由 bors 提交于
-
由 bors 提交于
When a method exists in an impl but can not be used due to missing trait bounds for the type parameters, we should inform the user which trait bounds are missing. For example, this code ``` // Note this is missing a Debug impl struct Foo; fn main() { let a: Result<(), Foo> = Ok(()); a.unwrap() } ``` Now gives the following error: ``` /home/gulshan/tmp/tmp.rs:6:7: 6:15 error: no method named `unwrap` found for type `core::result::Result<(), Foo>` in the current scope /home/gulshan/tmp/tmp.rs:6 a.unwrap() ^~~~~~~~ /home/gulshan/tmp/tmp.rs:6:7: 6:15 note: The method `unwrap` exists but the following trait bounds were not satisfied: `Foo : core::fmt::Debug` error: aborting due to previous error ``` Fixes https://github.com/rust-lang/rust/issues/20941.
-
由 Tshepang Lekhonkhobe 提交于
-
由 Gulshan Singh 提交于
-
由 Jake Hickey 提交于
I'm currently reading the rust book and this variable name tripped me up. Because it was called "input", I thought at first it might contain the line read by read_line(). This new variable name will be more instructive to rust beginners.
-
由 bors 提交于
-
由 Yongqian Li 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 bors 提交于
Fix #26353.
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 bors 提交于
UNIX specifies that signal dispositions and masks get inherited to child processes, but in general, programs are not very robust to being started with non-default signal dispositions or to signals being blocked. For example, libstd sets `SIGPIPE` to be ignored, on the grounds that Rust code using libstd will get the `EPIPE` errno and handle it correctly. But shell pipelines are built around the assumption that `SIGPIPE` will have its default behavior of killing the process, so that things like `head` work: ``` geofft@titan:/tmp$ for i in `seq 1 20`; do echo "$i"; done | head -1 1 geofft@titan:/tmp$ cat bash.rs fn main() { std::process::Command::new("bash").status(); } geofft@titan:/tmp$ ./bash geofft@titan:/tmp$ for i in `seq 1 20`; do echo "$i"; done | head -1 1 bash: echo: write error: Broken pipe bash: echo: write error: Broken pipe bash: echo: write error: Broken pipe bash: echo: write error: Broken pipe bash: echo: write error: Broken pipe [...] ``` Here, `head` is supposed to terminate the input process quietly, but the bash subshell has inherited the ignored disposition of `SIGPIPE` from its Rust grandparent process. So it gets a bunch of `EPIPE`s that it doesn't know what to do with, and treats it as a generic, transient error. You can see similar behavior with `find / | head`, `yes | head`, etc. This PR resets Rust's `SIGPIPE` handler, as well as any signal mask that may have been set, before spawning a child. Setting a signal mask, and then using a dedicated thread or something like `signalfd` to dequeue signals, is one of two reasonable ways for a library to process signals. See carllerche/mio#16 for more discussion about this approach to signal handling and why it needs a change to `std::process`. The other approach is for the library to set a signal-handling function (`signal()` / `sigaction()`): in that case, dispositions are reset to the default behavior on exec (since the function pointer isn't valid across exec), so we don't have to care about that here. As part of this PR, I noticed that we had two somewhat-overlapping sets of bindings to signal functionality in `libstd`. One dated to old-IO and probably the old runtime, and was mostly unused. The other is currently used by `stack_overflow.rs`. I consolidated the two bindings into one set, and double-checked them by hand against all supported platforms' headers. This probably means it's safe to enable `stack_overflow.rs` on more targets, but I'm not including such a change in this PR. r? @alexcrichton cc @Zoxc for changes to `stack_overflow.rs`
-
- 22 6月, 2015 9 次提交
-
-
由 Seo Sanghyeon 提交于
-
由 bors 提交于
Since the "Book" already avoids jQuery in its inline script tags and playpen.js is tiny, I figured I would convert it to plain old JS as well. Side note: This is a separate issue, but another thing I noticed in my testing is that the "⇱" character doesn't display correctly in Chrome on Windows 7. (Firefox and IE work fine; other browsers not tested) r? @steveklabnik Edit: Github didn't like the "script" tag above Edit 2: Actually, now IE seems to render "⇱" fine for me. Odd.
-
由 Geoffrey Thomas 提交于
signal(), sigemptyset(), and sigaddset() are only available as inline functions until Android API 21. liblibc already handles signal() appropriately, so drop it from c.rs; translate sigemptyset() and sigaddset() (which is only used in a test) by hand from the C inlines. We probably want to revert this commit when we bump Android API level.
-
由 Geoffrey Thomas 提交于
Make sure that child processes don't get affected by libstd's desire to ignore SIGPIPE, nor a third-party library's signal mask (which is needed to use either a signal-handling thread correctly or to use signalfd / kqueue correctly).
-
由 Geoffrey Thomas 提交于
Both c.rs and stack_overflow.rs had bindings of libc's signal-handling routines. It looks like the split dated from #16388, when (what is now) c.rs was in libnative but not libgreen. Nobody is currently using the c.rs bindings, but they're a bit more accurate in some places. Move everything to c.rs (since I'll need signal handling in process.rs, and we should avoid duplication), clean up the bindings, and manually double-check everything against the relevant system headers (fixing a few things in the process).
-
由 Geoffrey Thomas 提交于
It looks like a lot of this dated to previous incarnations of the io module, etc., and went unused in the reworking leading up to 1.0. Remove everything we're not actively using (except for signal handling, which will be reworked in the next commit).
-
由 Geoffrey Thomas 提交于
The test that used it was removed in 700e627c.
-
由 bors 提交于
These issues are fixed but still open. Closes #18655. Closes #18988.
-
由 bors 提交于
This makes them compliant with the new version of RFC 401 (i.e. RFC 1052). Fixes #26391. I *hope* the tests I have are enough. This is a [breaking-change] r? @nrc
-