Rather than port each individual change to these files, for the release,
I just waited to do it all at the end, in this commit. Since individual
comits made it to master, everyone should get proper credit in the
main tree, and AUTHORS includes those whose changes are here.
An automated script was run against the `.rs` and `.md` files,
subsituting every occurrence of `task` with `thread`. In the `.rs`
files, only the texts in the comment blocks were affected.
This commit cleans out a large amount of deprecated APIs from the standard
library and some of the facade crates as well, updating all users in the
compiler and in tests as it goes along.
Fixes#11794
I mostly removed superflous examples which use the standard library.
I have one more quesiton here though: threads. They're mostly a library thing, at this point, right?
I assume since both shifts say the same thing, I should fix both of them, but then I realized I don't strictly know about left shift.
Fixes#23421
r? @pnkfelix
The docs currently define `array_expr`s as:
array_expr : '[' \"mut\" ? vec_elems? ']' ;
array_elems : [expr [',' expr]*] | [expr ',' \"..\" expr] ;
`vec_elems` is not defined anywhere else so it is probably a typo for `array_elems`.
This is a hack, but I don't think we can do much better as long as `derive` is
running at the syntax expansion phase.
If the custom_derive feature gate is enabled, this works with user-defined
traits and syntax extensions. Without the gate, you can't use e.g. #[derive_Clone]
directly, so this does not change the stable language.
This commit also cleans up the deriving code somewhat, and forbids some
previously-meaningless attribute syntax. For this reason it's technically a
[breaking-change]
Unstable items used in a macro expansion will now always trigger
stability warnings, *unless* the unstable items are directly inside a
macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns
unless the span of the unstable item is a subspan of the definition of a
macro marked with that attribute.
E.g.
#[allow_internal_unstable]
macro_rules! foo {
($e: expr) => {{
$e;
unstable(); // no warning
only_called_by_foo!();
}}
}
macro_rules! only_called_by_foo {
() => { unstable() } // warning
}
foo!(unstable()) // warning
The unstable inside `foo` is fine, due to the attribute. But the
`unstable` inside `only_called_by_foo` is not, since that macro doesn't
have the attribute, and the `unstable` passed into `foo` is also not
fine since it isn't contained in the macro itself (that is, even though
it is only used directly in the macro).
In the process this makes the stability tracking much more precise,
e.g. previously `println!("{}", unstable())` got no warning, but now it
does. As such, this is a bug fix that may cause [breaking-change]s.
The attribute is definitely feature gated, since it explicitly allows
side-stepping the feature gating system.
The API this exposes is a little strange (being attached to `static`s),
so it makes sense to conservatively feature gate it. If it is highly
popular, it is possible to reverse this gating.
The Rust Reference should include the tuple indexing (using a number
as a field) notation; currently it is only available on
http://doc.rust-lang.org/std/primitive.tuple.html and not easily
searchable.
The Rust Reference should include the tuple indexing (using a number
as a field) notation; currently it is only available on
http://doc.rust-lang.org/std/primitive.tuple.html and not easily
searchable.
Steve Klabnik