Add armv7-linux-androideabi target
This PR adds `armv7-linux-androideabi` target that matches `armeabi-v7a` Android ABI, ~~downscales `arm-linux-androideabi` target to match `armeabi` Android ABI~~ (TBD later if needed).
This should allow us to get the best performance from every [Android ABI level](http://developer.android.com/ndk/guides/abis.html).
Currently existing target `arm-linux-androideabi` started gaining features out of the supported range of [android `armeabi`](http://developer.android.com/ndk/guides/abis.html). While android compiler does not use a different target for later supported `armv7` architecture, it has distinct ABI name `armeabi-v7a`. We decided to add rust target `armv7-linux-androideabi` to match it.
Note that `NEON`, `VFPv3-D32`, and `ThumbEE` instruction sets are not added, because not all android devices are guaranteed to support all or some of these, and [their availability should be checked at runtime](http://developer.android.com/ndk/guides/abis.html#v7a).
~~This reduces performance of existing `arm-linux-androideabi` and may make it _much_ slower (we are talking more than order of magnitude in some random ad-hoc fp benchmark that I did).~~
Part of #33278.
The definition of this value recently changed slightly. It no
longer corresponds directly to the target triple.
Also shuffled things around to make the order of cfg descriptions more
logical and added text related them to the target triple.
cc #33403
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
`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.
rustbuild: Run all markdown documentation tests
This commit adds support to rustbuild to run all documentation tests, basically
running `rustdoc --test` over all our documentation.
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.
This commit adds support to rustbuild to run all documentation tests, basically
running `rustdoc --test` over all our documentation. This also includes support
for running the error index tests.
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’ ;)
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.
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
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.
(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:👿: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](cb5533e159/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:👿: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.
```
