- 01 10月, 2013 1 次提交
-
-
由 blake2-ppc 提交于
-
- 29 9月, 2013 3 次提交
-
-
由 bors 提交于
r? strcat (please double check that it fixes things on your chroot, if possible, before approval) Fix #9531
-
由 bors 提交于
They're getting smaller each time though! The highlight of this round is source files in documentation. Still trying to figure out the best syntax-highlighting solution.
-
由 Alex Crichton 提交于
This removes the internal type representation of an `External` type and instead relies on passing around DefId structures and interpreting them accordingly. Progress on #9539, but there's still the problem of a crate => url mapping.
-
- 28 9月, 2013 24 次提交
-
-
由 bors 提交于
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
-
由 bors 提交于
change formula (other solution could be using abs()).
-
由 bors 提交于
Small change that suppresses a warning because of an unused import.
-
由 bors 提交于
-
由 blake2-ppc 提交于
std::vec::{concat, connect, concat_slices, connect_slices} are replaced by the already existing trait methods .concat_vec() and .connect_vec().
-
由 bors 提交于
-
由 blake2-ppc 提交于
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
-
由 blake2-ppc 提交于
-
由 bors 提交于
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.
-
由 bors 提交于
Instead use &mut everywhere as much as possible and then reorganize lots of code to get past the borrow checker.
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
All items have source links back to their actual code. Source files can be omitted with the doc(html_no_source) attribute on the crate. Currently there is no syntax highlighting, but that will come with syntax highlighting with all other snippets. Closes #2072
-
由 bors 提交于
-
由 bors 提交于
-
由 Flavio Percoco 提交于
-
由 bors 提交于
r? @metajack Towards #7401
-
由 bors 提交于
This purges doc/{std,extra} entirely during a `make clean` instead of just the html files in some top level directories. This should help old documentation from showing up on static.rust-lang.org
-
由 Alex Crichton 提交于
This purges doc/{std,extra} entirely during a `make clean` instead of just the html files in some top level directories. This should help old documentation from showing up on static.rust-lang.org
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
Closes #9566
-
由 Alex Crichton 提交于
It's just a waste of disk space and it can be done just as well in JS.
-
由 bors 提交于
As mentioned in #9456, the format! syntax extension would previously consider an empty format as a 'Unknown' format which could then also get coerced into a different style of format on another argument. This is unusual behavior because `{}` is a very common format and if you have `{0} {0:?}` you wouldn't expect them both to be coereced to the `Poly` formatter. This commit removes this coercion, but still retains the requirement that each argument has exactly one format specified for it (an empty format now counts as well). Perhaps at a later date we can add support for multiple formats of one argument, but this puts us in at least a backwards-compatible situation if we decide to do that.
-
由 Alex Crichton 提交于
As mentioned in #9456, the format! syntax extension would previously consider an empty format as a 'Unknown' format which could then also get coerced into a different style of format on another argument. This is unusual behavior because `{}` is a very common format and if you have `{0} {0:?}` you wouldn't expect them both to be coereced to the `Poly` formatter. This commit removes this coercion, but still retains the requirement that each argument has exactly one format specified for it (an empty format now counts as well). Perhaps at a later date we can add support for multiple formats of one argument, but this puts us in at least a backwards-compatible situation if we decide to do that.
-
由 Tim Chevalier 提交于
Towards #7401
-
- 27 9月, 2013 12 次提交
-
-
由 bors 提交于
The 0.8 release was cut, down with printf!
-
由 bors 提交于
Closes #9494
-
由 bors 提交于
Commit messages have the details, mostly just knocking out more low-hanging-fruit type issues.
-
由 bors 提交于
This is broken, and results in poor performance due to the undefined behaviour in the LLVM IR. LLVM's `mergefunc` is a *much* better way of doing this since it merges based on the equality of the bytecode. For example, consider `std::repr`. It generates different code per type, but is not included in the type bounds of generics. The `mergefunc` pass works for most of our code but currently hits an assert on libstd. It is receiving attention upstream so it will be ready soon, but I don't think removing this broken code should wait any longer. I've opened #9536 about enabling it by default. Closes #8651 Closes #3547 Closes #2537 Closes #6971 Closes #9222
-
由 bors 提交于
that is, if super trait had more methods, tnen subtrait, compiling would fail. I simply forgot to update variable name. Updated test case , too.
-
由 Alex Crichton 提交于
-
由 bors 提交于
One of the downsides with `c_str` is that it always forces an allocation, and so this could add unnecessary overhead to various calls. This PR implements one of the suggestions @graydon made in #8296 for `vec.with_c_str` in that for a short string can use a small stack array instead of a malloced array for our temporary c string. This ends up being twice as fast for small strings. There are two things to consider before landing this commit though. First off, I arbitrarily picked the stack array as 32 bytes, and I'm not sure if this a reasonable amount or not. Second, there is a risk that someone can keep a reference to the interior stack pointer, which could cause mayhem if someone were to dereference the pointer. Since we also can easily grab and return interior pointers to vecs though, I don't think this is that much of an issue.
-
由 Erick Tryzelaar 提交于
This also fixes a bug in `vec.with_c_str_unchecked` where we were not calling `.to_c_str_unchecked()` for long strings.
-
由 Erick Tryzelaar 提交于
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)
-
由 Erick Tryzelaar 提交于
This matches @graydon's recommendation.
-
由 Erick Tryzelaar 提交于
The documentation for `.with_c_str()` already says that the pointer will be deallocated before returning from the function.
-
由 Erick Tryzelaar 提交于
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)
-