Use "an" before "i32"
(Minor typo fix.)
Since the word `i32` starts with a vowel, the indefinite article should use "an", not "a" \[[1](http://www.dictionary.com/browse/an)\]. (Previously there was one instance of "an i32" and two instances of "a i32", so at least something is wrong!) Since I believe that "an" is the correct form, I aligned everything with that.
Add missing apostrophe.
(Minor typo fix.)
The "support" in this case is possessed by the "programmer", and that ownership should be indicated by an apostrophe.
(Minor typo fix.)
Since the word `i32` starts with a vowel, the indefinite article should use "an", not "a" \[[1](http://www.dictionary.com/browse/an)\]. (Previously there was one instance of "an i32" and two instances of "a i32", so at least something is wrong!) Since I believe that "an" is the correct form, I aligned everything with that.
Fix Markdown list formatting.
The Markdown engine used by the book can cope with a single leading space on the list marker:
Like this:
* List item
Rather than like this:
* List item
… but it’s not the typical convention employed in the book, and moreover the Markdown engine used for producing the error index *can’t* cope with it (its behaviour looks like a bug, as it appears to lose one of the two line breaks as well, but that’s immaterial here).
So, we shift to a single convention which doesn’t trigger bugs in the Markdown renderer.
----
See https://doc.rust-lang.org/error-index.html#E0458 and https://doc.rust-lang.org/error-index.html#E0101 for the bad current rendering in the error index.
Simplify notes on testing and concurrency
The start of the notes on tests running concurrently, added in https://github.com/rust-lang/rust/pull/37766 read a little awkwardly. This PR fixes that and simplifies the wording a bit.
r? @steveklabnik
The Markdown engine used by the book can cope with a single leading space
on the list marker:
Like this:
* List item
Rather than like this:
* List item
… but it’s not the typical convention employed in the book, and moreover
the Markdown engine used for producing the error index *can’t* cope with
it (its behaviour looks like a bug, as it appears to lose one of the two
line breaks as well, but that’s immaterial here).
So, we shift to a single convention which doesn’t trigger bugs in the
Markdown renderer.
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.
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).
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`.
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
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?
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.
