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.
make dist: specify the archive file as stdout
If the `-f` option isn't given, GNU tar will use environment variable
`TAPE` first, and next use the compiled-in default, which isn't
necessary `stdout` (it is the tape device `/dev/rst0` under OpenBSD for
example).
implement RFC 1521
Adds documentation to Clone, specifying that Copy types should have a trivial Clone impl.
Fixes#33416.
I tried to use "should" and "must" as defined [here](https://tools.ietf.org/html/rfc2119).
cc @ubsan
Improve diagnostics for constants being used in irrefutable patterns
It's pretty confusing and this error triggers in resolve only when "shadowing" a const, so let's make that clearer.
r? @steveklabnik
rustdoc: use btree map for where clauses
to get more reproducible output.
Fixes: #32555
I've looked at the other uses of HashMap in rustdoc, and they seem ok to (i.e. they use `iter()` and related only for constructing a new map, or when the output goes into independent files).
Not sure what the cause of #24473 is, it shouldn't be where clauses, but maybe it was also fixed inbetween since May 2015.
degrade gracefully with empty spans
In https://github.com/rust-lang/rust/pull/32756, we solved the final test failure, but digging more into it the handling of that scenario could be better. The error was caused by an empty span supplied by the parser representing EOF. This patch checks that we cope more gracefully with such spans:
r? @jonathandturner
rustc: Change target_env for ARM targets to `gnu`
Right now they're `gnueabihf` and `gnueabi`, but when adding new platforms like
musl on ARM it's unfortunate to have to test for all three (`musl`, `musleabi`,
and `musleabihf`). This PR switches everything currently to `gnu`, and the new
musl targets can also use `musl` when they land.
Closes#33244
Implement constant support in MIR.
All of the intended features in `trans::consts` are now supported by `mir::constant`.
The implementation is considered a temporary measure until `miri` replaces it.
A `-Z orbit` bootstrap build will only translate LLVM IR from AST for `#[rustc_no_mir]` functions.
Furthermore, almost all checks of constant expressions have been moved to MIR.
In non-`const` functions, trees of temporaries are promoted, as per RFC 1414 (rvalue promotion).
Promotion before MIR borrowck would allow reasoning about promoted values' lifetimes.
The improved checking comes at the cost of four `[breaking-change]`s:
* repeat counts must contain a constant expression, e.g.:
`let arr = [0; { println!("foo"); 5 }];` used to be allowed (it behaved like `let arr = [0; 5];`)
* dereference of a reference to a `static` cannot be used in another `static`, e.g.:
`static X: [u8; 1] = [1]; static Y: u8 = (&X)[0];` was unintentionally allowed before
* the type of a `static` *must* be `Sync`, irrespective of the initializer, e.g.
`static FOO: *const T = &BAR;` worked as `&T` is `Sync`, but it shouldn't because `*const T` isn't
* a `static` cannot wrap `UnsafeCell` around a type that *may* need drop, e.g.
`static X: MakeSync<UnsafeCell<Option<String>>> = MakeSync(UnsafeCell::new(None));`
was previously allowed based on the fact `None` alone doesn't need drop, but in `UnsafeCell`
it can be later changed to `Some(String)` which *does* need dropping
The drop restrictions are relaxed by RFC 1440 (#33156), which is implemented, but feature-gated.
However, creating `UnsafeCell` from constants is unstable, so users can just enable the feature gate.
doc: Update reference with better description of target_env
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
rustdoc: add "src" links to individual impls
Since these impls can be scattered around quite a bit, it is nice to be able to jump to the location where individual methods and trait impls are defined.
NOTE: this needs an update to the CSS, which I'd like to leave for whoever is the "rustdoc frontend champion". The new [src] links are currently too large and bold. Also, the interaction with the "since version X" annotations is not good.
Fixes: #30416
parser: do not try to continue with `unsafe` on foreign fns
The changed line makes it look like `unsafe` is allowed, but the first statement of `parse_item_foreign_fn` is:
```
self.expect_keyword(keywords::Fn)?;
```
So we get the strange "expected one of `fn`, `pub`, `static`, or `unsafe`, found `unsafe`".
Fixes: #27361
std::thread docs: spawn() does not return a Thread anymore
Also move the "Thread type" section down a bit, since it is not so important anymore.
Fixes: #33321
mk: Fix building with --enable-ccache
We will no longer use `ccache` in the makefiles for our local dependencies like
miniz, but they're so small anyway it doesn't really matter.
Closes#33285
dep_graph: avoid panicking in thread when channel closed
On my system, when the processor is already loaded, and I try to
run the test suite, e.g. compile-fail/dep-graph-assoc-type-trans.rs
fails because of undecodable JSON.
Running the compiler manually, I can see that the dep graph thread
panics (and puts non-JSON on stderr) while `send`ing on `swap_out`,
presumably because the other end has already quit. I think that in
this case, we can just gracefully exit the thread.
