This removes the warning "Note" about visibility not being fully defined, as it
should now be considered fully defined with further bugs being considered just
bugs in the implementation.
A few features are now hidden behind various #[feature(...)] directives. These
include struct-like enum variants, glob imports, and macro_rules! invocations.
Closes#9304Closes#9305Closes#9306Closes#9331
It is simply defined as `f64` across every platform right now.
A use case hasn't been presented for a `float` type defined as the
highest precision floating point type implemented in hardware on the
platform. Performance-wise, using the smallest precision correct for the
use case greatly saves on cache space and allows for fitting more
numbers into SSE/AVX registers.
If there was a use case, this could be implemented as simply a type
alias or a struct thanks to `#[cfg(...)]`.
Closes#6592
The mailing list thread, for reference:
https://mail.mozilla.org/pipermail/rust-dev/2013-July/004632.html
Many people will be very confused that their debug! statements aren't working
when they first use rust only to learn that they should have been building with
`--cfg debug` the entire time. This inverts the meaning of the flag to instead
of enabling debug statements, now it disables debug statements.
This way the default behavior is a bit more reasonable, and requires less
end-user configuration. Furthermore, this turns on debug by default when
building the rustc compiler.
This commit adds support for `\0` escapes in character and string literals.
Since `\0` is equivalent to `\x00`, this is a direct translation to the latter
escape sequence. Future builds will be able to compile using `\0` directly.
Also updated the grammar specification and added a test for NUL characters.
The old documentation for for loops/expressions has been quite wrong since the change to iterators. This updates the docs to make them relevant to how for loops work now, if not very in-depth. There may be a need for updates giving more depth on how they work, such as detailing what method calls they make, but I don't know enough about the implementation to include that.
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.
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>
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
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
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.
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.
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.
