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
While waiting on some builds I started cleaning up the various python bits and pieces.
I'm going to keep poking, want to ping me before the next rollup?
Note that I have not yet managed to expose any bug in
`trans::expr::into_fat_ptr`; it would be good to try to do so (or show
that the use of `.to_lvalue_datum` there is sound).
This fixes a subtle issue where temporaries were being allocated (but
not necessarily initialized) to the (parent) terminating scope of a
match expression; in particular, the code to zero out the temporary
emitted by `datum.store_to` is only attached to the particular
match-arm for that temporary, but when going down other arms of the
match expression, the temporary may falsely appear to have been
initialized, depending on what the stack held at that location, and
thus may have its destructor erroneously run at the end of the
terminating scope.
Test cases to appear in a follow-up commit.
Fix#20055
Hi! I added some examples to some SliceExt methods that didn't have any.
I'm looking forward to feedback and I'm happy to change anything-- it looks like the doc conventions are still a bit in flux, based on the discussions going on in [rfc 505](https://github.com/rust-lang/rfcs/pull/505).
I was most unsure about examples for methods that return iterators over slices... I wanted to use asserts on the result of calling `.next()` like in [this permutations example](804c1446b3/src/libcollections/slice.rs (L608-L617)), but then it gets all cluttered up with lifetime stuff... so I went with iterating and printing and mentioning what the expected printed output is like in [this chunks example](804c1446b3/src/libcollections/slice.rs (L297-L304))... any ideas for the best ways to do this are appreciated.
Thank you! ❤️
when saving .rs files under vim
do not fail to run the syntax checker
error: Unrecognized option: 'parse-only'.
due to this commit
953f294ea3
which removed the deprecated flag --parse-only
This PR removes the `min-width` rule from `body` so that no horizontal scrolling is necessary on mobile, and also hides out-of-band information on mobile to create more room for the in-band information.
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
UFCS form. In both cases the problems came about because we were
failing to process pending trait obligations. So change code to
process pending trait obligations before coercions to ensure maximum
type information is available (and also adjust shift to do something
similar).
Fixes#21245.
Spellfix for `Debug` trait documentation. Change "most all types should implement this" to "all types should implement this". Same fix for deprecated `Show` trait.
Add `CodeExtent::Remainder` variant; pre-req for new scoping/drop rules.
This new enum 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, in particular #21022; I have just factored it out into its own PR to ease my own near-future rebasing, and also get people used to the new rules.)
----
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:
```rust
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 restrictions outlined above, this is a ...
[breaking-change]
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]
