bors [Tue, 25 Mar 2014 04:56:50 +0000 (21:56 -0700)]
auto merge of #12991 : alexcrichton/rust/sync-chan, r=brson
This commit contains an implementation of synchronous, bounded channels for
Rust. This is an implementation of the proposal made last January [1]. These
channels are built on mutexes, and currently focus on a working implementation
rather than speed. Receivers for sync channels have select() implemented for
them, but there is currently no implementation of select() for sync senders.
Rust will continue to provide both synchronous and asynchronous channels as part
of the standard distribution, there is no intent to remove asynchronous
channels. This flavor of channels is meant to provide an alternative to
asynchronous channels because like green tasks, asynchronous channels are not
appropriate for all situations.
Alex Crichton [Mon, 17 Mar 2014 21:34:25 +0000 (14:34 -0700)]
comm: Implement synchronous channels
This commit contains an implementation of synchronous, bounded channels for
Rust. This is an implementation of the proposal made last January [1]. These
channels are built on mutexes, and currently focus on a working implementation
rather than speed. Receivers for sync channels have select() implemented for
them, but there is currently no implementation of select() for sync senders.
Rust will continue to provide both synchronous and asynchronous channels as part
of the standard distribution, there is no intent to remove asynchronous
channels. This flavor of channels is meant to provide an alternative to
asynchronous channels because like green tasks, asynchronous channels are not
appropriate for all situations.
bors [Tue, 25 Mar 2014 01:11:51 +0000 (18:11 -0700)]
auto merge of #12900 : alexcrichton/rust/rewrite-sync, r=brson
* Remove clone-ability from all primitives. All shared state will now come
from the usage of the primitives being shared, not the primitives being
inherently shareable. This allows for fewer allocations for stack-allocated
primitives.
* Add `Mutex<T>` and `RWLock<T>` which are stack-allocated primitives for purely
wrapping a piece of data
* Remove `RWArc<T>` in favor of `Arc<RWLock<T>>`
* Remove `MutexArc<T>` in favor of `Arc<Mutex<T>>`
* Shuffle around where things are located
* The `arc` module now only contains `Arc`
* A new `lock` module contains `Mutex`, `RWLock`, and `Barrier`
* A new `raw` module contains the primitive implementations of `Semaphore`,
`Mutex`, and `RWLock`
* The Deref/DerefMut trait was implemented where appropriate
* `CowArc` was removed, the functionality is now part of `Arc` and is tagged
with `#[experimental]`.
* The crate now has #[deny(missing_doc)]
* `Arc` now supports weak pointers
This is not a large-scale rewrite of the functionality contained within the
`sync` crate, but rather a shuffling of who does what an a thinner hierarchy of
ownership to allow for better composability.
Alex Crichton [Sat, 22 Mar 2014 07:53:58 +0000 (00:53 -0700)]
sync: Update the arc module
This removes the now-outdated MutexArc and RWArc types. These are superseded by
Arc<Mutex<T>> and Arc<RWLock<T>>. The only remaining arc is the one true Arc.
Additionally, the arc now has weak pointers implemented for it to assist in
breaking cycles.
This commit brings the arc api up to parity with the sibling Rc api, making them
nearly interchangeable for inter and intra task communication.
bors [Mon, 24 Mar 2014 21:32:09 +0000 (14:32 -0700)]
auto merge of #13080 : alexcrichton/rust/possible-osx-deadlock, r=brson
The OSX bots have been deadlocking recently in the rustdoc tests. I have only
been able to rarely reproduce the deadlock on my local setup. When reproduced,
it looks like the child process is spinning on the malloc mutex, which I
presume is locked with no other threads to unlock it.
I'm not convinced that this is what's happening, because OSX should protect
against this with pthread_atfork by default. Regardless, running as little code
as possible in the child after fork() is normally a good idea anyway, so this
commit moves all allocation to the parent process to run before the child
executes.
After running 6k iterations of rustdoc tests, this deadlocked twice before, and
after 20k iterations afterwards, it never deadlocked. I draw the conclusion that
this is either sweeping the bug under the rug, or it did indeed fix the
underlying problem.
bors [Mon, 24 Mar 2014 17:01:57 +0000 (10:01 -0700)]
auto merge of #13113 : pnkfelix/rust/correct-static-kind-doc, r=huonw
While double-checking my understanding of the meaning of `'static`, I made the following test program:
```rust
fn foo<X:'static>(_x: X) { }
#[cfg(not(acceptable))]
fn bar() {
let a = 3;
let b = &a;
foo(b);
}
#[cfg(acceptable)]
fn bar() {
static c : int = 4;;
let d : &'static int = &c;
foo(d);
}
fn main() {
bar();
}
```
Transcript of compiling above program, illustrating that the `--cfg acceptable` variant of `bar` compiles successfully, showing that the`'static` kind bound only disallows non-`static` references, not *all* references:
```
% rustc --version
/Users/fklock/opt/rust-dbg/bin/rustc 0.10-pre (caf17fe 2014-03-21 02:21:50 -0700)
host: x86_64-apple-darwin
% rustc /tmp/s.rs
/tmp/s.rs:7:5: 7:8 error: instantiating a type parameter with an incompatible type `&int`, which does not fulfill `'static`
/tmp/s.rs:7 foo(b);
^~~
error: aborting due to previous error
% rustc --cfg acceptable /tmp/s.rs
% ./s
%
```
(Note that the explicit type annotation on `let d : &'static int` is necessary; it did not suffice for me to just write `let d = &'static c;`. That might be a latent bug, I am not sure yet.)
Anyway, a fix to the documentation seemed prudent.
bors [Mon, 24 Mar 2014 14:11:59 +0000 (07:11 -0700)]
auto merge of #12998 : huonw/rust/log_syntax, r=alexcrichton
syntax: allow `trace_macros!` and `log_syntax!` in item position.
Previously
trace_macros!(true)
fn main() {}
would complain about `trace_macros` being an expression macro in item
position. This is a pointless limitation, because the macro is purely
compile-time, with no runtime effect. (And similarly for log_syntax.)
This also changes the behaviour of `trace_macros!` very slightly, it
used to be equivalent to
I.e. you could invoke it with arbitrary trailing arguments, which were
ignored. It is changed to accept only exactly `true` or `false` (with no
trailing arguments) and expands to `()`.
Correct overly broad definition of `'static` kind bound.
While double-checking my understanding of the meaning of `'static`,
I made the following test program:
```rust
fn foo<X:'static>(_x: X) { }
#[cfg(not(acceptable))]
fn bar() {
let a = 3;
let b = &a;
foo(b);
}
#[cfg(acceptable)]
fn bar() {
static c : int = 4;;
let d : &'static int = &c;
foo(d);
}
fn main() {
bar();
}
```
Transcript of compiling above program, illustrating that the `--cfg
acceptable` variant of `bar` compiles successfully, showing that the
`'static` kind bound only disallows non-`static` references, not *all*
references:
```
% rustc --version
/Users/fklock/opt/rust-dbg/bin/rustc 0.10-pre (caf17fe 2014-03-21 02:21:50 -0700)
host: x86_64-apple-darwin
% rustc /tmp/s.rs
/tmp/s.rs:7:5: 7:8 error: instantiating a type parameter with an incompatible type `&int`, which does not fulfill `'static`
/tmp/s.rs:7 foo(b);
^~~
error: aborting due to previous error
% rustc --cfg acceptable /tmp/s.rs
% ./s
%
```
(Note that the explicit type annotation on `let d : &'static int` is
necessary; it did not suffice for me to just write `let d = &'static
c;`. That might be a latent bug, I am not sure yet.)
Anyway, a fix to the documentation seemed prudent.
bors [Sun, 23 Mar 2014 22:16:48 +0000 (15:16 -0700)]
auto merge of #13095 : alexcrichton/rust/serialize-tuple, r=huonw
This commit moves from {read,emit}_seq for tuples to {read,emit}_tuple, as well
as providing a generalized macro for generating these implementations from one
invocation.
Alex Crichton [Sun, 23 Mar 2014 04:58:51 +0000 (21:58 -0700)]
serialize: Read/emit tuples with {read,emit}_tuple
This commit moves from {read,emit}_seq for tuples to {read,emit}_tuple, as well
as providing a generalized macro for generating these implementations from one
invocation.
Alex Crichton [Sat, 22 Mar 2014 07:52:33 +0000 (00:52 -0700)]
sync: Introduce new wrapper types for locking
This introduces new synchronization types which are meant to be the foundational
building blocks for sharing data among tasks. The new Mutex and RWLock types
have a type parameter which is the internal data that is accessed. Access to the
data is all performed through the guards returned, and the guards all have
autoderef implemented for easy access.
Alex Crichton [Sat, 22 Mar 2014 07:50:19 +0000 (00:50 -0700)]
sync: Rewrite the base primitives
This commit rewrites the core primitives of the sync library: Mutex, RWLock, and
Semaphore. These primitives now have updated, more modernized apis:
* Guards are returned instead of locking with closures. All condition variables
have moved inside the guards and extraneous methods have been removed.
* Downgrading on an rwlock is now done through the guard instead of the rwlock
itself.
These types are meant to be general locks, not locks of an internal type (for
external usage). New types will be introduced for locking shared data.
Alex Crichton [Sat, 22 Mar 2014 07:49:16 +0000 (00:49 -0700)]
sync: Move Once to using &self
Similarly to the rest of the previous commits, this moves the once primitive to
using &self instead of &mut self for proper sharing among many threads now.
Alex Crichton [Sat, 22 Mar 2014 07:45:41 +0000 (00:45 -0700)]
std: Move NativeMutex from &mut self to &self
The proper usage of shared types is now sharing through `&self` rather than
`&mut self` because the mutable version will provide stronger guarantees (no
aliasing on *any* thread).
bors [Sun, 23 Mar 2014 15:36:51 +0000 (08:36 -0700)]
auto merge of #13102 : huonw/rust/totaleq-deriving, r=thestinger
std: remove the `equals` method from `TotalEq`.
`TotalEq` is now just an assertion about the `Eq` impl of a
type (i.e. `==` is a total equality if a type implements `TotalEq`) so
the extra method is just confusing.
Also, a new method magically appeared as a hack to allow deriving to
assert that the contents of a struct/enum are also TotalEq, because the
deriving infrastructure makes it very hard to do anything but create a
trait method. (You didn't hear about this horrible work-around from me
:(.)
bors [Sun, 23 Mar 2014 13:06:54 +0000 (06:06 -0700)]
auto merge of #13093 : Havvy/rust/master, r=sfackler
This will make the types more readable in the documentation, since the letters correspond with what you should either be sending or expecting to receive.
Huon Wilson [Sun, 23 Mar 2014 11:54:42 +0000 (22:54 +1100)]
std: remove the `equals` method from `TotalEq`.
`TotalEq` is now just an assertion about the `Eq` impl of a
type (i.e. `==` is a total equality if a type implements `TotalEq`) so
the extra method is just confusing.
Also, a new method magically appeared as a hack to allow deriving to
assert that the contents of a struct/enum are also TotalEq, because the
deriving infrastructure makes it very hard to do anything but create a
trait method. (You didn't hear about this horrible work-around from me
:(.)
Piotr Czarnecki [Sun, 23 Mar 2014 07:59:18 +0000 (08:59 +0100)]
rustc: Change the filename of compressed bitcode
Fixes #12992
Store compressed bitcode files in rlibs with a different extension. Compression doesn't interfere with --emit=bc.
Regression test compares outputs.
bors [Sun, 23 Mar 2014 11:01:59 +0000 (04:01 -0700)]
auto merge of #13092 : sfackler/rust/buffer-vec, r=thestinger
`Vec` is now used for the internal buffer instead of `~[]`. Some module
level documentation somehow ended up attached to `BufferedReader` so I
fixed that as well.
Daniel Micay [Sat, 22 Mar 2014 23:18:37 +0000 (19:18 -0400)]
iter: remove `to_owned_vec`
This needs to be removed as part of removing `~[T]`. Partial type hints
are now allowed, and will remove the need to add a version of this
method for `Vec<T>`. For now, this involves a few workarounds for
partial type hints not completely working.
Steven Fackler [Sun, 23 Mar 2014 00:18:27 +0000 (17:18 -0700)]
Some cleanup in std::io::buffered
`Vec` is now used for the internal buffer instead of `~[]`. Some module
level documentation somehow ended up attached to `BufferedReader` so I
fixed that as well.
bors [Sat, 22 Mar 2014 16:51:49 +0000 (09:51 -0700)]
auto merge of #13053 : alexcrichton/rust/removing-ref-cell-get, r=huonw
This commit removes the `get()` method from `Ref` and `RefMut` in favor of the `*` operator, and removes all usage of the `deref()` function manually from rustc, favoring using `*` instead.
Some of the code is a little wacky, but that's due to either #13044 or #13042
Alex Crichton [Fri, 21 Mar 2014 01:53:30 +0000 (18:53 -0700)]
rand: Use fill() instead of read()
It's possible for a reader to have a short read, and there's no reason the task
should fail in this scenario. By using fill(), this has a stronger guarantee
that the buffer will get filled with data.
Alex Crichton [Fri, 21 Mar 2014 01:52:00 +0000 (18:52 -0700)]
std: Add an I/O reader method to fill a buffer
I've found a common use case being to fill a slice (not an owned vector)
completely with bytes. It's posible for short reads to happen, and if you're
trying to get an exact number of bytes then this helper will be useful.
bors [Sat, 22 Mar 2014 15:36:50 +0000 (08:36 -0700)]
auto merge of #13078 : klutzy/rust/issue-13075, r=alexcrichton
`FormatMessageW()` is called by `std::os::last_os_error()` to convert
errno into string, but the function may fail on non-english locale.
I don't know why it fails, but anyway it's better to return errno
than to `fail!()` in the case.
klutzy [Sat, 22 Mar 2014 14:13:40 +0000 (23:13 +0900)]
std::os: Handle FormatMessage failure
`FormatMessageW()` is called by `std::os::last_os_error()` to convert
errno into string, but the function may fail on non-english locale.
I don't know why it fails, but anyway it's better to return errno
than to `fail!()` in the case.
bors [Sat, 22 Mar 2014 14:21:44 +0000 (07:21 -0700)]
auto merge of #13062 : mbrubeck/rust/doc-edit, r=alexcrichton
This is a very minor edit to the tutorial section on references.
Reading this section for the first time, I stumbled on the phrase "a reference can be borrowed to any object." Its meaning was clear enough once I got it, but I had to re-read it a couple of times to parse it correctly. Something about the passive voice plus the way "reference to any object" is split up by the verb phrase. How about this instead?
Alex Crichton [Sat, 22 Mar 2014 08:07:02 +0000 (01:07 -0700)]
native: Fix a possible deadlock in spawn
The OSX bots have been deadlocking recently in the rustdoc tests. I have only
been able to rarely reproduce the deadlock on my local setup. When reproduced,
it looks like the child process is spinning on the malloc mutex, which I
presume is locked with no other threads to unlock it.
I'm not convinced that this is what's happening, because OSX should protect
against this with pthread_atfork by default. Regardless, running as little code
as possible in the child after fork() is normally a good idea anyway, so this
commit moves all allocation to the parent process to run before the child
executes.
After running 6k iterations of rustdoc tests, this deadlocked twice before, and
after 20k iterations afterwards, it never deadlocked. I draw the conclusion that
this is either sweeping the bug under the rug, or it did indeed fix the
underlying problem.
bors [Sat, 22 Mar 2014 07:56:47 +0000 (00:56 -0700)]
auto merge of #12907 : alexcrichton/rust/issue-12892, r=brson
These methods can be mistaken for general "read some bytes" utilities when
they're actually only meant for reading an exact number of bytes. By renaming
them it's much clearer about what they're doing without having to read the
documentation.
bors [Sat, 22 Mar 2014 03:06:44 +0000 (20:06 -0700)]
auto merge of #13016 : huonw/rust/new-opt-vec, r=cmr
Replace syntax::opt_vec with syntax::owned_slice
The `owned_slice::OwnedSlice` is `(*T, uint)` (i.e. a direct equivalent to DSTs `~[T]`).
This shaves two words off the old OptVec type; and also makes substituting in other implementations easy, by removing all the mutation methods. (And also everything that's very rarely/never used.)
bors [Sat, 22 Mar 2014 01:51:51 +0000 (18:51 -0700)]
auto merge of #12833 : alexcrichton/rust/libnative, r=brson
The compiler will no longer inject libgreen as the default runtime for rust
programs, this commit switches it over to libnative by default. Now that
libnative has baked for some time, it is ready enough to start getting more
serious usage as the default runtime for rustc generated binaries.
We've found that there isn't really a correct decision in choosing a 1:1 or M:N
runtime as a default for all applications, but it seems that a larger number of
programs today would work more reasonably with a native default rather than a
green default.
With this commit come a number of bugfixes:
* The main native task is now named `<main>`
* The main native task has the stack bounds set up properly
* #[no_uv] was renamed to #[no_start]
* The core-run-destroy test was rewritten for both libnative and libgreen and
one of the tests was modified to be more robust.
* The process-detach test was locked to libgreen because it uses signal handling
bors [Fri, 21 Mar 2014 23:41:48 +0000 (16:41 -0700)]
auto merge of #13043 : alexcrichton/rust/fix-rustdoc-windows, r=brson
If the dwShareMode parameter is 0 on windows, it "prevents other processes from
opening a file or device if they request delete, read, or write access", which
is the opposite of what we want! This changes the 0 parameter to something which
will allow multiple processes to open the file and then lock it.
Alex Crichton [Fri, 21 Mar 2014 18:51:11 +0000 (11:51 -0700)]
rand: Fix a bug acquiring a context on windows
The details can be found in the comment I wrote on the block in question, but
the gist of it is that our usage of the TIB for a stack limit was causing
CryptAcquireContext to fail, so we temporarily get around it by setting the
stack limit to 0.
Alex Crichton [Tue, 11 Mar 2014 20:38:36 +0000 (13:38 -0700)]
rustc: Switch defaults from libgreen to libnative
The compiler will no longer inject libgreen as the default runtime for rust
programs, this commit switches it over to libnative by default. Now that
libnative has baked for some time, it is ready enough to start getting more
serious usage as the default runtime for rustc generated binaries.
We've found that there isn't really a correct decision in choosing a 1:1 or M:N
runtime as a default for all applications, but it seems that a larger number of
programs today would work more reasonable with a native default rather than a
green default.
With this commit come a number of bugfixes:
* The main native task is now named "<main>"
* The main native task has the stack bounds set up properly
* #[no_uv] was renamed to #[no_start]
* The core-run-destroy test was rewritten for both libnative and libgreen and
one of the tests was modified to be more robust.
* The process-detach test was locked to libgreen because it uses signal handling
Alex Crichton [Thu, 20 Mar 2014 20:59:07 +0000 (13:59 -0700)]
rustdoc: Fix file locking on windows
If the dwShareMode parameter is 0 on windows, it "prevents other processes from
opening a file or device if they request delete, read, or write access", which
is the opposite of what we want! This changes the 0 parameter to something which
will allow multiple processes to open the file and then lock it.
Huon Wilson [Wed, 19 Mar 2014 14:51:08 +0000 (01:51 +1100)]
syntax: add the OwnedSlice vector wrapper.
This is a stand-in until we have a saner `~[T]` type (i.e. a proper
owned slice). It's a library version of what `~[T]` will be, i.e. an
owned pointer and a length.
Huon Wilson [Tue, 18 Mar 2014 12:14:08 +0000 (23:14 +1100)]
syntax: allow `trace_macros!` and `log_syntax!` in item position.
Previously
trace_macros!(true)
fn main() {}
would complain about `trace_macros` being an expression macro in item
position. This is a pointless limitation, because the macro is purely
compile-time, with no runtime effect. (And similarly for log_syntax.)
This also changes the behaviour of `trace_macros!` very slightly, it
used to be equivalent to
I.e. you could invoke it with arbitrary trailing arguments, which were
ignored. It is changed to accept only exactly `true` or `false` (with no
trailing arguments) and expands to `()`.