bors [Fri, 5 Feb 2016 17:16:03 +0000 (17:16 +0000)]
Auto merge of #31349 - nikomatsakis:issue-31157-obligation-forest-cache, r=aturon
Have the `ObligationForest` keep some per-tree state (or type `T`) and have it give a mutable reference for use when processing obligations. In this case, it will be a hashmap. This obviously affects the work that @soltanmm has been doing on snapshotting. I partly want to toss this out there for discussion.
Fixes #31157. (The test in question goes to approx. 30s instead of 5 minutes for me.)
cc #30977.
cc @aturon @arielb1 @soltanmm
r? @aturon who reviewed original `ObligationForest`
bors [Fri, 5 Feb 2016 15:11:45 +0000 (15:11 +0000)]
Auto merge of #31400 - durka:civilized-deriving, r=alexcrichton
You can `#[derive(FromPrimitive)]`, but it [fails later in the compile](https://play.rust-lang.org/?gist=82cb8ad2fac49e3fe472&version=stable) due to hardcoding `std::num::FromPrimitive` which [was removed](https://github.com/rust-lang/rust/commit/eeb94886adccb3f13003f92f117115d17846ce1f) (for some reason Github doesn't show `FromPrimitive` in the diff, but `git show` does).
Anyway, this PR removes the code. I didn't mark it as a breaking change, even though [this extremely contrived code using highly unstable features](https://play.rust-lang.org/?gist=1e1b1bbff962837b228a&version=nightly) is broken by it -- should I?
bors [Fri, 5 Feb 2016 13:02:26 +0000 (13:02 +0000)]
Auto merge of #31390 - dotdash:fix_quadratic_drop, r=nagisa
If a new cleanup is added to a cleanup scope, the cached exits for that
scope are cleared, so all previous cleanups have to be translated
again. In the worst case this means that we get N distinct landing pads
where the last one has N cleanups, then N-1 and so on.
As new cleanups are to be executed before older ones, we can instead
cache the number of already translated cleanups in addition to the
block that contains them, and then only translate new ones, if any and
then jump to the cached ones, getting away with linear growth instead.
For the crate in #31381 this reduces the compile time for an optimized
build from >20 minutes (I cancelled the build at that point) to about 11
seconds. Testing a few crates that come with rustc show compile time
improvements somewhere between 1 and 8%. The "big" winner being
rustc_platform_intrinsics which features code similar to that in #31381.
bors [Fri, 5 Feb 2016 08:54:46 +0000 (08:54 +0000)]
Auto merge of #31388 - gmbonnet:compiler-rt-werror, r=alexcrichton
Without this patch, `compiler-rt` fails to build when the `CFLAGS` environment variable contains a `-Werror=*` flag (for example `-Werror=format-security`).
The build system was removing only the `-Werror` part from the flag, thus passing an unrecognized `=*` (for example `=format-security`) argument to gcc.
bors [Fri, 5 Feb 2016 03:03:45 +0000 (03:03 +0000)]
Auto merge of #31321 - jseyfried:cleanup, r=nrc
The first commit improves detection of unused imports -- it should have been part of #30325. Right now, the unused import in the changed test would not be reported.
The rest of the commits are miscellaneous, independent clean-ups in resolve that I didn't think warranted individual PRs.
bors [Fri, 5 Feb 2016 01:00:31 +0000 (01:00 +0000)]
Auto merge of #30865 - alexcrichton:mtime-system-time, r=aturon
These accessors are used to get at the last modification, last access, and
creation time of the underlying file. Currently not all platforms provide the
creation time, so that currently returns `Option`.
Steve Klabnik [Thu, 4 Feb 2016 21:39:05 +0000 (16:39 -0500)]
Rollup merge of #31007 - pra85:license, r=aturon
According to http://www.copyright.gov/circs/circ01.pdf (See screenshot of relevant section below) , listing the first year of publication in the copyright is enough
This commit reverts back those changes, so that license year is again 2014 (As it was, when this license was first introduced in commit 90ba013bde2396f200196 )
Alex Crichton [Wed, 13 Jan 2016 01:24:16 +0000 (17:24 -0800)]
std: Expose SystemTime accessors on fs::Metadata
These accessors are used to get at the last modification, last access, and
creation time of the underlying file. Currently not all platforms provide the
creation time, so that currently returns `Option`.
bors [Thu, 4 Feb 2016 18:48:41 +0000 (18:48 +0000)]
Auto merge of #31360 - pitdicker:fs_tests_cleanup, r=alexcrichton
- use `symlink_file` and `symlink_dir` instead of the old `soft_link`
- create a junction instead of a directory symlink for testing recursive_rmdir (as it causes the
same troubles, but can be created by users without `SeCreateSymbolicLinkPrivilege`)
- `remove_dir_all` was unable to remove directory symlinks and junctions
- only run tests that create symlinks if we have the right permissions.
- rename `Path2` to `Path`
- remove the global `#[allow(deprecated)]` and outdated comments
- After factoring out `create_junction()` from the test `directory_junctions_are_directories` and
removing needlessly complex code, what I was left with was:
```
#[test]
#[cfg(windows)]
fn directory_junctions_are_directories() {
use sys::fs::create_junction;
let tmpdir = tmpdir();
let foo = tmpdir.join("foo");
let bar = tmpdir.join("bar");
fs::create_dir(&foo).unwrap();
check!(create_junction(&foo, &bar));
assert!(bar.metadata().unwrap().is_dir());
}
```
It test whether a junction is a directory instead of a reparse point. But it actually test the
target of the junction (which is a directory if it exists) instead of the junction itself, which
should always be a symlink. So this test is invalid, and I expect it only exists because the
author was suprised by it. So I removed it.
Some things that do not yet work right:
- relative symlinks do not accept forward slashes
- the conversion of paths for `create_junction` is hacky
- `remove_dir_all` now messes with the internal data of `FileAttr` to be able to remove symlinks.
We should add some method like `is_symlink_dir()` to it, so code outside the standard library
can see the difference between file and directory symlinks too.
bors [Thu, 4 Feb 2016 13:41:42 +0000 (13:41 +0000)]
Auto merge of #31161 - sfackler:slice-to-socket-addrs, r=alexcrichton
This is useful when you have an API that takes a `T: ToSocketAddrs` and needs to turn that into an owned value which will be passed to another API taking `T: ToSocketAddrs` at a later time, for example: https://github.com/sfackler/rust-hyper-socks/blob/master/src/lib.rs#L15
bors [Thu, 4 Feb 2016 06:07:26 +0000 (06:07 +0000)]
Auto merge of #31326 - sdleffler:master, r=nikomatsakis
After the truly incredible and embarrassing mess I managed to make in my last pull request, this should be a bit less messy.
Fixes #31267 - with this change, the code mentioned in the issue compiles.
Found and fixed another issue as well - constants of zero-size types, when used in ExprRepeats inside associated constants, were causing the compiler to crash at the same place as #31267. An example of this:
```
struct Bar;
const BAZ: Bar = Bar;
struct Foo([Bar; 1]);
struct Biz;
impl Biz {
const BAZ: Foo = Foo([BAZ; 1]);
}
fn main() {
let foo = Biz::BAZ;
println!("{:?}", foo);
}
```
However, I'm fairly certain that my fix for this is not as elegant as it could be. The problem seems to occur only with an associated constant of a tuple struct containing a fixed size array which is initialized using a repeat expression, and when the element to be repeated provided to the repeat expression is another constant which is of a zero-sized type. The fix works by looking for constants and associated constants which are zero-width and consequently contain no data, but for which rustc is still attempting to emit an LLVM value; it simply stops rustc from attempting to emit anything. By my logic, this should work fine since the only values that are emitted in this case (according to the comments) are for closures with side effects, and constants will never have side effects, so it's fine to simply get rid of them. It fixes the error and things compile fine with it, but I have a sneaking suspicion that it could be done in a far better manner.
bors [Thu, 4 Feb 2016 02:46:44 +0000 (02:46 +0000)]
Auto merge of #30962 - Amanieu:non_volatile_atomic, r=alexcrichton
Rust currently emits atomic loads and stores with the LLVM `volatile` qualifier. This is unnecessary and prevents LLVM from performing optimization on these atomic operations.
Avoid quadratic growth of functions due to cleanups
If a new cleanup is added to a cleanup scope, the cached exits for that
scope are cleared, so all previous cleanups have to be translated
again. In the worst case this means that we get N distinct landing pads
where the last one has N cleanups, then N-1 and so on.
As new cleanups are to be executed before older ones, we can instead
cache the number of already translated cleanups in addition to the
block that contains them, and then only translate new ones, if any and
then jump to the cached ones, getting away with linear growth instead.
For the crate in #31381 this reduces the compile time for an optimized
build from >20 minutes (I cancelled the build at that point) to about 11
seconds. Testing a few crates that come with rustc show compile time
improvements somewhere between 1 and 8%. The "big" winner being
rustc_platform_intrinsics which features code similar to that in #31381.
bors [Wed, 3 Feb 2016 22:40:32 +0000 (22:40 +0000)]
Auto merge of #31078 - nbaksalyar:illumos, r=alexcrichton
This pull request adds support for [Illumos](http://illumos.org/)-based operating systems: SmartOS, OpenIndiana, and others. For now it's x86-64 only, as I'm not sure if 32-bit installations are widespread. This PR is based on #28589 by @potatosalad, and also closes #21000, #25845, and #25846.
Required changes in libc are already merged: https://github.com/rust-lang-nursery/libc/pull/138
Here's a snapshot required to build a stage0 compiler:
https://s3-eu-west-1.amazonaws.com/nbaksalyar/rustc-sunos-snapshot.tar.gz
It passes all checks from `make check`.
There are some changes I'm not quite sure about, e.g. macro usage in `src/libstd/num/f64.rs` and `DirEntry` structure in `src/libstd/sys/unix/fs.rs`, so any comments on how to rewrite it better would be greatly appreciated.
Also, LLVM configure script might need to be patched to build it successfully, or a pre-built libLLVM should be used. Some details can be found here: https://llvm.org/bugs/show_bug.cgi?id=25409
bors [Wed, 3 Feb 2016 19:26:05 +0000 (19:26 +0000)]
Auto merge of #30834 - reem:rwlock-read-guard-map, r=alexcrichton
This is very useful when the RwLock is synchronizing access to a data
structure and you would like to return or store guards which contain
references to data inside the data structure instead of the data structure
itself.
bors [Wed, 3 Feb 2016 06:38:01 +0000 (06:38 +0000)]
Auto merge of #31263 - dhuseby:fixing_bsd_builds, r=alexcrichton
Something went haywire with github last night and the old PR https://github.com/rust-lang/rust/pull/31230 got closed somehow. This new PR is to replace the old one. This incorporates all of the feedback from the other PR.
@alexcrichton I incorporated the suggestion from @semarie and the result is cleaner and clearer. I think this is ready to go.
bors [Wed, 3 Feb 2016 03:06:52 +0000 (03:06 +0000)]
Auto merge of #31319 - alexcrichton:msvc-backtraces, r=michaelwoerister
This mirrors the behavior of `clang-cl.exe` by adding a `CodeView` global
variable when emitting debug information. This should in turn help stack traces
that are generated when code is compiled with debuginfo enabled.
Rollup merge of #31329 - quodlibetor:no-const-doc-in-stable, r=alexcrichton
Fixes #31098
AFAICT this is the only place where rustdoc explicitly checks if we are on stable before emitting content, so I can't tell if this is the sane way to handle this, or if anything else should be done to make sure that nobody forgets to remove this check when `const` is stabilized.
Rollup merge of #27499 - barosl:macro-doc-raw-str-hashes, r=nikomatsakis
Any documentation comments that contain raw-string-looking sequences may pretty-print invalid code when expanding them, as the current logic always uses the `r"literal"` form, without appending any `#`s.
This commit calculates the minimum number of `#`s required to wrap a comment correctly and appends `#`s appropriately.
bors [Tue, 2 Feb 2016 17:11:48 +0000 (17:11 +0000)]
Auto merge of #31312 - alexcrichton:no-le-in-powerpc64le, r=alexcrichton
Currently the `mipsel-unknown-linux-gnu` target doesn't actually set the
`target_arch` value to `mipsel` but it rather uses `mips`. Alternatively the
`powerpc64le` target does indeed set the `target_arch` as `powerpc64le`,
causing a bit of inconsistency between theset two.
As these are just the same instance of one instruction set, let's use
`target_endian` to switch between them and only set the `target_arch` as one
value. This should cut down on the number of `#[cfg]` annotations necessary and
all around be a little more ergonomic.
bors [Tue, 2 Feb 2016 14:00:50 +0000 (14:00 +0000)]
Auto merge of #31254 - tmiasko:macro-pretty-print-fix, r=sfackler
Pretty printing of macro with braces but without terminated semicolon
removed more boxes from stack than it put there, resulting in panic.
This fixes the issue #30731.
Steve Klabnik [Tue, 2 Feb 2016 05:32:20 +0000 (00:32 -0500)]
Rollup merge of #31348 - alexcrichton:shuffle-tiers, r=steveklabnik
Some other shufflings as well:
* Three powerpc triples for Linux have been added recently
* An armv7 linux triple was added recently
* The 64-bit Solaris triple is now mentioned in tier 3
We are currently now also building nightlies for iOS, powerpc triples, and
armv7, but there hasn't been much vetting of the triples themselves so I've left
them in tier 3 for now.