Simon Sapin [Tue, 29 Jul 2014 21:05:37 +0000 (22:05 +0100)]
Gedit/gtksourceview language spec: add raw strings
… and color (raw) strings as such in attributes.
This fixes cases where a string contains ] inside an attribute:
that ] used to incorrectly end the attribute coloring.
For large (many lines) doc comments, I’ve found preferable to use
`#![doc = r#"..."#]` to avoid prefixing every line with `//!`.
* Make the code fill up the full width of the page (no massive whitespace on the left)
* Move the code down to make it not intersect the logo
* Set a min-width and remove the max-width so that the code doesn't scroll internally, but instead scrolls the page, meaning horizontal scroll bars are always available
* Set overflow to actually overflow, just to be sure
Jonas Hietala [Mon, 28 Jul 2014 14:03:01 +0000 (16:03 +0200)]
Rename Integer trait `divides` to `is_multiple_of`.
It is being changed because the previous wording was ambiguous.
`a.divides(b)` implied `a % b == 0` but it sounds like the other way
around. `9.divides(&3) == true` but we might read that as
"does 9 divide 3?". It has been renamed to sidestep the ambiguity.
Work around the change by using `is_multiple_of` instead.
Anton Lofgren [Tue, 22 Jul 2014 06:33:03 +0000 (08:33 +0200)]
lint: Improve ffi-unsafe enum lint warning
I think this is an improvement of the previous warning message, which
- like the comment that I removed implies - is in need of some
improvement.
I've opted to point the user in the right direction w.r.t how to fix the
problem, which I think is good form.
Not being familiar with the repr(...) attribute, I personally had to
check the lint rules myself to figure out what was wrong. Hopefully,
this will save he next person some time and headache.
auto merge of #15989 : pcwalton/rust/borrowck-pattern-guards, r=pnkfelix
the CFG for match statements.
There were two bugs in issue #14684. One was simply that the borrow
check didn't know about the correct CFG for match statements: the
pattern must be a predecessor of the guard. This disallows the bad
behavior if there are bindings in the pattern. But it isn't enough to
prevent the memory safety problem, because of wildcards; thus, this
patch introduces a more restrictive rule, which disallows assignments
and mutable borrows inside guards outright.
I discussed this with Niko and we decided this was the best plan of
action.
This breaks code that performs mutable borrows in pattern guards. Most
commonly, the code looks like this:
- fixing mismatch between the documentation and the function parameters. (i.e. documentation references `path` parameter, but it's actually called `from`, or vice versa)
- A few Error sections were missing an "if" on the middle clause. For example, they used to be: "This function will return an error if [Thing], [Another Thing], or if [Yet Another Thing]." I added an "if" so it becomes "This function will return an error if [Thing], if [Another Thing], or if [Yet Another Thing]"
- The error sections previously started off with 3 different phrases:
- "This function will return an error if ..."
- "Will return an error if ..."
- "This call will return an error if ..."
auto merge of #16033 : nham/rust/hash_tuple_impl, r=alexcrichton
Previously the implementation of Hash was limited to tuples of up to arity 8. This increases it to tuples of up to arity 12.
Also, the implementation macro for `Hash` used to expand to something like this:
impl Hash for (a7,)
impl Hash for (a6, a7)
impl Hash for (a5, a6, a7)
...
This style is inconsistent with the implementations in core::tuple, which look like this:
impl Trait for (A,)
impl Trait for (A, B)
impl Trait for (A, B, C)
...
This is perhaps a minor point, but it does mean the documentation pages are inconsistent. Compare the tuple implementations in the documentation for [Hash](http://static.rust-lang.org/doc/master/std/hash/trait.Hash.html) and [PartialOrd](http://static.rust-lang.org/doc/master/core/cmp/trait.PartialOrd.html)
This changes the Hash implementation to be consistent with `core::tuple`.
auto merge of #15983 : brson/rust/fail, r=alexcrichton
A few refactorings to decrease text size and increase data size. I'm not sure about this tradeoff. Various stats below. cc @pcwalton
This reduces the code needed to pass arguments for `fail!()`, `fail!("{}", ...)`, and to a lesser extent `fail!("...")`. Still more work to be done on compiler-generated failures and the `fail!("...")` case.
```
-rw-rw-r-- 1 brian brian 100501740 Jul 24 23:28 /home/brian/dev/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.rlib
-rwxrwxr-x 1 brian brian 21201780 Jul 24 23:27 /home/brian/dev/rust2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.so
```
file size after:
```
-rw-rw-r-- 1 brian brian 101542484 Jul 25 00:34 x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.rlib
-rwxrwxr-x 1 brian brian 21348862 Jul 25 00:34 x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.so
```
Text size decreases by 52486 while data size increases by 143686.
section size before:
```
text data bss dec hex filename 127122625924997 368 1863762711c633b x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.so
```
section size after:
```
text data bss dec hex filename 126597766068683 368 1872882711dc77b /home/brian/dev/rust/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc-4e7c5e5c.so
```
I don't know if anything can be learned from these benchmarks. Looks like a wash.
std bench before:
```
test collections::hashmap::bench::find_existing ... bench: 43452 ns/iter (+/- 2423)
test collections::hashmap::bench::find_nonexisting ... bench: 42416 ns/iter (+/- 3996)
test collections::hashmap::bench::find_pop_insert ... bench: 214 ns/iter (+/- 11)
test collections::hashmap::bench::hashmap_as_queue ... bench: 123 ns/iter (+/- 6)
test collections::hashmap::bench::insert ... bench: 153 ns/iter (+/- 14)
test collections::hashmap::bench::new_drop ... bench: 547 ns/iter (+/- 259)
test collections::hashmap::bench::new_insert_drop ... bench: 682 ns/iter (+/- 366)
test io::buffered::test::bench_buffered_reader ... bench: 1046 ns/iter (+/- 86)
test io::buffered::test::bench_buffered_stream ... bench: 2156 ns/iter (+/- 801)
test io::buffered::test::bench_buffered_writer ... bench: 1057 ns/iter (+/- 75)
test io::extensions::bench::u64_from_be_bytes_4_aligned ... bench: 80 ns/iter (+/- 5)
test io::extensions::bench::u64_from_be_bytes_4_unaligned ... bench: 81 ns/iter (+/- 6)
test io::extensions::bench::u64_from_be_bytes_7_aligned ... bench: 80 ns/iter (+/- 4)
test io::extensions::bench::u64_from_be_bytes_7_unaligned ... bench: 69 ns/iter (+/- 4)
test io::extensions::bench::u64_from_be_bytes_8_aligned ... bench: 69 ns/iter (+/- 3)
test io::extensions::bench::u64_from_be_bytes_8_unaligned ... bench: 81 ns/iter (+/- 4)
test io::mem::test::bench_buf_reader ... bench: 628 ns/iter (+/- 18)
test io::mem::test::bench_buf_writer ... bench: 478 ns/iter (+/- 19)
test io::mem::test::bench_mem_reader ... bench: 712 ns/iter (+/- 44)
test io::mem::test::bench_mem_writer_001_0000 ... bench: 31 ns/iter (+/- 1)
test io::mem::test::bench_mem_writer_001_0010 ... bench: 51 ns/iter (+/- 3)
test io::mem::test::bench_mem_writer_001_0100 ... bench: 121 ns/iter (+/- 8)
test io::mem::test::bench_mem_writer_001_1000 ... bench: 774 ns/iter (+/- 47)
test io::mem::test::bench_mem_writer_100_0000 ... bench: 756 ns/iter (+/- 50)
test io::mem::test::bench_mem_writer_100_0010 ... bench: 2726 ns/iter (+/- 198)
test io::mem::test::bench_mem_writer_100_0100 ... bench: 8961 ns/iter (+/- 712)
test io::mem::test::bench_mem_writer_100_1000 ... bench: 105673 ns/iter (+/- 24711)
test num::bench::bench_pow_function ... bench: 5849 ns/iter (+/- 371)
test num::strconv::bench::f64::float_to_string ... bench: 662 ns/iter (+/- 202)
test num::strconv::bench::int::to_str_base_36 ... bench: 424 ns/iter (+/- 7)
test num::strconv::bench::int::to_str_bin ... bench: 1227 ns/iter (+/- 80)
test num::strconv::bench::int::to_str_dec ... bench: 466 ns/iter (+/- 13)
test num::strconv::bench::int::to_str_hex ... bench: 498 ns/iter (+/- 22)
test num::strconv::bench::int::to_str_oct ... bench: 502 ns/iter (+/- 229)
test num::strconv::bench::uint::to_str_base_36 ... bench: 375 ns/iter (+/- 7)
test num::strconv::bench::uint::to_str_bin ... bench: 1011 ns/iter (+/- 590)
test num::strconv::bench::uint::to_str_dec ... bench: 407 ns/iter (+/- 17)
test num::strconv::bench::uint::to_str_hex ... bench: 442 ns/iter (+/- 7)
test num::strconv::bench::uint::to_str_oct ... bench: 433 ns/iter (+/- 46)
test path::posix::bench::ends_with_path_home_dir ... bench: 167 ns/iter (+/- 10)
test path::posix::bench::ends_with_path_missmatch_jome_home ... bench: 148 ns/iter (+/- 6)
test path::posix::bench::is_ancestor_of_path_with_10_dirs ... bench: 221 ns/iter (+/- 31)
test path::posix::bench::join_abs_path_home_dir ... bench: 144 ns/iter (+/- 23)
test path::posix::bench::join_home_dir ... bench: 196 ns/iter (+/- 9)
test path::posix::bench::join_many_abs_path_home_dir ... bench: 143 ns/iter (+/- 6)
test path::posix::bench::join_many_home_dir ... bench: 195 ns/iter (+/- 8)
test path::posix::bench::path_relative_from_backward ... bench: 248 ns/iter (+/- 10)
test path::posix::bench::path_relative_from_forward ... bench: 241 ns/iter (+/- 13)
test path::posix::bench::path_relative_from_same_level ... bench: 296 ns/iter (+/- 11)
test path::posix::bench::push_abs_path_home_dir ... bench: 104 ns/iter (+/- 7)
test path::posix::bench::push_home_dir ... bench: 27311 ns/iter (+/- 2727)
test path::posix::bench::push_many_abs_path_home_dir ... bench: 109 ns/iter (+/- 5)
test path::posix::bench::push_many_home_dir ... bench: 23263 ns/iter (+/- 1726)
test rand::bench::rand_isaac ... bench: 884 ns/iter (+/- 31) = 904 MB/s
test rand::bench::rand_isaac64 ... bench: 440 ns/iter (+/- 126) = 1818 MB/s
test rand::bench::rand_shuffle_100 ... bench: 2518 ns/iter (+/- 1371)
test rand::bench::rand_std ... bench: 429 ns/iter (+/- 17) = 1864 MB/s
test rand::bench::rand_xorshift ... bench: 0 ns/iter (+/- 0) = 800000 MB/s
```
std bench after:
```
test collections::hashmap::bench::find_existing ... bench: 43635 ns/iter (+/- 4508)
test collections::hashmap::bench::find_nonexisting ... bench: 42323 ns/iter (+/- 1753)
test collections::hashmap::bench::find_pop_insert ... bench: 216 ns/iter (+/- 11)
test collections::hashmap::bench::hashmap_as_queue ... bench: 125 ns/iter (+/- 8)
test collections::hashmap::bench::insert ... bench: 153 ns/iter (+/- 63)
test collections::hashmap::bench::new_drop ... bench: 517 ns/iter (+/- 282)
test collections::hashmap::bench::new_insert_drop ... bench: 734 ns/iter (+/- 264)
test io::buffered::test::bench_buffered_reader ... bench: 1063 ns/iter (+/- 206)
test io::buffered::test::bench_buffered_stream ... bench: 2321 ns/iter (+/- 2302)
test io::buffered::test::bench_buffered_writer ... bench: 1060 ns/iter (+/- 24)
test io::extensions::bench::u64_from_be_bytes_4_aligned ... bench: 69 ns/iter (+/- 2)
test io::extensions::bench::u64_from_be_bytes_4_unaligned ... bench: 81 ns/iter (+/- 7)
test io::extensions::bench::u64_from_be_bytes_7_aligned ... bench: 70 ns/iter (+/- 5)
test io::extensions::bench::u64_from_be_bytes_7_unaligned ... bench: 69 ns/iter (+/- 5)
test io::extensions::bench::u64_from_be_bytes_8_aligned ... bench: 80 ns/iter (+/- 6)
test io::extensions::bench::u64_from_be_bytes_8_unaligned ... bench: 81 ns/iter (+/- 5)
test io::mem::test::bench_buf_reader ... bench: 663 ns/iter (+/- 44)
test io::mem::test::bench_buf_writer ... bench: 489 ns/iter (+/- 17)
test io::mem::test::bench_mem_reader ... bench: 700 ns/iter (+/- 23)
test io::mem::test::bench_mem_writer_001_0000 ... bench: 31 ns/iter (+/- 3)
test io::mem::test::bench_mem_writer_001_0010 ... bench: 49 ns/iter (+/- 5)
test io::mem::test::bench_mem_writer_001_0100 ... bench: 112 ns/iter (+/- 6)
test io::mem::test::bench_mem_writer_001_1000 ... bench: 765 ns/iter (+/- 59)
test io::mem::test::bench_mem_writer_100_0000 ... bench: 727 ns/iter (+/- 54)
test io::mem::test::bench_mem_writer_100_0010 ... bench: 2586 ns/iter (+/- 215)
test io::mem::test::bench_mem_writer_100_0100 ... bench: 8846 ns/iter (+/- 439)
test io::mem::test::bench_mem_writer_100_1000 ... bench: 105747 ns/iter (+/- 17443)
test num::bench::bench_pow_function ... bench: 5844 ns/iter (+/- 421)
test num::strconv::bench::f64::float_to_string ... bench: 669 ns/iter (+/- 571)
test num::strconv::bench::int::to_str_base_36 ... bench: 417 ns/iter (+/- 24)
test num::strconv::bench::int::to_str_bin ... bench: 1216 ns/iter (+/- 36)
test num::strconv::bench::int::to_str_dec ... bench: 466 ns/iter (+/- 24)
test num::strconv::bench::int::to_str_hex ... bench: 492 ns/iter (+/- 8)
test num::strconv::bench::int::to_str_oct ... bench: 496 ns/iter (+/- 295)
test num::strconv::bench::uint::to_str_base_36 ... bench: 366 ns/iter (+/- 8)
test num::strconv::bench::uint::to_str_bin ... bench: 1005 ns/iter (+/- 69)
test num::strconv::bench::uint::to_str_dec ... bench: 396 ns/iter (+/- 20)
test num::strconv::bench::uint::to_str_hex ... bench: 435 ns/iter (+/- 4)
test num::strconv::bench::uint::to_str_oct ... bench: 436 ns/iter (+/- 451)
test path::posix::bench::ends_with_path_home_dir ... bench: 171 ns/iter (+/- 6)
test path::posix::bench::ends_with_path_missmatch_jome_home ... bench: 152 ns/iter (+/- 6)
test path::posix::bench::is_ancestor_of_path_with_10_dirs ... bench: 215 ns/iter (+/- 8)
test path::posix::bench::join_abs_path_home_dir ... bench: 143 ns/iter (+/- 6)
test path::posix::bench::join_home_dir ... bench: 192 ns/iter (+/- 29)
test path::posix::bench::join_many_abs_path_home_dir ... bench: 144 ns/iter (+/- 9)
test path::posix::bench::join_many_home_dir ... bench: 194 ns/iter (+/- 19)
test path::posix::bench::path_relative_from_backward ... bench: 254 ns/iter (+/- 15)
test path::posix::bench::path_relative_from_forward ... bench: 244 ns/iter (+/- 17)
test path::posix::bench::path_relative_from_same_level ... bench: 293 ns/iter (+/- 27)
test path::posix::bench::push_abs_path_home_dir ... bench: 108 ns/iter (+/- 5)
test path::posix::bench::push_home_dir ... bench: 32292 ns/iter (+/- 4361)
test path::posix::bench::push_many_abs_path_home_dir ... bench: 108 ns/iter (+/- 6)
test path::posix::bench::push_many_home_dir ... bench: 20305 ns/iter (+/- 1331)
test rand::bench::rand_isaac ... bench: 888 ns/iter (+/- 35) = 900 MB/s
test rand::bench::rand_isaac64 ... bench: 439 ns/iter (+/- 17) = 1822 MB/s
test rand::bench::rand_shuffle_100 ... bench: 2582 ns/iter (+/- 1001)
test rand::bench::rand_std ... bench: 431 ns/iter (+/- 93) = 1856 MB/s
test rand::bench::rand_xorshift ... bench: 0 ns/iter (+/- 0) = 800000 MB/s
```
Some minor changes to the compiler to expose this information. Very
inconvenient since struct fields aren't an item. Adds (yet another) table to
metadata.
auto merge of #16001 : Gankro/rust/rawstrings-proof, r=pnkfelix
Stumbled across this and thought it would be cool to prove. I've never used Ogden's Lemma before, but I'm pretty sure I used it right. The pumping lemma definitely doesn't seem sufficient for the job. In particular, when using the pumping lemma, you can always just pump one of the quotes, and it's fine. Ogden's Lemma lets you effectively force the pumper to use certain characters in the string.
auto merge of #15936 : alexcrichton/rust/stability, r=brson
This commit applies stability attributes to the contents of these modules,
summarized here:
* The `unit` and `bool` modules have become #[unstable] as they are purely meant
for documentation purposes and are candidates for removal.
* The `ty` module has been deprecated, and the inner `Unsafe` type has been
renamed to `UnsafeCell` and moved to the `cell` module. The `marker1` field
has been removed as the compiler now always infers `UnsafeCell` to be
invariant. The `new` method i stable, but the `value` field, `get` and
`unwrap` methods are all unstable.
* The `tuple` module has its name as stable, the naming of the `TupleN` traits
as stable while the methods are all #[unstable]. The other impls in the module
have appropriate stability for the corresponding trait.
* The `arc` module has received the exact same treatment as the `rc` module
previously did.
* The `any` module has its name as stable. The `Any` trait is also stable, with
a new private supertrait which now contains the `get_type_id` method. This is
to make the method a private implementation detail rather than a public-facing
detail.
The two extension traits in the module are marked #[unstable] as they will not
be necessary with DST. The `is` method is #[stable], the as_{mut,ref} methods
have been renamed to downcast_{mut,ref} and are #[unstable].
The extension trait `BoxAny` has been clarified as to why it is unstable as it
will not be necessary with DST.
This is a breaking change because the `marker1` field was removed from the
`UnsafeCell` type. To deal with this change, you can simply delete the field and
only specify the value of the `data` field in static initializers.
Alex Crichton [Thu, 24 Jul 2014 02:10:12 +0000 (19:10 -0700)]
std: Stabilize unit, bool, ty, tuple, arc, any
This commit applies stability attributes to the contents of these modules,
summarized here:
* The `unit` and `bool` modules have become #[unstable] as they are purely meant
for documentation purposes and are candidates for removal.
* The `ty` module has been deprecated, and the inner `Unsafe` type has been
renamed to `UnsafeCell` and moved to the `cell` module. The `marker1` field
has been removed as the compiler now always infers `UnsafeCell` to be
invariant. The `new` method i stable, but the `value` field, `get` and
`unwrap` methods are all unstable.
* The `tuple` module has its name as stable, the naming of the `TupleN` traits
as stable while the methods are all #[unstable]. The other impls in the module
have appropriate stability for the corresponding trait.
* The `arc` module has received the exact same treatment as the `rc` module
previously did.
* The `any` module has its name as stable. The `Any` trait is also stable, with
a new private supertrait which now contains the `get_type_id` method. This is
to make the method a private implementation detail rather than a public-facing
detail.
The two extension traits in the module are marked #[unstable] as they will not
be necessary with DST. The `is` method is #[stable], the as_{mut,ref} methods
have been renamed to downcast_{mut,ref} and are #[unstable].
The extension trait `BoxAny` has been clarified as to why it is unstable as it
will not be necessary with DST.
This is a breaking change because the `marker1` field was removed from the
`UnsafeCell` type. To deal with this change, you can simply delete the field and
only specify the value of the `data` field in static initializers.
auto merge of #15998 : luqmana/rust/nmnnbd, r=thestinger
LLVM recently added a new attribute, dereferenceable: http://reviews.llvm.org/D4449
>This patch adds a dereferencable attribute. In some sense, this is a companion to the nonnull attribute, but specifies that the pointer is known to be dereferencable in the same sense as a pointer generated by alloca is known to be dereferencable.
With rust, everywhere that we previously marked `nonnull` we can actually mark as `dereferenceable` (which implies nonnull) since we know the size. That is, except for one case: when generating calls for TyVisitor. It seems like we haven't substituted the self type (so we have `ty_param`) and just treat it as an opaque pointer so I just left that bit as nonnull.
With this, LLVM can for example hoist a load out of a loop where it previously couldn't:
```Rust
pub fn baz(c: &uint, n: uint) -> uint {
let mut res = 0;
for i in range(0, n) {
if i > 0 {
res += *c * i;
}
}
res
}
```
auto merge of #15988 : brson/rust/antlrprep, r=cmr
Add `check-secondary`, which runs the pretty and lexer tests so we can run them on a dedicated bot. Leaves the pretty tests running under `check` until the bots are switched over. Also fixes some issues.
auto merge of #15982 : alexcrichton/rust/rustdoc-fixes, r=brson
Sadly there's still a lot of open issues, but this tackles some of the more pressing ones. Each commit has its own description along with the issues it closes.
auto merge of #15975 : dotdash/rust/unwind_lifetimes, r=pcwalton
Currently we don't emit lifetime end markers when translating the
unwinding code. I omitted that when I added the support for lifetime
intrinsics, because I initially made the mistake of just returning true
in clean_on_unwind(). That caused almost all calls to be translated as
invokes, leading to quite awful results.
To correctly emit the lifetime end markers, we must differentiate
between cleanup that requires unwinding and such cleanup that just wants
to emit code during unwinding.
auto merge of #15789 : steveklabnik/rust/guide_pointers, r=cmr
This is super, super WIP, but I'm going to go get lunch for a while, and figured I'd toss my work up here in case anyone wants to see my work as I do it.
This contains a new introductory section explaining the basics of pointers, and some pitfalls that Rust attempts to solve. I'd be interested in hearing how my explanation is, as well as if this belongs here. Pointers are such a crucial concept, I don't mind having a beginners' section on them in the main docs, even though our main audience is supposed to understand them already. Reasonable people may disagree, however.