| Age | Commit message (Collapse) | Author | Lines |
|---|
|
It's not like GCC's.
Fixes #20213
|
|
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
|
|
A few categories:
* Links into compiler docs were just all removed as we're not generating
compiler docs.
* Move up one more level to forcibly go to std docs to fix inlined documentation
across the facade crates.
|
|
Update a spelling inconsistency
L26: "zero cost" -> "zero-cost"
|
|
Fixed link in ownership documentation
Changed "[vector]" to a link to the vector documentation.
|
|
Update syntax index with OpAssign traits
book: Update syntax index with OpAssign traits
The traits are stable from Rust 1.8.
|
|
The information that documentation tests cannot be run in binary crates is already given at the beginning of the section.
|
|
L26: "zero cost" -> "zero-cost"
|
|
Changed "[vector]" to a link to the vector documentation.
|
|
|
|
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 #30877 rust-lang/rust#1192 rust-lang/rfcs#1254
relevant to #28237 (tracking issue)
|
|
Issue here : https://github.com/rust-lang/rust/issues/31991
|
|
|
|
|
|
|
|
|
|
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.
|
|
r? @steveklabnik
|
|
|
|
Had a discussion at https://www.reddit.com/r/rust/comments/488mjv/borrowing_or_returning_ownership/ about how an example could be worded more clearly and tried to take my recommendation and expand upon it with further information provided in the post.
|
|
|
|
|
|
|
|
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`.
|
|
See http://www.ietf.org/rfc/rfc2119.txt
|
|
|
|
issue](https://github.com/rust-lang/rust/issues/31927)
|
|
|
|
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 :-)
|
|
|
|
|
|
|
|
|
|
See title and diff for more information.
|
|
|
|
Closes #31554.
Contributes to #29380.
|
|
In the Rust code above this block of compiler output, the function is called print_sum, so use the same function name in the error message.
|
|
In the Rust code above, the function is called print_sum, so use the
same function name in the error message.
|
|
|
|
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).
|
|
of doing out of bounds accesses.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
