| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This slurps in the commits from #9684 as well as closing #9539.
|
|
Add a test to make sure it works and switch a private struct over to a
newtype.
Closes #9155
|
|
UnboundedPipeStream is still a newtype since process::set_stdio needs to
look into its internals.
Closes #9667
|
|
UnboundedPipeStream is still a newtype since process::set_stdio needs to
look into its internals.
Closes #9667
|
|
This fixes an issue for APIs that return FromStr. Before this change,
they would have to offer a seperate function for returning the source
string.
|
|
The general idea of hyperlinking between crates is that it should require as
little configuration as possible, if any at all. In this vein, there are two
separate ways to generate hyperlinks between crates:
1. When you're generating documentation for a crate 'foo' into folder 'doc',
then if foo's external crate dependencies already have documented in the
folder 'doc', then hyperlinks will be generated. This will work because all
documentation is in the same folder, allowing links to work seamlessly both
on the web and on the local filesystem browser.
The rationale for this use case is a package with multiple libraries/crates
that all want to link to one another, and you don't want to have to deal with
going to the web. In theory this could be extended to have a RUST_PATH-style
searching situtation, but I'm not sure that it would work seamlessly on the
web as it does on the local filesystem, so I'm not attempting to explore this
case in this pull request. I believe to fully realize this potential rustdoc
would have to be acting as a server instead of a static site generator.
2. One of foo's external dependencies has a #[doc(html_root_url = "...")]
attribute. This means that all hyperlinks to the dependency will be rooted at
this url.
This use case encompasses all packages using libstd/libextra. These two
crates now have this attribute encoded (currently at the /doc/master url) and
will be read by anything which has a dependency on libstd/libextra. This
should also work for arbitrary crates in the wild that have online
documentation. I don't like how the version is hard-wired into the url, but I
think that this may be a case-by-case thing which doesn't end up being too
bad in the long run.
Closes #9539
|
|
Closes #9671
|
|
Closes #9671
|
|
One downside with this current implementation is that since BigInt's
default is now 64 bit, we can convert larger BigInt's to a primitive,
however the current implementation on 32 bit architectures does not
take advantage of this fact.
|
|
|
|
This fixes an issue for APIs that return FromStr. Before this change,
they would have to offer a seperate function for returning the source
string.
|
|
Uses the new snapshots to kill the old `loop` and introduce the new `continue`.
|
|
pnkfelix/rust/fsk-issue7526-attempt-to-catch-nonuc-statics-in-match-patterns, r=alexcrichton
r? anyone
Address scariest part of #7526 by adding a new more specific lint (that is set to warn by default, rather than allow).
|
|
Closes #9341
|
|
Closes #9341
|
|
Closes #9467
|
|
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 was a little ambiguous before how explicitl positional parameters and
implicit positional parameters intermingled, and this clarifies how the two
intermingle. This also updates a little bit of documentation/code examples
elsewhere as well.
|
|
Fixes #9125
|
|
|
|
|
|
|
|
It was a little ambiguous before how explicitl positional parameters and
implicit positional parameters intermingled, and this clarifies how the two
intermingle. This also updates a little bit of documentation/code examples
elsewhere as well.
|
|
This tries to warn about code like:
```rust
match (0,0) {
(0, aha) => { ... },
...
}
```
where `aha` is actually a static constant, not a binding.
|
|
Creates a wrapper around a mutable reference to the iterator.
This is useful to allow applying iterator adaptors while still
retaining ownership of the original iterator value.
Example::
let mut xs = range(0, 10);
// sum the first five values
let partial_sum = xs.by_ref().take(5).fold(0, |a, b| a + b);
assert!(partial_sum == 10);
// xs.next() is now `5`
assert!(xs.next() == Some(5));
|
|
|
|
|
|
Closes #8815.
|
|
|
|
|
|
std::vec: Sane implementations for connect_vec and concat_vec
Avoid unnecessary copying of subvectors, and calculate the needed space
beforehand. These implementations are simple but better than the
previous.
Also only implement it once, for all `Vector<T>` using:
impl<'self, T: Clone, V: Vector<T>> VectorVector<T> for &'self [V]
Closes #9581
|
|
Small change that suppresses a warning because of an unused import.
|
|
|
|
std::vec::{concat, connect, concat_slices, connect_slices} are replaced
by the already existing trait methods .concat_vec() and .connect_vec().
|
|
|
|
Avoid unnecessary copying of subvectors, and calculate the needed space
beforehand. These implementations are simple but better than the
previous.
Also only implement it once, for all `Vector<T>` using:
impl<'self, T: Clone, V: Vector<T>> VectorVector<T> for &'self [V]
performance improved according to the bench test:
before
test vec::bench::concat ... bench: 74818 ns/iter (+/- 408)
test vec::bench::connect ... bench: 87066 ns/iter (+/- 376)
after
test vec::bench::concat ... bench: 17724 ns/iter (+/- 126)
test vec::bench::connect ... bench: 18353 ns/iter (+/- 691)
Closes #9581
|
|
|
|
std::vec: Use a valid value as lifetime dummy in iterator
The current implementation uses `&v[0]` for the lifetime struct field,
but that is a dangling pointer for iterators derived from zero-length
slices.
Example:
let v: [int, ..0] = []; println!("{:?}", v.iter())
std::vec::VecIterator<,int>{ptr: (0x7f3768626100 as *()), end: (0x7f3768626100 as *()), lifetime: &139875951207128}
To replace this parameter, use a field of type `Option<&'self ()>`
that is simply initialized with `None`, but still allows the iterator to
have a lifetime parameter.
|
|
|
|
|
|
The 0.8 release was cut, down with printf!
|
|
|
|
This also fixes a bug in `vec.with_c_str_unchecked` where we
were not calling `.to_c_str_unchecked()` for long strings.
|
|
before:
test c_str::bench::bench_with_c_str_unchecked_long ... bench: 361 ns/iter (+/- 9)
test c_str::bench::bench_with_c_str_unchecked_medium ... bench: 75 ns/iter (+/- 2)
test c_str::bench::bench_with_c_str_unchecked_short ... bench: 60 ns/iter (+/- 9)
after:
test c_str::bench::bench_with_c_str_unchecked_long ... bench: 362 ns/iter (+/-
test c_str::bench::bench_with_c_str_unchecked_medium ... bench: 30 ns/iter (+/- 7)
test c_str::bench::bench_with_c_str_unchecked_short ... bench: 12 ns/iter (+/- 4)
|
|
This matches @graydon's recommendation.
|
|
The documentation for `.with_c_str()` already says that the pointer
will be deallocated before returning from the function.
|
|
This now makes it unsafe to save the pointer returned by .with_c_str
as that pointer now may be pointing at a stack allocated array.
I arbitrarily chose 32 bytes as the length of the stack vector, and
so it might not be the most optimal size.
before:
test c_str::bench::bench_with_c_str_long ... bench: 539 ns/iter (+/- 91)
test c_str::bench::bench_with_c_str_medium ... bench: 97 ns/iter (+/- 2)
test c_str::bench::bench_with_c_str_short ... bench: 70 ns/iter (+/- 5)
after:
test c_str::bench::bench_with_c_str_long ... bench: 542 ns/iter (+/- 13)
test c_str::bench::bench_with_c_str_medium ... bench: 53 ns/iter (+/- 6)
test c_str::bench::bench_with_c_str_short ... bench: 19 ns/iter (+/- 0)
|
|
|
|
|
|
|
