bors [Fri, 29 Aug 2014 15:41:20 +0000 (15:41 +0000)]
auto merge of #16767 : SiegeLord/rust/reexported_methods, r=cmr
Previously, this caused methods of re-exported types to not be inserted into
the search index. This fix may introduce some false positives, but in my
testing they appear as orphaned methods and end up not being inserted into the
final search index at a later stage.
Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.
However, a few methods have been deprecated, either due to lack of use or redundancy:
* `take_unwrap`, `get_ref` and `get_mut_ref` (redundant, and we prefer for this functionality to go through an explicit .unwrap)
* `filtered` and `while`
* `mutate` and `mutate_or_set`
* `collect`: this functionality is being moved to a new `FromIterator` impl.
# Changes to `core::result`
Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues.
* `collect`: this functionality is being moved to a new `FromIterator` impl.
* `fold_` is deprecated due to lack of use
* Several methods found in `core::option` are added here, including `iter`, `as_slice`, and variants.
bors [Thu, 28 Aug 2014 22:11:18 +0000 (22:11 +0000)]
auto merge of #16626 : ruud-v-a/rust/duration-reform, r=brson
This changes the internal representation of `Duration` from
days: i32,
secs: i32,
nanos: u32
to
secs: i64,
nanos: i32
This resolves #16466. Note that `nanos` is an `i32` and not `u32` as suggested, because `i32` is easier to deal with, and it is not exposed anyway. Some methods now take `i64` instead of `i32` due to the increased range. Some methods, like `num_milliseconds`, now return an `Option<i64>` instead of `i64`, because the range of `Duration` is now larger than e.g. 2^63 milliseconds.
A few remarks:
- Negating `MIN` is impossible. I chose to return `MAX` as `-MIN`, but it is one nanosecond less than the actual negation. Is this the desired behaviour?
- In `std::io::timer`, some functions accept a `Duration`, which is internally converted into a number of milliseconds. However, the range of `Duration` is now larger than 2^64 milliseconds. There is already a FIXME in the file that this should be addressed (without a ticket number though). I chose to silently use 0 ms if the duration is too long. Is that right, as long as the backend still uses milliseconds?
- Negative durations are not formatted correctly, but they were not formatted correctly before either.
Most of the module is marked as stable or unstable; most of the unstable
items are awaiting resolution of conventions issues.
* `collect`: this functionality is being moved to a new `FromIterator`
impl.
* `fold_` is deprecated due to lack of use
* Several methods found in `core::option` are added here, including
`iter`, `as_slice`, and variants.
Most of the module is marked as stable or unstable; most of the unstable
items are awaiting resolution of conventions issues.
However, a few methods have been deprecated, either due to lack of use
or redundancy:
* `take_unwrap`, `get_ref` and `get_mut_ref` (redundant, and we prefer
for this functionality to go through an explicit .unwrap)
* `filtered` and `while`
* `mutate` and `mutate_or_set`
* `collect`: this functionality is being moved to a new `FromIterator`
impl.
1. type parameters can have lifetime bounds and objects can close over borrowed values, presuming that they have suitable bounds.
2. objects must have a bound, though it may be derived from the trait itself or from a `Send` bound.
3. all types must be well-formed.
4. type parameters and lifetime parameters may themselves have lifetimes as bounds. Something like `T:'a` means "the type T outlives 'a`" and something like `'a:'b`" means "'a outlives 'b". Outlives here means "all borrowed data has a lifetime at least as long".
This is a [breaking-change]. The most common things you have to fix after this change are:
1. Introduce lifetime bounds onto type parameters if your type (directly or indirectly) contains a reference. Thus a struct like `struct Ref<'a, T> { x: &'a T }` would be changed to `struct Ref<'a, T:'a> { x: &'a T }`.
2. Introduce lifetime bounds onto lifetime parameters if your type contains a double reference. Thus a type like `struct RefWrapper<'a, 'b> { r: &'a Ref<'b, int> }` (where `Ref` is defined as before) would need to be changed to `struct RefWrapper<'a, 'b:'a> { ... }`.
2. Explicitly give object lifetimes in structure definitions. Most commonly, this means changing something like `Box<Reader>` to `Box<Reader+'static>`, so as to indicate that this is a reader without any borrowed data. (Note: you may wish to just change to `Box<Reader+Send>` while you're at it; it's a more restrictive type, technically, but means you can send the reader between threads.)
The intuition for points 1 and 2 is that a reference must never outlive its referent (the thing it points at). Therefore, if you have a type `&'a T`, we must know that `T` (whatever it is) outlives `'a`. And so on.
bors [Wed, 27 Aug 2014 21:31:13 +0000 (21:31 +0000)]
auto merge of #16757 : steveklabnik/rust/lets_not_lie_in_the_concurrency_guide, r=alexcrichton
This cleans up blatant lies in the concurrency guide, and modernizes it
a bit. There's a lot more to do, but until I get to it, let's make it a
little bit better.
Steve Klabnik [Tue, 26 Aug 2014 01:15:20 +0000 (21:15 -0400)]
Fix lies in the concurrency guide.
This cleans up blatant lies in the concurrency guide, and modernizes it
a bit. There's a lot more to do, but until I get to it, let's make it a
little bit better.
bors [Wed, 27 Aug 2014 19:46:14 +0000 (19:46 +0000)]
auto merge of #16797 : nikomatsakis/rust/remove-invalid-spsc_queue-test, r=alexcrichton
This test seems to read freed memory -- the peeked variable points into the queue, but then the pop operation removes the node from the queue and moves the enclosing `T` elsewhere, invalidating the `peeked` pointer.
bors [Wed, 27 Aug 2014 07:46:17 +0000 (07:46 +0000)]
auto merge of #16724 : tshepang/rust/misleading, r=brson
We have to specify the module and the function name in the example where
the module shares a crate with the executable as well, so remove the
redundant (and potentially confusing) mention.
bors [Wed, 27 Aug 2014 00:31:25 +0000 (00:31 +0000)]
auto merge of #16704 : flugsio/rust/fix-rustc-ice-lint-underscores-only, r=brson
Fix for type identifiers with only underscores (two or more), I assume they doesn't count as camel case.
```rust
type __ = int;
fn main() {
}
```
```
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
task 'rustc' failed at 'index out of bounds: the len is 0 but the index is 0', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/librustc/lib.rs:1
SiegeLord [Tue, 26 Aug 2014 18:41:25 +0000 (14:41 -0400)]
Always insert methods into the search index, even if we're currently in a private module.
Previously, this caused methods of re-exported types to not be inserted into
the search index. This fix may introduce some false positives, but in my
testing they appear as orphaned methods and end up not being inserted into the
final search index at a later stage.
bors [Tue, 26 Aug 2014 10:31:06 +0000 (10:31 +0000)]
auto merge of #14397 : nick29581/rust/coerce, r=pnkfelix
DST coercions and DST fields in structs
The commits are not quite stand alone, I should probably squash them together before landing. In particular if you review the individual commits, then you'll see some scrappy stuff that gets fixed in later commits. But reading the commits in order might be easier to get an overall idea of what is going on.
The first commit includes putting back time zone into our time library - @pcwalton removed that as part of his de-~str'ing, but I had already converted it to use StrBuf, so we may as well leave it in. Update: no longer, this is removed in a later commit.
Nick Cameron [Mon, 4 Aug 2014 12:20:11 +0000 (14:20 +0200)]
DST coercions and DST structs
[breaking-change]
1. The internal layout for traits has changed from (vtable, data) to (data, vtable). If you were relying on this in unsafe transmutes, you might get some very weird and apparently unrelated errors. You should not be doing this! Prefer not to do this at all, but if you must, you should use raw::TraitObject rather than hardcoding rustc's internal representation into your code.
2. The minimal type of reference-to-vec-literals (e.g., `&[1, 2, 3]`) is now a fixed size vec (e.g., `&[int, ..3]`) where it used to be an unsized vec (e.g., `&[int]`). If you want the unszied type, you must explicitly give the type (e.g., `let x: &[_] = &[1, 2, 3]`). Note in particular where multiple blocks must have the same type (e.g., if and else clauses, vec elements), the compiler will not coerce to the unsized type without a hint. E.g., `[&[1], &[1, 2]]` used to be a valid expression of type '[&[int]]'. It no longer type checks since the first element now has type `&[int, ..1]` and the second has type &[int, ..2]` which are incompatible.
3. The type of blocks (including functions) must be coercible to the expected type (used to be a subtype). Mostly this makes things more flexible and not less (in particular, in the case of coercing function bodies to the return type). However, in some rare cases, this is less flexible. TBH, I'm not exactly sure of the exact effects. I think the change causes us to resolve inferred type variables slightly earlier which might make us slightly more restrictive. Possibly it only affects blocks with unreachable code. E.g., `if ... { fail!(); "Hello" }` used to type check, it no longer does. The fix is to add a semicolon after the string.
Alex Crichton [Mon, 25 Aug 2014 00:05:47 +0000 (17:05 -0700)]
rustc: Encode the visibility of foreign items
The privacy pass of the compiler was previously not taking into account the
privacy of foreign items, or bindings to external functions. This commit fixes
this oversight by encoding the visibility of foreign items into the metadata for
each crate.
Any code relying on this will start to fail to compile and the bindings must be
marked with `pub` to indicate that they can be used externally.
bors [Mon, 25 Aug 2014 01:45:57 +0000 (01:45 +0000)]
auto merge of #15704 : alexcrichton/rust/issue-15595, r=brson
If a task is spinning in an accept loop, there is currently no method of gracefully shutting it down. This PR introduces a way to do so by cloning the acceptor and implementing a close_accept method to unblocking any pending acceptor.
As with other I/O methods like this, it is `#[experimental]` from the start and sadly carries with it a good deal of code to support it. Much of the complication is from the fact that you can now concurrently accept on the same socket.
I tried to add a good deal of tests for this change, but another set of eyes is always appreciated!
Alex Crichton [Tue, 15 Jul 2014 05:48:05 +0000 (22:48 -0700)]
rustuv: Implement clone/close_accept
This commits implements {Tcp,Unix}Acceptor::{clone,close_accept} methods for
all of librustuv.
This implementation rewrites much of Access, AccessTimeout, and AcceptTimeout to
have type parameter for shared state that all acceptors share (a shared queue of
sockets). The incoming/outgoing channels have been removed as all timeouts and
such are now managed on the event loop rather than concurrently.
Alex Crichton [Fri, 11 Jul 2014 21:29:15 +0000 (14:29 -0700)]
native: Implement clone/close_accept for unix
This commits implements {Tcp,Unix}Acceptor::{clone,close_accept} methods for
unix. A windows implementation is coming in a later commit.
The clone implementation is based on atomic reference counting (as with all
other clones), and the close_accept implementation is based on selecting on a
self-pipe which signals that a close has been seen.
bors [Sun, 24 Aug 2014 20:30:59 +0000 (20:30 +0000)]
auto merge of #16718 : Sawyer47/rust/bool-cast, r=pcwalton
Current version of rust fails when casting from bool, e.g.
```rust
fn main() {
let _a = false as uint;
let _b = true as uint;
let _c: [bool, ..false as uint];
let _d: [bool, ..true as uint];
// _a and _b work, but _c and _d result in an error
// error: expected constant expr for vector length: can't cast str to uint
}
```
This commit makes it work as expected.
bors [Sun, 24 Aug 2014 18:46:01 +0000 (18:46 +0000)]
auto merge of #16728 : bluss/rust/zip-next-back, r=alexcrichton
Use ExactSize::len() and defer to its decisions about overly defensive
assertions. Remove the length double-check and simply put a failure
case if the Zip finds an uneven end in .next_back().
Fixing this up since I think I wrote this, and it's been known to
confuse rusties (PR #15886).
root [Sun, 24 Aug 2014 13:04:28 +0000 (15:04 +0200)]
libcore: Simplify Enumerate, Zip::next_back
Use ExactSize::len() and defer to its decisions about overly defensive
assertions. Remove the length double-check and simply put a failure
case if the Zip finds an uneven end in .next_back().
Fixing this up since I think I wrote this, and it's been known to
confuse rusties (PR#15886).
bors [Sun, 24 Aug 2014 11:16:02 +0000 (11:16 +0000)]
auto merge of #16717 : tshepang/rust/misplaced-comma, r=pcwalton
Also:
* Remove unseeming repetition.
* By now, the reader has already heard that Rust is safe by default, so
reduce the overlong sentence, making it easier to read.
We have to specify the module and the function name in the example where
the module shares a crate with the executable as well, so remove the
redundant (and potentially confusing) mention.
bors [Sun, 24 Aug 2014 09:30:56 +0000 (09:30 +0000)]
auto merge of #16710 : dotdash/rust/mergefunc, r=thestinger
Fixes #9536
---
From https://github.com/rust-lang/rust/issues/9536#issuecomment-45495670:
I've built rustc with the aforementioned fix, once with MergeFunc being run early (that's what the patch for clang that comes with LLVM does), and once with MergeFunc being run late (using `-C passes=mergefunc`). Here are some time/code size measurements I made with them:
So running MergeFunc early like in the clang patch isn't nearly as good as running it late. I also tried to enable usage of global aliases instead of just thunks when merging functions, but that crashes.
bors [Sun, 24 Aug 2014 03:10:59 +0000 (03:10 +0000)]
auto merge of #16698 : bluss/rust/slice-bloat, r=huonw
These are somewhat stop-gap solutions to address #16625
core: Separate failure formatting in str methods slice, slice_to, slice_from
Use a separate inline-never function to format failure message for
str::slice() errors.
Using strcat's idea, this makes sure no formatting code from failure is
inlined when str::slice() is inlined. The number of `unreachable` being
inlined when usingi `.slice()` drops from 5 to just 1.
* Remove unseeming repetition.
* By now, the reader has already heard that Rust is safe by default, so
reduce the overlong sentence, making it easier to read.
bors [Sat, 23 Aug 2014 20:50:57 +0000 (20:50 +0000)]
auto merge of #16670 : Swatinem/rust/charascii, r=alexcrichton
I was doing a lot of parsing ascii strings, and the generic bsearch functions in `tables.rs` came up very high in the profile.
This should avoid calling those functions for simple ASCII range chars.
bors [Sat, 23 Aug 2014 18:00:59 +0000 (18:00 +0000)]
auto merge of #16612 : nham/rust/twoway_searcher_fix, r=alexcrichton
There is a check in TwoWaySearcher::new to determine whether the needle is periodic. This is needed because during searching when a match fails, we cannot advance the position by the entire length of the needle when it is periodic, but can only advance by the length of the period.
The reason "bananas".contains("nana") (and similar searches) were returning false was because the periodicity check was wrong.
Closes #16589
Also, thanks to @Gankro, who came up with many buggy examples.
root [Sat, 23 Aug 2014 10:30:08 +0000 (12:30 +0200)]
core: Separate failure formatting in str methods slice, slice_to, slice_from
Use a separate inline-never function to format failure message for
str::slice() errors.
Using strcat's idea, this makes sure no formatting code from failure is
inlined when str::slice() is inlined. The number of `unreachable` being
inlined when usingi `.slice()` drops from 5 to just 1.
projects / rust.git / log