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.
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?
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.
