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]
This is an implementation of [RFC 578][rfc] which adds a new `std::env` module
to replace most of the functionality in the current `std::os` module. More
details can be found in the RFC itself, but as a summary the following methods
have all been deprecated:
[rfc]: https://github.com/rust-lang/rfcs/pull/578
* `os::args_as_bytes` => `env::args`
* `os::args` => `env::args`
* `os::consts` => `env::consts`
* `os::dll_filename` => no replacement, use `env::consts` directly
* `os::page_size` => `env::page_size`
* `os::make_absolute` => use `env::current_dir` + `join` instead
* `os::getcwd` => `env::current_dir`
* `os::change_dir` => `env::set_current_dir`
* `os::homedir` => `env::home_dir`
* `os::tmpdir` => `env::temp_dir`
* `os::join_paths` => `env::join_paths`
* `os::split_paths` => `env::split_paths`
* `os::self_exe_name` => `env::current_exe`
* `os::self_exe_path` => use `env::current_exe` + `pop`
* `os::set_exit_status` => `env::set_exit_status`
* `os::get_exit_status` => `env::get_exit_status`
* `os::env` => `env::vars`
* `os::env_as_bytes` => `env::vars`
* `os::getenv` => `env::var` or `env::var_string`
* `os::getenv_as_bytes` => `env::var`
* `os::setenv` => `env::set_var`
* `os::unsetenv` => `env::remove_var`
Many function signatures have also been tweaked for various purposes, but the
main changes were:
* `Vec`-returning APIs now all return iterators instead
* All APIs are now centered around `OsString` instead of `Vec<u8>` or `String`.
There is currently on convenience API, `env::var_string`, which can be used to
get the value of an environment variable as a unicode `String`.
All old APIs are `#[deprecated]` in-place and will remain for some time to allow
for migrations. The semantics of the APIs have been tweaked slightly with regard
to dealing with invalid unicode (panic instead of replacement).
The new `std::env` module is all contained within the `env` feature, so crates
must add the following to access the new APIs:
#![feature(env)]
[breaking-change]
In preparation for upcoming changes to the `Writer` trait (soon to be called
`Write`) this commit renames the current `write` method to `write_all` to match
the semantics of the upcoming `write_all` method. The `write` method will be
repurposed to return a `usize` indicating how much data was written which
differs from the current `write` semantics. In order to head off as much
unintended breakage as possible, the method is being deprecated now in favor of
a new name.
[breaking-change]
This gets rid of the 'experimental' level, removes the non-staged_api
case (i.e. stability levels for out-of-tree crates), and lets the
staged_api attributes use 'unstable' and 'deprecated' lints.
This makes the transition period to the full feature staging design
a bit nicer.
To avoid using the feauture, change uses of `box <expr>` to
`Box::new(<expr>)` alternative, as noted by the feature gate message.
(Note that box patterns have no analogous trivial replacement, at
least not in general; you need to revise the code to do a partial
match, deref, and then the rest of the match.)
[breaking-change]
This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.
It has three primary user-visible effects:
* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.
Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.
Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.
Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.
The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).
Since the Rust codebase itself makes use of unstable features the
compiler and build system to a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).
This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint. I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.
Closes#16678
[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
This library is now published on crates.io as the `term` crate, so the in-tree
version is now deprecated. Once stability warnings are enabled, this library
will automatically be gated.
This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.
A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.
For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.
This breaks code like:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
Change this code to:
#[deriving(Show)]
struct Point2D {
x: int,
y: int,
}
impl Copy for Point2D {}
fn main() {
let mypoint = Point2D {
x: 1,
y: 1,
};
let otherpoint = mypoint;
println!("{}{}", mypoint, otherpoint);
}
This is the backwards-incompatible part of #13231.
Part of RFC #3.
[breaking-change]
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:
```
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
=>
```
pub use self::Foo::{A, B};
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
or
```
pub enum Foo {
A,
B
}
fn main() {
let a = Foo::A;
}
```
[breaking-change]
This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.
The semantics of these three kinds of globals are:
* A `const` does not represent a memory location, but only a value. Constants
are translated as rvalues, which means that their values are directly inlined
at usage location (similar to a #define in C/C++). Constant values are, well,
constant, and can not be modified. Any "modification" is actually a
modification to a local value on the stack rather than the actual constant
itself.
Almost all values are allowed inside constants, whether they have interior
mutability or not. There are a few minor restrictions listed in the RFC, but
they should in general not come up too often.
* A `static` now always represents a memory location (unconditionally). Any
references to the same `static` are actually a reference to the same memory
location. Only values whose types ascribe to `Sync` are allowed in a `static`.
This restriction is in place because many threads may access a `static`
concurrently. Lifting this restriction (and allowing unsafe access) is a
future extension not implemented at this time.
* A `static mut` continues to always represent a memory location. All references
to a `static mut` continue to be `unsafe`.
This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:
* Statics may no longer be used in patterns. Statics now always represent a
memory location, which can sometimes be modified. To fix code, repurpose the
matched-on-`static` to a `const`.
static FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
change this code to:
const FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
* Statics may no longer refer to other statics by value. Due to statics being
able to change at runtime, allowing them to reference one another could
possibly lead to confusing semantics. If you are in this situation, use a
constant initializer instead. Note, however, that statics may reference other
statics by address, however.
* Statics may no longer be used in constant expressions, such as array lengths.
This is due to the same restrictions as listed above. Use a `const` instead.
[breaking-change]
Closes#17718
[rfc]: https://github.com/rust-lang/rfcs/pull/246
This can break code that looked like:
impl Foo for Box<Any> {
fn f(&self) { ... }
}
let x: Box<Any + Send> = ...;
x.f();
Change such code to:
impl Foo for Box<Any> {
fn f(&self) { ... }
}
let x: Box<Any> = ...;
x.f();
That is, upcast before calling methods.
This is a conservative solution to #5781. A more proper treatment (see
the xfail'd `trait-contravariant-self.rs`) would take variance into
account. This change fixes the soundness hole.
Some library changes had to be made to make this work. In particular,
`Box<Any>` is no longer showable, and only `Box<Any+Send>` is showable.
Eventually, this restriction can be lifted; for now, it does not prove
too onerous, because `Any` is only used for propagating the result of
task failure.
This patch also adds a test for the variance inference work in #12828,
which accidentally landed as part of DST.
Closes#5781.
[breaking-change]
