| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
While the commit message on this one sounds terrible, it's really not so
bad. The issue is that our test runner _expects_ a `fn main() {}` in
code blocks that it'll test, but this code really shouldn't have them.
If it did, then clicking the "play" link in the docs would result in
play.rust-lang.org not treating this code as a test example to be run.
|
|
|
|
I had used `/tmp/adder` for my previous commits. Flipped over to
`/home/you/projects/adder` for consistency with other parts of testing.md
|
|
The narrative flows better if we follow what @steveklabnik is doing in
rust-lang/book#288. Therefore, I completely copied it.
|
|
Without these changes, play.rust-lang.org (as of today) would wrap
our examples in `fn main() {}`. This prevents the user from being able
to easily run the tests.
|
|
Document the question mark operator in reference and the book's syntax index
The question mark operator will be stabilized for the Rust 1.13 release (unfortunately). Even though I don't like the operator, it still should be documented in the syntax index in the book and in the reference.
Maybe there are people who also want to change the book's chapters on error handling, depending on their views of what idiomatic error handling is, now that the operator is stable, but I don't want to and I'd prefer to keep this PR focused on the reference and syntax index only.
Please also apply this PR to the beta branch of rust.
|
|
|
|
book: Removed platform compatibility table, link to the forge
The content is duplicated, and it doesn't need to be in this location.
It's mostly trivia that doesn't apply to most of the audience.
The forge is up to date.
r? @steveklabnik cc @alexcrichton
|
|
Match guessing game output to newest language version
Cargo now informs that it has finished, and there is new error format.
|
|
Add error note to illegal code snippet
Mark intentionally invalid code snippet in documentation as such with a comment. Similar comments used elsewhere in this file.
r? @steveklabnik
|
|
`cargo new` now creates a `src/lib.rs` with a `tests` module by default. I've updated the earlier examples in this doc to reflect this. However, I don't know how we want to approach the "introduction" to idiomatic testing that follows in "the tests module" section. I _think_ it should be broken apart, with the module concept being introduced early on, and the `super` concept being addressed when we hit the `add_two` example. I'd like to get agreement on that being the right approach before I do it though.
I _also_ removed the `#fn main() {}` hidden at the beginning of each example, as these cause Rust Playground to not treat the file as a set of tests that it can run. Removing it _should_ cause Rust Playground to display a "Test >" button in the top left when a user runs the code, which will allow them to see the test runner output.
|
|
The content is duplicated, and it doesn't need to be in this location.
It's mostly trivia that doesn't apply to most of the audience.
The forge is up to date.
|
|
Fix some mistakes in HRTB docs
The example code for higher-ranked trait bounds on closures had an unnecessary `mut` which was confusing, and the text referred to an mutable reference which does not exist in the code (and isn't needed). Removed the `mut`s and fixed the text to better describe the actual error for the failing example.
Thanks to csd_ on IRC for pointing out these problems!
r? @steveklabnik
|
|
|
|
Commented out final 'main' function in order to fit within pattern of…
… other examples and prevent incorrect indentation
|
|
Don't mention "*" dependency version in guessing game example
It's a bad practice as far [RFC 1241](https://github.com/rust-lang/rfcs/blob/master/text/1241-no-wildcard-deps.md) is concerned, and introducing it in early tutorial may as well make it feel legitimate.
|
|
The current wording [seems to be confusing](https://www.reddit.com/r/rust/comments/5aat03/why_is_implementing_traits_on_primitive_types/). As an explanation when and why this could be considered as poor style would go beyond of the scope of this chapter I suggest to remove this remark.
|
|
in the Closures section
|
|
examples and prevent incorrect indentation
|
|
It's a bad practice as far [RFC 1241] is concerned, and introducing it
in early tutorial may as well make it feel legitimate.
[RFC 1241]: https://github.com/rust-lang/rfcs/blob/master/text/1241-no-wildcard-deps.md
|
|
I followed the "Testing" chapter using Rust 1.12.1 but there are some differences. By default the `tests` module is now also generated by `cargo new`, and the console output is updated.
|
|
Cargo now informs that it has finished, and there is new error format.
|
|
|
|
Fix a error of 'book/deref-coercions.html'
The original sentence is:
> This example has two conversions: `Rc<String>` to `String` and then `String` to `&str`.
But it should be
> This example has two conversions: `Rc<String>` to `String` and then `String` to `str`.
or
> This example has two conversions: `&Rc<String>` to `&String` and then `&String` to `&str`.
I think the latter is more clearly.
r? @steveklabnik
|
|
|
|
|
|
The example code for higher-ranked trait bounds on closures had an
unnecessary `mut` which was confusing, and the text referred to an
mutable reference which does not exist in the code (and isn't needed).
Removed the `mut`s and fixed the text to better describe the actual
error for the failing example.
|
|
The original sentence is:
> This example has two conversions: `Rc<String>` to `String` and then `String` to `&str`.
But it should be
> This example has two conversions: `Rc<String>` to `String` and then `String` to `str`.
or
> This example has two conversions: `&Rc<String>` to `&String` and then `&String` to `&str`.
I think the latter is more clearly.
|
|
|
|
book: remove backticks in Type Aliases header
Fix #37116.
|
|
Start the lifetime section with an explanation of the issues that
lack of explicit lifetimes cause and how lifetimes alleviate these.
|
|
Fix #37116.
|
|
Book: Be very explicit of lifetimes being descriptive
... not prescriptive. Pointed out in https://users.rust-lang.org/t/what-if-i-get-lifetimes-wrong/7535/4, which was a revelation to me and made me think this should be more clear in the book. I'm not sure if I got this entirely right or if the wording is good, but I figured a PR is more helpful than a simple issue.
r? @steveklabnik
Small Note: There's also https://github.com/rust-lang/book, should I have sent the PR there? It doesn't coincide with the online book though, so I figured it's better of here.
|
|
|
|
Minor modifications in concurrency section of the Rust book
Fixes #36939
r? @steveklabnik
|
|
|
|
|
|
Also, emphasize differently.
|
|
... no prescriptive. Pointed out in https://users.rust-lang.org/t/what-if-i-get-lifetimes-wrong/7535/4, which was a revelation to me and made me think this should be more clear in the book.
|
|
|
|
As it stands, getting-started and guessing-game both introduce `run` as
a new command. The second should probably make it clear that the reader
has seen it before :)
|
|
Suggesting a change to a comment that puzzled me
While reading this, the comment made it difficult for me to simply absorb the concept. It interrupted my reading flow, and I think this expresses the same meaning, but reads a bit better. It's trivial, but makes it easier for me to move on to the next line.
|
|
Add docs for "!" Never type (rfc 1216)
Pull Request: https://github.com/rust-lang/rfcs/pull/1216
Tracking Issue: #35121
|
|
doc: Fix minor typo in book/variable-bindings.md
r? @steveklabnik
|
|
|
|
|
|
|
|
Docs: Update to "Getting Started" section
I came across #34523 and wanted to suggest a solution. See commit for details.
It seemed like a good place to start contributing, let me know if I did anything wrong 😇
|
