- 11 1月, 2014 9 次提交
-
-
由 klutzy 提交于
-
由 bors 提交于
The `print!` and `println!` macros are now the preferred method of printing, and so there is no reason to export the `stdio` functions in the prelude. The functions have also been replaced by their macro counterparts in the tutorial and other documentation so that newcomers don't get confused about what they should be using.
-
由 bors 提交于
...Therefore, we should not iterate over it.
-
由 Brendan Zabarauskas 提交于
The `print!` and `println!` macros are now the preferred method of printing, and so there is no reason to export the `stdio` functions in the prelude. The functions have also been replaced by their macro counterparts in the tutorial and other documentation so that newcomers don't get confused about what they should be using.
-
由 bors 提交于
Instead of reading a byte at a time in a loop we hardcode how to read each size. We also try to do as few reads as possible by reading as big primitive types as possible. For example if size is eight we do a single read of a u64 value and if size is seven we read it as [u32|u16|u8]. Timings on a Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz -- Before -- running 7 tests test io::extensions::test::test_u64_from_be_bytes ... ok test io::extensions::bench::u64_from_be_bytes_4_aligned ... bench: 386 ns/iter (+/- 5) test io::extensions::bench::u64_from_be_bytes_4_unaligned ... bench: 387 ns/iter (+/- 2) test io::extensions::bench::u64_from_be_bytes_7_aligned ... bench: 628 ns/iter (+/- 1) test io::extensions::bench::u64_from_be_bytes_7_unaligned ... bench: 637 ns/iter (+/- 3) test io::extensions::bench::u64_from_be_bytes_8_aligned ... bench: 727 ns/iter (+/- 18) test io::extensions::bench::u64_from_be_bytes_8_unaligned ... bench: 723 ns/iter (+/- 22) callgrind rustc -S rust/src/test/bench/sudoku.rs u64_from_be_bytes self: 4.37% -- After -- running 7 tests test io::extensions::test::test_u64_from_be_bytes ... ok test io::extensions::bench::u64_from_be_bytes_4_aligned ... bench: 162 ns/iter (+/- 7) test io::extensions::bench::u64_from_be_bytes_4_unaligned ... bench: 164 ns/iter (+/- 7) test io::extensions::bench::u64_from_be_bytes_7_aligned ... bench: 201 ns/iter (+/- 7) test io::extensions::bench::u64_from_be_bytes_7_unaligned ... bench: 210 ns/iter (+/- 9) test io::extensions::bench::u64_from_be_bytes_8_aligned ... bench: 163 ns/iter (+/- 7) test io::extensions::bench::u64_from_be_bytes_8_unaligned ... bench: 163 ns/iter (+/- 10) callgrind rustc -S rust/src/test/bench/sudoku.rs u64_from_be_bytes self: 1.78%
-
由 bors 提交于
So far the following code ``` struct Foo; fn main() { let mut t = Foo; let ref b = Foo; a += *b; } ``` errors with ``` test.rs:15:3: 13:11 error: binary operation + cannot be applied to type `Foo` test.rs:15 *a += *b; ``` Since assignment-operators are no longer expanded to ```left = left OP right``` but are independents operators it should be ``` test.rs:15:3: 13:11 error: binary operation += cannot be applied to type `Foo` test.rs:15 *a += *b; ``` to make it clear that implementing Add for Foo is not gonna work. (cf issues #11143, #11344) Besides that, we also need to typecheck the rhs expression even if the operator has no implementation, or we end up with unknown types for the nodes of the rhs and an ICE later on while resolving types. (once again cf #11143 and #11344). This probably would get fixed with #5992, but in the meantime it's a confusing error to stumble upon. @pcwalton, you wrote the original code, what do you think? (closes #11143 and #11344)
-
由 Raphael Catolino 提交于
-
由 Carl-Anton Ingmarsson 提交于
Instead of reading a byte at a time in a loop we copy the relevant bytes into a temporary vector of size eight. We can then read the value from the temporary vector using a single u64 read. LLVM seems to be able to optimize this almost scarily good.
-
由 bors 提交于
Closes #11421. A pretty trivial fix.
-
- 10 1月, 2014 31 次提交
-
-
由 bors 提交于
-
由 Derek Chiang 提交于
-
由 kud1ing 提交于
-
由 Carl-Anton Ingmarsson 提交于
-
由 bors 提交于
That is, if you have an enum type that is subject to the nullable pointer optimization, but the null variant has a nonzero number of fields, and you declare a static whose value is of that variant, then that used to be an ICE but this change fixes it.
-
由 bors 提交于
It's easy to figure out and useful as a sanity check sometimes.
-
由 bors 提交于
We're not moving everything just yet, but it's good to start somewhere!
-
由 bors 提交于
-
由 Jed Davis 提交于
That is, if you have an enum type that is subject to the nullable pointer optimization, but the null variant has a nonzero number of fields, and you declare a static whose value is of that variant, then that used to be an ICE but this change fixes it.
-
由 bors 提交于
-
由 Steven Fackler 提交于
It's easy to figure out and useful as a sanity check sometimes.
-
由 Nick Cameron 提交于
item_impl holds an Option<> to the trait ref, not a list of trait refs. Therefore, we should not iterate over it.
-
由 Alex Crichton 提交于
-
由 bors 提交于
We just approximate with a 2MB stack for native::start.
-
由 bors 提交于
-
由 Daniel Micay 提交于
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 bors 提交于
r? @nikomatsakis
-
由 Patrick Walton 提交于
-
由 bors 提交于
`doc/po/*.pot` files are generated automatically using `po4a` and they includes timestamps in their content. The files can cause huge conflicts unnecessarily. Also, removing them save disk space if you are not a translator.
-
由 OGINO Masanori 提交于
The .pot files can be generated automatically and the files contain timestamps in their content. They can cause huge conflicts and take huge space even if you are not a translator. This commit is a part of improvement discussed on https://github.com/mozilla/rust/pull/11383 . Signed-off-by: NOGINO Masanori <masanori.ogino@gmail.com>
-
由 OGINO Masanori 提交于
Signed-off-by: NOGINO Masanori <masanori.ogino@gmail.com>
-
由 Daniel Micay 提交于
-
由 Daniel Micay 提交于
-
由 Daniel Micay 提交于
-
由 bors 提交于
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 bors 提交于
This is something I have been meaning to do for awhile, but upon inspection of the `eof` method on all of the `Reader` impls you may find some interesting surprises. The method returns a good answer for almost all wrapped I/O objects (buffered readers, mem readers, util readers, etc), but the actual return value on all I/O objects themselves is almost always useless. Almost no I/O object other than a file actually knows when it's hit EOF or not. I think that pretending that all objects know when they've hit the end when almost none do is probably a bad idea. I can't really come up with a good answer to "is this file descriptor at eof" or "is this tcp stream at eof" much less "is this udp socket at eof". Due to being unable to answer these questions for *all* readers, I believe that it shouldn't be a part of the core `Reader` trait.
-
由 Alex Crichton 提交于
-