doc: fix inconsistency in error output in guessing-game.md
The line '.expect("failed to read line");' is partly started with a
lower case 'f' and partly with an uppercase one, adding additional
spurious changes to otherwise clean diffs if each sample is
copy-and-pasted over the previous.
This change starts the string with an uppercase everywhere which is in
line with the style of the other strings.
Unit-like structs doc: Improve code sample
r? @steveklabnik
BTW it seems that
```Rust
let p = Proton {};
```
compiles without an error. That's why I didn't add it to the example. It's about consistency anyway.
The line '.expect("failed to read line");' is partly started with a
lower case 'f' and partly with an uppercase one, adding additional
spurious changes to otherwise clean diffs if each sample is
copy-and-pasted over the previous.
This change starts the string with an uppercase everywhere which is in
line with the style of the other strings.
sort unstable book alphabetically
I made these the same order as they were in the compiler, but for no good reason. Much easier to find out what you need when they're sorted alphabetically
r? @frewsxcv
Structs doc: Change "pointers" to "references"
Let's call them "references" instead of "pointers". That's how they're called in chapter 4.9 "References and Borrowing".
r? @steveklabnik
I made these the same order as they were in the compiler, but for no good reason. Much easier to find out what you need when they're sorted alphabetically
Make lifetime elision docs clearer
Previously it said
"It's forbidden to allow reasoning about types based on the item signature alone."
I think that sentence is wrong. Rust **uses** the item signatures to perform type inference within the body. I think what's meant is the other way around: It does not infer types for item signatures.
r? @steveklabnik
Improve backtrace formating while panicking.
Fixes#37783.
Done:
- Fix alignment of file paths for better readability
- `RUST_BACKTRACE=full` prints all the informations (current behaviour)
- `RUST_BACKTRACE=(short|yes)` is the default and does:
- Skip irrelevant frames at the beginning and the end
- Remove function address
- Remove the current directory from the absolute paths
- Remove `::hfabe6541873` at the end of the symbols
- `RUST_BACKTRACE=(0|no)` disables the backtrace.
- `RUST_BACKTRACE=<everything else>` is equivalent to `short` for
backward compatibility.
- doc
- More uniform printing across platforms.
Removed, TODO in a new PR:
- Remove path prefix for libraries and libstd
Example of short backtrace:
```rust
fn fail() {
panic!();
}
fn main() {
let closure = || fail();
closure();
}
```
Short:
```
thread 'main' panicked at 'explicit panic', t.rs:2
Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
0: t::fail
at ./t.rs:2
1: t::main::{{closure}}
at ./t.rs:6
2: t::main
at ./t.rs:7
```
Full:
```
thread 'main' panicked at 'This function never returns!', t.rs:2
stack backtrace:
0: 0x558ddf666478 - std::sys:👿:backtrace::tracing:👿:unwind_backtrace::hec84c9dd8389cc5d
at /home/yamakaky/dev/rust/rust/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: 0x558ddf65d90e - std::sys_common::backtrace::_print::hfa25f8b31f4b4353
at /home/yamakaky/dev/rust/rust/src/libstd/sys_common/backtrace.rs:71
2: 0x558ddf65cb5e - std::sys_common::backtrace::print::h9b711e11ac3ba805
at /home/yamakaky/dev/rust/rust/src/libstd/sys_common/backtrace.rs:60
3: 0x558ddf66796e - std::panicking::default_hook::{{closure}}::h736d216e74748044
at /home/yamakaky/dev/rust/rust/src/libstd/panicking.rs:355
4: 0x558ddf66743c - std::panicking::default_hook::h16baff397e46ea10
at /home/yamakaky/dev/rust/rust/src/libstd/panicking.rs:371
5: 0x558ddf6682bc - std::panicking::rust_panic_with_hook::h6d5a9bb4eca42c80
at /home/yamakaky/dev/rust/rust/src/libstd/panicking.rs:559
6: 0x558ddf64ea93 - std::panicking::begin_panic::h17dc549df2f10b99
at /home/yamakaky/dev/rust/rust/src/libstd/panicking.rs:521
7: 0x558ddf64ec42 - t::diverges::he6bc43fc925905f5
at /tmp/p/t.rs:2
8: 0x558ddf64ec5a - t::main::h0ffc20356b8a69c0
at /tmp/p/t.rs:6
9: 0x558ddf6687f5 - core::ops::FnOnce::call_once::hce41f19c0db56f93
10: 0x558ddf667cde - std::panicking::try::do_call::hd4c8c97efb4291df
at /home/yamakaky/dev/rust/rust/src/libstd/panicking.rs:464
11: 0x558ddf698d77 - __rust_try
12: 0x558ddf698c57 - __rust_maybe_catch_panic
at /home/yamakaky/dev/rust/rust/src/libpanic_unwind/lib.rs:98
13: 0x558ddf667adb - std::panicking::try::h2c56ed2a59ec1d12
at /home/yamakaky/dev/rust/rust/src/libstd/panicking.rs:440
14: 0x558ddf66cc9a - std::panic::catch_unwind::h390834e0251cc9af
at /home/yamakaky/dev/rust/rust/src/libstd/panic.rs:361
15: 0x558ddf6809ee - std::rt::lang_start::hb73087428e233982
at /home/yamakaky/dev/rust/rust/src/libstd/rt.rs:57
16: 0x558ddf64ec92 - main
17: 0x7fecb869e290 - __libc_start_main
18: 0x558ddf64e8b9 - _start
19: 0x0 - <unknown>
```
Loop docs: Present perfect instead of simple past
Sounds better with present perfect because there's a link to the present.
I'm not a native speaker, though. So, plz check whether it really is better ;)
r? @steveklabnik
doc: Use "macOS" terminology consistently
One line in the documentation used the term macOS while the other six used OSX. Be consistent and use the current product brand of macOS.
Add Gankro's table to nomicon/src/phantom-data.md
Original: https://github.com/rust-lang/rust/issues/30069#issuecomment-159928136
Testing confirms that:
- `PhantomData<fn() -> T>` does not actually enable drop checking.
- `PhantomData<fn(T) -> T>` is neither variant nor contravariant.
Correct another typo in procedural macros chapter of the Book.
Another (and the only remaining) instance of the lets/let's mistake fixed in c8292fc / 36b00cf.
r? @steveklabnik
Add Documentation for Custom Attributes and Error Reporting in Procedural Macros
This fixes#39821 .
I'm not sure if the process of how to access custom attributes should be documented as well.
But I feel, that this should rather be documented in `syn`
book: binary prefixed are defined by IEC and not in SI
Binary prefixes (such as Gi for ‘gibi-’ in GiB) are defined by
International Electrotechnical Commission (IEC) and not in the
International System of Units (SI).
Though to be honest I’d just reword the previous paragraph to use ‘1 GiB’.
