This commit stabilizes `std::borrow`, making the following modifications
to catch up the API with language changes:
* It renames `BorrowFrom` to `Borrow`, as was originally intended (but
blocked for technical reasons), and reorders the parameters
accordingly.
* It moves the type parameter of `ToOwned` to an associated type. This
is somewhat less flexible, in that each borrowed type must have a
unique owned type, but leads to a significant simplification for
`Cow`. Flexibility can be regained by using newtyped slices, which is
advisable for other reasons anyway.
* It removes the owned type parameter from `Cow`, making the type much
less verbose.
* Deprecates the `is_owned` and `is_borrowed` predicates in favor of
direct matching.
The above API changes are relatively minor; the basic functionality
remains the same, and essentially the whole module is now marked
`#[stable]`.
[breaking-change]
This commit is an implementation of [RFC 823][rfc] which is another pass over
the `std::hash` module for stabilization. The contents of the module were not
entirely marked stable, but some portions which remained quite similar to the
previous incarnation are now marked `#[stable]`. Specifically:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0823-hash-simplification.md
* `std::hash` is now stable (the name)
* `Hash` is now stable
* `Hash::hash` is now stable
* `Hasher` is now stable
* `SipHasher` is now stable
* `SipHasher::new` and `new_with_keys` are now stable
* `Hasher for SipHasher` is now stable
* Many `Hash` implementations are now stable
All other portions of the `hash` module remain `#[unstable]` as they are less
commonly used and were recently redesigned.
This commit is a breaking change due to the modifications to the `std::hash` API
and more details can be found on the [RFC][rfc].
Closes#22467
[breaking-change]
The big change here is that we update the object-safety rules to prohibit references to `Self` in the supertrait listing. See #22040 for the motivation. The other change is to handle the interaction of defaults that reference `Self` and object types (where `Self` is erased). We force users to give an explicit type in that scenario.
r? @aturon
Take 2. This PR includes a bunch of refactoring that was part of an experimental branch implementing [implied bounds]. That particular idea isn't ready to go yet, but the refactoring proved useful for fixing #22246. The implied bounds branch also exposed #22110 so a simple fix for that is included here. I still think some more refactoring would be a good idea here -- in particular I think most of the code in wf.rs is kind of duplicating the logic in implicator and should go, but I decided to post this PR and call it a day before diving into that. I'll write a bit more details about the solutions I adopted in the various bugs. I patched the two issues I was concerned about, which was the handling of supertraits and HRTB (the latter turned out to be fine, so I added a comment explaining why.)
r? @pnkfelix (for now, anyway)
cc @aturon
[implied bounds]: http://smallcultfollowing.com/babysteps/blog/2014/07/06/implied-bounds/
After making `rustc` fail on errors at a stop point, like `-Z parse-only`, in #22117, the files in this PR also fail during the parse stage and should be moved as well. Sorry for spliting this move up in two PRs.
they are used without a feature-gate. This is both kinder to existing
code and should make it easier to land this PR, since we don't
have to catch EVERY SINGLE SUFFIX.
This commit is an implementation of [RFC 823][rfc] which is another pass over
the `std::hash` module for stabilization. The contents of the module were not
entirely marked stable, but some portions which remained quite similar to the
previous incarnation are now marked `#[stable]`. Specifically:
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0823-hash-simplification.md
* `std::hash` is now stable (the name)
* `Hash` is now stable
* `Hash::hash` is now stable
* `Hasher` is now stable
* `SipHasher` is now stable
* `SipHasher::new` and `new_with_keys` are now stable
* `Hasher for SipHasher` is now stable
* Many `Hash` implementations are now stable
All other portions of the `hash` module remain `#[unstable]` as they are less
commonly used and were recently redesigned.
This commit is a breaking change due to the modifications to the `std::hash` API
and more details can be found on the [RFC][rfc].
Closes#22467
[breaking-change]
into variance inference; fix various bugs in variance inference
so that it considers the correct set of constraints; modify infer to
consider the results of variance inference for type arguments.
* Move the type parameter on the `AsciiExt` trait to an associated type named
`Owned`.
* Move `ascii::escape_default` to using an iterator.
This is a breaking change due to the removal of the type parameter on the
`AsciiExt` trait as well as the modifications to the `escape_default` function
to returning an iterator. Manual implementations of `AsciiExt` (or `AsciiExt`
bounds) should be adjusted to remove the type parameter and using the new
`escape_default` should be relatively straightforward.
[breaking-change]
This commit renames the features for the `std::old_io` and `std::old_path`
modules to `old_io` and `old_path` to help facilitate migration to the new APIs.
This is a breaking change as crates which mention the old feature names now need
to be renamed to use the new feature names.
[breaking-change]
Previously an implementation of a stable trait allows implementations of
unstable methods. This updates the stability pass to ensure that all items of an
impl block of a trait are indeed stable on the trait itself.
Pass features along during expansion
Use the set of passed features to detect uses of feature-gated macros without the corresponding feature enabled.
Fix#22234.
----
Also, the framework this add (passing along a reference to the features in the expansion context) is a necessary precursor for landing a properly feature-gated desugaring-based overloaded-`box` and placement-`in` (#22181).
----
This is fixing a bug, but since there might be code out there that is unknowingly taking advantage of that bug, I feel obligated to mark this as a:
[breaking-change]
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.
Add `#[rustc_error]` annotation, which causes trans to signal an error
if found on the `main()` function. This lets you write tests that live
in `compile-fail` but are expected to compile successfully. This is
handy when you have many small variations on a theme that you want to
keep together, and you are just testing the type checker, not the
runtime semantics.
r? @pnkfelix
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.
if found on the `main()` function. This lets you write tests that live
in `compile-fail` but are expected to compile successfully. This is
handy when you have many small variations on a theme that you want to
keep together, and you are just testing the type checker, not the
runtime semantics.
Names of structs, enums, traits, type aliases and type parameters (i.e. all identifiers that can be used as full paths in type position) are not allowed to match the names of primitive types.
See #20427 for more information.
This is a minor [breaking-change]
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
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()`.
Closes#8962Closes#16360Closes#20327
This renames the PrivateNoMangleFns lint to allow both to happen in a
single pass, since they do roughly the same work.
Closes#21856
Open questions:
[ ]: Do the tests actually pass (I'm running make check and running out the door now)
[ ]: Is the name of this lint ok. it seems to mostly be fine with [convention](cc53afbe5d/text/0344-conventions-galore.md (lints))
[ ]: I'm not super thrilled about the warning text
r? @kmcallister (Shamelessly nominating because you were looking at my other ticket)
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 a resurrection and heavy revision/expansion of a PR that pcwalton did to resolve#8861.
The most relevant, user-visible semantic change is this: #[unsafe_destructor] is gone. Instead, if a type expression for some value has a destructor, then any lifetimes referenced within that type expression must strictly outlive the scope of the value.
See discussion on https://github.com/rust-lang/rfcs/pull/769
Some compile-fail tests illustrated cases to be rejected by dropck,
including ones that check cyclic data cases designed to exposed bugs
if they are actually tricked into running by an unsound analysis.
E.g. these exposed bugs in earlier broken ways of handling `Vec<T>`.
(Note that all the uses of `unsafe_destructor` are just placating the
simple analysis used for that feature, which will eventually go away
once we have put the dropck through its paces.)
```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.
This PR moves all `compile-fail` tests that fail at the parsing stage to a `parse-fail` directory, in order to use the tests in the `parse-fail` directory to test if the new LALR parser rejects the same files as the Rust parser. I also adjusted the `testparser.py` script to handle the tests in `parse-fail` differently.
However during working on this, I discovered, that Rust's parser sometimes fails during parsing, but does not return a nonzero return code, e.g. compiling `/test/compile-fail/doc-before-semi.rs` with `-Z parse-only` prints an error message, but returns status code 0. Compiling the same file without `-Z parse-only`, the same error message is displayed, but error code 101 returned. I'll look into that over the next week.
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.
Note that the change to the error message in
borrowck-use-in-index-lvalue.rs, where we report that `*w` is
uninitialized rather than `w`, was unintended fallout from the
implementation strategy used here.
The change appears harmless to me, but I welcome advice on how to
bring back the old message, which was slightly cleaner (i.e. less
unintelligible).
----
drive-by: revise compile-fail/borrowck-vec-pattern-move-tail to make
it really clear that there is a conflict that must be signaled.
(A hypothetical future version of Rust might be able to accept the
prior version of the code, since the previously updated index was not
actually aliased.)
....
The 'stable_features' lint helps people progress from unstable to
stable Rust by telling them when they no longer need a `feature`
attribute because upstream Rust has declared it stable.
This compares to the existing 'unstable_features' lint, which is used
to implement feature staging, and triggers on *any* use
of `#[feature]`.
This was particularly helpful in the time just after OIBIT's
implementation to make sure things that were supposed to be Copy
continued to be, but it's now creates a lot of noise for types that
intentionally don't want to be Copy.
r? @alexcrichton
Implement step 1 of rust-lang/rfcs#702
Allows the expression `..` (without either endpoint) in general, can be
used in slicing syntax `&expr[..]` where we previously wrote `&expr[]`.
The old syntax &expr[] is not yet removed or warned for.
The 'stable_features' lint helps people progress from unstable to
stable Rust by telling them when they no longer need a `feature`
attribute because upstream Rust has declared it stable.
This compares to the existing 'unstable_features', which is used
to implement feature staging, and triggers on *any* use
of `#[feature]`.
Allows the expression `..` (without either endpoint) in general, can be
used in slicing syntax `&expr[..]` where we previously wrote `&expr[]`.
The old syntax &expr[] is not yet removed or warned for.
This was particularly helpful in the time just after OIBIT's
implementation to make sure things that were supposed to be Copy
continued to be, but it's now creates a lot of noise for types that
intentionally don't want to be Copy.
Currently, if a `#![staged_api]` crate contains an exported item without a stability marker (or inherited stability),
the item is useless.
This change introduces a check to ensure that all exported items have a defined stability.
it also introduces the `unmarked_api` feature, which lets users import unmarked features. While this PR should in theory forbid these from existing,
in practice we can't be so sure; so this lets users bypass this check instead of having to wait for the library and/or compiler to be fixed (since otherwise this is a hard error).
r? @aturon
This *almost* completes the job for #16440. The idea is that even if we do not know whether some closure type `C` implements `Fn` or `FnMut` (etc), we still know its argument and return types. So if we see an obligation `C : Fn(_0)`, we can unify `_0` with those argument types while still considering the obligation ambiguous and unsatisfied. This helps to make a lot of progress with type inference even before closure kind inference is done.
As part of this PR, the explicit `:` syntax is removed from the AST and completely ignored. We still infer the closure kind based on the expected type if that is available. There are several reasons for this. First, deciding the closure kind earlier is always better, as it allows us to make more progress. Second, this retains a (admittedly obscure) way for users to manually specify the closure kind, which is useful for writing tests if nothing else. Finally, there are still some cases where inference can fail, so it may be useful to have this manual override. (The expectation is that we will eventually revisit an explicit syntax for specifying the closure kind, but it will not be `:` and may be some sort of generalization of the `||` syntax to handle other traits as well.)
This commit does not *quite* fix#16640 because a snapshot is still needed to enable the obsolete syntax errors for explicit `&mut:` and friends.
r? @eddyb as he reviewed the prior patch in this direction
Use the crates.io crate `rand` (version 0.1 should be a drop in
replacement for `std::rand`) and `rand_macros` (`#[derive_Rand]` should
be a drop-in replacement).
[breaking-change]
As part of [RFC 474](https://github.com/rust-lang/rfcs/pull/474), this
commit renames `std::path` to `std::old_path`, leaving the existing path
API in place to ease migration to the new one. Updating should be as
simple as adjusting imports, and the prelude still maps to the old path
APIs for now.
[breaking-change]
closure kind, thereby detecting what happens if there are
mismatches. Simply removing the `:` annotations caused most of these
tests to pass or produce other errors, because the inference would
convert the closure into a more appropriate kind. (The ability to
override the inference by using the expected type is an important
backdoor partly for this reason.)
That is, when offering suggestions for unresolved method calls, avoid
suggesting traits for which implementing the trait for the receiver type
either makes little sense (e.g. type errors, or sugared unboxed
closures), or violates coherence.
The latter is approximated by ensuring that at least one of `{receiver
type, trait}` is local. This isn't precisely correct due to
multidispatch, but the error messages one encounters in such situation
are useless more often than not; it is better to be conservative and
miss some cases, than have overly many false positives (e.g. writing
`some_slice.map(|x| ...)` uselessly suggested that one should implement
`IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`).
Closes#21420.
That is, when offering suggestions for unresolved method calls, avoid
suggesting traits for which implementing the trait for the receiver type
either makes little sense (e.g. type errors, or sugared unboxed
closures), or violates coherence.
The latter is approximated by ensuring that at least one of `{receiver
type, trait}` is local. This isn't precisely correct due to
multidispatch, but the error messages one encounters in such situation
are useless more often than not; it is better to be conservative and
miss some cases, than have overly many false positives (e.g. writing
`some_slice.map(|x| ...)` uselessly suggested that one should implement
`IteratorExt` for `&[T]`, while the correct fix is to call `.iter()`).
Closes#21420.
For "symmetric" binary operators, meaning the types of two sides must be
equal, if the type of LHS doesn't know yet but RHS does, use that as an
hint to infer LHS' type.
Closes#21634
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]
The new `::ops::Range` has separated implementations for each of the
numeric types, while the old `::iter::Range` has one for type `Int`.
However, we do not take output bindings into account when selecting
traits. So it confuses `typeck` and makes the new range does not work as
good as the old one when it comes to type inference.
This patch implements `Iterator` for the new range for one type `Int`.
This limitation could be lifted, however, if we ever reconsider the
output types' role in type inference.
Closes#21595Closes#21649Closes#21672
specialized to closures, and invoke them as soon as we know the
closure kind. I thought initially we would need a fixed-point
inference algorithm but it appears I was mistaken, so we can do this.
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
An alternative to #21749.
This also refactors the naming lint code a little bit and slightly rephrases some warnings (`uppercase` → `upper case`).
Closes#21735.
The usecase is that functions made visible to systems outside of the
rust ecosystem require the symbol to be visible.
This adds a lint for functions that are not exported, but also not mangled.
It has some gotchas:
[ ]: There is fallout in core that needs taking care of
[ ]: I'm not convinced the error message is correct
[ ]: It has no tests
~~However, there's an underlying issue which I'd like feedback on- which is that my belief that that non-pub functions would not have their symbols exported, however that seems not to be the case in the first case that this lint turned up in rustc (`rust_fail`), which intuition suggests has been working.~~
This seems to be a separate bug in rust, wherein the symbols are exported in binaries, but not in rlibs or dylibs. This lint would catch that case.
The usecase is that functions made visible to systems outside of the
rust ecosystem require the symbol to be visible.
This adds a lint for functions that are not exported, but also not mangled.
It has some gotchas:
[ ]: There is fallout in core that needs taking care of
[ ]: I'm not convinced the error message is correct
[ ]: It has no tests
~~However, there's an underlying issue which I'd like feedback on- which is that my belief that that non-pub functions would not have their symbols exported, however that seems not to be the case in the first case that this lint turned up in rustc (`rust_fail`), which intuition suggests has been working.~~
This seems to be a separate bug in rust, wherein the symbols are exported in binaries, but not in rlibs or dylibs. This lint would catch that case.
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]
Coercions will now attempt to autoderef as needed before reborrowing.
This includes overloaded `Deref`, e.g. `&Rc<T>` coerces to `&T`, and
`DerefMut`, e.g. `&mut Vec<T>` coerces to `&mut [T]` (in addition to `&[T]`).
Closes#21432.
It was considered to be impossible but actually it can
happen for nested closures. Also, because there must
be nested closures when this happens, we can use more
targeted help message.
Closes#21390Closes#21600
explicit form `Fn<A,B>` and now should use `Fn(A) -> B` or
`Fn<A,Output=B>`, but in some cases we get duplicate error
reports. This is mildly annoying and arises because of the main error
and another error from the projection. Might be worth squashing those,
but seems like a separate problem.
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
It was considered to be impossible but actually it can
happen for nested closures. Also, because there must
be nested closures when this happens, we can use more
targeted help message.
Closes#21390Closes#21600
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]
I'm beginning to suspect it's impossible to avoid accidentally writing
`#[deriving]` at least once in every program, and it results in
non-intuitive error messages: "Foo doesn't have any method in scope
`clone`" despite there being a `#[deriv...(Clone)]` attribute!
Also, lots of documentation around the internet uses `#[deriving]` so
providing this guidance is very helpful (lots of people ask in #rust
about this error).
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.
I'm beginning to suspect it's impossible to avoid accidentally writing
`#[deriving]` at least once in every program, and it results in
non-intuitive error messages: "Foo doesn't have any method in scope
`clone`" despite there being a `#[deriv...(Clone)]` attribute!
Also, lots of documentation around the internet uses `#[deriving]` so
providing this guidance is very helpful (lots of people ask in #rust
about this error).
Fixes#21166.
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.
Grammar changes:
* allow 'for _ in 1..i {}' (fixes#20241)
* allow 'for _ in 1.. {}' as infinite loop
* prevent use of range notation in contexts where only operators of high
precedence are expected (fixes#20811)
Parser code cleanup:
* remove RESTRICTION_NO_DOTS
* make AS_PREC const and follow naming convention
* make min_prec inclusive
This is a bit of cleanup work to clean out some old deprecated flags and deprecated lint names from the compiler (they've been deprecated for quite awhile now).
This also notably puts `--pretty` behind the `-Z unstable-options` flag (where it was supposed to be previously).
This is little clean code of this PR: #21366. I patched the same thing as aochagavia but too slowly obviously. This is a merge of our two codes, more "rust-like".
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
These two attributes are used to change the entry point into a Rust program, but
for now they're being put behind feature gates until we have a chance to think
about them a little more. The #[start] attribute specifically may have its
signature changed.
This is a breaking change to due the usage of these attributes generating errors
by default now. If your crate is using these attributes, add this to your crate
root:
#![feature(start)] // if you're using the #[start] attribute
#![feature(main)] // if you're using the #[main] attribute
cc #20064
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.
Closes#21033. The new strategy for parsing a field pattern is to look 1 token ahead and if it's a colon, parse as "fieldname: pat", otherwise parse the shorthand form "(box) (ref) (mut) fieldname)". The previous strategy was to parse "(ref) (mut) fieldname" then if we encounter a colon, throw an error if either "ref" or "mut" were encountered.
