bors [Wed, 5 Feb 2014 20:56:34 +0000 (12:56 -0800)]
auto merge of #11894 : alexcrichton/rust/io-clone, r=brson
This is part of the overall strategy I would like to take when approaching
issue #11165. The only two I/O objects that reasonably want to be "split" are
the network stream objects. Everything else can be "split" by just creating
another version.
The initial idea I had was the literally split the object into a reader and a
writer half, but that would just introduce lots of clutter with extra interfaces
that were a little unnnecssary, or it would return a ~Reader and a ~Writer which
means you couldn't access things like the remote peer name or local socket name.
The solution I found to be nicer was to just clone the stream itself. The clone
is just a clone of the handle, nothing fancy going on at the kernel level.
Conceptually I found this very easy to wrap my head around (everything else
supports clone()), and it solved the "split" problem at the same time.
The cloning support is pretty specific per platform/lib combination:
* native/win32 - uses some specific WSA apis to clone the SOCKET handle
* native/unix - uses dup() to get another file descriptor
* green/all - This is where things get interesting. When we support full clones
of a handle, this implies that we're allowing simultaneous writes
and reads to happen. It turns out that libuv doesn't support two
simultaneous reads or writes of the same object. It does support
*one* read and *one* write at the same time, however. Some extra
infrastructure was added to just block concurrent writers/readers
until the previous read/write operation was completed.
I've added tests to the tcp/unix modules to make sure that this functionality is
supported everywhere.
Alex Crichton [Thu, 23 Jan 2014 03:32:16 +0000 (19:32 -0800)]
Implement clone() for TCP/UDP/Unix sockets
This is part of the overall strategy I would like to take when approaching
issue #11165. The only two I/O objects that reasonably want to be "split" are
the network stream objects. Everything else can be "split" by just creating
another version.
The initial idea I had was the literally split the object into a reader and a
writer half, but that would just introduce lots of clutter with extra interfaces
that were a little unnnecssary, or it would return a ~Reader and a ~Writer which
means you couldn't access things like the remote peer name or local socket name.
The solution I found to be nicer was to just clone the stream itself. The clone
is just a clone of the handle, nothing fancy going on at the kernel level.
Conceptually I found this very easy to wrap my head around (everything else
supports clone()), and it solved the "split" problem at the same time.
The cloning support is pretty specific per platform/lib combination:
* native/win32 - uses some specific WSA apis to clone the SOCKET handle
* native/unix - uses dup() to get another file descriptor
* green/all - This is where things get interesting. When we support full clones
of a handle, this implies that we're allowing simultaneous writes
and reads to happen. It turns out that libuv doesn't support two
simultaneous reads or writes of the same object. It does support
*one* read and *one* write at the same time, however. Some extra
infrastructure was added to just block concurrent writers/readers
until the previous read/write operation was completed.
I've added tests to the tcp/unix modules to make sure that this functionality is
supported everywhere.
bors [Wed, 5 Feb 2014 18:41:34 +0000 (10:41 -0800)]
auto merge of #11984 : olsonjeffery/rust/libserialize, r=alexcrichton
- `extra::json` didn't make the cut, because of `extra::json`'s required
dep on `extra::TreeMap`. If/when `extra::TreeMap` moves out of `extra`,
then `extra::json` could move into `libserialize`
- `libextra`, `libsyntax` and `librustc` depend on the newly created
`libserialize`
- The extensions to various `extra` types like `DList`, `RingBuf`, `TreeMap`
and `TreeSet` for `Encodable`/`Decodable` were moved into the respective
modules in `extra`
- There is some trickery, evident in `src/libextra/lib.rs` where a stub
of `extra::serialize` is set up (in `src/libextra/serialize.rs`) for
use in the stage0 build, where the snapshot rustc is still making
deriving for `Encodable` and `Decodable` point at extra. Big props to
@huonw for help working out the re-export solution for this
- @pcwalton's change in 449a7a8 didn't sneak back in
Jeff Olson [Wed, 5 Feb 2014 16:52:54 +0000 (08:52 -0800)]
pull extra::{serialize, ebml} into a separate libserialize crate
- `extra::json` didn't make the cut, because of `extra::json` required
dep on `extra::TreeMap`. If/when `extra::TreeMap` moves out of `extra`,
then `extra::json` could move into `serialize`
- `libextra`, `libsyntax` and `librustc` depend on the newly created
`libserialize`
- The extensions to various `extra` types like `DList`, `RingBuf`, `TreeMap`
and `TreeSet` for `Encodable`/`Decodable` were moved into the respective
modules in `extra`
- There is some trickery, evident in `src/libextra/lib.rs` where a stub
of `extra::serialize` is set up (in `src/libextra/serialize.rs`) for
use in the stage0 build, where the snapshot rustc is still making
deriving for `Encodable` and `Decodable` point at extra. Big props to
@huonw for help working out the re-export solution for this
extra: inline extra::serialize stub
fix stuff clobbered in rebase + don't reexport serialize::serialize
no more globs in libserialize
syntax: fix import of libserialize traits
librustc: fix bad imports in encoder/decoder
add serialize dep to librustdoc
fix failing run-pass tests w/ serialize dep
adjust uuid dep
more rebase de-clobbering for libserialize
fixing tests, pushing libextra dep into cfg(test)
fix doc code in extra::json
adjust index.md links to serialize and uuid library
Alex Crichton [Mon, 3 Feb 2014 23:53:43 +0000 (15:53 -0800)]
Run all target crate tests on the windows/try bots
Previously, the check-fast and check-lite test suites weren't picking up all
target crates, rather just std/extra. In order to ensure that all of our crates
work on windows, I've modified these rules to build the test suites for all
TARGET_CRATES members. Note that this still excludes rustc/syntax/rustdoc.
bors [Tue, 4 Feb 2014 22:41:36 +0000 (14:41 -0800)]
auto merge of #11230 : csherratt/rust/cow, r=alexcrichton
This allows patch adds a new arc type that allows for creation of copy-on-write data structures. The idea is that it is safe to mutate any data structure as long as it has only one reference to it. If there are multiple, it requires cloning of the data structure before mutation is possible.
bors [Mon, 3 Feb 2014 21:11:35 +0000 (13:11 -0800)]
auto merge of #11866 : alexcrichton/rust/atomic-u64, r=brson
Let's try this again.
This is an implementation of mutexes which I believe is free from undefined behavior of OS mutexes (the pitfall of the previous implementation).
This implementation is not ideal. There's a yield-loop spot, and it's not particularly fair with respect to lockers who steal without going through the normal code paths. That being said, I believe that this is a correct implementation which is a stepping stone to move from.
I haven't done rigorous benchmarking of this mutex, but preliminary results show that it's about 25% slower in the uncontended case on linux (same runtime on OSX), and it's actually faster than a pthreads mutex on high contention (again, not rigorous benchmarking, I just saw these numbers come up).
Alex Crichton [Fri, 17 Jan 2014 03:54:24 +0000 (19:54 -0800)]
std: Hardcode pthread constants and structures
This allows for easier static initialization of a pthread mutex, although the
windows mutexes still sadly suffer.
Note that this commit removes the clone() method from a mutex because it no
longer makes sense for pthreads mutexes. This also removes the Once type for
now, but it'll get added back shortly.
Alex Crichton [Thu, 16 Jan 2014 00:54:11 +0000 (16:54 -0800)]
Enable the +v7 feature on Android by default
With the recently added double word CAS functionality on 32-bit ARM (enabled via
a 64-bit atomic instruction in LLVM IR), without some extra features enabled
LLVM lowers code to function calls which emulate atomic instructions. With the
v7 feature enabled, proper 64-bit CAS instructions are used on 32-bit arm.
I've been told that v7 for arm is what we should have been doing anyway. This is
overridable by providing some other non-empty feature string.
bors [Mon, 3 Feb 2014 18:41:34 +0000 (10:41 -0800)]
auto merge of #11946 : alexcrichton/rust/no-io-error, r=brson
Turns out this was a little more far-reaching than I thought it was.
The first commit is the crux of this stack of commits. The `io::io_error` condition is completely removed and the `read` and `write` methods are altered to return `IoResult<T>`. This turned out to be an incredibly far-reaching change!
Overall, I'm very happy with how this turned out (in addition with the `unused_must_use` lint). I had to almost rewrite the pretty printer in `libsyntax` as well as the the formatting in `librustdoc` (as one would expect). These two modules do *tons* of I/O, and I believe that it's definitely improved.
This pull request also introduces the `if_ok!()` macro for returning-early from something that returns a result. I made quite liberal use of this in mostly the pretty printer and html renderer, and I found its usage generally quite pleasant and convenient to have. I didn't really feel like adding any other macro while I was using it, and I figured that pretty printing could be nicer, but it's nowhere near horrid today.
This may be a controversial issue closing, but I'm going to say it.
Alex Crichton [Thu, 30 Jan 2014 00:33:57 +0000 (16:33 -0800)]
std: Remove io::io_error
* All I/O now returns IoResult<T> = Result<T, IoError>
* All formatting traits now return fmt::Result = IoResult<()>
* The if_ok!() macro was added to libstd
bors [Mon, 3 Feb 2014 03:11:27 +0000 (19:11 -0800)]
auto merge of #12003 : bnoordhuis/rust/sizeof-epoll-event-fixup, r=brson
Make the definition of epoll_event use natural alignment on all
architectures except x86_64.
Before this commit, the struct was always 12 bytes big, which works okay
on x86 and x86_64 but not on ARM and MIPS, where it should be 16 bytes
big with the `data` field aligned on an 8 byte boundary.
bors [Sun, 2 Feb 2014 19:01:29 +0000 (11:01 -0800)]
auto merge of #11891 : alexcrichton/rust/docs, r=brson
I moved all documentation sources (guides, manuals, etc) to `src/doc` to free up `doc` as a build directory for all generated files.
At the same time, I also removed our usage of `VPATH` from the makefiles because it was wreaking havoc with doc deps and it's not very necessary now that we're primarily a rust project rather than having a good portion of C++/C inside of it.
Ben Noordhuis [Sun, 2 Feb 2014 17:04:05 +0000 (18:04 +0100)]
libnative: fix epoll_event struct layout
Make the definition of epoll_event use natural alignment on all
architectures except x86_64.
Before this commit, the struct was always 12 bytes big, which works okay
on x86 and x86_64 but not on ARM and MIPS, where it should be 16 bytes
big with the `data` field aligned on an 8 byte boundary.
bors [Sun, 2 Feb 2014 16:41:27 +0000 (08:41 -0800)]
auto merge of #11996 : lecram/rust/master, r=pcwalton
This Pull Request aims to add backticks to all instances of code inside comments in snippets present in tutorial.md. It also includes backticks for filenames in the same conditions. See #11796 for motivation.
bors [Sun, 2 Feb 2014 06:31:26 +0000 (22:31 -0800)]
auto merge of #11948 : huonw/rust/show, r=alexcrichton
- renames `Default` to `Show`
- introduces some hidden `std::fmt::secret_...` functions, designed to work-around the lack of UFCS (with UFCS they can be replaced by referencing the trait methods directly) because I'm going to convert the traits to have methods rather than static functions, since `#[deriving]` works much better with true methods.
I'm blocked on a snapshot after this. (I could probably do a large number of `#[cfg]`s, but I can work on other things in the meantime.)
bors [Sat, 1 Feb 2014 19:16:24 +0000 (11:16 -0800)]
auto merge of #11974 : huonw/rust/no-at-vec, r=pcwalton
This removes @[] from the parser as well as much of the handling of it (and `@str`) from the compiler as I can find.
I've just rebased @pcwalton's (already reviewed) `@str` removal (and fixed the problems in a separate commit); the only new work is the trailing commits with my authorship.
bors [Sat, 1 Feb 2014 18:01:25 +0000 (10:01 -0800)]
auto merge of #11973 : dotdash/rust/u64_to_bytes, r=huonw
LLVM fails to properly optimize the shifts used to convert the source
value to the right endianess. The resulting assembly copies the value
to the stack one byte at a time even when there's no conversion required
(e.g. u64_to_le_bytes on a little endian machine).
Instead of doing the conversion ourselves using shifts, we can use the
existing intrinsics to perform the endianess conversion and then
transmute the value to get a fixed vector of its bytes.
Before:
````
test be_i8 ... bench: 21442 ns/iter (+/- 70)
test be_i16 ... bench: 21447 ns/iter (+/- 45)
test be_i32 ... bench: 23832 ns/iter (+/- 63)
test be_i64 ... bench: 26887 ns/iter (+/- 267)
test le_i8 ... bench: 21442 ns/iter (+/- 56)
test le_i16 ... bench: 21448 ns/iter (+/- 36)
test le_i32 ... bench: 23825 ns/iter (+/- 153)
test le_i64 ... bench: 26271 ns/iter (+/- 138)
````
After:
````
test be_i8 ... bench: 21438 ns/iter (+/- 10)
test be_i16 ... bench: 21441 ns/iter (+/- 15)
test be_i32 ... bench: 19057 ns/iter (+/- 6)
test be_i64 ... bench: 21439 ns/iter (+/- 34)
test le_i8 ... bench: 21438 ns/iter (+/- 19)
test le_i16 ... bench: 21439 ns/iter (+/- 8)
test le_i32 ... bench: 21439 ns/iter (+/- 19)
test le_i64 ... bench: 21438 ns/iter (+/- 22)
````
projects / rust.git / log