This is little clean code of this PR: #21366. I patched the same thing as aochagavia but too slowly obviously. This is a merge of our two codes, more "rust-like".
The reference count can never be 0, unless we're about to drop the data
completely. Using the `assume` intrinsic allows us to inform LLVM about
that invariant, meaning it can avoid unnecessary drops.
---
Before and after IR: https://gist.github.com/Aatch/3786d20df2edaad6a0e8
Generated from the example in #13018Fixes#13018
Initial support for aarch64-linux-android (#18920)
- Add new configuration files
- Modify some options to compile & link succesfully.
(PIE, disable tls on jemalloc, modify some external function linkage, ..)
- To build, refer to https://github.com/rust-lang/rust/wiki/Doc-building-for-android.
(tested with platform=21 and toolchain=aarch64-linux-android-4.9)
closes#20953closes#21361
---
In the future, we will likely derive these `impl`s via syntax extensions or using compiler magic (see #20617). For the time being we can use these manual `impl`s.
r? @aturon
cc @burntsushi @Kroisse
There are two limitations to the macro that this addresses:
1. the expected type is not propagated, coercions don't trigger
2. references inside element expressions don't outlive the `Vec`
Both of these limitations are caused by the block in the
macro expansion, previously needed to trigger a coercion
from `Box<[T; N]>` to `Box<[T]>`, now possible with UFCS.
File cannot be written, for example, if directory does not exist.
Before this commit:
```
% rustc -o nonexistent/program program.rs
error: could not write output: No such file or directory
```
With this commit:
```
% rustc -o nonexistent/program program.rs
error: could not write output to nonexistent/program.0.o: No such file or directory
```
This is useful when full rust command is not displayed, or when last error is followed by thousands of warnings.
This does the bare minimum to make registration of error codes work again. After this patch, every call to `span_err!` with an error code gets that error code validated against a list in that crate and a new tidy script `errorck.py` validates that no error codes are duplicated globally.
There are further improvements to be made yet, detailed in #19624.
r? @nikomatsakis
The timezone of the server that builds rustc nightlies
appears to be in UTC. From what I can tell, it builds
the nightlies at 0300 UTC, which takes about ~15 minutes.
So, there were a couple options here for which offset to use.
UTC+3 would ensure that you always got the latest rust, but it
would mean the script is broken ~15/20 minutes a day. UTC+4
means users get a stale nightly for 45 minutes, but that feels
okay to me.
Ideally, buildbot would publish the "current" nightly, but
that seems unneeded relative to fixing it for all Timezones
quickly.
Fixes#21270
I added an option to auto-indent method chains to line up along their '.' operators. Like so:
```
let input = io::stdin().readline()
.ok()
.expect("Failed to read line");
```
The old default would indent like so:
```
let input = io::stdin().readme()
.ok()
.expect("Failed to read line");
```
The Rust guide explicitly condones the former, so I thought it would be nice for the emacs mode to support it. It's off by default, you have to set ```rust-indent-method-chain``` to ```t``` via your .emacs or the customize menu
This commit deprecates `slice`, `slice_from`, `slice_to` and their
mutable variants in favor of slice notation.
The `as_slice` methods are left intact, for now.
[breaking-change]
This commit marks as `#[stable]`:
* The `Index` and `IndexMut` traits. These are stabilized as taking the
index itself *by reference*; after extensive discussion it was
determined that this is a better match with our choices
elsewhere (e.g. making comparison operators auto-reference), and that
the use cases for by-value indices are better handled through
`IndexSet`.
* The `Range`, `RangeFrom` and `RangeTo` structs, introduced for range
notation.
* Various impls of `Index` and `IndexMut`.
The `FullRange` struct is left unstable as we may wish to rename it to
`RangeFull` in the future.
This commit also *removes* the `Step` trait in favor of direct
implementation of iterator traits on ranges for integers. The `Step`
trait was not a terribly useful factoring internally, and it is likely
that external integer types are best off implementing range iterators
directly. It was removed to simplify the API surface. We can always
reintroduce `Step` later if it turns out to be useful.
Due to this removal, this is a:
[breaking-change]
