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
There's only one build-critical path in which perl is used, and it was to do a text replacement trivially achievable with sed(1).
I ported the indenter script because it [appears to be used][indenter], but removed check links because it appears to be entirely out of date.
[indenter]: https://github.com/rust-lang/rust/blob/master/src/librustc/util/common.rs#L60-70
As discussed with @aturon I added implementations of various op traits for references to built-in types which was already suggested by the ops reform RFC.
The 2nd commit updates the module documentation of core::ops to fully reflect the recent change from pass-by-reference to pass-by-value and expands on the implications for generic code.
Removed use of unused LDPATH variable on Windows as is done for other platforms, and added GCC flag to ensure MINGW's ANSI compatible STDIO functions are used wherever available (required by jemalloc).
Without these changes it ends up setting the PATH twice, and the second time the PATH begins with `:` which is invalid. Also the regular msvcrt printf-like functions would be used which don't understand stuff like %hhd and %z which jemalloc uses.
This change ought not to make any difference to the output but it fixes the build process for me since at least my build environment couldn't handle that broken path caused by LDPATH being empty.
