This commit performs a stabilization pass over the `std::ascii` module taking
the following actions:
* the module name is now stable
* `AsciiExt` is now stable after moving its type parameter to an `Owned`
associated type
* `AsciiExt::is_ascii` is now stable
* `AsciiExt::to_ascii_uppercase` is now stable
* `AsciiExt::to_ascii_lowercase` is now stable
* `AsciiExt::eq_ignore_ascii_case` is now stable
* `AsciiExt::make_ascii_uppercase` is added to possibly replace
`OwnedAsciiExt::into_ascii_uppercase` (similarly for lowercase variants).
* `escape_default` now returns an iterator and is stable
* `EscapeDefault` is now stable
Trait implementations are now also marked stable.
Primarily it is still unstable to *implement* the `AsciiExt` trait due to it
containing some unstable methods.
[breaking-change]
Nonetheless, as this commit demonstrates, the previous commits was a [breaking-change].
In practice, breakage is focused on functions of this form:
```rust
fn foo(..., object: Box<FnMut()>)
````
where `FnMut()` could be any trait object type. The older scheme defaulted objects in argument
position so that they were bounded by a fresh lifetime:
```rust
fn foo<'a>(..., object: Box<FnMut()+'a>)
```
This meant that the object could contain borrowed data. The newer
scheme defaults to a lifetime bound of `'static`:
```rust
fn foo(..., object: Box<FnMut()+'static>)
```
This means that the object cannot contain borrowed data. In some cases, the best fix
is to stop using `Box`:
```rust
fn foo(..., object: &mut FnMut())
```
but another option is to write an explicit annotation for the `'a`
lifetime that used to be implicit. Both fixes are demonstrated in
this commit.
It's not clear what this means, because a macro in item position can expand to zero or more items. For now we disallow it, which is technically a
[breaking-change]
but is landing without an RFC. The `pub` keyword previously had no effect, which seems quite unintended.
Fixes#18317.
Fixes#14660.
Some function signatures have changed, so this is a [breaking-change].
In particular, radixes and numerical values of digits are represented by `u32` now.
Part of #22240
Added all active features to the list in reference.md.
Added a second note about keeping the reference.md list up-to-date to the bottom of the list, since not everyone (including me) reads the big comment at the top of it. :)
Ensured that the feature gate list in reference.md is kept in alphabetical order.
Re-tag `slicing_syntax` as `Accepted`.
Rollup merge (373cbab5b0) of PR #20723
accidentally reverted a portion of commit
8327bcc167 which shifted
`slicing_syntax` from Active to Accepted.
It is only allowed in paths now, where it will either work inside a `trait`
or `impl` item, or not resolve outside of it.
[breaking-change]
Closes#22137
It's not clear what this means, because a macro in item position can expand to
zero or more items. For now we disallow it, which is technically a
[breaking-change]
but is landing without an RFC. The `pub` keyword previously had no effect,
which seems quite unintended.
Fixes#18317.
Fixes#14660.
Added a second note about keeping the reference.md list up-to-date to
the bottom of the list, since not everyone (including me) reads the
big comment at the top of it. :)
Ensured that the feature gate list in reference.md is kept in
alphabetical order.
It is only allowed in paths now, where it will either work inside a `trait`
or `impl` item, or not resolve outside of it.
[breaking-change]
Closes#22137
This commit tweaks the interface of the `std::env` module to make it more
ergonomic for common usage:
* `env::var` was renamed to `env::var_os`
* `env::var_string` was renamed to `env::var`
* `env::args` was renamed to `env::args_os`
* `env::args` was re-added as a panicking iterator over string values
* `env::vars` was renamed to `env::vars_os`
* `env::vars` was re-added as a panicking iterator over string values.
This should make common usage (e.g. unicode values everywhere) more ergonomic
as well as "the default". This is also a breaking change due to the differences
of what's yielded from each of these functions, but migration should be fairly
easy as the defaults operate over `String` which is a common type to use.
[breaking-change]
This commit tweaks the interface of the `std::env` module to make it more
ergonomic for common usage:
* `env::var` was renamed to `env::var_os`
* `env::var_string` was renamed to `env::var`
* `env::args` was renamed to `env::args_os`
* `env::args` was re-added as a panicking iterator over string values
* `env::vars` was renamed to `env::vars_os`
* `env::vars` was re-added as a panicking iterator over string values.
This should make common usage (e.g. unicode values everywhere) more ergonomic
as well as "the default". This is also a breaking change due to the differences
of what's yielded from each of these functions, but migration should be fairly
easy as the defaults operate over `String` which is a common type to use.
[breaking-change]
There are a number of holes that the stability lint did not previously cover,
including:
* Types
* Bounds on type parameters on functions and impls
* Where clauses
* Imports
* Patterns (structs and enums)
These holes have all been fixed by overriding the `visit_path` function on the
AST visitor instead of a few specialized cases. This change also necessitated a
few stability changes:
* The `collections::fmt` module is now stable (it was already supposed to be).
* The `thread_local:👿:Key` type is now stable (it was already supposed to
be).
* The `std::rt::{begin_unwind, begin_unwind_fmt}` functions are now stable.
These are required via the `panic!` macro.
* The `std::old_io::stdio::{println, println_args}` functions are now stable.
These are required by the `print!` and `println!` macros.
* The `ops::{FnOnce, FnMut, Fn}` traits are now `#[stable]`. This is required to
make bounds with these traits stable. Note that manual implementations of
these traits are still gated by default, this stability only allows bounds
such as `F: FnOnce()`.
Additionally, the compiler now has special logic to ignore its own generated
`__test` module for the `--test` harness in terms of stability.
Closes#8962Closes#16360Closes#20327
[breaking-change]
Switch feature-gate checker from `box_syntax` to `box_patterns` when
visiting a pattern.
(Having to opt into both `box_syntax` and `box_patterns` seemed
unnecessary.)
[breaking-change]
Fixes#22091
I'm not sure how to write a test for this. An ICE happens with spans that start near (after?) a null character or some other zero-width unicode character.
Rename several remaining `Show`s to Debug, `String`s to Display (mostly in comments and docs).
Update reference.md:
- derive() no longer supports Zero trait
- derive() now supports Copy trait
```rust
#[plugin] #[no_link] extern crate bleh;
```
becomes a crate attribute
```rust
#![plugin(bleh)]
```
The feature gate is still required.
It's almost never correct to link a plugin into the resulting library / executable, because it will bring all of libsyntax and librustc with it. However if you really want this behavior, you can get it with a separate `extern crate` item in addition to the `plugin` attribute.
Fixes#21043.
Fixes#20769.
[breaking-change]
#[plugin] #[no_link] extern crate bleh;
becomes a crate attribute
#![plugin(bleh)]
The feature gate is still required.
It's almost never correct to link a plugin into the resulting library /
executable, because it will bring all of libsyntax and librustc with it.
However if you really want this behavior, you can get it with a separate
`extern crate` item in addition to the `plugin` attribute.
Fixes#21043.
Fixes#20769.
[breaking-change]
Makes the compilation abort when a parse error is encountered while
trying to parse an item in an included file. The previous behaviour was
to stop processing the file when a token that can't start an item was
encountered, without producing any error. Fixes#21146.
Fixes#21833.
[breaking-change]
r? @alexcrichton
The tests in #21912 will also need `#[feature(no_std)]`. If you're okay with both PRs, I can merge and test them.
make `for PAT in ITER_EXPR { ... }` a terminating-scope for ITER_EXPR.
In effect, temporary anonymous values created during the evaluation of ITER_EXPR no longer not live for the entirety of the block surrounding the for-loop; instead they only live for the extent of the for-loop itself, and no longer.
----
There is one case I know of that this breaks, demonstrated to me by @nikomatsakis (but it is also a corner-case that is useless in practice). Here is that case:
```
fn main() {
let mut foo: Vec<&i8> = Vec::new();
for i in &[1, 2, 3] { foo.push(i) }
}
```
Note that if you add any code following the for-loop above, or even a semicolon to the end of it, then the code will stop compiling (i.e., it gathers a vector of references but the gathered vector cannot actually be used.)
(The above code, despite being useless, did occur in one run-pass test by accident; that test is updated here to accommodate the new striction.)
----
So, technically this is a:
[breaking-change]
Makes the compilation abort when a parse error is encountered while
trying to parse an item in an included file. The previous behaviour was
to stop processing the file when a token that can't start an item was
encountered, without producing any error. Fixes#21146.
