The trait will keep the `Iterator` naming, but a more concise module
name makes using the free functions less verbose. The module will define
iterables in addition to iterators, as it deals with iteration in
general.
There are 6 new compiler recognised attributes: deprecated, experimental,
unstable, stable, frozen, locked (these levels are taken directly from
Node's "stability index"[1]). These indicate the stability of the
item to which they are attached; e.g. `#[deprecated] fn foo() { .. }`
says that `foo` is deprecated.
This comes with 3 lints for the first 3 levels (with matching names) that
will detect the use of items marked with them (the `unstable` lint
includes items with no stability attribute). The attributes can be given
a short text note that will be displayed by the lint. An example:
#[warn(unstable)]; // `allow` by default
#[deprecated="use `bar`"]
fn foo() { }
#[stable]
fn bar() { }
fn baz() { }
fn main() {
foo(); // "warning: use of deprecated item: use `bar`"
bar(); // all fine
baz(); // "warning: use of unmarked item"
}
The lints currently only check the "edges" of the AST: i.e. functions,
methods[2], structs and enum variants. Any stability attributes on modules,
enums, traits and impls are not checked.
[1]: http://nodejs.org/api/documentation.html
[2]: the method check is currently incorrect and doesn't work.
Document the fact that the iterator protocol only defines behavior up
until the first None is returned. After this point, iterators are free
to behave how they wish.
Add a new iterator adaptor Fuse<T> that modifies iterators to return
None forever if they returned None once.
in the rust grammar
to avoid error messages like this:
Exception: non-alpha apparent keyword: pub"
when using extract_grammar.py:
python2.7 src/etc/extract_grammar.py <doc/rust.md
Signed-off-by: Jan Kobler <eng1@koblersystems.de>
If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable<int> to a function that filled it
either from a Range or a Map<VecIterator>, one needs to write something
like:
fn foo<E: Extendable<int, Range<int>> +
Extendable<int, Map<&'self int, int, VecIterator<int>>>
(e: &mut E, ...) { ... }
since using a generic, i.e. `foo<E: Extendable<int, I>, I: Iterator<int>>`
means that `foo` takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
`foo` itself).
This patch changes it to:
fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }
If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable<int> to a function that filled it
either from a Range or a Map<VecIterator>, one needs to write something
like:
fn foo<E: Extendable<int, Range<int>> +
Extendable<int, Map<&'self int, int, VecIterator<int>>>
(e: &mut E, ...) { ... }
since using a generic, i.e. `foo<E: Extendable<int, I>, I: Iterator<int>>`
means that `foo` takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
`foo` itself).
This patch changes it to:
fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }
r? @graydon Also, notably, make rustpkgtest depend on the rustpkg executable (otherwise, tests that shell out to rustpgk might run when rustpkg doesn't exist).
This commit allows you to write:
extern mod x = "a/b/c";
which means rustc will search in the RUST_PATH for a package with
ID a/b/c, and bind it to the name `x` if it's found.
Incidentally, move get_relative_to from back::rpath into std::path
This is a fairly large rollup, but I've tested everything locally, and none of
it should be platform-specific.
r=alexcrichton (bdfdbdd)
r=brson (d803c18)
r=alexcrichton (a5041d0)
r=bstrie (317412a)
r=alexcrichton (135c85e)
r=thestinger (8805baa)
r=pcwalton (0661178)
r=cmr (9397fe0)
r=cmr (caa4135)
r=cmr (6a21d93)
r=cmr (4dc3379)
r=cmr (0aa5154)
r=cmr (18be261)
r=thestinger (f10be03)
Code like this is fixed now:
```
fn foo(p: [u8, ..4]) {
match p {
[a, b, c, d] => {}
};
}
```
Invalid constructors are not reported as errors yet:
```
fn foo(p: [u8, ..4]) {
match p {
[_, _, _] => {} // this should be error
[_, _, _, _, _, .._] => {} // and this
_ => {}
}
}
```
Issue #8311 is partially fixed by this commit. Fixed-length arrays in
let statement are not yet allowed:
```
let [a, b, c] = [1, 2, 3]; // still fails
```
This module provided adaptors for the old internal iterator protocol,
but they proved to be quite unreadable and are not generic enough to
handle borrowed pointers well.
Since Rust no longer defines an internal iteration protocol, I don't
think there's going to be any reuse via these adaptors.
This is preparation for removing `@fn`.
This does *not* use default methods yet, because I don't know
whether they work. If they do, a forthcoming PR will use them.
This also changes the precedence of `as`.
Change the former repetition::
for 5.times { }
to::
do 5.times { }
.times() cannot be broken with `break` or `return` anymore; for those
cases, use a numerical range loop instead.
r? @graydon Package IDs can now be of the form a/b/c#FOO, where (if a/b/c is
a git repository) FOO is any tag in the repository. Non-numeric
tags only match against package IDs with the same tag, and aren't
compared linearly like numeric versions.
While I was at it, refactored the code that calls `git clone`, and segregated build output properly for different packages.
To be more specific:
`UPPERCASETYPE` was changed to `UppercaseType`
`type_new` was changed to `Type::new`
`type_function(value)` was changed to `value.method()`
The free-standing functions in f32, f64, i8, i16, i32, i64, u8, u16,
u32, u64, float, int, and uint are replaced with generic functions in
num instead.
This means that instead of having to know everywhere what the type is, like
~~~
f64::sin(x)
~~~
You can simply write code that uses the type-generic versions in num instead, this works for all types that implement the corresponding trait in num.
~~~
num::sin(x)
~~~
Note 1: If you were previously using any of those functions, just replace them
with the corresponding function with the same name in num.
Note 2: If you were using a function that corresponds to an operator, use the
operator instead.
Note 3: This is just https://github.com/mozilla/rust/pull/7090 reopened against master.
Apparently yesterday wasn't my day, and I forgot to add the changes to
all the tests apparently, and in the end forgot the docs extra much.
Please documentation, forgive me, I really do love you, I hope you
forgive me.
Next time we'll meet tutorial, I promise to bring cookies and tea. I
really want to be best-friends-forever with you, <3.
XOXO
As per https://mail.mozilla.org/pipermail/rust-dev/2013-July/004685.html
This is the initial machinery to setup the l10n infrastructure for markdown documentation.
A new "docs-l10n" target will take care of generating, updating and then building .pot and .po files, and later on the final .md.
This commit includes the .pot for all current .md docs; they can be feed directly to Mozilla Verbatim if wanted.
Please note that po4a only provides the orig.md -> .pot -> l10n.po -> l10n.md flow. The l10n.md -> l10n.html generation is not currently built in the makefile, as no language has been enabled.
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.
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.
