Closes#7180 and #7179.
Before, the `deriving(ToStr)` attribute was essentially `fmt!("%?")`. This changes it to recursively invoke `to_str()` on fields instead of relying on `fmt!`-style things. This seems more natural to me and what should actually be expected.
The removed test for issue #2611 is well covered by the `std::iterator`
module itself.
This adds the `count` method to `IteratorUtil` to replace `EqIter`.
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?
I was making documentation for my own little Rust project, and I was somewhat unhappy with how the documentation looked. While many of the issues are endemic to how rustdoc generates its output, you can get pretty far in making the documentation readable by using a better CSS style.
This commit alters the CSS style used in Rust's documentation in order to make the various sections stand out more. You can see an example of its usage in my own project's documentation: http://siegelord.github.io/RustGnuplot/#implementation-for-figureself-where-self. I showed it to some people on IRC and they suggested that I make a pull request here. I tested it on the only browser that matters, but also Chrome and Opera.
The confusing mixture of byte index and character count meant that every
use of .substr was incorrect; replaced by slice_chars which only uses
character indices. The old behaviour of `.substr(start, n)` can be emulated
via `.slice_from(start).slice_chars(0, n)`.
This is something that's only been briefly mentioned in the beginning of
the tutorial and all of the closure examples within this subsection
include only one expression between { and }.
This is something that's only been briefly mentioned in the beginning of
the tutorial and all of the closure examples within this subsection
include only one expression between { and }.
The "4.3 Loops" section only describes `while` and `loop`. We then see `for`
used in a code sample at the end of the "13. Vectors and strings" section,
but it's explained for the first time only in the next section --
"14. Closures".
It is worth mentioning it in "4.3 Loops".
Although in the example function `each` works as expected with
rust-0.6 (the latest release), it fails to even compile with `incoming`
rust (see test/compile-fail/bad-for-loop-2.rs). Change the function to
return a `bool` instead of `()`: this works fine with both versions of
rust, and does not misguide potential contributors.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
I don't have a strong opinion on the function vs. method, but there's no point in having both. I'd like to make a `repeat` adaptor like Python/Haskell for turning a value into an infinite stream of the value, so this has to at least be renamed.
fail!() used to require owned strings but can handle static strings
now. Also, it can pass its arguments to fmt!() on its own, no need for
the caller to call fmt!() itself.
This removes the comparison to manual memory management examples,
because it requires too much existing knowledge. Implementing custom
destructors can be covered in the FFI tutorial, where `unsafe` is
already well explained.
The example with OpenSSL is incorrect, because OpenSSL is using a
static variable for the return value and isn't thread-safe.
The gettimeofday example isn't great because it's not very portable.
This is some stuff which seemed to be missing to me (though I haven't read everything yet so hope I haven't missed the relevant section).
A similar addition for borrowing handles is needed, but #5720 stumped me.
Comments welcome.
The sentence "Remember that `(float, float)` is a tuple of two floats"
sounds like you've already read a section on tuples, but that section
comes later. Changing it to "Assuming that ..." makes it more about
taking the writer's word that the syntax is how tuples are defined.
The sentence "Remember that `(float, float)` is a tuple of two floats"
sounds like you've already read a section on tuples, but that section
comes later. Changing it to "Assuming that ..." makes it more about
taking the writer's word that the syntax is how tuples are defined.
Before it wouldn't warn about unused imports in the list if something in the list was used. These commits fix that case, add a test, and remove all unused imports in lists of imports throughout the compiler.
Added notes explaining how [expr, ..expr] form is used, targeted at
individuals like me who thought it was more general and handled
dynamic repeat expressions. (I left a TODO for this section in a
comment, but perhaps that is bad form for the manual...)
Added example of `do` syntax with a function of arity > 1; yes, one
should be able to derive this from the text above it, but it is still
a useful detail to compare and contrast against the arity == 1 case.
Added example of using for expression over a uint range, since someone
who is most used to write `for(int i; i < lim; i++) { ... }` will
likely want to know how to translate that form (regardless of whether
it happens to be good style or not for their use-case).
Added note about the semi-strange meaning of "fixed size" of vectors
in the vector type section.
In struct section of tutorial, make everything more coherent and
clear by always using "struct Point". Also, do not prematurely
introduce pointers and arrays. Fixes#5240
Signed-off-by: Luca Bruno <lucab@debian.org>
For bootstrapping purposes, this commit does not remove all uses of
the keyword "pure" -- doing so would cause the compiler to no longer
bootstrap due to some syntax extensions ("deriving" in particular).
Instead, it makes the compiler ignore "pure". Post-snapshot, we can
remove "pure" from the language.
There are quite a few (~100) borrow check errors that were essentially
all the result of mutable fields or partial borrows of `@mut`. Per
discussions with Niko I think we want to allow partial borrows of
`@mut` but detect obvious footguns. We should also improve the error
message when `@mut` is erroneously reborrowed.
