This change prevents the indentation in code blocks inside the /// doc comments
from being eaten. The indentation that is the same across the consecutive doc
comments is removed by the uindent_pass in librustdoc.
The bug can be seen, e.g., here: http://static.rust-lang.org/doc/std/iterator.html#example-12
I also altered how the block comments are treated, for consistency. There isn't much testing done on the documentation output (I added a few tests of my own for the modified function), so I don't know if anything relied on the previous behavior. I checked a number of documentation files and observed either no change in output or changes that consistent of the above bug being fixed.
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.htmlhttp://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?
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%.
This change prevents the indentation in code blocks inside the /// doc comments
from being eaten. The indentation that is the same across the consecutive doc
comments is removed by the uindent_pass in librustdoc.
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.
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%.
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.
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?)
