| Age | Commit message (Collapse) | Author | Lines |
|---|
|
The previous version suggested that the compiler chooses not to check, rather than being unable to check.
|
|
Fix a few links in the docs
r? @steveklabnik
|
|
|
|
It was stable since Rust 1.8.
|
|
rather than "test function", which would be `it_works`
|
|
r=steveklabnik
book: size and align in trait object vtables are used
The book currently claims that the `size` and `align` fields in the
trait object vtable are not used, but this is false. These two fields
are used by the stable `mem::size_of_val` and `mem::align_of_val`
functions.
See the `ty::TyDynamic` case of the `glue::size_and_align_of_dst`
function in librustc_trans, which is used to implement both intrinsics
in the unsized case.
r? @steveklabnik
|
|
Add `&mut expr` to syntax index
|
|
r=steveklabnik
Update struct_expr grammar for field init shorthand.
Part of the work for #38830 .
r? @steveklabnik
|
|
book: match enum warning
Matching enums with named fields in the previous way yielded the "non_shorthand_field_patterns" warning.
The new code shows the shorthand syntax as well as field renaming, so it should be exhaustive ;-)
|
|
|
|
Also fix a typo which linkchecker should have caught.
|
|
|
|
The book currently claims that the `size` and `align` fields in the
trait object vtable are not used, but this is false. These two fields
are used by the stable `mem::size_of_val` and `mem::align_of_val`
functions.
See the `ty::TyDynamic` case of the `glue::size_and_align_of_dst`
function in librustc_trans, which is used to implement both intrinsics
in the unsized case.
|
|
As it is written it creates a lot of confusion.
|
|
[libcollections] [doc] Fix typo in documentation
Replace two instances of `an raw` with `a raw` in documentation blocks.
|
|
|
|
|
|
|
|
|
|
Add more docs for CoerceUnsized and Unsize
here be dragons
r? @ubsan @steveklabnik
|
|
book: use abort() over loop {} for panic
Due to #28728 `loop {}` is very risky and can lead to fun debugging experiences such as #38136. Besides, aborting is probably better behavior than an infinite loop.
r? @steveklabnik
|
|
Due to #28728 loop {} is very risky and can lead to fun debugging experiences like in #38136. Besides, aborting is probably better behavior than an infinite loop.
|
|
These are some bare-bones documentation for custom derive, needed
to stabilize "macros 1.1",
https://github.com/rust-lang/rust/issues/35900
The book chapter is based off of a blog post by @cbreeden,
https://cbreeden.github.io/Macros11/
Normally, we have a policy of not mentioning external crates in
documentation. However, given that syn/quote are basically neccesary
for properly using macros 1.1, I feel that not including them here
would make the documentation very bad. So the rules should be bent
in this instance.
|
|
|
|
Use more specific panic message for &str slicing errors
Separate out of bounds errors from character boundary errors, and print
more details for character boundary errors.
It reports the first error it finds in:
1. begin out of bounds
2. end out of bounds
3. begin <= end violated
3. begin not char boundary
5. end not char boundary.
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αβγ`'
Fixes #38052
|
|
Matching enums with named fields in the previous way yielded the "non_shorthand_field_patterns" warning.
The new code shows the shorthand syntax as well as field renaming, so it should be exhaustive ;-)
|
|
|
|
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.
|
|
Document foreign variadic functions in TRPL and the reference.
Fixes https://github.com/rust-lang/rust/issues/38485.
|
|
(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.
|
|
(Minor typo fix.)
The "support" in this case is possessed by the "programmer", and that ownership should be indicated by an apostrophe.
|
|
Fixes https://github.com/rust-lang/rust/issues/38485.
|
|
"verboten" is german for "forbidden"
|
|
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
|
|
book: replace example I do not understand
|
|
|
|
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.
|
|
minor fix about visibility in reference
|
|
|
|
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.
|
