bors [Thu, 25 Jun 2015 08:24:23 +0000 (08:24 +0000)]
Auto merge of #26561 - SimonSapin:remove-titlecase, r=alexcrichton
I added it because it was easy (same a `char::to_lowercase`, just a different table), but it doesn’t make sense to have this in std but not str::to_titlecase, which would require https://github.com/unicode-rs/unicode-segmentation
At some point in the future this feature will be available (both on char and str) in a crates.io crate.
Simon Sapin [Thu, 25 Jun 2015 05:14:27 +0000 (22:14 -0700)]
Remove char::to_titlecase. Fix #26555
I added it because it was easy (same a `char::to_lowercase`,
just a different table), but it doesn’t make sense to have this
in std but not str::to_titlecase, which would require
https://github.com/unicode-rs/unicode-segmentation
At some point in the future this feature will be available
(both on char and str) in a crates.io crate.
bors [Wed, 24 Jun 2015 05:53:19 +0000 (05:53 +0000)]
Auto merge of #26526 - djc:patch-1, r=steveklabnik
In particular, I found that the disclaimer (promised in the second paragraph) doesn't stand out right now. I think the extra headers help with scanning this document, and making it easier to discern which steps are relevant to my particular flow through the options.
Dirkjan Ochtman [Tue, 23 Jun 2015 19:31:07 +0000 (21:31 +0200)]
Add some more headers to installation documentations
In particular, I found that the disclaimer (promised in the second paragraph) doesn't stand out right now. I think the extra headers help with scanning this document, and making it easier to discern which steps are relevant to my particular flow through the options.
bors [Tue, 23 Jun 2015 12:52:59 +0000 (12:52 +0000)]
Auto merge of #26354 - jroesch:remove-param-bounds-take-n, r=nikomatsakis
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.
bors [Tue, 23 Jun 2015 08:18:14 +0000 (08:18 +0000)]
Auto merge of #26513 - shunyata:master, r=alexcrichton
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 [Tue, 23 Jun 2015 01:00:48 +0000 (01:00 +0000)]
Auto merge of #26435 - gsingh93:master, r=nikomatsakis
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
```
Jake Hickey [Mon, 22 Jun 2015 22:38:19 +0000 (18:38 -0400)]
Use a more descriptive variable name.
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 [Mon, 22 Jun 2015 16:11:38 +0000 (16:11 +0000)]
Auto merge of #25784 - geofft:subprocess-signal-masks, r=alexcrichton
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`
bors [Mon, 22 Jun 2015 05:23:50 +0000 (05:23 +0000)]
Auto merge of #26037 - nhowell:plain_js_playpen, r=steveklabnik
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 [Thu, 11 Jun 2015 20:23:57 +0000 (16:23 -0400)]
Fix build on Android API levels below 21
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 [Sun, 24 May 2015 02:25:49 +0000 (22:25 -0400)]
sys/unix/process: Reset signal behavior before exec
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).
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 [Fri, 22 May 2015 21:30:06 +0000 (17:30 -0400)]
sys/unix/c.rs: Remove unused code
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).
bors [Sun, 21 Jun 2015 17:45:01 +0000 (17:45 +0000)]
Auto merge of #25641 - geofft:execve-const, r=alexcrichton
The `execv` family of functions and `getopt` are prototyped somewhat strangely in C: they take a `char *const argv[]` (and `envp`, for `execve`), an immutable array of mutable C strings -- in other words, a `char *const *argv` or `argv: *const *mut c_char`. The current Rust binding uses `*mut *const c_char`, which is backwards (a mutable array of constant C strings).
That said, these functions do not actually modify their arguments. Once upon a time, C didn't have `const`, and to this day, string literals in C have type `char *` (`*mut c_char`). So an array of string literals has type `char * []`, equivalent to `char **` in a function parameter (Rust `*mut *mut c_char`). C allows an implicit cast from `T **` to `T * const *` (`*const *mut T`) but not to `const T * const *` (`*const *const T`). Therefore, prototyping `execv` as taking `const char * const argv[]` would have broken existing code (by requiring an explicit cast), despite being more correct. So, even though these functions don't need mutable data, they're prototyped as if they do.
While it's theoretically possible that an implementation could choose to use its freedom to modify the mutable data, such an implementation would break the innumerable users of `execv`-family functions that call them with string literals. Such an implementation would also break `std::process`, which currently works around this with an unsafe `as *mut _` cast, and assumes that `execvp` secretly does not modify its argument. Furthermore, there's nothing useful to be gained by being able to write to the strings in `argv` themselves but not being able to write to the array containing those strings (you can't reorder arguments, add arguments, increase the length of any parameter, etc.).
So, despite the C prototype with its legacy C problems, it's simpler for everyone for Rust to consider these functions as taking `*const *const c_char`, and it's also safe to do so. Rust does not need to expose the mistakes of C here. This patch makes that change, and drops the unsafe cast in `std::process` since it's now unnecessary.
projects / rust.git / log