bors [Mon, 13 Oct 2014 17:42:42 +0000 (17:42 +0000)]
auto merge of #17910 : taylorhutchison/rust/patch-1, r=alexcrichton
Added 64-bit Windows support to the list of platforms. Support for 64-bit Windows was added in Rust 0.12.0. See https://mail.mozilla.org/pipermail/rust-dev/2014-October/011267.html for the release notes.
bors [Mon, 13 Oct 2014 12:27:43 +0000 (12:27 +0000)]
auto merge of #17963 : sfackler/rust/cfg-error, r=alexcrichton
All deprecation warnings have been converted to errors. This includes
the warning for multiple cfgs on one item. We'll leave that as an error
for some period of time to ensure that all uses are updated before the
behavior changes from "or" to "and".
bors [Mon, 13 Oct 2014 10:32:43 +0000 (10:32 +0000)]
auto merge of #17975 : thestinger/rust/fPIE, r=eddyb
Position independent code has fewer requirements in executables, so pass
the appropriate flag to LLVM in order to allow more optimization. At the
moment this means faster thread-local storage.
NODA, Kai [Sun, 5 Oct 2014 10:11:17 +0000 (18:11 +0800)]
Clean up rustc warnings.
compiletest: compact "linux" "macos" etc.as "unix".
liballoc: remove a superfluous "use".
libcollections: remove invocations of deprecated methods in favor of
their suggested replacements and use "_" for a loop counter.
libcoretest: remove invocations of deprecated methods; also add
"allow(deprecated)" for testing a deprecated method itself.
libglob: use "cfg_attr".
libgraphviz: add a test for one of data constructors.
libgreen: remove a superfluous "use".
libnum: "allow(type_overflow)" for type cast into u8 in a test code.
librustc: names of static variables should be in upper case.
libserialize: v[i] instead of get().
libstd/ascii: to_lowercase() instead of to_lower().
libstd/bitflags: modify AnotherSetOfFlags to use i8 as its backend.
It will serve better for testing various aspects of bitflags!.
libstd/collections: "allow(deprecated)" for testing a deprecated
method itself.
libstd/io: remove invocations of deprecated methods and superfluous "use".
Also add #[test] where it was missing.
libstd/num: introduce a helper function to effectively remove
invocations of a deprecated method.
libstd/path and rand: remove invocations of deprecated methods and
superfluous "use".
libstd/task and libsync/comm: "allow(deprecated)" for testing
a deprecated method itself.
libsync/deque: remove superfluous "unsafe".
libsync/mutex and once: names of static variables should be in upper case.
libterm: introduce a helper function to effectively remove
invocations of a deprecated method.
We still see a few warnings about using obsoleted native::task::spawn()
in the test modules for libsync. I'm not sure how I should replace them
with std::task::TaksBuilder and native::task::NativeTaskBuilder
(dependency to libstd?)
libtime: `strftime` and `strptime` return type changed to `Result<String, ParseError>`.
`strftime` currently returns a `String`. This does not indicate that
this function may return an error due to to a malformed format string.
This change introduces a `ParseError` enum which indicates the type of
error that occurred. The return type of `strptime` was also changed to
use this new enum instead of returning `Result<String, String>`. Now,
all instances where `strftime` was used need to have their return value
checked to see if it were valid or not.
Steven Fackler [Sun, 12 Oct 2014 01:05:54 +0000 (18:05 -0700)]
Continue cfg syntax transition
All deprecation warnings have been converted to errors. This includes
the warning for multiple cfgs on one item. We'll leave that as an error
for some period of time to ensure that all uses are updated before the
behavior changes from "or" to "and".
Jakub Wieczorek [Sat, 11 Oct 2014 12:05:16 +0000 (14:05 +0200)]
Never expand specialized columns that only contain wild patterns in them
Doing so would incur deeply nested expansion of the tree with no useful
side effects. This is problematic for "wide" data types such as structs
with dozens of fields but where only a few are actually being matched or bound.
Most notably, matching a fixed slice would use a number of stack frames that
grows with the number of elements in the slice.
Daniel Micay [Sat, 9 Aug 2014 16:43:45 +0000 (12:43 -0400)]
optimize position independent code in executables
Position independent code has fewer requirements in executables, so pass
the appropriate flag to LLVM in order to allow more optimization. At the
moment this means faster thread-local storage.
bors [Sat, 11 Oct 2014 21:42:17 +0000 (21:42 +0000)]
auto merge of #17892 : nodakai/rust/rustdoc-dont-nest-a, r=alexcrichton
Some examples:
- `std::slice::slice`: [before](http://validator.w3.org/check?uri=http%3A%2F%2Fdoc.rust-lang.org%2Fstd%2Fslice%2Fprimitive.slice.html&charset=%28detect+automatically%29&doctype=Inline&group=0) and [after](http://validator.w3.org/check?uri=http%3A%2F%2Fnodakai.github.io%2Frust-f40b60b-doc%2Fstd%2Fslice%2Fprimitive.slice.html&charset=%28detect+automatically%29&doctype=Inline&group=0)
- `core::char::char`: [before](http://validator.w3.org/check?uri=http%3A%2F%2Fdoc.rust-lang.org%2Fcore%2Fchar%2Fprimitive.char.html&charset=%28detect+automatically%29&doctype=Inline&group=0) and [after](http://validator.w3.org/check?uri=http%3A%2F%2Fnodakai.github.io%2Frust-f40b60b-doc%2Fcore%2Fchar%2Fprimitive.char.html&charset=%28detect+automatically%29&doctype=Inline&group=0)
- `hexfloat::expand_syntax_ext`: [before](http://validator.w3.org/check?uri=http%3A%2F%2Fdoc.rust-lang.org%2Fhexfloat%2Ffn.expand_syntax_ext.html&charset=%28detect+automatically%29&doctype=Inline&group=0) and [after](http://validator.w3.org/check?uri=http%3A%2F%2Fnodakai.github.io%2Frust-f40b60b-doc%2Fhexfloat%2Ffn.expand_syntax_ext.html&charset=%28detect+automatically%29&doctype=Inline&group=0)
bors [Sat, 11 Oct 2014 18:37:13 +0000 (18:37 +0000)]
auto merge of #17801 : Gankro/rust/collections-stuff, r=sfackler
I previously avoided `#[inline]`ing anything assuming someone would come in and explain to me where this would be appropriate. Apparently no one *really* knows, so I'll just go the opposite way an inline everything assuming someone will come in and yell at me that such-and-such shouldn't be `#[inline]`.
==================
For posterity, iteration comparisons:
```
test btree::map::bench::iter_20 ... bench: 971 ns/iter (+/- 30)
test btree::map::bench::iter_1000 ... bench: 29445 ns/iter (+/- 480)
test btree::map::bench::iter_100000 ... bench: 2929035 ns/iter (+/- 21551)
test treemap::bench::iter_20 ... bench: 530 ns/iter (+/- 66)
test treemap::bench::iter_1000 ... bench: 26287 ns/iter (+/- 825)
test treemap::bench::iter_100000 ... bench: 7650084 ns/iter (+/- 356711)
test trie::bench_map::iter_20 ... bench: 646 ns/iter (+/- 265)
test trie::bench_map::iter_1000 ... bench: 43556 ns/iter (+/- 5014)
test trie::bench_map::iter_100000 ... bench: 12988002 ns/iter (+/- 139676)
```
As you can see `btree` "scales" much better than `treemap`. `triemap` scales quite poorly.
Note that *completely* different results are given if the elements are inserted in order from the range [0, size]. In particular, TrieMap *completely* dominates in the sorted case. This suggests adding benches for both might be worthwhile. However unsorted is *probably* the more "normal" case, so I consider this "good enough" for now.
bors [Sat, 11 Oct 2014 04:37:04 +0000 (04:37 +0000)]
auto merge of #17936 : TeXitoi/rust/remove-shootout-warnings, r=alexcrichton
Only one warning remain, and I can't find a way to remove it without doing more bound checks:
```
shootout-nbody.rs:105:36: 105:51 warning: use of deprecated item: use iter_mut, #[warn(deprecated)] on by default
shootout-nbody.rs:105 let bi = match b_slice.mut_shift_ref() {
```
using `split_at_mut` may be an option, but it will do more bound checking.
Taylor Hutchison [Fri, 10 Oct 2014 04:41:30 +0000 (23:41 -0500)]
Update README.md
Added 64-bit Windows support to the list of platforms. Support for 64-bit Windows was added in Rust 0.12.0. See https://mail.mozilla.org/pipermail/rust-dev/2014-October/011267.html for the release notes.
bors [Fri, 10 Oct 2014 03:02:02 +0000 (03:02 +0000)]
auto merge of #17669 : nikomatsakis/rust/multidispatch, r=pcwalton
Implement multidispatch and conditional dispatch. Because we do not attempt to preserve crate concatenation, this is a backwards compatible change. This is not yet fully integrated into method dispatch, so "UFCS"-style wrappers must be used to take advantage of the new features (see the run-pass tests).
cc #17307 (multidispatch)
cc #5527 (trait reform -- conditional dispatch)
Because we no longer preserve crate concatenability, this deviates slightly from what was specified in the RFC. The motivation for this change is described in [this blog post](http://smallcultfollowing.com/babysteps/blog/2014/09/30/multi-and-conditional-dispatch-in-traits/). I will post an amendment to the RFC in due course but do not anticipate great controversy on this point -- particularly as the RFCs more important features (e.g., conditional dispatch) just don't work without the change.
bors [Fri, 10 Oct 2014 00:07:08 +0000 (00:07 +0000)]
auto merge of #17853 : alexcrichton/rust/issue-17718, r=pcwalton
This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.
The semantics of these three kinds of globals are:
* A `const` does not represent a memory location, but only a value. Constants
are translated as rvalues, which means that their values are directly inlined
at usage location (similar to a #define in C/C++). Constant values are, well,
constant, and can not be modified. Any "modification" is actually a
modification to a local value on the stack rather than the actual constant
itself.
Almost all values are allowed inside constants, whether they have interior
mutability or not. There are a few minor restrictions listed in the RFC, but
they should in general not come up too often.
* A `static` now always represents a memory location (unconditionally). Any
references to the same `static` are actually a reference to the same memory
location. Only values whose types ascribe to `Sync` are allowed in a `static`.
This restriction is in place because many threads may access a `static`
concurrently. Lifting this restriction (and allowing unsafe access) is a
future extension not implemented at this time.
* A `static mut` continues to always represent a memory location. All references
to a `static mut` continue to be `unsafe`.
This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:
* Statics may no longer be used in patterns. Statics now always represent a
memory location, which can sometimes be modified. To fix code, repurpose the
matched-on-`static` to a `const`.
* Statics may no longer refer to other statics by value. Due to statics being
able to change at runtime, allowing them to reference one another could
possibly lead to confusing semantics. If you are in this situation, use a
constant initializer instead. Note, however, that statics may reference other
statics by address, however.
* Statics may no longer be used in constant expressions, such as array lengths.
This is due to the same restrictions as listed above. Use a `const` instead.
bors [Thu, 9 Oct 2014 19:02:06 +0000 (19:02 +0000)]
auto merge of #17558 : kaseyc/rust/fix_bitvset_union, r=aturon
Updates the other_op function shared by the union/intersect/difference/symmetric_difference -with functions to fix an issue where certain elements would not be present in the result. To fix this, when other op is called, we resize self's nbits to account for any new elements that may be added to the set.
Example:
```rust
let mut a = BitvSet::new();
let mut b = BitvSet::new();
a.insert(0);
b.insert(5);
a.union_with(&b);
println!("{}", a); //Prints "{0}" instead of "{0, 5}"
```
Alex Crichton [Tue, 7 Oct 2014 02:15:08 +0000 (19:15 -0700)]
syntax: Tweak the return value of bytes!()
Instead of returning &'static [u8], an invocation of `bytes!()` now returns
`&'static [u8, ..N]` where `N` is the length of the byte vector. This should
functionally be the same, but there are some cases where an explicit cast may be
needed, so this is a:
projects / rust.git / log