- 10 1月, 2014 16 次提交
-
-
由 Alex Crichton 提交于
-
由 bors 提交于
-
由 Daniel Micay 提交于
-
由 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 提交于
-
- 09 1月, 2014 19 次提交
-
-
由 bors 提交于
...at the start of the path, rather than at the start of the view_path. Fixes #11317
-
由 bors 提交于
The methods contained in `std::num::{Algebraic, Trigonometric, Exponential, Hyperbolic}` have now been moved into `std::num::Real`. This is part of an ongoing effort to simplify `std::num` (see issue #10387). `std::num::RealExt` has also been removed from the prelude because it is not a commonly used trait. r? @alexcrichton
-
由 bors 提交于
This trait seems to stray too far from the mandate of a standard library as implementations may vary between use cases. Third party libraries should implement their own if they need something like it. This closes #5316. r? @alexcrichton, @pcwalton
-
由 bors 提交于
This is just an unnecessary trait that no one's ever going to parameterize over and it's more useful to just define the methods directly on the types themselves. The implementors of this type almost always don't want inner_mut_ref() but they're forced to define it as well.
-
由 bors 提交于
r? @brson
-
由 bors 提交于
So, like I mentioned in issue #10955 it doesn't seem like we need to call ```ty::subst_tps``` when the method is generic. But then I realized that this function doesn't mutate any of its input, and the return value is unused. Plus the type param substitution seems to be taken care of in ```trans_fn_ref_with_vtables```, so I thought I'd just try to remove it. As far as I can tell everything works. This closes #10955.
-
由 Alex Crichton 提交于
This is just an unnecessary trait that no one's ever going to parameterize over and it's more useful to just define the methods directly on the types themselves. The implementors of this type almost always don't want inner_mut_ref() but they're forced to define it as well.
-
由 Nick Cameron 提交于
Start the span for a path in a view_path at the correct place (at the start of the path, rather than at the start of the view_path).
-
由 bors 提交于
-Fixed Gc::clone to not require a Clone implementation for T -Implemented Gc::ptr_eq to match Rc::ptr_eq, added a test for that
-
由 Brendan Zabarauskas 提交于
This trait seems to stray too far from the mandate of a standard library as implementations may vary between use cases.
-
由 Brendan Zabarauskas 提交于
The methods contained in `std::num::{Algebraic, Trigonometric, Exponential, Hyperbolic}` have now been moved into `std::num::Real`. This is part of an ongoing effort to simplify `std::num` (see issue #10387). `std::num::RealExt` has also been removed from the prelude because it is not a commonly used trait.
-
由 Brian Anderson 提交于
-
由 Brian Anderson 提交于
-
由 bors 提交于
Closes #11372
-
由 Alex Crichton 提交于
Closes #11372
-
由 bors 提交于
`expand_include_str()` in libsyntax seems to have corrupted the CodeMap by always setting the BytePos of any included files to zero. It now uses `CodeMap::new_filemap()` which should set everything properly. This should fix issue #11322 but I don't want to close it before I have confirmation from the reporters that the problem is indeed fixed.
-
由 bors 提交于
Turned out to be a 2-line fix, but the compiler fallout was huge.
-
由 bors 提交于
If we bootstrap a cross compile from a stage1 compiler, then the stage1 compiler already knows about the rustc => rustlib change, so we need to not add the extra flag if it's a stage0 version of a target from a stage1 of another target.
-
由 Alex Crichton 提交于
If we bootstrap a cross compile from a stage1 compiler, then the stage1 compiler already knows about the rustc => rustlib change, so we need to not add the extra flag if it's a stage0 version of a target from a stage1 of another target.
-
- 08 1月, 2014 5 次提交
-
-
由 Michael Woerister 提交于
-
由 bors 提交于
Various documentation changes, change the 'borrowed pointer' terminology to 'reference', fix a problem with 'make dist' on windows.
-
由 Huon Wilson 提交于
0xDEADBEEF doesn't fit in an int = i32 (on 32-bit computers).
-
由 bors 提交于
A typed arena is a type of arena that can only allocate objects of one type. It is 3x faster than the existing arena and 13x faster than malloc on Mac. r? @brson
-
由 bors 提交于
If a reexport comes from a non-public module, then the documentation for the reexport will be inlined into the module that exports it, but if the reexport is targeted at a public type (like the prelude), then it is not inlined but rather hyperlinked.
-