| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Calling if-let a combination of if and let is confusing, as some may be led to believe that it's a literal combination, instead of syntactic sugar added to the language as a convenience. What's there to stop someone from thinking if-let is just if and let together?
I do think this article does a good job of implying what's really going on; however, I was only able to notice this after I had begun to understand if/while-let statements, courtesy of the Rust IRC chat.
Basically, this article lacks the clarity and explicitness an inexperienced programmer like me needs in order to understand the contents fully. This is shown by my inability to understand the if-let concept from this page of the Book alone.
I think convenience, sugar, and (if-let != if + let) should all be made mention of in a clear, explicit manner. I lack confidence in my understanding of this issue, so I wrote just enough to hopefully get my thoughts across.
|
|
|
|
Fixes #35653
cc https://github.com/rust-lang/rust-www/pull/621
|
|
respectively.
|
|
|
|
|
|
Avoid using locally installed Source Code Pro font (fixes #24355).
In some versions of this font the ampersands are drawn badly.
A doc tree built with this change is at https://storage.googleapis.com/mbp-rust-builds/fonts/doc/std/index.html
I'm not seeing this problem locally so I'm not sure this fixes it, but based on the diagnosis in the bug it should.
I've made this a minimal change by only removing the one problematic font but maybe for consistency every font should be read from the Rust docs tree?
|
|
|
|
Update book/ffi to use catch_unwind
r? @GuillaumeGomez
The doc mentioned to spawn a new thread instead of using catch_unwind, which has been the recommended way to catch panics for foreign function interfaces for a few releases now.
This commit fixes that.
|
|
reference: fix definition of :tt
The reference says that $x:tt matches "either side of the `=>` in macro_rules` which is technically true but completely uninformative. This changes that bullet point to what the book says (a single token or sequence of token trees inside brackets).
|
|
r? @GuillaumeGomez
The doc mentioned to spawn a new thread instead of using catch_unwind, which has been the recommended way to catch panics for foreign function interfaces for a few releases now.
|
|
In some versions of this font the ampersands are drawn badly.
|
|
The reference says that $x:tt matches "either side of the `=>` in macro_rules` which is technically true but completely uninformative. This changes that bullet point to what the book says (a single token or sequence of token trees inside brackets).
|
|
Remove the `unmarked_api` feature
Closes #37981.
|
|
Update items section in reference
Make clear that items must be definitions, and add missing extern block
|
|
Make clear that items must be definitions, and add missing extern block
|
|
|
|
Separate out of bounds errors from character boundary errors, and print
more details for character boundary errors.
Example:
&"abcαβγ"[..4]
thread 'str::test_slice_fail_boundary_1' panicked at 'byte index 4 is not
a char boundary; it is inside `α` (bytes 3..5) of `abcαβγ`'
|
|
Closes #37981.
|
|
Use literal 5 instead of five in book section 4.1
The other two code snippets in this sentence are valid code, so it makes more sense to use the literal `5` rather than the invalid symbol `five`.
|
|
|
|
r=GuillaumeGomez
Clarify the reference's status.
The former wording only gave part of the picture, we want to be crystal
clear about this.
/cc @petrochenkov, who had concerns about https://github.com/rust-lang/rust/pull/37820
|
|
reference: fix duplicate bullet points in feature list
|
|
Fix grammar error in lifetimes.md
|
|
|
|
|
|
Add sections about testing concurrency and stdout/err capture
|
|
The former wording only gave part of the picture, we want to be crystal
clear about this.
|
|
|
|
|
|
Improved punctuation, capitalization, and sentence structure of code snippet comments
r? @GuillaumeGomez
|
|
of the book.
|
|
comments
|
|
|
|
change the `box_free` lang item to accept pointers to unsized types
in miri we use the `box_free` lang item as the destructor for `Box` objects, since the function's api matches that of an `fn drop(&mut self)` in a hypothetical `impl<T: ?Sized> Drop for Box<T>` exactly.
This works fine except if we insert a check in the `size_of` intrinsic to ensure that it is only called with sized types, since the `box_free` lang item calls that intrinsic.
cc @eddyb
no clue who to r? here, probably lang team?
|
|
Remove remark about poor code style
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.
|
|
Update testing.md to reflect changes to cargo new
`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.
|
|
|
|
|
|
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
|
|
Make it clear that the reference isn't normative
Any time someone edits the reference, it has to be taken very seriously,
since it's the closest thing we have to a specification. This commit
adds language which indicates that this is not a normative document,
which makes it easier to make tweaks without worrying about forever
harming the future of Rust by painting ourselves in a corner.
r? @aturon
|
