- 17 6月, 2013 17 次提交
-
-
由 Ralph Bodenner 提交于
-
由 Ralph Bodenner 提交于
-
由 bors 提交于
After reading issue #7077, all header elements had a border. In my opinion those borders are a bit too much distraction. I tried a different approach with increasing the padding and font size, and omitting the borders. Comparison: http://smvv.io/rust-doc/std/hashmap.html http://static.rust-lang.org/doc/std/hashmap.html Note: the highlighted code blocks are not caused by this commit. I left the border of the code block / function signature as is. The reason behind that is that code blocks are really block elements, while headers are not. What do you guys think?
-
由 bors 提交于
I did a little bit of cleanup work in driver.rs. It's not much but hey little steps.
-
由 bors 提交于
-
由 Brian Anderson 提交于
-
由 bors 提交于
Currently, cleanup blocks are only reused when there are nested scopes, the child scope's cleanup block will terminate with a jump to the parent scope's cleanup block. But within a single scope, adding or revoking any cleanup will force a fresh cleanup block. This means quadratic growth with the number of allocations in a scope, because each allocation needs a landing pad. Instead of forcing a fresh cleanup block, we can keep a list chained cleanup blocks that form a prefix of the currently required cleanups. That way, the next cleanup block only has to handle newly added cleanups. And by keeping the whole list instead of just the latest block, we can also handle revocations more efficiently, by only dropping those blocks that are no longer required, instead of all of them. Reduces the size of librustc by about 5% and the time required to build it by about 10%.
-
由 bors 提交于
-
由 bors 提交于
Two changes: 1. Make type parameters move by default, even if they have a Copy bound. After all, they could be bound to `~T` or `~[]`. Also, this is a necessary step towards removing `copy` keyword and replacing with clone. 2. Make it illegal to move from `*T`. This is dangerous in a "moves-by-default" scenario, because it's very easy to move when working with a `*T` pointer. Also, it requires zeroing memory, which we hope to do away with someday.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
since it creates moves that were not apparent. It also turns out to be not widely used.
-
由 Niko Matsakis 提交于
Consider: T:Copy could be bound to ~T, which is not implicitly copyable.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
- 16 6月, 2013 23 次提交
-
-
由 bors 提交于
-
由 Björn Steinbrink 提交于
Currently, cleanup blocks are only reused when there are nested scopes, the child scope's cleanup block will terminate with a jump to the parent scope's cleanup block. But within a single scope, adding or revoking any cleanup will force a fresh cleanup block. This means quadratic growth with the number of allocations in a scope, because each allocation needs a landing pad. Instead of forcing a fresh cleanup block, we can keep a list chained cleanup blocks that form a prefix of the currently required cleanups. That way, the next cleanup block only has to handle newly added cleanups. And by keeping the whole list instead of just the latest block, we can also handle revocations more efficiently, by only dropping those blocks that are no longer required, instead of all of them. Reduces the size of librustc by about 5% and the time required to build it by about 10%.
-
由 Sander Mathijs van Veen 提交于
-
由 bors 提交于
It is suffering from a bad case of megabitrot. #5247
-
由 bors 提交于
-
由 bors 提交于
My latest terminfo work introduced a bug in the handling of %i, which was noticed by @huonw after the PR was already merged in. r? @thestinger
-
由 bors 提交于
The free glue shouldn't be called for structs, and the drop glue already contains the destructor.
-
由 bors 提交于
It can sometimes be useful to have maps/sets of floating point values. Doing arithmetic with floats and then using them as keys is, of course, not a good idea.
-
由 bors 提交于
Removes one alloca and store from the drop glue of @ boxes. This speeds up the rustc build by 1s (might be noise, though).
-
由 bors 提交于
This allows mass-initialization of large structs without having to specify all the fields. I'm a bit hesitant, but I wanted to get this out there. I don't really like using the `Zero` trait, because it doesn't really make sense for a type like `HashMap` to use `Zero` as the 'blank allocation' trait. In theory there'd be a new trait, but then that's adding cruft to the language which may not necessarily need to be there. I do think that this can be useful, but I only implemented `Zero` on the basic types where I thought it made sense, so it may not be all that usable yet. (opinions?)
-
由 Huon Wilson 提交于
-
由 bors 提交于
This is to make sure we track optimizing `vec::from_elem`.
-
由 bors 提交于
Moves all the remaining functions that could reasonably be methods to be methods, except for some FFI ones (which I believe @erickt is working on, possibly) and `each_split_within`, since I'm not really sure the details of it (I believe @kimundi wrote the current implementation, so maybe he could convert it to an external iterator method on `StrSlice`, e.g. `word_wrap_iter(&self) -> WordWrapIterator<'self>`, where `WordWrapIterator` impls `Iterator<&'self str>`. It probably won't be too hard, since it's already a state machine.) This also cleans up the comparison impls for the string types, except I'm not sure how the lang items `eq_str` and `eq_str_uniq` need to be handled, so they (`eq_slice` and `eq`) remain stand-alone functions.
-
由 bors 提交于
-
由 Daniel Micay 提交于
-
由 bors 提交于
-
由 Ben Striegel 提交于
-
由 bors 提交于
r? (yes, the review request is back, now that I got it building against incom... I mean master!) (Attempting to port from orphaned pull-request #6764 ) Fix for #3961. Also includes a test case to illustrate the issues. (All of the entries that say "should align" should align with each other, and the four lines near the end that say "compare _" for _ in {A,B,C,D} should line up with each other.) Before applying this change set: -- the "(should align)"'s are all over the place, and the form/line feeding spaces are not cut out as one might or might not expect. -- compare B and D do not match A and C. (To be honest, its hard to really say what the right behavior is here, and people who are expecting a particular behavior out of a pretty printer in these cases may well get burned.)
-
由 Huon Wilson 提交于
-
由 Daniel Micay 提交于
-
由 Daniel Micay 提交于
-
由 Daniel Micay 提交于
replaced with OrdIterator
-
由 Daniel Micay 提交于
-