- 14 11月, 2015 5 次提交
-
-
由 Ariel Ben-Yehuda 提交于
-
由 Ariel Ben-Yehuda 提交于
no tests - sorry
-
由 Ariel Ben-Yehuda 提交于
this does add some complexity, but to do otherwise would require unsized lvalues to have their own allocas, which would be ugly.
-
由 Ariel Ben-Yehuda 提交于
The implementation itself only requires changes to trans, but a few additional bugs concerning the handling of fat pointers had to be fixed.
-
由 bors 提交于
Fixes #29578 r? @nikomatsakis My own observations are posted inline as comments.
-
- 13 11月, 2015 9 次提交
-
-
由 bors 提交于
BinaryHeap: Simplify sift down Sift down was doing all too much work: it can stop directly when the current element obeys the heap property in relation to its children. In the old code, sift down didn't compare the element to sift down at all, so it was maximally sifted down and relied on the sift up call to put it in the correct location. This should speed up heapify and .pop(). Also rename Hole::removed() to Hole::element()
-
由 Ulrik Sverdrup 提交于
Sift down was doing all too much work: it can stop directly when the current element obeys the heap property in relation to its children. In the old code, sift down didn't compare the element to sift down at all, so it was maximally sifted down and relied on the sift up call to put it in the correct location. This should speed up heapify and .pop(). Also rename Hole::removed() to Hole::element()
-
由 bors 提交于
Just `sed s/_nopanic//g`. Hopefully makes libsyntax a bit more readable.
-
由 bors 提交于
Fundamental attribute was missing a feature gate test.
-
由 bors 提交于
sort: Fast path for already sorted data When merging two sorted blocks `left` and `right` if the last element in `left` is <= the first in `right`, the blocks are already in sorted order. Add this as an additional fast path by simply copying the whole left block into the output and advancing the left pointer. The right block is then treated the same way by the already present logic in the merge loop. Can reduce runtime of .sort() to less than 50% of the previous, if the data was already perfectly sorted. Sorted data with a few swaps are also sorted quicker than before. The overhead of one comparison per merge seems to be negligible.
-
由 bors 提交于
cc @nagisa
-
由 Nick Cameron 提交于
-
由 bors 提交于
This is my first code contribution to Rust, so I'm sure there are some issues with the changes I've made. I've added the `quote_arg!`, `quote_block!`, `quote_path!`, and `quote_meta_item!` quasiquoting macros. From my experience trying to build AST in compiler plugins, I would like to be able to build any AST piece with a quasiquoting macro (e.g., `quote_struct_field!` or `quote_variant!`) and then use those AST pieces in other quasiquoting macros, but this pull request just adds some of the low-hanging fruit. I'm not sure if these additions are desirable, and I'm sure these macros can be implemented in an external crate if not.
-
由 bors 提交于
Adds `Example` sections to the rest of the integer methods. cc @steveklabnik
-
- 12 11月, 2015 26 次提交
-
-
由 bors 提交于
For now, this pass does some easy transformations, like eliminating empty blocks that just jump to another block, some trivial conversion of If terminators into Gotos and removal of dead blocks. r? @nikomatsakis
-
由 Antti Keränen 提交于
-
由 Björn Steinbrink 提交于
For now, this pass does some easy transformations, like eliminating empty blocks that just jump to another block, some trivial conversion of If terminators into Gotos and removal of dead blocks.
-
由 bors 提交于
Did this alphabetically, so I didn't see [how `std` was doing things](https://dxr.mozilla.org/rust/source/src/libstd/lib.rs#215) till I was nearly finished. If you prefer to add crate-level-whitelists like std instead of test-level, I can rebase with that strategy. A number of these commits can probably be dropped as the crates don't have much to test, and are deprecated. Let me know which if any to drop! (can also squash after review if desired) r? @steveklabnik
-
由 bors 提交于
`format_args!` doesn't support none Sized types so we should just pass it the references to `left_val` and `right_val`. The following works: ```rust assert!([1, 2, 3][..] == vec![1, 2, 3][..]) ``` So I would expect this to as well: ```rust assert_eq!([1, 2, 3][..], vec![1, 2, 3][..]) ``` But it fails with "error: the trait `core::marker::Sized` is not implemented for the type `[_]` [E0277]" I don't know if this change will have any nasty side effects I don't understand.
-
由 bors 提交于
- Successful merges: #29776, #29785, #29786, #29787 - Failed merges:
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
Fix usage of wrong article in `Result` docs. This is my first rust PR, if something about the process is wrong let me know. As this is a documentation change, I believe the correct highfive line to use is the following: r? @steveklabnik
-
由 Manish Goregaokar 提交于
-
由 Manish Goregaokar 提交于
This mostly brings them in line with existing linking convention, but also has some minor re-wording. The text at the top has been re-focused, by starting out with what the prelude does, rather than starting from injecting std. Also, it now mentions that other preludes exist. Part of https://github.com/rust-lang/rust/issues/29369
-
由 Manish Goregaokar 提交于
In previous PRs, I changed the match desugaring to generate more efficient code for ints/chars and the like. But this doesn't help when you're matching strings, ranges, or other crazy complex things (leading to #29740). This commit restructures match desugaring *yet again* to handle that case better -- basically we now degenerate to an if-else-if chain in such cases. ~~Note that this builds on https://github.com/rust-lang/rust/pull/29763 which will hopefully land soon. So ignore the first few commits.~~ landed now r? @Aatch since he's been reviewing the other commits in this series
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-
由 Kevin Butler 提交于
-