| Age | Commit message (Collapse) | Author | Lines |
|
This also inverts the dependency between libserialize and libcollections.
cc #8784
|
|
This commit changes the ToStr trait to:
impl<T: fmt::Show> ToStr for T {
fn to_str(&self) -> ~str { format!("{}", *self) }
}
The ToStr trait has been on the chopping block for quite awhile now, and this is
the final nail in its coffin. The trait and the corresponding method are not
being removed as part of this commit, but rather any implementations of the
`ToStr` trait are being forbidden because of the generic impl. The new way to
get the `to_str()` method to work is to implement `fmt::Show`.
Formatting into a `&mut Writer` (as `format!` does) is much more efficient than
`ToStr` when building up large strings. The `ToStr` trait forces many
intermediate allocations to be made while the `fmt::Show` trait allows
incremental buildup in the same heap allocated buffer. Additionally, the
`fmt::Show` trait is much more extensible in terms of interoperation with other
`Writer` instances and in more situations. By design the `ToStr` trait requires
at least one allocation whereas the `fmt::Show` trait does not require any
allocations.
Closes #8242
Closes #9806
|
|
These two containers are indeed collections, so their place is in
libcollections, not in libstd. There will always be a hash map as part of the
standard distribution of Rust, but by moving it out of the standard library it
makes libstd that much more portable to more platforms and environments.
This conveniently also removes the stuttering of 'std::hashmap::HashMap',
although 'collections::HashMap' is only one character shorter.
|
|
This "bubble up an error" macro was originally named if_ok! in order to get it
landed, but after the fact it was discovered that this name is not exactly
desirable.
The name `if_ok!` isn't immediately clear that is has much to do with error
handling, and it doesn't look fantastic in all contexts (if if_ok!(...) {}). In
general, the agreed opinion about `if_ok!` is that is came in as subpar.
The name `try!` is more invocative of error handling, it's shorter by 2 letters,
and it looks fitting in almost all circumstances. One concern about the word
`try!` is that it's too invocative of exceptions, but the belief is that this
will be overcome with documentation and examples.
Close #12037
|
|
|
|
|
|
|
|
It's too easy to forget the `rust` tag to test something.
Closes #11698
|
|
|
|
This was previously implemented, and it just needed a snapshot to go through
|
|
Avoid using -1 as a char sentinel, when Option<char> is the perfect
thing.
|
|
|
|
- `extra::json` didn't make the cut, because of `extra::json` required
dep on `extra::TreeMap`. If/when `extra::TreeMap` moves out of `extra`,
then `extra::json` could move into `serialize`
- `libextra`, `libsyntax` and `librustc` depend on the newly created
`libserialize`
- The extensions to various `extra` types like `DList`, `RingBuf`, `TreeMap`
and `TreeSet` for `Encodable`/`Decodable` were moved into the respective
modules in `extra`
- There is some trickery, evident in `src/libextra/lib.rs` where a stub
of `extra::serialize` is set up (in `src/libextra/serialize.rs`) for
use in the stage0 build, where the snapshot rustc is still making
deriving for `Encodable` and `Decodable` point at extra. Big props to
@huonw for help working out the re-export solution for this
extra: inline extra::serialize stub
fix stuff clobbered in rebase + don't reexport serialize::serialize
no more globs in libserialize
syntax: fix import of libserialize traits
librustc: fix bad imports in encoder/decoder
add serialize dep to librustdoc
fix failing run-pass tests w/ serialize dep
adjust uuid dep
more rebase de-clobbering for libserialize
fixing tests, pushing libextra dep into cfg(test)
fix doc code in extra::json
adjust index.md links to serialize and uuid library
|
|
|
|
`Times::times` was always a second-class loop because it did not support the `break` and `continue` operations. Its playful appeal was then lost after `do` was disabled for closures. It's time to let this one go.
|
|
|
|
from_utf8_owned() behavior
|
|
|
|
|
|
There was an old and barely used implementation of pow, which expected
both parameters to be uint and required more traits to be implemented.
Since a new implementation for `pow` landed, I'm proposing to remove
this old impl in favor of the new one.
The benchmark shows that the new implementation is faster than the one being removed:
```
test num::bench::bench_pow_function ..bench: 9429 ns/iter (+/- 2055)
test num::bench::bench_pow_with_uint_function ...bench: 28476 ns/iter (+/- 2202)
```
|
|
|
|
|
|
commit d00623d60afd460755b749ad5f94935f756f29d2
Author: musitdev <philippe.delrieu@free.fr>
Date: Sat Jan 4 22:31:40 2014 +0100
correct last comments.
commit ef09d6b6d1eebbd7c713c9dad96ed7bfc19dd884
Author: musitdev <philippe.delrieu@free.fr>
Date: Thu Jan 2 20:28:53 2014 +0100
update with the last remarks.
commit 46a028fe1fcdc2a7dcdd78a63001793eff614349
Author: musitdev <philippe.delrieu@free.fr>
Date: Thu Jan 2 10:17:18 2014 +0100
wrap example code in main function.
commit 2472901929bef09786b7aef8ca7c89fbe67d8e3e
Author: musitdev <philippe.delrieu@free.fr>
Date: Mon Dec 30 19:32:46 2013 +0100
Correct code to compile.
commit ed96b2223176781743e984af0e19abcb82150f1f
Author: musitdev <philippe.delrieu@free.fr>
Date: Thu Dec 5 11:32:28 2013 +0100
Correct the comment based on the PR comment.
Change init call to new to reflect last change.
commit 38b0390c3533a16f822a6df5f90b907bd8ed6edc
Author: musitdev <philippe.delrieu@free.fr>
Date: Wed Dec 4 22:34:25 2013 +0100
correct from_utf8_owned call.
commit 08bed4c5f4fadf93ec457b605a1a1354323d2f5c
Author: musitdev <philippe.delrieu@free.fr>
Date: Wed Dec 4 22:12:41 2013 +0100
correct code '''
commit 02fddcbe2ab37fe842872691105bc4c5cff5abb5
Author: musitdev <philippe.delrieu@free.fr>
Date: Wed Dec 4 13:25:54 2013 +0100
correct typing error
commit b26830b8ddb49f551699e791832ed20640a0fafc
Author: musitdev <philippe.delrieu@free.fr>
Date: Wed Dec 4 13:18:39 2013 +0100
pass make check
commit e87c4f53286122efd0d2364ea45600d4fa4d5744
Author: musitdev <philippe.delrieu@free.fr>
Date: Wed Dec 4 10:47:24 2013 +0100
Add Json example and documentation.
|
|
There was an old and barely used implementation of pow, which expected
both parameters to be uint and required more traits to be implemented.
Since a new implementation for `pow` landed, I'm proposing to remove
this old impl in favor of the new one.
The benchmark shows that the new implementation is faster than the one
being removed:
test num::bench::bench_pow_function ..bench: 9429 ns/iter (+/- 2055)
test num::bench::bench_pow_with_uint_function ...bench: 28476 ns/iter (+/- 2202)
|
|
* Reexport io::mem and io::buffered structs directly under io, make mem/buffered
private modules
* Remove with_mem_writer
* Remove DEFAULT_CAPACITY and use DEFAULT_BUF_SIZE (in io::buffered)
|
|
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.
|
|
|
|
Also remove all instances of 'self within the codebase.
This fixes #10889.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`librustuv`.
|
|
|
|
Fixes #4244.
|
|
|
|
|
|
These methods are all excellent candidates for default methods, so there's no
need to require extra imports of various traits.
|
|
Big fish fried here:
extra::json
most of the compiler
extra::io_util removed
extra::fileinput removed
Fish left to fry
extra::ebml
|
|
|
|
|
|
Who doesn't like a massive renaming?
|
|
It is simply defined as `f64` across every platform right now.
A use case hasn't been presented for a `float` type defined as the
highest precision floating point type implemented in hardware on the
platform. Performance-wise, using the smallest precision correct for the
use case greatly saves on cache space and allows for fitting more
numbers into SSE/AVX registers.
If there was a use case, this could be implemented as simply a type
alias or a struct thanks to `#[cfg(...)]`.
Closes #6592
The mailing list thread, for reference:
https://mail.mozilla.org/pipermail/rust-dev/2013-July/004632.html
|
|
|
|
It now uses `{"type": VariantName, "fields": [...]}`, which, according to
@Seldaek, since all enums will have the same "shape" rather than being a weird
ad-hoc array, will optimize better in javascript JITs. It also looks prettier,
and makes more sense.
|