| Age | Commit message (Collapse) | Author | Lines |
|
When using closures that take references with explicit lifetimes sometimes
it's required to use where F: for<..> ... syntax to express the right
lifetimes. This adds a quick note to the docs so other users can discover
it as well.
|
|
|
|
rustdoc: remove artificial indentation of doctest code
The indentation makes the examples look nicer when printed (when is this done?), but breaks tests using multi-line string literals.
Fixes: #25944
|
|
book: fixup code in error handling tutorial
A few oversights happened while porting the example from docopt to getopts. I retraced all the steps, fixing code and description as necessary.
Fixes: #33422
|
|
This makes the examples look nicer when printed (when is this
done?), but breaks tests using multi-line string literals.
Fixes: #25944
|
|
|
|
A few oversights happened while porting the example from docopt to
getopts. I retraced all the steps, fixing code and description as
necessary.
Fixes: #33422
|
|
from 'Converting to Cargo'.
|
|
|
|
|
|
|
|
|
|
r=GuillaumeGomez
Fix use of the `move` command in the Windows shell
`move` works both in `cmd` and in Powershell. `mv` works only in Powershell and the book says nothing about which shell is recommended so this could confuse beginners.
Closes #33219.
|
|
Tweaks to sections related to Ownership
Reading through these sections, I thought the intro text could be improved slightly. So
here is a PR that addresses what was bugging me about it. :-)
Main issue was the wording of the opening sentence ("guide" is not clearly defined and the
wording was a bit too terse in my opinion). I also took issue with the term "one of the most
unique". Uniqueness is a `bool`, not an `f64`. :-)
r? @steveklabnik
|
|
make the borrowing example more concrete
|
|
|
|
I made the "tuple structs are useless" editorializing a bit weaker and moved it to the end. Feel free to overrule me on that.
I also added an example of how to unpack a tuple struct with dot notation, because it came up on IRC.
`braced_empty_structs` is stable now, so I updated the example for unit-like structs to use that syntax. Should we show both ways?
cc @ubsan
r? @steveklabnik or @GuillameGomez
|
|
`move` work both in `cmd` and in Powershell. `mv` works only in Powershell and the book says nothing about which shell is recommended so this could confuse beginners.
Closes #33219.
|
|
add as 2nd example.
|
|
|
|
doc: Update our tier support
This modifies our listing of tiered platforms a few ways:
* All lists are alphabetized based on target now
* Lots of targets are moved up to "Tier 2" as we're gating on all these builds
and official releases are provided (and installable via rustup).
* A few targets now list having a compiler + cargo now as well.
No more platforms have been moved up to Tier 1 at this time, however. The only
real candidate is ``x86_64-unknown-linux-musl`, but that's not *quite* to a tier
1 level of quality just yet so let's hold off for another release or so to iron
it out a bit.
|
|
unique" (it either is or is not unique).
|
|
unique" (it either is or is not unique).
|
|
Opening sentence was confusing and something cannot be "one of the most unique" (it either is or is not unique).
|
|
jbranchaud:use-consistent-variable-names-in-ownership, r=GuillaumeGomez
Use `v` instead of `v1` for consistency
The code examples and previous paragraphs all use `v` and `v2`
|
|
Do not use "bind" to refer to both referencing and to assignment
See https://users.rust-lang.org/t/difference-between-four-references/5406/7
|
|
Reword explanation of 'size' types.
Do not reference machine 'pointers' in explanation of 'size' types.
I think the number of elements that can be directly addressed is a fundamental feature of a machine architecture in its own right. The fact that it coincides with the ‘size’ of a pointer should be viewed as an ‘implementation detail’ ;)
|
|
The code examples and previous paragraphs all use `v` and `v2`
|
|
|
|
|
|
remove "#" symbols to make the code compile
|
|
deepak:gh-issue-32928-update-cargo-in-getting-started-doc, r=GuillaumeGomez
Doc fix: Update Cargo.toml in book/getting-started
The Cargo.toml mentioned in book/getting-started
is missing the section called `[dependencies]`
fixes https://github.com/rust-lang/rust/issues/32928
|
|
|
|
|
|
This modifies our listing of tiered platforms a few ways:
* All lists are alphabetized based on target now
* Lots of targets are moved up to "Tier 2" as we're gating on all these builds
and official releases are provided (and installable via rustup).
* A few targets now list having a compiler + cargo now as well.
No more platforms have been moved up to Tier 1 at this time, however. The only
real candidate is ``x86_64-unknown-linux-musl`, but that's not *quite* to a tier
1 level of quality just yet so let's hold off for another release or so to iron
it out a bit.
|
|
The next project refers to the dining-philosophers problem
https://github.com/rust-lang/rust/blob/27a1834ce522e3ec7fe4726b1661de16ee30c503/src/doc/book/dining-philosophers.md
which was removed in
https://github.com/rust-lang/rust/commit/0c6c34de87c899ecb8b977e7ef24510ab2a68168
so removing reference to that project from book/guessing-game
|
|
The Cargo.toml mentioned in book/getting-started
is missing the section called `[dependencies]`
|
|
Replace "make for" by the slightly more accurate "account for".
|
|
Simplify explanation and rephrase as per @GuillaumeGomez's suggestion.
|
|
|
|
Suggest adding a where-clause when that can help
Suggest adding a where-clause when there is an unmet trait-bound that can be satisfied if some type can implement it.
r? @nikomatsakis
|
|
Remove error description of `move`
(1) `x` can be used in main() after the call to spawn(). Because the variables follow normal move semantics, though the keyword `move` is used, and i32 implements `Copy`.
(2) I remove this sentence because the previous sentence gives the referrence to `move closures`, and more description of `move` may be redundant.
|
|
Minor doc fixes in "Crates and Modules" and "Lifetimes" chapters
These commits fix a couple of (minor) issues in the _Crates and Modules_ and the _Lifetimes_ chapters of the book.
r? @steveklabnik
|
|
|
|
suggest adding a where-clause when there is an unmet trait-bound that
can be satisfied if some type can implement it.
|
|
1. In the English/Japanese phrases example in the "Multiple File
Crates" section of the "Crates and Modules" chapter, there are a total
of 8 module files that Rust looks for, while only four were
listed. This commit lists all 8 explicitly.
2. Title case fix.
|
|
|
|
Conflicts:
src/doc/book/concurrency.md
|
|
(1) `x` can be used in main() after the call to spawn(). Because the variables follow normal move semantics, though the keyword `move` is used, and i32 implements `Copy`.
(2) I remove this sentence because the previous sentence gives the referrence to `move closures`, and more description of `move` may be redundant.
|
|
allow RUST_BACKTRACE=0 to act as if unset
**UPDATE:** `RUST_BACKTRACE=0` to act as if the env. var is unset! (now `0` is what `disabled` was for, below)
When RUST_BACKTRACE is set to "disabled" then this acts as if the env. var is unset. So, either make sure `RUST_BACKTRACE` is not set OR set it to `disabled` to achieve the same effect.
Sample usage:
```bash
$ rustc -o /tmp/a.out -- <(echo 'fn main(){ panic!() }') && RUST_BACKTRACE=disabled /tmp/a.out
!! executing '/home/zazdxscf/build/1nonpkgs/rust/rust//x86_64-unknown-linux-gnu/stage2/bin//rustc' with args: '-o /tmp/a.out -- /dev/fd/63'
thread '<main>' panicked at 'explicit panic', /dev/fd/63:1
note: Run with `RUST_BACKTRACE=1` for a backtrace.
$ rustc -o /tmp/a.out -- <(echo 'fn main(){ panic!() }') && RUST_BACKTRACE=1 /tmp/a.out
!! executing '/home/zazdxscf/build/1nonpkgs/rust/rust//x86_64-unknown-linux-gnu/stage2/bin//rustc' with args: '-o /tmp/a.out -- /dev/fd/63'
thread '<main>' panicked at 'explicit panic', /dev/fd/63:1
stack backtrace:
1: 0x55709e8148c0 - sys::backtrace::tracing::imp::write::h140f24a0cfc189b98Ru
2: 0x55709e816a5b - panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::closure.45165
3: 0x55709e8166e8 - panicking::default_hook::hed419823688cb82aXoA
4: 0x55709e810fff - sys_common::unwind::begin_unwind_inner::hbb9642f6e212d56fmHt
5: 0x55709e810513 - sys_common::unwind::begin_unwind::h16232867470678019594
6: 0x55709e810489 - main::hb524f9576270962feaa
7: 0x55709e816314 - sys_common::unwind::try::try_fn::h1274188004693518534
8: 0x55709e813dfb - __rust_try
9: 0x55709e815dab - rt::lang_start::h712b1cd650781872ahA
10: 0x55709e810679 - main
11: 0x7efd1026859f - __libc_start_main
12: 0x55709e810348 - _start
13: 0x0 - <unknown>
```
Some programs(eg. [vim's syntactic](https://github.com/scrooloose/syntastic) used by [rust.vim](https://github.com/rust-lang/rust.vim)) cannot unset the env. var RUST_BACKTRACE if it's already set(eg. in .bashrc) but [they can set it to some value](https://github.com/respeccing/gentooskyline/blob/cb5533e1598f871d3fdf7c3d8248ce767b5b9360/system/Z575/OSes/gentoo/on_baremetal/filesystem_now/gentoo/home/zazdxscf/build/1nonpkgs/rust.vim/upd#L17), and I needed to ensure the env. var is unset in order to avoid this issue: https://github.com/rust-lang/rust/issues/29293
**EDIT:** Sample usage 2:
```bash
$ export RUST_BACKTRACE=1
$ rustc -o /tmp/a.out -- <(echo 'fn main(){ panic!() }') && /tmp/a.out
!! executing '/home/zazdxscf/build/1nonpkgs/rust/rust//x86_64-unknown-linux-gnu/stage2/bin//rustc' with args: '-o /tmp/a.out -- /dev/fd/63'
thread '<main>' panicked at 'explicit panic', /dev/fd/63:1
stack backtrace:
1: 0x55c2696738c0 - sys::backtrace::tracing::imp::write::h140f24a0cfc189b98Ru
2: 0x55c269675a5b - panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::closure.45165
3: 0x55c2696756e8 - panicking::default_hook::hed419823688cb82aXoA
4: 0x55c26966ffff - sys_common::unwind::begin_unwind_inner::hbb9642f6e212d56fmHt
5: 0x55c26966f513 - sys_common::unwind::begin_unwind::h16023941661074805588
6: 0x55c26966f489 - main::hb524f9576270962feaa
7: 0x55c269675314 - sys_common::unwind::try::try_fn::h1274188004693518534
8: 0x55c269672dfb - __rust_try
9: 0x55c269674dab - rt::lang_start::h712b1cd650781872ahA
10: 0x55c26966f679 - main
11: 0x7f593d58459f - __libc_start_main
12: 0x55c26966f348 - _start
13: 0x0 - <unknown>
$ rustc -o /tmp/a.out -- <(echo 'fn main(){ panic!() }') && RUST_BACKTRACE=disabled /tmp/a.out
!! executing '/home/zazdxscf/build/1nonpkgs/rust/rust//x86_64-unknown-linux-gnu/stage2/bin//rustc' with args: '-o /tmp/a.out -- /dev/fd/63'
thread '<main>' panicked at 'explicit panic', /dev/fd/63:1
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```
|