bors [Mon, 22 Feb 2016 05:20:39 +0000 (05:20 +0000)]
Auto merge of #31811 - alexcrichton:clean-deps, r=sanxiyn
The standard library doesn't depend on rustc_bitflags, so move it to explicit
dependencies on all other crates. Additionally, the arena/fmt_macros deps could
be dropped from libsyntax.
bors [Mon, 22 Feb 2016 03:08:39 +0000 (03:08 +0000)]
Auto merge of #31805 - cuviper:android-lfs, r=alexcrichton
Android should use 64-bit LFS symbols for `lseek` and `ftruncate`, lest
those offset parameters suffer a lossy cast down to a 32-bit `off_t`.
Unlike GNU/Linux, Android's `stat`, `dirent`, and related functions are
always 64-bit LFS compatible, and `open` already implies `O_LARGEFILE`,
so all those don't need to follow Linux. It might be nice to unify them
anyway, but those other LFS symbols aren't present in API 18 bionic.
bors [Sun, 21 Feb 2016 23:08:24 +0000 (23:08 +0000)]
Auto merge of #31810 - gandro:netbsd-fix-stat, r=alexcrichton
Some struct members have a slighty different name on NetBSD. This has been fixed in the libc crate, but not in libstd, breaking the NetBSD build. Related C struct definition: http://nxr.netbsd.org/xref/src/sys/sys/stat.h?r=1.68#59
This also removes the broken `st_spare()` from MetadataExt, since it is private field reserved for future use.
@dhuseby In case this conflicts with any of your pending patches, feel free to intervene - I'm happy to withdraw this PR.
bors [Sun, 21 Feb 2016 19:24:02 +0000 (19:24 +0000)]
Auto merge of #31792 - Zoxc:sysroot, r=alexcrichton
With these changes you can build a freestanding sysroot without using floating points using a Cargo.toml and copying the `deps` folder cargo outputs.
```
[package]
name = "sysroot"
version = "0.1.0"
[lib]
path = "lib.rs"
crate-type = ["rlib"]
[dependencies.core]
path = "../vendor/rust/src/src/libcore"
features = ["disable_float"]
Alex Crichton [Sun, 21 Feb 2016 17:49:13 +0000 (09:49 -0800)]
rustbuild: Sync some Cargo.toml/lib.rs dependencies
The standard library doesn't depend on rustc_bitflags, so move it to explicit
dependencies on all other crates. Additionally, the arena/fmt_macros deps could
be dropped from libsyntax.
Josh Stone [Sun, 21 Feb 2016 09:04:14 +0000 (01:04 -0800)]
std: Use Android LFS off64_t, ftruncate64, and lseek64
Android should use 64-bit LFS symbols for `lseek` and `ftruncate`, lest
those offset parameters suffer a lossy cast down to a 32-bit `off_t`.
Unlike GNU/Linux, Android's `stat`, `dirent`, and related functions are
always 64-bit LFS compatible, and `open` already implies `O_LARGEFILE`,
so all those don't need to follow Linux. It might be nice to unify them
anyway, but those other LFS symbols aren't present in API 18 bionic.
Alex Crichton [Sun, 21 Feb 2016 02:19:32 +0000 (18:19 -0800)]
mk: Specify armv6 for gcc on arm-unknown-linux-*
Right now the compiler's we're using actually default to armv7/thumb2 I believe,
so this should help push them back to what the arm-unknown-linux-* targets are
for. This at least matches that clang does for the `arm-unknown-linux-gnueabihf`
target which is to map it to an armv6 architecture.
bors [Sun, 21 Feb 2016 00:56:08 +0000 (00:56 +0000)]
Auto merge of #31761 - Amanieu:volatile, r=alexcrichton
Tracking issue: #31756
RFC: rust-lang/rfcs#1467
I've made these unstable for now. Should they be stabilized straight away since we've had plenty of experience with people using the unstable intrinsics?
bors [Sat, 20 Feb 2016 20:33:33 +0000 (20:33 +0000)]
Auto merge of #31757 - petrochenkov:unitdotdot, r=nikomatsakis
This warning was introduced on Nov 28, 2015 and got into 1.6 stable, it was later requalified from a hardwired warning to a warn-by-default lint.
If this patch is landed soon enough, then `match_of_unit_variant_via_paren_dotdot` will get into 1.8 stable as a deny-by-default lint.
My intention is to turn it into a hard error after March 3, 2016, then it will hit stable at 1.9.
bors [Sat, 20 Feb 2016 14:33:13 +0000 (14:33 +0000)]
Auto merge of #31747 - jseyfried:stop_resolve_after_fail, r=nrc
Now that #31461 is merged, a failing resolution can never become indeterminate or succeed, so we no longer have to keep trying to resolve failing import directives.
r? @nrc
bors [Sat, 20 Feb 2016 10:40:42 +0000 (10:40 +0000)]
Auto merge of #31674 - VladUreche:issue/21221, r=nikomatsakis
This commit adds functionality that allows the name resolution pass
to search for entities (traits/types/enums/structs) by name, in
order to show recommendations along with the errors.
For now, only E0405 and E0412 have suggestions attached, as per the
request in bug #21221, but it's likely other errors can also benefit
from the ability to generate suggestions.
bors [Sat, 20 Feb 2016 02:52:01 +0000 (02:52 +0000)]
Auto merge of #31771 - alexcrichton:oops-that-didnt-fix-anything, r=brson
In #31717 we rebased our LLVM fork over the 3.8 release branch, and it was
thought that this fixed #31702. The testing, however, must have been erroneous,
as it unfortunately didn't fix the issue! Our MUSL nightly builders are failing
from the same assertion reported in the issue, so we at least know the test case
is a reproduction!
I believe the failure is only happening on the MUSL nightly builders because
none of the auto builders have LLVM assertions enabled, and the Linux nightly
builder *does* have assertions enabled for the binaries we generate but the
distcheck run doesn't test a compiler with LLVM assertions enabled.
bors [Sat, 20 Feb 2016 00:58:49 +0000 (00:58 +0000)]
Auto merge of #31781 - alexcrichton:wtf-segfault, r=aturon
It's unclear to me whether this test failing under valgrind is actually legit.
The test only fails in valgrind when everything is dynamically linked, and it
appears to work when statically linked.
For now just add the `// no-prefer-dynamic` directive and let's just chalk it up
to a weird valgrind issue.
Alex Crichton [Sat, 20 Feb 2016 00:53:06 +0000 (16:53 -0800)]
test: Fix a spuriously failing test on valgrind
It's unclear to me whether this test failing under valgrind is actually legit.
The test only fails in valgrind when everything is dynamically linked, and it
appears to work when statically linked.
For now just add the `// no-prefer-dynamic` directive and let's just chalk it up
to a weird valgrind issue.
Alex Crichton [Fri, 19 Feb 2016 06:47:42 +0000 (22:47 -0800)]
Ignore the test added in #31717
In #31717 we rebased our LLVM fork over the 3.8 release branch, and it was
thought that this fixed #31702. The testing, however, must have been erroneous,
as it unfortunately didn't fix the issue! Our MUSL nightly builders are failing
from the same assertion reported in the issue, so we at least know the test case
is a reproduction!
I believe the failure is only happening on the MUSL nightly builders because
none of the auto builders have LLVM assertions enabled, and the Linux nightly
builder *does* have assertions enabled for the binaries we generate but the
distcheck run doesn't test a compiler with LLVM assertions enabled.
Vlad Ureche [Sun, 14 Feb 2016 01:47:27 +0000 (02:47 +0100)]
Show candidates for names not in scope
This commit adds functionality that allows the name resolution pass
to search for entities (traits/types/enums/structs) by name, in
order to show recommendations along with the errors.
For now, only E0405 and E0412 have suggestions attached, as per the
request in bug #21221, but it's likely other errors can also benefit
from the ability to generate suggestions.
bors [Thu, 18 Feb 2016 16:29:55 +0000 (16:29 +0000)]
Auto merge of #31734 - aliclark:bsd-stat-fixes, r=alexcrichton
In https://github.com/rust-lang/rust/issues/25155 the os::freebsd::raw stat was split for the x86 vs. x86-64 cases, which appears to have been done to implement the padding on the end of struct stat for the x86 case (the struct is otherwise the same notwistanding the size of long).
This PR de-duplicates the struct using #[cfg(target_arch = "x86")] for the __unused field, which also fixes the definitions which had sinced changed with the LFS work d088b671872f1df6993ccca6fa6139ebed0a8cf3.
Also changed definitions to c_long for dragonfly and freebsd where appropriate.
Also removes some unused imports that the compiler was complaining about.
freebsd's long time_t:
https://svnweb.freebsd.org/base/release/10.1.0/sys/x86/include/_types.h?view=markup
https://github.com/rust-lang/rust/blob/d088b671872f1df6993ccca6fa6139ebed0a8cf3/src/liblibc/lib.rs#L980
freebsd's padding for i686 stat:
https://svnweb.freebsd.org/base/release/10.1.0/sys/sys/stat.h?view=markup#l139
https://github.com/rust-lang/rust/blob/d088b671872f1df6993ccca6fa6139ebed0a8cf3/src/liblibc/lib.rs#L1038
bors [Thu, 18 Feb 2016 07:35:49 +0000 (07:35 +0000)]
Auto merge of #31727 - semarie:openbsd-llvm-cpu, r=alexcrichton
The initial purpose is to workaround the LLVM bug
https://llvm.org/bugs/show_bug.cgi?id=26554 for OpenBSD.
By default, the `cpu` is defined to `generic`. But with a 64bit
processor, the optimization for `generic` will use invalid asm code as
NOP (the generated code for NOP isn't a NOP).
According to #20777, "x86-64" is the right thing to do for x86_64
builds.
bors [Thu, 18 Feb 2016 03:35:21 +0000 (03:35 +0000)]
Auto merge of #31641 - petrochenkov:reach, r=alexcrichton
Fixes https://github.com/rust-lang/rust/issues/16734 and probably some other issues
This is a continuation of https://github.com/rust-lang/rust/pull/29822, but the algorithm is mostly a copy of https://github.com/rust-lang/rust/pull/29973, so
r? @alexcrichton or @nikomatsakis