bors [Fri, 6 Jun 2014 19:17:10 +0000 (12:17 -0700)]
auto merge of #14318 : zwarich/rust/check-loans-refactor, r=nikomatsakis
I tried to split up the less mechanical changes into separate commits so they are easier to review. One thing I'm not quite sure of is whether `MoveReason` should just be replaced with `move_data::MoveKind`.
Cameron Zwarich [Fri, 6 Jun 2014 18:59:33 +0000 (11:59 -0700)]
Add a test for borrowck errors with multiple closure captures.
When converting check_loans to use ExprUseVisitor I encountered a few
issues where the wrong number of errors were being emitted for multiple
closure captures, but there is no existing test for this.
Cameron Zwarich [Fri, 6 Jun 2014 18:59:33 +0000 (11:59 -0700)]
Add a move reason to the Move ConsumeMode.
Currently it is not possible to distinguish moves caused by captures
in the ExprUseVisitor interface. Since check_Loans needs to make that
distinction for generating good diagnostics, this is necessary for
check_loans to switch to ExprUseVisitor.
Cameron Zwarich [Fri, 6 Jun 2014 18:59:32 +0000 (11:59 -0700)]
Add an Init mode to MutateMode.
This isn't necessary right now, but check_loans needs to be able to
distinguish between initialization and writes in the ExprUseVisitor
mutate callback.
Cameron Zwarich [Fri, 6 Jun 2014 18:59:32 +0000 (11:59 -0700)]
Fix mem_categorization to treat an AutoObject adjustment as an rvalue.
Currently mem_categorization categorizes an AutoObject adjustment the
same as the original expression. This can cause two moves to be
generated for the same underlying expression. Currently this isn't a
problem in practice, since check_loans doesn't rely on ExprUseVisitor.
Cameron Zwarich [Fri, 6 Jun 2014 18:59:32 +0000 (11:59 -0700)]
Clean up check_loans.
Refactor a number of functions in check_loans to take node IDs and spans
rather than taking expressions directly. Also rename some variables to
make them less ambiguous.
This is the first step towards using ExprUseVisitor in check_loans, as
now some of the interfaces more closely match those used in
ExprUseVisitor.
bors [Fri, 6 Jun 2014 01:36:56 +0000 (18:36 -0700)]
auto merge of #14653 : alexcrichton/rust/travis-opt, r=cmr
The most frequent failure for our travis builds is running into the timeout
limits when building the compiler itself. Building librustc takes a very long
amount of time, often hitting the 10 minutes with no output threshold that
travis imposes on us.
This commit switches the relevant `make` step to being wrapped in the
`travis_wait` command [1]. This command will print something once a minute so as
to not time out a build.
This will hopefully enable us to have fewer flaky builds on travis!
bors [Thu, 5 Jun 2014 22:01:54 +0000 (15:01 -0700)]
auto merge of #14538 : alexcrichton/rust/libcollections, r=brson
As with the previous commit with `librand`, this commit shuffles around some
`collections` code. The new state of the world is similar to that of librand:
* The libcollections crate now only depends on libcore and liballoc.
* The standard library has a new module, `std::collections`. All functionality
of libcollections is reexported through this module.
I would like to stress that this change is purely cosmetic. There are very few
alterations to these primitives.
There are a number of notable points about the new organization:
* std::{str, slice, string, vec} all moved to libcollections. There is no reason
that these primitives shouldn't be necessarily usable in a freestanding
context that has allocation. These are all reexported in their usual places in
the standard library.
* The `hashmap`, and transitively the `lru_cache`, modules no longer reside in
`libcollections`, but rather in libstd. The reason for this is because the
`HashMap::new` contructor requires access to the OSRng for initially seeding
the hash map. Beyond this requirement, there is no reason that the hashmap
could not move to libcollections.
I do, however, have a plan to move the hash map to the collections module. The
`HashMap::new` function could be altered to require that the `H` hasher
parameter ascribe to the `Default` trait, allowing the entire `hashmap` module
to live in libcollections. The key idea would be that the default hasher would
be different in libstd. Something along the lines of:
// src/libstd/collections/mod.rs
pub type HashMap<K, V, H = RandomizedSipHasher> =
core_collections::HashMap<K, V, H>;
This is not possible today because you cannot invoke static methods through
type aliases. If we modified the compiler, however, to allow invocation of
static methods through type aliases, then this type definition would
essentially be switching the default hasher from `SipHasher` in libcollections
to a libstd-defined `RandomizedSipHasher` type. This type's `Default`
implementation would randomly seed the `SipHasher` instance, and otherwise
perform the same as `SipHasher`.
This future state doesn't seem incredibly far off, but until that time comes,
the hashmap module will live in libstd to not compromise on functionality.
* In preparation for the hashmap moving to libcollections, the `hash` module has
moved from libstd to libcollections. A previously snapshotted commit enables a
distinct `Writer` trait to live in the `hash` module which `Hash`
implementations are now parameterized over.
Due to using a custom trait, the `SipHasher` implementation has lost its
specialized methods for writing integers. These can be re-added
backwards-compatibly in the future via default methods if necessary, but the
FNV hashing should satisfy much of the need for speedier hashing.
A list of breaking changes:
* HashMap::{get, get_mut} no longer fails with the key formatted into the error
message with `{:?}`, instead, a generic message is printed. With backtraces,
it should still be not-too-hard to track down errors.
* The HashMap, HashSet, and LruCache types are now available through
std::collections instead of the collections crate.
* Manual implementations of hash should be parameterized over `hash::Writer`
instead of just `Writer`.
Alex Crichton [Fri, 30 May 2014 01:50:12 +0000 (18:50 -0700)]
std: Recreate a `collections` module
As with the previous commit with `librand`, this commit shuffles around some
`collections` code. The new state of the world is similar to that of librand:
* The libcollections crate now only depends on libcore and liballoc.
* The standard library has a new module, `std::collections`. All functionality
of libcollections is reexported through this module.
I would like to stress that this change is purely cosmetic. There are very few
alterations to these primitives.
There are a number of notable points about the new organization:
* std::{str, slice, string, vec} all moved to libcollections. There is no reason
that these primitives shouldn't be necessarily usable in a freestanding
context that has allocation. These are all reexported in their usual places in
the standard library.
* The `hashmap`, and transitively the `lru_cache`, modules no longer reside in
`libcollections`, but rather in libstd. The reason for this is because the
`HashMap::new` contructor requires access to the OSRng for initially seeding
the hash map. Beyond this requirement, there is no reason that the hashmap
could not move to libcollections.
I do, however, have a plan to move the hash map to the collections module. The
`HashMap::new` function could be altered to require that the `H` hasher
parameter ascribe to the `Default` trait, allowing the entire `hashmap` module
to live in libcollections. The key idea would be that the default hasher would
be different in libstd. Something along the lines of:
// src/libstd/collections/mod.rs
pub type HashMap<K, V, H = RandomizedSipHasher> =
core_collections::HashMap<K, V, H>;
This is not possible today because you cannot invoke static methods through
type aliases. If we modified the compiler, however, to allow invocation of
static methods through type aliases, then this type definition would
essentially be switching the default hasher from `SipHasher` in libcollections
to a libstd-defined `RandomizedSipHasher` type. This type's `Default`
implementation would randomly seed the `SipHasher` instance, and otherwise
perform the same as `SipHasher`.
This future state doesn't seem incredibly far off, but until that time comes,
the hashmap module will live in libstd to not compromise on functionality.
* In preparation for the hashmap moving to libcollections, the `hash` module has
moved from libstd to libcollections. A previously snapshotted commit enables a
distinct `Writer` trait to live in the `hash` module which `Hash`
implementations are now parameterized over.
Due to using a custom trait, the `SipHasher` implementation has lost its
specialized methods for writing integers. These can be re-added
backwards-compatibly in the future via default methods if necessary, but the
FNV hashing should satisfy much of the need for speedier hashing.
A list of breaking changes:
* HashMap::{get, get_mut} no longer fails with the key formatted into the error
message with `{:?}`, instead, a generic message is printed. With backtraces,
it should still be not-too-hard to track down errors.
* The HashMap, HashSet, and LruCache types are now available through
std::collections instead of the collections crate.
* Manual implementations of hash should be parameterized over `hash::Writer`
instead of just `Writer`.
bors [Thu, 5 Jun 2014 20:26:53 +0000 (13:26 -0700)]
auto merge of #14647 : BurntSushi/rust/fix-14185, r=alexcrichton
This fix suppresses dead_code warnings from code generated by regex! when
the result of regex! is unused. Correct behavior should be a single
unused variable warning.
Regression tests are included for both `let` and `static` bound regex!
values.
bors [Thu, 5 Jun 2014 18:06:53 +0000 (11:06 -0700)]
auto merge of #14526 : pczarn/rust/hashmap-opt, r=alexcrichton
An interface that gives a better control over the load factor and the minimum capacity for HashMap.
The size of `HashMap<K, V>` is now 64 bytes by default on a 64-bit platform (or at least 40 bytes, that is 3 words less, with FNV and without minimum capacity)
Unanswered questions about `ResizePolicy`
* should it control the `INITIAL_CAPACITY`?
* should it fully control the resizing behavior? Even though the capacity always changes by a factor of 2.
* is caching `grow_at` desirable?
bors [Thu, 5 Jun 2014 15:26:51 +0000 (08:26 -0700)]
auto merge of #14644 : alexcrichton/rust/more-no-runtime-use-cases, r=brson
A few notable improvements were implemented to cut down on the number of aborts
triggered by the standard library when a local task is not found.
* Primarily, the unwinding functionality was restructured to support an unsafe
top-level function, `try`. This function invokes a closure, capturing any
failure which occurs inside of it. The purpose of this function is to be as
lightweight of a "try block" as possible for rust, intended for use when the
runtime is difficult to set up.
This function is *not* meant to be used by normal rust code, nor should it be
consider for use with normal rust code.
* When invoking spawn(), a `fail!()` is triggered rather than an abort.
* When invoking LocalIo::borrow(), which is transitively called by all I/O
constructors, None is returned rather than aborting to indicate that there is
no local I/O implementation.
A test case was also added showing the variety of things that you can do without
a runtime or task set up now. In general, this is just a refactoring to abort
less quickly in the standard library when a local task is not found.
bors [Thu, 5 Jun 2014 07:51:48 +0000 (00:51 -0700)]
auto merge of #14568 : erickt/rust/slice-update, r=alexcrichton
This PR adds two features to make it possible to transform an `Iterator<u8>` into a `Reader`. The first patch adds a method to mutable slices that allows it to be updated with an `Iterator<T>` without paying for the bounds cost. The second adds a Iterator adaptor, `IterReader`, to provide that `Reader` interface.
I had two questions. First, are these named the right things? Second, should `IterReader` instead wrap an `Iterator<Result<u8, E>>`? This would allow you to `IterReader::new(rdr.bytes())`, which could be useful if you want to apply some iterator transformations on a reader while still exporting the Reader interface, but I'd expect there'd be a lot of overhead annotating each byte with an error result.
bors [Thu, 5 Jun 2014 03:41:44 +0000 (20:41 -0700)]
auto merge of #14610 : alexcrichton/rust/issue-14008, r=brson
This commit removes the <M: Any + Send> type parameter from Option::expect in
favor of just taking a hard-coded `&str` argument. This allows this function to
move into libcore.
Previous code using strings with `expect` will continue to work, but code using
this implicitly to transmit task failure will need to unwrap manually with a
`match` statement.
bors [Thu, 5 Jun 2014 01:56:48 +0000 (18:56 -0700)]
auto merge of #14529 : brson/rust/ptr, r=brson
This time we're not promoting anything directly to 'stable', but instead promoting functions we're happy with to 'unstable'. They'll become stable in another pass later.
* null and mut_null are unstable. Their names may change if the unsafe
pointer types change.
* copy_memory and copy_overlapping_memory are unstable. We think they
aren't going to change.
* set_memory and zero_memory are experimental. Both the names and
the semantics are under question.
* swap and replace are unstable and probably won't change.
* read is unstable, probably won't change
* read_and_zero is experimental. It's necessity is in doubt.
* mem::overwrite is now called ptr::write to match read and is
unstable. mem::overwrite is now deprecated
* array_each, array_each_with_len, buf_len, and position are
all deprecated because they use old style iteration and their
utility is generally under question.
Note that `mem::overwrite`, which was just declared stable last week, is deprecated now in favor of `ptr::write`. Woo!
Brian Anderson [Fri, 30 May 2014 00:40:18 +0000 (17:40 -0700)]
core: Apply stability attributes to ptr mod
* null and mut_null are unstable. Their names may change if the unsafe
pointer types change.
* copy_memory and copy_overlapping_memory are unstable. We think they
aren't going to change.
* set_memory and zero_memory are experimental. Both the names and
the semantics are under question.
* swap and replace are unstable and probably won't change.
* read is unstable, probably won't change
* read_and_zero is experimental. It's necessity is in doubt.
* mem::overwrite is now called ptr::write to match read and is
unstable. mem::overwrite is now deprecated
* array_each, array_each_with_len, buf_len, and position are
all deprecated because they use old style iteration and their
utility is generally under question.
Alex Crichton [Wed, 4 Jun 2014 19:00:42 +0000 (12:00 -0700)]
travis: Prevent timeouts with travis_wait
The most frequent failure for our travis builds is running into the timeout
limits when building the compiler itself. Building librustc takes a very long
amount of time, often hitting the 10 minutes with no output threshold that
travis imposes on us.
This commit switches the relevant `make` step to being wrapped in the
`travis_wait` command [1]. This command will print something once a minute so as
to not time out a build.
This will hopefully enable us to have fewer flaky builds on travis!
Andrew Gallant [Wed, 4 Jun 2014 20:59:27 +0000 (16:59 -0400)]
Fixes #14185.
This fix suppresses dead_code warnings from code generated by regex! when
the result of regex! is unused. Correct behavior should be a single
unused variable warning.
Regression tests are included for both `let` and `static` bound regex!
values.
bors [Wed, 4 Jun 2014 20:06:47 +0000 (13:06 -0700)]
auto merge of #14630 : cmr/rust/rewrite-lexer, r=alexcrichton
These are a pain to rebase, so I'm separating this from the rest of my work.
Nothing controversial here, just some simple refactoring and removal of an
unused entry in the token table. Brings the lexer into 2012 with methods!
Alex Crichton [Wed, 4 Jun 2014 17:54:35 +0000 (10:54 -0700)]
std: Improve non-task-based usage
A few notable improvements were implemented to cut down on the number of aborts
triggered by the standard library when a local task is not found.
* Primarily, the unwinding functionality was restructured to support an unsafe
top-level function, `try`. This function invokes a closure, capturing any
failure which occurs inside of it. The purpose of this function is to be as
lightweight of a "try block" as possible for rust, intended for use when the
runtime is difficult to set up.
This function is *not* meant to be used by normal rust code, nor should it be
consider for use with normal rust code.
* When invoking spawn(), a `fail!()` is triggered rather than an abort.
* When invoking LocalIo::borrow(), which is transitively called by all I/O
constructors, None is returned rather than aborting to indicate that there is
no local I/O implementation.
* Invoking get() on a TLD key will return None if no task is available
* Invoking replace() on a TLD key will fail if no task is available.
A test case was also added showing the variety of things that you can do without
a runtime or task set up now. In general, this is just a refactoring to abort
less quickly in the standard library when a local task is not found.
bors [Wed, 4 Jun 2014 18:06:49 +0000 (11:06 -0700)]
auto merge of #14623 : exscape/rust-fork/master, r=alexcrichton
Unlike ImmutableClonableVector::permutations() which returns an iterator,
cloning the entire array each iteration, these methods mutate the vector in-place.
For that reason, these methods are much faster; between 35-55 times faster,
depending on the benchmark. They also generate permutations in lexicographical order.
Refactored the load factor and the minimum capacity out of HashMap.
The size of HashMap<K, V> is now 64 bytes by default on a 64-bit platform
(or 48 bytes, that is 2 words less, with FNV)
Added a documentation in a few places to clarify the behavior.
bors [Wed, 4 Jun 2014 05:01:43 +0000 (22:01 -0700)]
auto merge of #14634 : BurntSushi/rust/fix-13843, r=alexcrichton
An empty regex is a valid regex that always matches. This behavior
is consistent with at least Go and Python.
A couple regression tests are included.
I'd just assume that an empty regex is an invalid regex and that an error should be returned (I can't think of any reason to use an empty regex?), but it's probably better to be consistent with other regex libraries.
Alex Crichton [Mon, 2 Jun 2014 22:49:42 +0000 (15:49 -0700)]
std: Remove generics from Option::expect
This commit removes the <M: Any + Send> type parameter from Option::expect in
favor of just taking a hard-coded `&str` argument. This allows this function to
move into libcore.
Previous code using strings with `expect` will continue to work, but code using
this implicitly to transmit task failure will need to unwrap manually with a
`match` statement.
bors [Tue, 3 Jun 2014 21:06:42 +0000 (14:06 -0700)]
auto merge of #14626 : klutzy/rust/issue-14618, r=alexcrichton
As part of removing `pub use` glob, two extra import globs were
injected to make `quote_expr!` work. However the globs caused
`unused_import` warning in some places.
Quasiquoter needed the globs since it generated idents (e.g. `TyU`)
rather than absolute paths (`::syntax::ast::TyU`).
This patch removes the extra globs and makes quasiquoter use absolute
paths.
klutzy [Tue, 3 Jun 2014 16:42:11 +0000 (01:42 +0900)]
syntax: Make quasiquoter use absolute paths
As part of removing `pub use` glob, two extra import globs were
injected to make `quote_expr!` work. However the globs caused
`unused_import` warning in some places.
Quasiquoter needed the globs since it generated idents (e.g. `TyU`)
rather than absolute paths (`::syntax::ast::TyU`).
This patch removes the extra globs and makes quasiquoter use absolute
paths.
Thomas Backman [Tue, 3 Jun 2014 14:11:47 +0000 (16:11 +0200)]
Add next_permutation and prev_permutation onto MutableOrdVector<T>.
Unlike ImmutableClonableVector::permutations() which returns an iterator,
cloning the entire array each iteration, these methods mutate the vector in-place.
For that reason, these methods are much faster; between 35-55 times faster,
depending on the benchmark. They also generate permutations in lexicographical order.
bors [Tue, 3 Jun 2014 00:16:31 +0000 (17:16 -0700)]
auto merge of #14601 : skade/rust/remove-notrust-tags, r=alexcrichton
Now that rustdoc understands proper language tags
as the code not being Rust, we can tag everything
properly. `norust` as a negative statement is a bad
tag.
This change tags examples in other languages by
their language. Plain notations are marked as `text`.
Console examples are marked as `console`.
Also fix markdown.rs to not highlight non-rust code.
Amends the documentation to reflect the new
behaviour.
projects / rust.git / log