Steve Klabnik [Fri, 29 Jul 2016 22:56:09 +0000 (18:56 -0400)]
Remove style guide.
We originally imported this into the repository with the intent of
fixing it up. Instead, nothing happened.
Its appearance on rust-lang.org makes it seem semi-official, but it's
not. The rustfmt strike team will end up producing something like this
anyway, and leaving it around does nothing but mislead people.
bors [Thu, 25 Aug 2016 15:32:19 +0000 (08:32 -0700)]
Auto merge of #35884 - habnabit:freebsd-arc4rand, r=alexcrichton
Use arc4rand(9) on FreeBSD
From rust-lang-nursery/rand#112:
>After reading through #30691 it seems that there's general agreement that using OS-provided facilities for seeding rust userland processes is fine as long as it doesn't use too much from libc. FreeBSD's `arc4random_buf(3)` is not only a whole lot of libc code, but also not even currently exposed in the libc crate. Fortunately, the mechanism `arc4random_buf(3)` et al. use for getting entropy from the kernel ([`arc4rand(9)`](https://www.freebsd.org/cgi/man.cgi?query=arc4random&apropos=0&sektion=9&manpath=FreeBSD+10.3-RELEASE&arch=default&format=html)) is exposed via `sysctl(3)` with constants that are already in the libc crate.
>I haven't found too much documentation on `KERN_ARND`—it's missing or only briefly described in most of the places that cover sysctl mibs. But, from digging through the kernel source, it appears that the sysctl used in this PR is very close to just calling `arc4rand(9)` directly (with `reseed` set to 0 and no way to change it).
I expected [rand](/rust-lang-nursery/rand) to reply quicker, so I tried submitting it there first. It's been a few weeks with no comment, so I don't know the state of it, but maybe someone will see it here and have an opinion. This is basically the same patch. It pains me to duplicate the code but I guess it hasn't been factored out into just one place yet.
Rollup merge of #35916 - eddyb:mir-no-dead-allocas, r=Aatch
rustc_trans: do not generate allocas for unused locals.
This fixes a regression observed in a [`mio` test](https://travis-ci.org/carllerche/mio/jobs/152142886) which was referencing a 4MB `const` array.
Even though MIR rvalue promotion would promote the borrow of the array, a dead temp was left behind.
As the array doesn't have an immediate type, an `alloca` was generated for it, even though it had no uses.
The fix is pretty dumb: assume that locals need to be borrowed or assigned before being used.
And if it can't be used, it doesn't get an `alloca`, even if the type would otherwise demand it.
This could change in the future, but all the MIR we generate now doesn't break that rule.
Rollup merge of #35238 - vadimcn:macro-debug-locs, r=michaelwoerister
Fix debug line number info for macro expansions.
Macro expansions result in code tagged with completely different debug locations than the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines.
This change fixes the problem by tagging expanded code as "inlined" at the macro expansion site, which allows the debugger to sort it out.
Note that only the outermost expansion is currently handled, stepping into a macro will still result in stepping craziness.
Vadim Chugunov [Thu, 25 Aug 2016 02:34:31 +0000 (19:34 -0700)]
Fix debug line info for macro expansions.
Macro expansions produce code tagged with debug locations that are completely different from the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines.
In order to have a good line stepping behavior in debugger, we overwrite debug locations of macro expansions with that of the outermost expansion site.
bors [Thu, 25 Aug 2016 06:05:47 +0000 (23:05 -0700)]
Auto merge of #35814 - alexcrichton:armv7-no-neon, r=brson
rustc: Don't enable NEON by default on armv7 Linux
One of the primary platforms for the `armv7-unknown-linux-gnueabihf` target,
Linux distributions, do not enable NEON extensions by default. This PR disables
that feature by defualt but enables the `d16` feature which enables VFP3D16 that
distributions do enable.
bors [Wed, 24 Aug 2016 21:57:34 +0000 (14:57 -0700)]
Auto merge of #35764 - eddyb:byegone, r=nikomatsakis
Remove the old AST-based backend from rustc_trans.
Starting with Rust 1.13, `--disable-orbit` , `-Z orbit=off` and `#[rustc_no_mir]` have been removed.
Only the new MIR backend is left in the compiler, and only early const_eval uses ASTs from other crates.
Filling drop (previously "zeroing drop"), `#[unsafe_no_drop_flag]` and associated unstable APIs are gone.
Implementing `Drop` doesn't add a flag anymore to the type, all of the dynamic drop is function local.
This is a [breaking-change], please use `Option::None` and/or `mem::forget` if you are unsure about your ability to prevent/control the drop of a value. In the future, `union` will be usable in some such cases.
**NOTE**: DO NOT MERGE before we get the new beta as the stage0, there's some cruft to remove.
All of this will massively simplify any efforts to implement (and as such it blocks) features such as `union`s, safe use of `#[packed]` or new type layout optimizations, not to mention many other experiments.
Jonathan Turner [Wed, 24 Aug 2016 17:35:29 +0000 (10:35 -0700)]
Rollup merge of #35876 - matthew-piziak:sub-examples, r=GuillaumeGomez
more evocative examples for `Sub` and `SubAssign`
These examples are exactly analogous to those in PRs #35709 and #35806. I'll probably remove the `fn main` wrappers for `Add` and `Sub` once this is merged in.
bors [Tue, 23 Aug 2016 18:53:17 +0000 (11:53 -0700)]
Auto merge of #35854 - nikomatsakis:incr-comp-cache-hash-35549, r=mw
compute and cache HIR hashes at beginning
This avoids the compile-time overhead of computing them twice. It also fixes
an issue where the hash computed after typeck is differen than the hash before,
because typeck mutates the def-map in place.
Fixes #35549.
Fixes #35593.
Some performance measurements suggest this `HashesMap` is very small in memory (unobservable via `-Z time-passes`) and very cheap to construct. I do see some (very minor) performance wins in the incremental case after the first run -- the first run costs more because loading the dep-graph didn't have any hashing to do in that case. Example timings from two runs of `libsyntex-syntax` -- the (1) indicates first run, (2) indicates second run, and (*) indicates both together:
bors [Tue, 23 Aug 2016 14:46:52 +0000 (07:46 -0700)]
Auto merge of #35656 - Stebalien:fused, r=alexcrichton
Implement 1581 (FusedIterator)
* [ ] Implement on patterns. See https://github.com/rust-lang/rust/issues/27721#issuecomment-239638642.
* [ ] Handle OS Iterators. A bunch of iterators (`Args`, `Env`, etc.) in libstd wrap platform specific iterators. The current ones all appear to be well-behaved but can we assume that future ones will be?
* [ ] Does someone want to audit this? On first glance, all of the iterators on which I implemented `FusedIterator` appear to be well-behaved but there are a *lot* of them so a second pair of eyes would be nice.
* I haven't touched rustc internal iterators (or the internal rand) because rustc doesn't actually call `fuse()`.
* `FusedIterator` can't be implemented on `std::io::{Bytes, Chars}`.
bors [Tue, 23 Aug 2016 11:16:28 +0000 (04:16 -0700)]
Auto merge of #35627 - apasel422:coerce-cell, r=alexcrichton
Implement `CoerceUnsized` for `{Cell, RefCell, UnsafeCell}`
These impls are analogous to the one for `NonZero`. It's occasionally useful to be able to coerce the cell types when they're being used inside another abstraction. See Manishearth/rust-gc#17 for an example.
Matthew Piziak [Sun, 21 Aug 2016 20:01:27 +0000 (16:01 -0400)]
more evocative examples for `Sub` and `SubAssign`
These examples are exactly analogous to those in PRs #35709 and #35806. I'll probably remove the `fn main` wrappers for `Add` and `Sub` once this is merged in.
bors [Mon, 22 Aug 2016 15:29:41 +0000 (08:29 -0700)]
Auto merge of #35871 - bluss:cstring-new, r=alexcrichton
cstring: avoid excessive growth just to 0-terminate
Based on following what happens in CString::new("string literal"):
1. Using `Into<Vec<u8>>`, a Vec is allocated with capacity exactly equal
to the string's input length.
2. By `v.push(0)`, the Vec is grown to twice capacity, since it was full.
3. By `v.into_boxed_slice()`, the Vec capacity is shrunk to fit the length again.
If we use `.reserve_exact(1)` just before the push, then we avoid the
capacity doubling that we're going to have to shrink anyway.
Growing by just 1 byte means that the step (2) is less likely to have to
move the memory to a larger allocation chunk, and that the step (3) does
not have to reallocate.
bors [Mon, 22 Aug 2016 12:39:53 +0000 (05:39 -0700)]
Auto merge of #35848 - Mark-Simulacrum:make-tidy-in-tree, r=alexcrichton
Check that executable file is in-tree before failing tidy check
I silenced stdout and stderr for ls-files, not sure if that's appropriate (is `make tidy` intended to give debugging information)? Otherwise it prints each file it find to stdout/stderr, which currently prints nothing (only executable files are checked).
I have not done major testing regarding the behavior of ls-files when the file is ignored, but judging by the man page everything should be fine.
I've duplicated the code which makes the path git-friendly from the `Cargo.lock` checking code; I can extract that into a common helper if wanted (it's only two lines).
bors [Mon, 22 Aug 2016 05:30:46 +0000 (22:30 -0700)]
Auto merge of #35821 - nbaksalyar:solaris-trans-fix, r=alexcrichton
Fix linker on Solaris/Illumos
This patch provides a fix for the `GnuLinker::export_symbols` function that currently relies on a `--retain-symbols-file` option which is not supported by the Solaris & Illumos linker.
Instead, a [version script](https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html) is used on this platform to achieve the same goal. Here's an example of a similar approach in LLVM's CMake script: https://github.com/llvm-mirror/llvm/blob/master/cmake/modules/AddLLVM.cmake#L88-L94.
Perhaps other platforms like OpenBSD could benefit from this as well. /cc @semarie