Rollup merge of #31870 - ivan:filter-explain, r=steveklabnik
As a Rust newbie, I found the book's explanation for why the `filter` closure gets a reference very confusing, and tried to figure out why `filter` is somehow less consumptive than `map` -- but it isn't; that's controlled by `iter`/`into_iter`. I flailed around for a while until @habnabit explained it to me, and in retrospect it is quite obvious :-)
In MIR we previously tried to match `let x in { exprs; let y in { exprs; }}` with our data
structures which is rather unwieldy, espeicially because it requires some sort of recursion or
stack to process, while, a flat list of statements is enough – lets only relinquish their lifetime
at the end of the block (i.e. end of the list).
Hopefully the author caught all the cases. For the mir_dynamic_drops_3 test case the ratio of
memsets to other instructions is 12%. On the other hand we actually do not double drop for at least
the test cases provided anymore in MIR.
Alex Crichton [Sat, 20 Feb 2016 06:03:54 +0000 (22:03 -0800)]
rustc: Refactor how unstable flags are handled
This commit adds support for *truly* unstable options in the compiler, as well
as adding warnings for the start of the deprecation path of
unstable-but-not-really options. Specifically, the following behavior is now in
place for handling unstable options:
* As before, an unconditional error is emitted if an unstable option is passed
and the `-Z unstable-options` flag is not present. Note that passing another
`-Z` flag does not require passing `-Z unstable-options` as well.
* New flags added to the compiler will be in the `Unstable` category as opposed
to the `UnstableButNotReally` category which means they will unconditionally
emit an error when used on stable.
* All current flags are in a category where they will emit warnings when used
that the option will soon be a hard error.
Also as before, it is intended that `-Z` is akin to `#![feature]` in a crate
where it is required to unlock unstable functionality. A nightly compiler which
is used without any `-Z` flags should only be exercising stable behavior.
Alex Crichton [Wed, 24 Feb 2016 07:22:58 +0000 (23:22 -0800)]
std: Cap read/write limits on Windows networking
Similar to #31825 where the read/write limits were capped for files, this
implements similar limits when reading/writing networking types. On Unix this
shouldn't affect anything because the write size is already a `usize`, but on
Windows this will cap the read/write amounts to `i32::max_value`.
bors [Wed, 24 Feb 2016 07:21:44 +0000 (07:21 +0000)]
Auto merge of #31782 - pitdicker:clean_out_windows_c, r=alexcrichton
I am not entirely sure I have got everything right, but if it compiles it is ok probably...
I tested it with msvc x86_64 and gnu.
Somehow a lot of `EXCEPTION-*` constants are dead code when running test, no idea why.
I have put `#![cfg_attr(test, allow(dead_code))]` at the top for this.
bors [Wed, 24 Feb 2016 01:55:45 +0000 (01:55 +0000)]
Auto merge of #31855 - alexcrichton:fix-tidy, r=nikomatsakis
The MinGW-based Python implementations would automatically do this, but if we
want to use Python from the official downloads our usage of `/` instead of `\`
can wreak havoc. In a few select locations just use `os.path.normpath` do do the
conversions properly for us.
Alex Crichton [Wed, 24 Feb 2016 01:42:50 +0000 (17:42 -0800)]
mk: Tweak tidy script to work on Windows python
The MinGW-based Python implementations would automatically do this, but if we
want to use Python from the official downloads our usage of `/` instead of `\`
can wreak havoc. In a few select locations just use `os.path.normpath` do do the
conversions properly for us.
bors [Tue, 23 Feb 2016 14:09:35 +0000 (14:09 +0000)]
Auto merge of #31825 - ollie27:win_lfs, r=alexcrichton
`ReadFile` and `WriteFile` take a DWORD (u32) for the length argument
which was erroneously cast from a usize causing truncation. This meant
methods like `write_all` and `read_exact` would unexpectedly fail if
given a buffer 4 GiB or larger.
We can instead just ask for `u32::MAX` bytes if the given buffer is too
big.
bors [Tue, 23 Feb 2016 05:17:08 +0000 (05:17 +0000)]
Auto merge of #31814 - petevine:master, r=alexcrichton
The `vfp2` option was a leftover from `armv6` compatibility features of the original armhf target.
Gcc defaults to `vfp3`on `armv7` hard-float linux systems so we should make it the default for rustc too.
Oliver Middleton [Tue, 23 Feb 2016 00:04:24 +0000 (00:04 +0000)]
Fix reading/writing 4 GiB or larger files on Windows 64-bit
`ReadFile` and `WriteFile` take a DWORD (u32) for the length argument
which was erroneously cast from a usize causing truncation. This meant
methods like `write_all` and `read_exact` would unexpectedly fail if
given a buffer 4 GiB or larger.
We can instead just ask for `u32::MAX` bytes if the given buffer is too
big.
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.