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]
Update the coherence rules to "covered first" -- the first type parameter to contain either a local type or a type parameter must contain only covered type parameters.
cc #19470.
Fixes#20974.
Fixes#20749.
r? @aturon
This commits adds an associated type to the `FromStr` trait representing an
error payload for parses which do not succeed. The previous return value,
`Option<Self>` did not allow for this form of payload. After the associated type
was added, the following attributes were applied:
* `FromStr` is now stable
* `FromStr::Err` is now stable
* `FromStr::from_str` is now stable
* `StrExt::parse` is now stable
* `FromStr for bool` is now stable
* `FromStr for $float` is now stable
* `FromStr for $integral` is now stable
* Errors returned from stable `FromStr` implementations are stable
* Errors implement `Display` and `Error` (both impl blocks being `#[stable]`)
Closes#15138
This commit performs a final stabilization pass over the std::fmt module,
marking all necessary APIs as stable. One of the more interesting aspects of
this module is that it exposes a good deal of its runtime representation to the
outside world in order for `format_args!` to be able to construct the format
strings. Instead of hacking the compiler to assume that these items are stable,
this commit instead lays out a story for the stabilization and evolution of
these APIs.
There are three primary details used by the `format_args!` macro:
1. `Arguments` - an opaque package of a "compiled format string". This structure
is passed around and the `write` function is the source of truth for
transforming a compiled format string into a string at runtime. This must be
able to be constructed in stable code.
2. `Argument` - an opaque structure representing an argument to a format string.
This is *almost* a trait object as it's just a pointer/function pair, but due
to the function originating from one of many traits, it's not actually a
trait object. Like `Arguments`, this must be constructed from stable code.
3. `fmt::rt` - this module contains the runtime type definitions primarily for
the `rt::Argument` structure. Whenever an argument is formatted with
nonstandard flags, a corresponding `rt::Argument` is generated describing how
the argument is being formatted. This can be used to construct an
`Arguments`.
The primary interface to `std::fmt` is the `Arguments` structure, and as such
this type name is stabilize as-is today. It is expected for libraries to pass
around an `Arguments` structure to represent a pending formatted computation.
The remaining portions are largely "cruft" which would rather not be stabilized,
but due to the stability checks they must be. As a result, almost all pieces
have been renamed to represent that they are "version 1" of the formatting
representation. The theory is that at a later date if we change the
representation of these types we can add new definitions called "version 2" and
corresponding constructors for `Arguments`.
One of the other remaining large questions about the fmt module were how the
pending I/O reform would affect the signatures of methods in the module. Due to
[RFC 526][rfc], however, the writers of fmt are now incompatible with the
writers of io, so this question has largely been solved. As a result the
interfaces are largely stabilized as-is today.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0526-fmt-text-writer.md
Specifically, the following changes were made:
* The contents of `fmt::rt` were all moved under `fmt::rt::v1`
* `fmt::rt` is stable
* `fmt::rt::v1` is stable
* `Error` is stable
* `Writer` is stable
* `Writer::write_str` is stable
* `Writer::write_fmt` is stable
* `Formatter` is stable
* `Argument` has been renamed to `ArgumentV1` and is stable
* `ArgumentV1::new` is stable
* `ArgumentV1::from_uint` is stable
* `Arguments::new_v1` is stable (renamed from `new`)
* `Arguments::new_v1_formatted` is stable (renamed from `with_placeholders`)
* All formatting traits are now stable, as well as the `fmt` method.
* `fmt::write` is stable
* `fmt::format` is stable
* `Formatter::pad_integral` is stable
* `Formatter::pad` is stable
* `Formatter::write_str` is stable
* `Formatter::write_fmt` is stable
* Some assorted top level items which were only used by `format_args!` were
removed in favor of static functions on `ArgumentV1` as well.
* The formatting-flag-accessing methods remain unstable
Within the contents of the `fmt::rt::v1` module, the following actions were
taken:
* Reexports of all enum variants were removed
* All prefixes on enum variants were removed
* A few miscellaneous enum variants were renamed
* Otherwise all structs, fields, and variants were marked stable.
In addition to these actions in the `std::fmt` module, many implementations of
`Show` and `String` were stabilized as well.
In some other modules:
* `ToString` is now stable
* `ToString::to_string` is now stable
* `Vec` no longer implements `fmt::Writer` (this has moved to `String`)
This is a breaking change due to all of the changes to the `fmt::rt` module, but
this likely will not have much impact on existing programs.
Closes#20661
[breaking-change]
This commits adds an associated type to the `FromStr` trait representing an
error payload for parses which do not succeed. The previous return value,
`Option<Self>` did not allow for this form of payload. After the associated type
was added, the following attributes were applied:
* `FromStr` is now stable
* `FromStr::Err` is now stable
* `FromStr::from_str` is now stable
* `StrExt::parse` is now stable
* `FromStr for bool` is now stable
* `FromStr for $float` is now stable
* `FromStr for $integral` is now stable
* Errors returned from stable `FromStr` implementations are stable
* Errors implement `Display` and `Error` (both impl blocks being `#[stable]`)
Closes#15138
Note: Do not merge until we get a newer snapshot that includes #21374
There was some type inference fallout (see 4th commit) because type inference with `a..b` is not as good as with `range(a, b)` (see #21672).
r? @alexcrichton
the compiler that assumed two input types to assume two ouputs; we also have to teach `project.rs`
to project `Output` from the unboxed closure and fn traits.
This implements the remaining bits of 'feature staging', as described in [RFC 507](https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md).
This is not quite done, but the substance of the work is complete so submitting for early review.
Key changes:
* `unstable`, `stable` and `deprecated` attributes all require 'feature' and 'since', and support an optional 'reason'.
* The `unstable` lint is removed.
* A new 'stability checking' pass warns when a used unstable library feature has not been activated with the `feature` attribute. At 1.0 beta this will become an error.
* A new 'unused feature checking' pass emits a lint ('unused_feature', renamed from 'unknown_feature') for any features that were activated but not used.
* A new tidy script `featureck.py` performs some global sanity checking, particularly that 'since' numbers agree, and also prints out a summary of features.
Differences from RFC:
* As implemented `unstable` requires a `since` attribute. I do not know if this is useful. I included it in the original sed script and just left it.
* RFC didn't specify the name of the optional 'reason' attribute.
* This continues to use 'unstable', 'stable' and 'deprecated' names (the 'nice' names) instead of 'staged_unstable', but only activates them with the crate-level 'staged_api' attribute.
I intend to update the RFC based on the outcome of this PR.
Issues:
* The unused feature check doesn't account for language features - i.e. you can activate a language feature, not use it, and not get the error.
Open questions:
* All unstable and deprecated features are named 'unnamed_feature', which i picked just because it is uniquely greppable. This is the 'catch-all' feature. What should it be?
* All stable features are named 'grandfathered'. What should this be?
TODO:
* Add check that all `deprecated` attributes are paired with a `stable` attribute in order to preserve the knowledge about when a feature became stable.
* Update rustdoc in various ways.
* Remove obsolete stability discussion from reference.
* Add features for 'path', 'io', 'os', 'hash' and 'rand'.
cc #20445 @alexcrichton @aturon
This new variant introduces finer-grain code extents, i.e. we now
track that a binding lives only for a suffix of a block, and
(importantly) will be dropped when it goes out of scope *before* the
bindings that occurred earlier in the block.
Both of these notions are neatly captured by marking the block (and
each suffix) as an enclosing scope of the next suffix beneath it.
This is work that is part of the foundation for issue #8861.
(It actually has been seen in earlier posted pull requests; I have
just factored it out into its own PR to ease my own rebasing.)
----
These finer grained scopes do mean that some code is newly rejected by
`rustc`; for example:
```rust
let mut map : HashMap<u8, &u8> = HashMap::new();
let tmp = Box::new(2);
map.insert(43, &*tmp);
```
This will now fail to compile with a message that `*tmp` does not live
long enough, because the scope of `tmp` is now strictly smaller than
that of `map`, and the use of `&u8` in map's type requires that the
borrowed references are all to data that live at least as long as the
map.
The usual fix for a case like this is to move the binding for `tmp`
up above that of `map`; note that you can still leave the initialization
in the original spot, like so:
```rust
let tmp;
let mut map : HashMap<u8, &u8> = HashMap::new();
tmp = box 2;
map.insert(43, &*tmp);
```
Similarly, one can encounter an analogous situation with `Vec`: one
would need to rewrite:
```rust
let mut vec = Vec::new();
let tmp = 'c';
vec.push(&tmp);
```
as:
```
let tmp;
let mut vec = Vec::new();
tmp = 'c';
vec.push(&tmp);
```
----
In some corner cases, it does not suffice to reorder the bindings; in
particular, when the types for both bindings need to reflect exactly
the *same* code extent, and a parent/child relationship between them
does not work.
In pnkfelix's experience this has arisen most often when mixing uses
of cyclic data structures while also allowing a lifetime parameter
`'a` to flow into a type parameter context where the type is
*invariant* with respect to the type parameter. An important instance
of this is `arena::TypedArena<T>`, which is invariant with respect
to `T`.
(The reason that variance is relevant is this: *if* `TypedArena` were
covariant with respect to its type parameter, then we could assign it
the longer lifetime when it is initialized, and then convert it to a
subtype (via covariance) with a shorter lifetime when necessary. But
`TypedArena` is invariant with respect to its type parameter, and thus
if `S` is a subtype of `T` (in particular, if `S` has a lifetime
parameter that is shorter than that of `T`), then a `TypedArena<S>` is
unrelated to `TypedArena<T>`.)
Concretely, consider code like this:
```rust
struct Node<'a> { sibling: Option<&'a Node<'a>> }
struct Context<'a> {
// because of this field, `Context<'a>` is invariant with respect to `'a`.
arena: &'a TypedArena<Node<'a>>,
...
}
fn new_ctxt<'a>(arena: &'a TypedArena<Node<'a>>) -> Context<'a> { ... }
fn use_ctxt<'a>(fcx: &'a Context<'a>) { ... }
let arena = TypedArena::new();
let ctxt = new_ctxt(&arena);
use_ctxt(&ctxt);
```
In these situations, if you try to introduce two bindings via two
distinct `let` statements, each is (with this commit) assigned a
distinct extent, and the region inference system cannot find a single
region to assign to the lifetime `'a` that works for both of the
bindings. So you get an error that `ctxt` does not live long enough;
but moving its binding up above that of `arena` just shifts the error
so now the compiler complains that `arena` does not live long enough.
SO: What to do? The easiest fix in this case is to ensure that the two
bindings *do* get assigned the same static extent, by stuffing both
bindings into the same let statement, like so:
```rust
let (arena, ctxt): (TypedArena, Context);
arena = TypedArena::new();
ctxt = new_ctxt(&arena);
use_ctxt(&ctxt);
```
Due to the new code rejections outlined above, this is a ...
[breaking-change]
In preparation for the I/O rejuvination of the standard library, this commit
renames the current `io` module to `old_io` in order to make room for the new
I/O modules. It is expected that the I/O RFCs will land incrementally over time
instead of all at once, and this provides a fresh clean path for new modules to
enter into as well as guaranteeing that all old infrastructure will remain in
place for some time.
As each `old_io` module is replaced it will be deprecated in-place for new
structures in `std::{io, fs, net}` (as appropriate).
This commit does *not* leave a reexport of `old_io as io` as the deprecation
lint does not currently warn on this form of use. This is quite a large breaking
change for all imports in existing code, but all functionality is retained
precisely as-is and path statements simply need to be renamed from `io` to
`old_io`.
[breaking-change]
E.g. `fn foo() { foo() }`, or, more subtlely
impl Foo for Box<Foo+'static> {
fn bar(&self) {
self.bar();
}
}
The compiler will warn and point out the points where recursion occurs,
if it determines that the function cannot return without calling itself.
Closes#17899.
---
This is highly non-perfect, in particular, my wording above is quite precise, and I have some unresolved questions: This currently will warn about
```rust
fn foo() {
if bar { loop {} }
foo()
}
```
even though `foo` may never be called (i.e. our apparent "unconditional" recursion is actually conditional). I don't know if we should handle this case, and ones like it with `panic!()` instead of `loop` (or anything else that "returns" `!`).
However, strictly speaking, it seems to me that changing the above to not warn will require changing
```rust
fn foo() {
while bar {}
foo()
}
```
to also not warn since it could be that the `while` is an infinite loop and doesn't ever hit the `foo`.
I'm inclined to think we let these cases warn since true edge cases like the first one seem rare, and if they do occur they seem like they would usually be typos in the function call. (I could imagine someone accidentally having code like `fn foo() { assert!(bar()); foo() /* meant to be boo() */ }` which won't warn if the `loop` case is "fixed".)
(Part of the reason this is unresolved is wanting feedback, part of the reason is I couldn't devise a strategy that worked in all cases.)
---
The name `unconditional_self_calls` is kinda clunky; and this reconstructs the CFG for each function that is linted which may or may not be very expensive, I don't know.
This allows one to look at an `ExprMethodCall` `foo.bar()` where `bar`
is a method in some trait and (sometimes) extract the `impl` that `bar`
is defined in, e.g.
trait Foo {
fn bar(&self);
}
impl Foo for uint { // <A>
fn bar(&self) {}
}
fn main() {
1u.bar(); // impl_def_id == Some(<A>)
}
This definitely doesn't handle all cases, but is correct when it is
known, meaning it should only be used for certain linting/heuristic
purposes; no safety analysis.
This does the bare minimum to make registration of error codes work again. After this patch, every call to `span_err!` with an error code gets that error code validated against a list in that crate and a new tidy script `errorck.py` validates that no error codes are duplicated globally.
There are further improvements to be made yet, detailed in #19624.
r? @nikomatsakis
This commit is an implementation of [RFC 565][rfc] which is a stabilization of
the `std::fmt` module and the implementations of various formatting traits.
Specifically, the following changes were performed:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0565-show-string-guidelines.md
* The `Show` trait is now deprecated, it was renamed to `Debug`
* The `String` trait is now deprecated, it was renamed to `Display`
* Many `Debug` and `Display` implementations were audited in accordance with the
RFC and audited implementations now have the `#[stable]` attribute
* Integers and floats no longer print a suffix
* Smart pointers no longer print details that they are a smart pointer
* Paths with `Debug` are now quoted and escape characters
* The `unwrap` methods on `Result` now require `Display` instead of `Debug`
* The `Error` trait no longer has a `detail` method and now requires that
`Display` must be implemented. With the loss of `String`, this has moved into
libcore.
* `impl<E: Error> FromError<E> for Box<Error>` now exists
* `derive(Show)` has been renamed to `derive(Debug)`. This is not currently
warned about due to warnings being emitted on stage1+
While backwards compatibility is attempted to be maintained with a blanket
implementation of `Display` for the old `String` trait (and the same for
`Show`/`Debug`) this is still a breaking change due to primitives no longer
implementing `String` as well as modifications such as `unwrap` and the `Error`
trait. Most code is fairly straightforward to update with a rename or tweaks of
method calls.
[breaking-change]
Closes#21436
This commit aims to stabilize the `TypeId` abstraction by moving it out of the
`intrinsics` module into the `any` module of the standard library. Specifically,
* `TypeId` is now defined at `std::any::TypeId`
* `TypeId::hash` has been removed in favor of an implementation of `Hash`.
This commit also performs a final pass over the `any` module, confirming the
following:
* `Any::get_type_id` remains unstable as *usage* of the `Any` trait will likely
never require this, and the `Any` trait does not need to be implemented for
any other types. As a result, this implementation detail can remain unstable
until associated statics are implemented.
* `Any::downcast_ref` is now stable
* `Any::downcast_mut` is now stable
* `BoxAny` remains unstable. While a direct impl on `Box<Any>` is allowed today
it does not allow downcasting of trait objects like `Box<Any + Send>` (those
returned from `Thread::join`). This is covered by #18737.
* `BoxAny::downcast` is now stable.
This commit modifies resolve to prevent conflicts with typedef names in the same
method that conflits are prevented with enum names. This is a breaking change
due to the differing semantics in resolve, and any errors generated on behalf of
this change require that a conflicting typedef, module, or structure to be
renamed so they do not conflict.
[breaking-change]
Closes#6936
This commit aims to stabilize the `TypeId` abstraction by moving it out of the
`intrinsics` module into the `any` module of the standard library. Specifically,
* `TypeId` is now defined at `std::any::TypeId`
* `TypeId::hash` has been removed in favor of an implementation of `Hash`.
This commit also performs a final pass over the `any` module, confirming the
following:
* `Any::get_type_id` remains unstable as *usage* of the `Any` trait will likely
never require this, and the `Any` trait does not need to be implemented for
any other types. As a result, this implementation detail can remain unstable
until associated statics are implemented.
* `Any::downcast_ref` is now stable
* `Any::downcast_mut` is now stable
* `BoxAny` remains unstable. While a direct impl on `Box<Any>` is allowed today
it does not allow downcasting of trait objects like `Box<Any + Send>` (those
returned from `Thread::join`). This is covered by #18737.
* `BoxAny::downcast` is now stable.
Add `--xpretty flowgraph,unlabelled` variant to the (unstable) flowgraph printing `rustc` option.
This makes the tests much easier to maintain; the particular details of the labels attached to exiting scopes is not worth the effort required to keep it up to date as things change in the compiler internals.
Refactor compare_impl_method into its own file. Modify the
code to stop comparing individual parameter bounds.
Instead we now use the predicates list attached to the trait
and implementation generics. This ensures consistency even
when bounds are declared in different places (i.e on
a parameter vs. in a where clause).
#### Updated 1/12/2014
I updated the multi-line testcase to current but didn't modify the others. The spew code was broke by the `matches!` macro no longer working and I'm not interested in fixing the testcase.
I additionally added one testcase below.
Errors will in general look similar to below if the error is either `mismatched types` or a few other types. The rest are ignored.
---
#### Extra testcase:
```rust
pub trait Foo {
type A;
fn boo(&self) -> <Self as Foo>::A;
}
struct Bar;
impl Foo for i32 {
type A = u32;
fn boo(&self) -> u32 {
42
}
}
fn foo1<I: Foo<A=Bar>>(x: I) {
let _: Bar = x.boo();
}
fn foo2<I: Foo>(x: I) {
let _: Bar = x.boo();
}
pub fn baz(x: &Foo<A=Bar>) {
let _: Bar = x.boo();
}
pub fn main() {
let a = 42i32;
foo1(a);
baz(&a);
}
```
#### Multi-line output:
```cmd
$ ./rustc test3.rs
test3.rs:20:18: 20:25 error: mismatched types:
expected `Bar`,
found `<I as Foo>::A`
(expected struct `Bar`,
found associated type)
test3.rs:20 let _: Bar = x.boo();
^~~~~~~
test3.rs:31:5: 31:9 error: type mismatch resolving `<i32 as Foo>::A == Bar`:
expected u32,
found struct `Bar`
test3.rs:31 foo1(a);
^~~~
test3.rs:31:5: 31:9 note: required by `foo1`
test3.rs:31 foo1(a);
^~~~
test3.rs:32:9: 32:11 error: type mismatch resolving `<i32 as Foo>::A == Bar`:
expected u32,
found struct `Bar`
test3.rs:32 baz(&a);
^~
test3.rs:32:9: 32:11 note: required for the cast to the object type `Foo`
test3.rs:32 baz(&a);
^~
error: aborting due to 3 previous errors
```
---
This is a continuation of #19203 which I apparently broke by force pushing after it was closed. I'm attempting to add multi-line errors where they are largely beneficial - to help differentiate different types in compiler messages. As before, this is still a simple fix.
#### Testcase:
```rust
struct S;
fn test() -> Option<i32> {
let s: S;
s
}
fn test2() -> Option<i32> {
Ok(7) // Should be Some(7)
}
impl Iterator for S {
type Item = i32;
fn next(&mut self) -> Result<i32, i32> { Ok(7) }
}
fn main(){
test();
test2();
}
```
---
#### Single-line playpen errors:
```cmd
<anon>:6:5: 6:6 error: mismatched types: expected `core::option::Option<int>`, found `S` (expected enum core::option::Option, found struct S)
<anon>:6 s
^
<anon>:10:5: 10:10 error: mismatched types: expected `core::option::Option<int>`, found `core::result::Result<_, _>` (expected enum core::option::Option, found enum core::result::Result)
<anon>:10 Ok(7) // Should be Some(7)
^~~~~
<anon>:14:5: 14:55 error: method `next` has an incompatible type for trait: expected enum core::option::Option, found enum core::result::Result [E0053]
<anon>:14 fn next(&mut self) -> Result<uint, uint> { Ok(7) }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 3 previous errors
playpen: application terminated with error code 101
```
---
#### Multi-line errors:
```cmd
$ ./rustc test.rs
test.rs:6:5: 6:6 error: mismatched types:
expected `core::option::Option<i32>`,
found `S`
(expected enum `core::option::Option`,
found struct `S`)
test.rs:6 s
^
test.rs:10:5: 10:10 error: mismatched types:
expected `core::option::Option<i32>`,
found `core::result::Result<_, _>`
(expected enum `core::option::Option`,
found enum `core::result::Result`)
test.rs:10 Ok(7) // Should be Some(7)
^~~~~
test.rs:15:5: 15:53 error: method `next` has an incompatible type for trait: expected enum `core::option::Option`, found enum `core::result::Result` [E0053]
test.rs:15 fn next(&mut self) -> Result<i32, i32> { Ok(7) }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 3 previous errors
```
---
#### Positive notes
* Vim worked fine with it: https://github.com/rust-lang/rust/pull/19203#issuecomment-66861668
* `make check` didn't find any errors
* Fixed *backtick* placement suggested by @p1start at https://github.com/rust-lang/rust/pull/19203#issuecomment-64062052
#### Negative notes
* Didn't check Emacs support but also wasn't provided a testcase...
* Needs to be tested with macro errors but I don't have a good testcase yet
* I would like to move the `E[0053]` earlier (see https://github.com/rust-lang/rust/issues/19464#issuecomment-65334301) but I don't know how
* It might be better to indent the types slightly like so (but I don't know how):
```cmd
test.rs:6:5: 6:6 error: mismatched types:
expected `core::option::Option<int>`,
found `S`
(expected enum `core::option::Option`,
found struct `S`)
test.rs:6 s
```
* Deep whitespace indentation may be a bad idea because early wrapping will cause misalignment between lines
#### Other
* I thought that compiler flags or something else (environment variables maybe) might be required because of comments against it but now that seems too much of a burden for users and for too little gain.
* There was concern that it will make large quantities of errors difficult to distinguish but I don't find that an issue. They both look awful and multi-line errors makes the types easier to understand.
---
#### Single lined spew:
```cmd
$ rustc test2.rs
test2.rs:161:9: 170:10 error: method `next` has an incompatible type for trait: expected enum core::option::Option, found enum core::result::Result [E0053]
test2.rs:161 fn next(&mut self) -> Result<&'a str, int> {
test2.rs:162 self.curr = self.next;
test2.rs:163
test2.rs:164 if let (Some(open), Some(close)) = Parens::find_parens(self.all, self.next) {
test2.rs:165 self.next = if self.all.char_at(self.next) == '(' { close }
test2.rs:166 else { open }
...
test2.rs:164:21: 164:31 error: mismatched types: expected `core::result::Result<uint, int>`, found `core::option::Option<_>` (expected enum core::result::Result, found enum core::option::Option)
test2.rs:164 if let (Some(open), Some(close)) = Parens::find_parens(self.all, self.next) {
^~~~~~~~~~
test2.rs:164:33: 164:44 error: mismatched types: expected `core::result::Result<uint, int>`, found `core::option::Option<_>` (expected enum core::result::Result, found enum core::option::Option)
test2.rs:164 if let (Some(open), Some(close)) = Parens::find_parens(self.all, self.next) {
^~~~~~~~~~~
test2.rs:169:40: 169:76 error: mismatched types: expected `core::result::Result<&'a str, int>`, found `core::option::Option<&str>` (expected enum core::result::Result, found enum core::option::Option)
test2.rs:169 if self.curr != self.len { Some(self.all[self.curr..self.next]) } else { None }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test2.rs:169:86: 169:90 error: mismatched types: expected `core::result::Result<&'a str, int>`, found `core::option::Option<_>` (expected enum core::result::Result, found enum core::option::Option)
test2.rs:169 if self.curr != self.len { Some(self.all[self.curr..self.next]) } else { None }
^~~~
test2.rs:205:14: 205:18 error: mismatched types: expected `core::result::Result<uint, int>`, found `core::option::Option<uint>` (expected enum core::result::Result, found enum core::option::Option)
test2.rs:205 (open, close)
^~~~
test2.rs:205:20: 205:25 error: mismatched types: expected `core::result::Result<uint, int>`, found `core::option::Option<uint>` (expected enum core::result::Result, found enum core::option::Option)
test2.rs:205 (open, close)
^~~~~
test2.rs:210:21: 210:31 error: mismatched types: expected `core::result::Result<uint, int>`, found `core::option::Option<_>` (expected enum core::result::Result, found enum core::option::Option)
test2.rs:210 if let (Some(open), _) = Parens::find_parens(self.all, 0) {
^~~~~~~~~~
test2.rs:210:13: 212:28 error: mismatched types: expected `core::option::Option<&'a int>`, found `core::option::Option<&str>` (expected int, found str)
test2.rs:210 if let (Some(open), _) = Parens::find_parens(self.all, 0) {
test2.rs:211 Some(self.all[0..open])
test2.rs:212 } else { None }
test2.rs:299:48: 299:58 error: mismatched types: expected `Box<translate::Entity>`, found `collections::vec::Vec<_>` (expected box, found struct collections::vec::Vec)
test2.rs:299 pub fn new() -> Entity { Entity::Group(Vec::new()) }
^~~~~~~~~~
test2.rs:359:51: 359:58 error: type `&mut Box<translate::Entity>` does not implement any method in scope named `push`
test2.rs:359 Entity::Group(ref mut vec) => vec.push(e),
^~~~~~~
test2.rs:366:51: 366:85 error: type `&mut Box<translate::Entity>` does not implement any method in scope named `push`
test2.rs:366 Entity::Group(ref mut vec) => vec.push(Entity::Inner(s.to_string())),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 12 previous errors
```
---
#### Multi-line spew:
```cmd
$ ./rustc test2.rs
test2.rs:161:9: 170:10 error: method `next` has an incompatible type for trait:
expected enum `core::option::Option`,
found enum `core::result::Result` [E0053]
test2.rs:161 fn next(&mut self) -> Result<&'a str, int> {
test2.rs:162 self.curr = self.next;
test2.rs:163
test2.rs:164 if let (Some(open), Some(close)) = Parens::find_parens(self.all, self.next) {
test2.rs:165 self.next = if self.all.char_at(self.next) == '(' { close }
test2.rs:166 else { open }
...
test2.rs:164:21: 164:31 error: mismatched types:
expected `core::result::Result<uint, int>`,
found `core::option::Option<_>`
(expected enum `core::result::Result`,
found enum `core::option::Option`)
test2.rs:164 if let (Some(open), Some(close)) = Parens::find_parens(self.all, self.next) {
^~~~~~~~~~
test2.rs:164:33: 164:44 error: mismatched types:
expected `core::result::Result<uint, int>`,
found `core::option::Option<_>`
(expected enum `core::result::Result`,
found enum `core::option::Option`)
test2.rs:164 if let (Some(open), Some(close)) = Parens::find_parens(self.all, self.next) {
^~~~~~~~~~~
test2.rs:169:40: 169:76 error: mismatched types:
expected `core::result::Result<&'a str, int>`,
found `core::option::Option<&str>`
(expected enum `core::result::Result`,
found enum `core::option::Option`)
test2.rs:169 if self.curr != self.len { Some(self.all[self.curr..self.next]) } else { None }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test2.rs:169:86: 169:90 error: mismatched types:
expected `core::result::Result<&'a str, int>`,
found `core::option::Option<_>`
(expected enum `core::result::Result`,
found enum `core::option::Option`)
test2.rs:169 if self.curr != self.len { Some(self.all[self.curr..self.next]) } else { None }
^~~~
test2.rs:205:14: 205:18 error: mismatched types:
expected `core::result::Result<uint, int>`,
found `core::option::Option<uint>`
(expected enum `core::result::Result`,
found enum `core::option::Option`)
test2.rs:205 (open, close)
^~~~
test2.rs:205:20: 205:25 error: mismatched types:
expected `core::result::Result<uint, int>`,
found `core::option::Option<uint>`
(expected enum `core::result::Result`,
found enum `core::option::Option`)
test2.rs:205 (open, close)
^~~~~
test2.rs:210:21: 210:31 error: mismatched types:
expected `core::result::Result<uint, int>`,
found `core::option::Option<_>`
(expected enum `core::result::Result`,
found enum `core::option::Option`)
test2.rs:210 if let (Some(open), _) = Parens::find_parens(self.all, 0) {
^~~~~~~~~~
test2.rs:210:13: 212:28 error: mismatched types:
expected `core::option::Option<&'a int>`,
found `core::option::Option<&str>`
(expected int,
found str)
test2.rs:210 if let (Some(open), _) = Parens::find_parens(self.all, 0) {
test2.rs:211 Some(self.all[0..open])
test2.rs:212 } else { None }
test2.rs:229:57: 229:96 error: the trait `core::ops::Fn<(char,), bool>` is not implemented for the type `|char| -> bool`
test2.rs:229 .map(|s| s.trim_chars(|c: char| c.is_whitespace()))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test2.rs:238:46: 239:75 error: type `core::str::CharSplits<'_, |char| -> bool>` does not implement any method in scope named `filter_map`
test2.rs:238 .filter_map(|s| if !s.is_empty() { Some(s.trim_chars('\'')) }
test2.rs:239 else { None })
test2.rs:237:46: 237:91 error: the trait `core::ops::Fn<(char,), bool>` is not implemented for the type `|char| -> bool`
test2.rs:237 let vec: Vec<&str> = value[].split(|c: char| matches!(c, '(' | ')' | ','))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test2.rs:238:65: 238:77 error: the type of this value must be known in this context
test2.rs:238 .filter_map(|s| if !s.is_empty() { Some(s.trim_chars('\'')) }
^~~~~~~~~~~~
test2.rs:299:48: 299:58 error: mismatched types:
expected `Box<translate::Entity>`,
found `collections::vec::Vec<_>`
(expected box,
found struct `collections::vec::Vec`)
test2.rs:299 pub fn new() -> Entity { Entity::Group(Vec::new()) }
^~~~~~~~~~
test2.rs:321:36: 322:65 error: type `core::str::CharSplits<'_, |char| -> bool>` does not implement any method in scope named `filter_map`
test2.rs:321 .filter_map(|s| if !s.is_empty() { Some(s.trim_chars('\'')) }
test2.rs:322 else { None })
test2.rs:320:36: 320:81 error: the trait `core::ops::Fn<(char,), bool>` is not implemented for the type `|char| -> bool`
test2.rs:320 let vec: Vec<&str> = s.split(|c: char| matches!(c, '(' | ')' | ','))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
test2.rs:321:55: 321:67 error: the type of this value must be known in this context
test2.rs:321 .filter_map(|s| if !s.is_empty() { Some(s.trim_chars('\'')) }
^~~~~~~~~~~~
test2.rs:359:51: 359:58 error: type `&mut Box<translate::Entity>` does not implement any method in scope named `push`
test2.rs:359 Entity::Group(ref mut vec) => vec.push(e),
^~~~~~~
test2.rs:366:51: 366:85 error: type `&mut Box<translate::Entity>` does not implement any method in scope named `push`
test2.rs:366 Entity::Group(ref mut vec) => vec.push(Entity::Inner(s.to_string())),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to 24 previous errors
```
Closes#18946#19464
cc @P1start @jakub- @tomjakubowski @kballard @chris-morgan
deref that is associated with an overloaded index, we should not
consult the method lookup table. This deref is *always* a deref of an
`&T` and hence is never overloaded (and is also not present in the
tables; it has no "id" or other associated key).
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 do 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
Next steps are to disable the existing out-of-tree behavior for stability attributes, and convert the remaining system to be feature-based per the RFC. During the first beta cycle we will set these lints to 'forbid'.
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[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
Opt-in built-in traits allowed one to explicitly implement both `Drop`
and `Copy` for a type. This can theoretically make some sense, but the
current implementation means it is codegened totally incorrectly which
can lead to memory unsafety, so this feature is disabled for now.
Fixes#20126.
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
There's been some debate over the precise form that these APIs should take, and
they've undergone some changes recently, so these APIs are going to be left
unstable for now to be fleshed out during the next release cycle.
fmt::Show is for debugging, and can and should be implemented for
all public types. This trait is used with `{:?}` syntax. There still
exists #[derive(Show)].
fmt::String is for types that faithfully be represented as a String.
Because of this, there is no way to derive fmt::String, all
implementations must be purposeful. It is used by the default format
syntax, `{}`.
This will break most instances of `{}`, since that now requires the type
to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the
correct fix. Types that were being printed specifically for users should
receive a fmt::String implementation to fix this.
Part of #20013
[breaking-change]
Treat associated types the same as type parameters when it comes to region bounding. Fixes#20303.
Strictly speaking, this is a [breaking-change] (if you are using
associated types). You are no longer free to wantonly violate the type
system rules by closing associated types into objects without any form
of region bound. Instead you should add region bounds like `T::X :
'a`, just as you would with a normal type parameter.
r? @aturon
macro_rules! is like an item that defines a macro. Other items don't have a
trailing semicolon, or use a paren-delimited body.
If there's an argument for matching the invocation syntax, e.g. parentheses for
an expr macro, then I think that applies more strongly to the *inner*
delimiters on the LHS, wrapping the individual argument patterns.
- the self type includes some local type; and,
- type parameters in the self type must be constrained by a local type.
A type parameter is called *constrained* if it appears in some type-parameter of a local type.
Here are some examples that are accepted. In all of these examples, I
assume that `Foo` is a trait defined in another crate. If `Foo` were
defined in the local crate, then all the examples would be legal.
- `impl Foo for LocalType`
- `impl<T> Foo<T> for LocalType` -- T does not appear in Self, so it is OK
- `impl<T> Foo<T> for LocalType<T>` -- T here is constrained by LocalType
- `impl<T> Foo<T> for (LocalType<T>, T)` -- T here is constrained by LocalType
Here are some illegal examples (again, these examples assume that
`Foo` is not local to the current crate):
- `impl Foo for int` -- the Self type is not local
- `impl<T> Foo for T` -- T appears in Self unconstrained by a local type
- `impl<T> Foo for (LocalType, T)` -- T appears in Self unconstrained by a local type
This is a [breaking-change]. For the time being, you can opt out of
the new rules by placing `#[old_orphan_check]` on the trait (and
enabling the feature gate where the trait is defined). Longer term,
you should restructure your traits to avoid the problem. Usually this
means changing the order of parameters so that the "central" type
parameter is in the `Self` position.
As an example of that refactoring, consider the `BorrowFrom` trait:
```rust
pub trait BorrowFrom<Sized? Owned> for Sized? {
fn borrow_from(owned: &Owned) -> &Self;
}
```
As defined, this trait is commonly implemented for custom pointer
types, such as `Arc`. Those impls follow the pattern:
```rust
impl<T> BorrowFrom<Arc<T>> for T {...}
```
Unfortunately, this impl is illegal because the self type `T` is not
local to the current crate. Therefore, we are going to change the order of the parameters,
so that `BorrowFrom` becomes `Borrow`:
```rust
pub trait Borrow<Sized? Borrowed> for Sized? {
fn borrow_from(owned: &Self) -> &Borrowed;
}
```
Now the `Arc` impl is written:
```rust
impl<T> Borrow<T> for Arc<T> { ... }
```
This impl is legal because the self type (`Arc<T>`) is local.
Strictly speaking, this is a [breaking-change] (if you are using
associated types). You are no longer free to wantonly violate the type
system rules by closing associated types into objects without any form
of region bound. Instead you should add region bounds like `T::X :
'a`, just as you would with a normal type parameter.
This commit moves the libserialize crate (and will force the hand of the
rustc-serialize crate) to not require the `old_orphan_check` feature gate as
well as using associated types wherever possible. Concretely, the following
changes were made:
* The error type of `Encoder` and `Decoder` is now an associated type, meaning
that these traits have no type parameters.
* The `Encoder` and `Decoder` type parameters on the `Encodable` and `Decodable`
traits have moved to the corresponding method of the trait. This movement
alleviates the dependency on `old_orphan_check` but implies that
implementations can no longer be specialized for the type of encoder/decoder
being implemented.
Due to the trait definitions changing, this is a:
[breaking-change]
This implements RFC 179 by making the pattern `&<pat>` require matching
against a variable of type `&T`, and introducing the pattern `&mut
<pat>` which only works with variables of type `&mut T`.
The pattern `&mut x` currently parses as `&(mut x)` i.e. a pattern match
through a `&T` or a `&mut T` that binds the variable `x` to have type
`T` and to be mutable. This should be rewritten as follows, for example,
for &mut x in slice.iter() {
becomes
for &x in slice.iter() {
let mut x = x;
Due to this, this is a
[breaking-change]
Closes#20496.
This commit introduces the syntax for negative implementations of traits
as shown below:
`impl !Trait for Type {}`
cc #13231
Part of RFC rust-lang/rfcs#127
r? @nikomatsakis
TODOs:
- ~~Entry is still `<'a, K, V>` instead of `<'a, O, V>`~~
- ~~BTreeMap is still outstanding~~.
- ~~Transform appropriate things into `.entry(...).get().or_else(|e| ...)`~~
Things that make me frowny face:
- I'm not happy about the fact that this `clone`s the key even when it's already owned.
- With small keys (e.g. `int`s), taking a reference seems wasteful.
r? @Gankro
cc: @cgaebel
Use autoderef for call notation. This is consistent in that we now autoderef all postfix operators (`.`, `[]`, and `()`). It also means you can call closures without writing `(*f)()`. Note that this is rebased atop the rollup, so only the final commit is relevant.
r? @pcwalton
This removes a large array of deprecated functionality, regardless of how
recently it was deprecated. The purpose of this commit is to clean out the
standard libraries and compiler for the upcoming alpha release.
Some notable compiler changes were to enable warnings for all now-deprecated
command line arguments (previously the deprecated versions were silently
accepted) as well as removing deriving(Zero) entirely (the trait was removed).
The distribution no longer contains the libtime or libregex_macros crates. Both
of these have been deprecated for some time and are available externally.
closes#20486closes#20474closes#20441
[breaking-change]
The `Index[Mut]` traits now have one less input parameter, as the return type of the indexing operation is an associated type. This breaks all existing implementations.
---
binop traits (`Add`, `Sub`, etc) now have an associated type for their return type. Also, the RHS input parameter now defaults to `Self` (except for the `Shl` and `Shr` traits). For example, the `Add` trait now looks like this:
``` rust
trait Add<Rhs=Self> {
type Output;
fn add(self, Rhs) -> Self::Output;
}
```
The `Neg` and `Not` traits now also have an associated type for their return type.
This breaks all existing implementations of these traits.
---
Affected traits:
- `Iterator { type Item }`
- `IteratorExt` no input/output types, uses `<Self as Iterator>::Item` in its methods
- `DoubleEndedIterator` no input/output types, uses `<Self as Iterator>::Item` in its methods
- `DoubleEndedIteratorExt` no input/output types, uses `<Self as Iterator>::Item` in its methods
- `RandomAccessIterator` no input/output types
- `ExactSizeIterator` no input/output types, uses `<Self as Iterator>::Item` in its methods
This breaks all the implementations of these traits.
and which uses EUV. For now, upvar inference is not any smarter than
it ever was, but regionck is simpler because it doesn't have to do as
many things at once.
