Small grammar fix in Guessing Game
When it was Option.expect(), there was an .ok().expect(), but now that it uses Result.expect(), there's only one method, not two.
Fixes#31912
Remove final note from testing chapter.
The information that documentation tests cannot be run in binary crates is already given at the beginning of the section.
This PR implements [RFC 1192](https://github.com/rust-lang/rfcs/blob/master/text/1192-inclusive-ranges.md), which is triple-dot syntax for inclusive range expressions. The new stuff is behind two feature gates (one for the syntax and one for the std::ops types). This replaces the deprecated functionality in std::iter. Along the way I simplified the desugaring for all ranges.
This is my first contribution to rust which changes more than one character outside of a test or comment, so please review carefully! Some of the individual commit messages have more of my notes. Also thanks for putting up with my dumb questions in #rust-internals.
- For implementing `std::ops::RangeInclusive`, I took @Stebalien's suggestion from https://github.com/rust-lang/rfcs/pull/1192#issuecomment-137864421. It seemed to me to make the implementation easier and increase type safety. If that stands, the RFC should be amended to avoid confusion.
- I also kind of like @glaebhoerl's [idea](https://github.com/rust-lang/rfcs/pull/1254#issuecomment-147815299), which is unified inclusive/exclusive range syntax something like `x>..=y`. We can experiment with this while everything is behind a feature gate.
- There are a couple of FIXMEs left (see the last commit). I didn't know what to do about `RangeArgument` and I haven't added `Index` impls yet. Those should be discussed/finished before merging.
cc @Gankro since you [complained](https://www.reddit.com/r/rust/comments/3xkfro/what_happened_to_inclusive_ranges/cy5j0yq)
cc #27777#30877rust-lang/rust#1192rust-lang/rfcs#1254
relevant to #28237 (tracking issue)
Vectors come up in sections dedicated to ownership with the assumption that we know something about it but we haven't seen it yet. On the other hand, you need not know anything about ownership or lifetimes to understand the basics of vectors covered in the vector section of the book. Additionally, by moving it where it is there is a natural progression from loops to an iterative type which discusses for loops. This kind of interaction is generally better for learning.
I would like to have moved the struct section as well but I'm less confident about how to handle it since the ownership sections discuss structs and the structs section talks about mutable borrow.
Refinement of paragraph referenced by [this issue](https://github.com/rust-lang/rust/issues/31927).
The paragraph in question had been adjusted already, but I've made some further clarifications which should help with readability and not leave the reader any `dangling pointers`.
As a Rust newbie, I found the book's explanation for why the `filter` closure gets a reference very confusing, and tried to figure out why `filter` is somehow less consumptive than `map` -- but it isn't; that's controlled by `iter`/`into_iter`. I flailed around for a while until @habnabit explained it to me, and in retrospect it is quite obvious :-)
I feel sorry for bothering you with such a literally one character changes. If it is counter productive feel free to point it out in the comments, that would be totally understandable. I could try to pack such a changes together in one PR to make them less distractive.
r? @steveklabnik
Not everyone knows this convention. We could just rename the variables in the
example, but since this notation is commonly used it's a good opportunity to
introduce it.
r? @steveklabnik
This is a minor change. Please see title. IMO this is important since this is the first instance when we talk about allocating a vector. Not saying that it is allocated on the stack here leaves room for speculation and this might put off some people (they might not even read the later sections which go into more detail about this).
