These files are automatically genereated by `make docs-l10n` (via po4a),
which will also take of updating them if the original .md changes.
Signed-off-by: Luca Bruno <lucab@debian.org>
This commit add a new "docs-l10n" make target which uses po4a to:
* create .pot (PO templates) from markdown doc
* update templates and po for enabled languages
* generate translated markdown for completed (> 80%) translations
Currently, no language has been activated.
Signed-off-by: Luca Bruno <lucab@debian.org>
Adds a lint for `static some_lowercase_name: uint = 1;`. Warning by default since it causes confusion, e.g. `static a: uint = 1; ... let a = 2;` => `error: only refutable patterns allowed here`.
I removed the `static-method-test.rs` test because it was heavily based
on `BaseIter` and there are plenty of other more complex uses of static
methods anyway.
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.
