I haven't landed this fix upstream just yet, but it's opened as
joyent/libuv#1048. For now, I've locally merged it into my fork, and I've
upgraded our repo to point to the new revision.
Closes#11027
I haven't landed this fix upstream just yet, but it's opened as
joyent/libuv#1048. For now, I've locally merged it into my fork, and I've
upgraded our repo to point to the new revision.
Closes#11027
This makes the included benchmark more than 3 times faster. Also,
`.unshift(x)` is now faster as `.insert(0, x)` which can reuse the
allocation if necessary.
`[1e20, 1.0, -1e20].sum()` returns `0.0`. This happens because during
the summation, `1.0` is too small relative to `1e20`, making it
negligible.
I have tried Kahan summation but it hasn't fixed the problem.
Therefore, I've used Python's `fsum()` implementation.
For more details, read:
www.cs.cmu.edu/~quake-papers/robust-arithmetic.ps
https://github.com/mozilla/rust/issues/10851
Python's fsum (msum)
http://code.activestate.com/recipes/393090/
@huonw, your feedback is more than welcome.
It looks unpolished; Do you have suggestions how to make it more beautiful and elegant?
Thanks in advance,
For `str.as_mut_buf`, un-closure-ification is achieved by outright removal (see commit message). The others are replaced by `.as_ptr`, `.as_mut_ptr` and `.len`
`[1e20, 1.0, -1e20].sum()` returns `0.0`. This happens because during
the summation, `1.0` is too small relative to `1e20`, making it
negligible.
I have tried Kahan summation but it hasn't fixed the problem.
Therefore, I've used Python's `fsum()` implementation with some
help from Jason Fager and Huon Wilson.
For more details, read:
www.cs.cmu.edu/~quake-papers/robust-arithmetic.ps
Moreover, benchmark and unit tests were added.
Note: `Status.sum` is still not fully fixed. It doesn't handle
NaNs, infinities and overflow correctly. See issue 11059:
https://github.com/mozilla/rust/issues/11059
Trap the io_error condition so that a more informative error message is
displayed when the linker program cannot be started, such as when the
name of the linker binary is accidentally mistyped.
closes#10755
`.as_mut_buf` was used exactly once, in `.push_char` which could be
written in a simpler way, using the `&mut ~[u8]` that it already
retrieved. In the rare situation when someone really needs
`.as_mut_buf`-like functionality (getting a `*mut u8`), they can go via
`str::raw::as_owned_vec`.
llvm supports both win32 native threads and pthread,
but configure tries to find pthread first.
This manually disables pthread to use native api.
This removes libpthreads-2.dll dependency on librustc.
As the title says. The trans changes will lead to an auxiliary alloca being created that allows debug info to track the `self` argument. This alloca is only created in debug builds however. Otherwise very little had to be done after I managed to navigate to some degree the jungle that is self-argument handling `:P`
Closes#10549
When a borrow occurs twice illegally, Rust will label the other borrow
as the "second borrow". This is quite confusing, as the "second borrow"
usually happened before the flagged barrow (e.g. as far as dataflow
is concerned, the first borrow is OK, the second borrow is illegal.)
This patch renames "second borrow" to "previous borrow", to make the
spatial relationship between the two borrows clearer.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
This code in resolve accidentally forced all types with an impl to become
public. This fixes it by default inheriting the privacy of what was previously
there and then becoming `true` if nothing else exits.
Closes#10545
llvm supports both win32 native threads and pthread,
but configure tries to find pthread first.
This manually disables pthread to use native api.
This removes libpthreads-2.dll dependency on librustc.
### Remove {As,Into,To}{Option,Either,Result} traits.
Expanded, that is:
- `AsOption`
- `IntoOption`
- `ToOption`
- `AsEither`
- `IntoEither`
- `ToEither`
- `AsResult`
- `IntoResult`
- `ToResult`
These were defined for each other but never *used* anywhere. They are
all trivial and so removal will have negligible effect upon anyone.
`Either` has fallen out of favour (and its implementation of these
traits of dubious semantics), `Option<T>` → `Result<T, ()>` was never
really useful and `Result<T, E>` → `Option<T>` should now be done with
`Result.ok()` (mirrored with `Result.err()` for even more usefulness).
In summary, there's really no point in any of these remaining.
### Rename To{Str,Bytes}Consume traits to Into*.
That is:
- `ToStrConsume` → `IntoStr`;
- `ToBytesConsume` → `IntoBytes`.
By performing this logic very late in the build process, it ended up leading to
bugs like those found in #10973 where certain stages of the build process
expected a particular output format which didn't end up being the case. In order
to fix this, the build output generation is moved very early in the build
process to the absolute first thing in phase 2.
Closes#10973
This code in resolve accidentally forced all types with an impl to become
public. This fixes it by default inheriting the privacy of what was previously
there and then becoming `true` if nothing else exits.
Closes#10545
By returning the items to process and storing them in a queue, we were losing
the context that was setup for that item during the recursion. This is an easy
fix, rather than hoisting out the state that it needs.
By returning the items to process and storing them in a queue, we were losing
the context that was setup for that item during the recursion. This is an easy
fix, rather than hoisting out the state that it needs.
This change extends the pkgid attribute to allow of explicit crate names, instead of always inferring them based on the path. This means that if your GitHub repo is called `rust-foo`, you can have your pkgid set your library name to `foo`. You'd do this with a pkgid attribute like `github.com/somewhere/rust-foo#foo:1.0`.
This is half of the fix for #10922.
Previously the a pkgid of `foo/rust-bar#1.0` implied a crate name of
`rust-bar` and didn't allow this to be overridden. Now you can override the
inferred crate name with `foo/rust-bar#bar:1.0`.
When a borrow occurs twice illegally, Rust will label the other borrow
as the "second borrow". This is quite confusing, as the "second borrow"
usually happened before the flagged borrow (e.g. as far as dataflow
is concerned, the first borrow is OK, the second borrow is illegal.)
This patch renames "second borrow" to "previous borrow", to make the
spatial relationship between the two borrows clearer.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
The removal of the aliasing &mut[] and &[] from `shift_opt` also comes with its simplification.
The above also allows the use of `copy_nonoverlapping_memory` in `[].copy_memory` (I did an audit of each use of `.copy_memory` and `std::vec::bytes::copy_memory`, and I believe none of them are called with arguments can ever alias). This changes requires that `unsafe` code using `copy_memory` **needs** to respect the aliasing rules of `&mut[]`.
