Alex Crichton [Thu, 8 Jan 2015 01:17:15 +0000 (17:17 -0800)]
rollup merge of #20237: RustOS-Fork-Holding-Ground/master
libc is only used when the heap allocations are not defined externally, or defined in another crate. I assume these extern* configurations were added for the sake of those of us experimenting with freestanding Rust. Avoiding libc where possible is often very important for us.
bors [Wed, 7 Jan 2015 12:25:15 +0000 (12:25 +0000)]
auto merge of #20606 : alexcrichton/rust/stabilize-libc, r=brson
This commit prepares the liblibc library to be moved to crates.io. Unlike the
log, serialize, term, etc crates, the source for this crate will *not* be
duplicated out-of-tree. Instead a new rust-lang/libc repository will be created
with a submodule to this repository and it will use the source directly.
In order to compile within the stable ecosystem of Rust, this crate cannot link
to libcore, and it also needs some tweaks for the other attributes that it has.
As a result this commit tweaks the source of the crate to link to libcore when
built in tree but link to libstd when built via cargo.
Note that the rust-lang/libc crate isn't quite prepared just yet, there's a
Cargo bug or two that I'd like to iron out before publishing it. This is simply
preparing the in-tree source.
Alex Crichton [Tue, 6 Jan 2015 02:01:03 +0000 (18:01 -0800)]
libc: Prepare for movement to crates.io
This commit prepares the liblibc library to be moved to crates.io. Unlike the
log, serialize, term, etc crates, the source for this crate will *not* be
duplicated out-of-tree. Instead a new rust-lang/libc repository will be created
with a submodule to this repository and it will use the source directly.
In order to compile within the stable ecosystem of Rust, this crate cannot link
to libcore, and it also needs some tweaks for the other attributes that it has.
As a result this commit tweaks the source of the crate to link to libcore when
built in tree but link to libstd when built via cargo.
Note that the rust-lang/libc crate isn't quite prepared just yet, there's a
Cargo bug or two that I'd like to iron out before publishing it. This is simply
preparing the in-tree source.
Alex Crichton [Tue, 6 Jan 2015 23:38:56 +0000 (15:38 -0800)]
rollup merge of #20650: klutzy/omg-windows-error-mode
Believe or not, `CreateProcess()` is racy if several threads create
child processes: [0], [1], [2].
This caused some tests show crash dialogs during
`make check-stage#-rpass`.
More explanation:
On Windows, `SetErrorMode()` controls display of error dialogs: it
accepts new error mode and returns old error mode.
The error mode is process-global and automatically inherited to child
process when created.
MSYS2 bash shell internally sets it to not show error dialogs, therefore
`make check-stage#-rpass` should not show them either.
However, [1] says that `CreateProcess()` internally invokes
`SetErrorMode()` twice: at first it sets mode `0x8001` and saves
original mode, and at second it restores original mode.
So if two threads simultaneously call `CreateProcess()`, the first
thread sets error mode to `0x8001` then the second thread recognizes
that current error mode is `0x8001`. Therefore, The second thread will
create process with wrong error mode.
This really occurs inside `compiletest`: it creates several processes on
each thread, so some `run-pass` tests are invoked with wrong error mode
therefore show crash dialog.
This commit adds `StaticMutex` for `CreateProcess()` call. This seems
to fix the "dialog annoyance" issue.
Alex Crichton [Tue, 6 Jan 2015 23:38:38 +0000 (15:38 -0800)]
rollup merge of #20615: aturon/stab-2-thread
This commit takes a first pass at stabilizing `std::thread`:
* It removes the `detach` method in favor of two constructors -- `spawn`
for detached threads, `scoped` for "scoped" (i.e., must-join)
threads. This addresses some of the surprise/frustrating debug
sessions with the previous API, in which `spawn` produced a guard that
on destruction joined the thread (unless `detach` was called).
The reason to have the division in part is that `Send` will soon not
imply `'static`, which means that `scoped` thread creation can take a
closure over *shared stack data* of the parent thread. On the other
hand, this means that the parent must not pop the relevant stack
frames while the child thread is running. The `JoinGuard` is used to
prevent this from happening by joining on drop (if you have not
already explicitly `join`ed.) The APIs around `scoped` are
future-proofed for the `Send` changes by taking an additional lifetime
parameter. With the current definition of `Send`, this is forced to be
`'static`, but when `Send` changes these APIs will gain their full
flexibility immediately.
Threads that are `spawn`ed, on the other hand, are detached from the
start and do not yield an RAII guard.
The hope is that, by making `scoped` an explicit opt-in with a very
suggestive name, it will be drastically less likely to be caught by a
surprising deadlock due to an implicit join at the end of a scope.
* The module itself is marked stable.
* Existing methods other than `spawn` and `scoped` are marked stable.
The migration path is:
```rust
Thread::spawn(f).detached()
```
becomes
```rust
Thread::spawn(f)
```
while
```rust
let res = Thread::spawn(f);
res.join()
```
becomes
```rust
let res = Thread::scoped(f);
res.join()
```
Alex Crichton [Tue, 6 Jan 2015 23:29:18 +0000 (15:29 -0800)]
rollup merge of #20653: alexcrichton/entry-unstable
There's been some debate over the precise form that these APIs should take, and
they've undergone some changes recently, so these APIs are going to be left
unstable for now to be fleshed out during the next release cycle.
Alex Crichton [Tue, 6 Jan 2015 23:29:17 +0000 (15:29 -0800)]
rollup merge of #20652: vhbit/thread-key-type
This is a manual merge of #20627 and #20634 to avoid conflicts in rollup and also avoid one roundtrip. I've leave copyright to original author. If this one is moved to rollup original PR could be closed. cc @mneumann
@alexcrichton r?
Both FreeBSD and DragonFly define pthread_key_t as int, while Linux
defines it as uint. As pthread_key_t is used as an opaque type and
storage size of both int and uint are the same, this is rather a
cosmetic change.
iOS uses ulong (as OS X) so difference is critical on 64bit platforms.
Alex Crichton [Tue, 6 Jan 2015 23:29:15 +0000 (15:29 -0800)]
rollup merge of #20647: aturon/stab-2-error
This commit is a first past stabilization of `std::error`:
* The module is stable.
* The `FromError` trait and impls are stable
* The `Error` trait itself is left unstable, pending current APIs and
possible revisions during the alpha cycle.
Alex Crichton [Tue, 6 Jan 2015 23:24:58 +0000 (15:24 -0800)]
rollup merge of #20612: retep998/winsize
This calculates the width and height using the bounding box of the window in the buffer. Bounding box coordinates are inclusive so I have to add 1 to both dimensions.
Alex Crichton [Tue, 6 Jan 2015 23:24:52 +0000 (15:24 -0800)]
rollup merge of #20557: cactorium/prettyprinters
As per https://github.com/rust-lang/rust/issues/20405. To be more precise, the changes just the processing of enums when the name is "RUST$ENCODED$ENUM$..." so it correctly parses when there is more than one number encoding the location of the field it's looking for to determine state of the enum
Sean McArthur [Sat, 20 Dec 2014 08:09:35 +0000 (00:09 -0800)]
core: split into fmt::Show and fmt::String
fmt::Show is for debugging, and can and should be implemented for
all public types. This trait is used with `{:?}` syntax. There still
exists #[derive(Show)].
fmt::String is for types that faithfully be represented as a String.
Because of this, there is no way to derive fmt::String, all
implementations must be purposeful. It is used by the default format
syntax, `{}`.
This will break most instances of `{}`, since that now requires the type
to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the
correct fix. Types that were being printed specifically for users should
receive a fmt::String implementation to fix this.
Niko Matsakis [Mon, 5 Jan 2015 11:17:42 +0000 (06:17 -0500)]
Implement impl reachability rules. This is a [breaking-change]. Type
parameters on impls must now also appear in the trait ref, self type,
or some associated type declared on the impl. This ensures that they
are constrianed in some way and that the semantics of the trait system
are well-defined (always a good thing).
There are three major ways to fix this error:
1. Convert the trait to use associated types; most often the type
parameters are not constrained because they are in fact outputs of
the impl.
2. Move the type parameters to methods.
3. Add an additional type parameter to the self type or trait so that
the unused parameter can appear there.
In some cases, it is not possible to fix the impl because the trait
definition needs to be changed first (and that may be out of your
control). In that case, for the time being, you can opt out of these
rules by using `#[old_impl_check]` on the impl and adding a
`#![feature(old_impl_check)]` to your crate declaration.
Alex Crichton [Tue, 6 Jan 2015 18:25:12 +0000 (10:25 -0800)]
std: Revert stability of Entry-based APIs
There's been some debate over the precise form that these APIs should take, and
they've undergone some changes recently, so these APIs are going to be left
unstable for now to be fleshed out during the next release cycle.
Niko Matsakis [Tue, 6 Jan 2015 10:03:42 +0000 (05:03 -0500)]
Fix ICE that @steveklabnik encountered in rust-ice. The problems turned out to be that were being very loose with bound regions in trans (we were basically just ignoring and flattening binders). Since binders are significant to subtyping and hence to trait selection, this can cause a lot of problems. So this patch makes us treat them more strictly -- for example, we propagate binders, and avoid skipping past the `Binder` by writing `foo.0`.
Michael Neumann [Tue, 6 Jan 2015 09:53:32 +0000 (10:53 +0100)]
Tuning pthread_key_t type
Both FreeBSD and DragonFly define pthread_key_t as int, while Linux
defines it as uint. As pthread_key_t is used as an opaque type and
storage size of both int and uint are the same, this is rather a
cosmetic change.
iOS uses ulong (as OS X) so difference is critical on 64bit platforms.
klutzy [Tue, 6 Jan 2015 15:42:26 +0000 (00:42 +0900)]
std: prevent `CreateProcess()` race on Windows
Believe or not, `CreateProcess()` is racy if several threads create
child processes: [0], [1], [2].
This caused some tests show crash dialogs during
`make check-stage#-rpass`.
More explanation:
On Windows, `SetErrorMode()` controls display of error dialogs: it
accepts new error mode and returns old error mode.
The error mode is process-global and automatically inherited to child
process when created.
MSYS2 bash shell internally sets it to not show error dialogs, therefore
`make check-stage#-rpass` should not show them either.
However, [1] says that `CreateProcess()` internally invokes
`SetErrorMode()` twice: at first it sets mode `0x8001` and saves
original mode, and at second it restores original mode.
So if two threads simultaneously call `CreateProcess()`, the first
thread sets error mode to `0x8001` then the second thread recognizes
that current error mode is `0x8001`. Therefore, The second thread will
create process with wrong error mode.
This really occurs inside `compiletest`: it creates several processes on
each thread, so some `run-pass` tests are invoked with wrong error mode
therefore show crash dialog.
This commit adds `StaticMutex` for `CreateProcess()` call. This seems
to fix the "dialog annoyance" issue.
Aaron Turon [Tue, 6 Jan 2015 17:20:40 +0000 (09:20 -0800)]
Stabilize std::error
This commit is a first past stabilization of `std::error`:
* The module is stable.
* The `FromError` trait and impls are stable
* The `Error` trait itself is left unstable, pending current APIs and
possible revisions during the alpha cycle.
Aaron Turon [Mon, 5 Jan 2015 23:45:18 +0000 (15:45 -0800)]
Stabilize std::thread
This commit takes a first pass at stabilizing `std::thread`:
* It removes the `detach` method in favor of two constructors -- `spawn`
for detached threads, `scoped` for "scoped" (i.e., must-join)
threads. This addresses some of the surprise/frustrating debug
sessions with the previous API, in which `spawn` produced a guard that
on destruction joined the thread (unless `detach` was called).
The reason to have the division in part is that `Send` will soon not
imply `'static`, which means that `scoped` thread creation can take a
closure over *shared stack data* of the parent thread. On the other
hand, this means that the parent must not pop the relevant stack
frames while the child thread is running. The `JoinGuard` is used to
prevent this from happening by joining on drop (if you have not
already explicitly `join`ed.) The APIs around `scoped` are
future-proofed for the `Send` changes by taking an additional lifetime
parameter. With the current definition of `Send`, this is forced to be
`'static`, but when `Send` changes these APIs will gain their full
flexibility immediately.
Threads that are `spawn`ed, on the other hand, are detached from the
start and do not yield an RAII guard.
The hope is that, by making `scoped` an explicit opt-in with a very
suggestive name, it will be drastically less likely to be caught by a
surprising deadlock due to an implicit join at the end of a scope.
* The module itself is marked stable.
* Existing methods other than `spawn` and `scoped` are marked stable.
The migration path is:
```rust
Thread::spawn(f).detached()
```
becomes
```rust
Thread::spawn(f)
```
while
```rust
let res = Thread::spawn(f);
res.join()
```
becomes
```rust
let res = Thread::scoped(f);
res.join()
```
projects / rust.git / log