Alex Crichton [Thu, 25 Feb 2016 07:50:32 +0000 (23:50 -0800)]
rustbuild: Add steps for linking a sysroot
When cross compiling for a new host, we can't actually run the host compiler to
generate its own libs. In theory, however, all stage2 compilers (for any host)
will produce the same libraries, so we just require the build compiler to
produce the necessary host libraries and then we link those into place.
Alex Crichton [Thu, 25 Feb 2016 03:04:35 +0000 (19:04 -0800)]
rustbuild: Compile with the build compiler
This switches the defaults to ensure that everything is built with the build
compiler rather than the host compiler itself (which we're not guaranteed to be
able to run)
Alex Crichton [Thu, 25 Feb 2016 01:09:17 +0000 (17:09 -0800)]
rustbuild: Enable cross-compiling LLVM
Currently all multi-host builds assume the the build platform can run the
`llvm-config` binary generated for each host platform we're creating a compiler
for. Unfortunately this assumption isn't always true when cross compiling, so we
need to handle this case.
This commit alters the build script of `rustc_llvm` to understand when it's
running an `llvm-config` which is different than the platform we're targeting for.
Alex Crichton [Wed, 24 Feb 2016 07:00:48 +0000 (23:00 -0800)]
rustbuild: Enable bootstrapping new hosts
This commit fixes a longstanding issue with the makefiles where all host
platforms bootstrap themselves. This commit alters the build logic for the
bootstrap to instead only bootstrap the build triple, and all other compilers
are compiled from that one compiler.
The benefit of this change is that we can cross-compile compilers which cannot
run on the build platform. For example our builders could start creating
`arm-unknown-linux-gnueabihf` compilers.
This reduces the amount of bootstrapping we do, reducing the amount of test
coverage, but overall it should largely just end in faster build times for
multi-host compiles as well as enabling a feature which can't be done today.
bors [Sat, 27 Feb 2016 20:26:59 +0000 (20:26 +0000)]
Auto merge of #31931 - Luke-Nukem:master, r=steveklabnik
Refinement of paragraph referenced by [this issue](https://github.com/rust-lang/rust/issues/31927).
The paragraph in question had been adjusted already, but I've made some further clarifications which should help with readability and not leave the reader any `dangling pointers`.
bors [Sat, 27 Feb 2016 06:58:28 +0000 (06:58 +0000)]
Auto merge of #31926 - llogiq:more_post, r=eddyb
These `_post` methods are quite helpful to control lint behavior without storing e.g. block node ids. So here are a few more I believe will be helpful.
mitaa [Fri, 26 Feb 2016 16:19:35 +0000 (17:19 +0100)]
Clearly separate code blocks from other blocks
For summary descriptions we need the first paragraph (adjacent lines
until a blank line) - but the rendered markdown of a code block did not
leave a blank line in the html and was thus included in the summary line.
Rollup merge of #31930 - miqid:doc, r=steveklabnik
Hello.
I've added links for items inside of some stable methods for consistency with existing ones that already have them. Also includes minor formatting fixes.
Rollup merge of #31929 - dotdash:less_rallocx, r=alexcrichton
When foldings Substs, we map over VecPerParamSpace instances using
EnumeratedItems which does not provide an accurate size_hint()
in its Iterator implementation. This leads to quite a large number or
reallocations. Providing a suitable size_hint() implementation reduces
the time spent in item-bodies checking quite a bit.
Rollup merge of #31926 - llogiq:more_post, r=eddyb
These `_post` methods are quite helpful to control lint behavior without storing e.g. block node ids. So here are a few more I believe will be helpful.
bors [Sat, 27 Feb 2016 01:15:23 +0000 (01:15 +0000)]
Auto merge of #31914 - bluss:copy-from-slice-everywhere, r=alexcrichton
Use .copy_from_slice() where applicable
.copy_from_slice() does the same job of .clone_from_slice(), but the
former is explicitly for Copy elements and calls `memcpy` directly, and
thus is it efficient without optimization too.
Björn Steinbrink [Fri, 26 Feb 2016 23:53:33 +0000 (00:53 +0100)]
Avoid excessive reallocations during item-bodies checking
When foldings Substs, we map over VecPerParamSpace instances using
EnumeratedItems which does not provide an accurate size_hint()
in its Iterator implementation. This leads to quite a large number or
reallocations. Providing a suitable size_hint() implementation reduces
the time spent in item-bodies checking quite a bit.
bors [Fri, 26 Feb 2016 15:42:44 +0000 (15:42 +0000)]
Auto merge of #31858 - alexcrichton:fix-networking-cast, r=brson
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`.
Ulrik Sverdrup [Tue, 23 Feb 2016 18:25:43 +0000 (19:25 +0100)]
Use .copy_from_slice() where applicable
.copy_from_slice() does the same job of .clone_from_slice(), but the
former is explicitly for Copy elements and calls `memcpy` directly, and
thus is it efficient without optimization too.
bors [Fri, 26 Feb 2016 13:38:46 +0000 (13:38 +0000)]
Auto merge of #31846 - alexcrichton:better-disable-jemallc, r=brson
The `--disable-jemalloc` configure option has a failure mode where it will
create a distribution that is not compatible with other compilers. For example
the nightly for Linux will assume that it will link to jemalloc by default as
an allocator for executable crates. If, however, a standard library is used
which was built via `./configure --disable-jemalloc` then this will fail
because the jemalloc crate wasn't built.
While this seems somewhat reasonable as a niche situation, the same mechanism is
used for disabling jemalloc for platforms that just don't support it. For
example if the rumprun target is compiled then the sibiling Linux target *also*
doesn't have jemalloc. This is currently a problem for our cross-build nightlies
which build many targets. If rumprun is also built, it will disable jemalloc for
all targets, which isn't desired.
This commit moves the platform-specific disabling of jemalloc as hardcoded logic
into the makefiles that is scoped per-platform. This way when configuring
multiple targets **without the `--disable-jemalloc` option specified** all
targets will get jemalloc as they should.
Rollup merge of #31904 - bluss:writer-formatter-error, r=alexcrichton
Make sure formatter errors are emitted by the default Write::write_fmt
Previously, if an error was returned from the formatter that did not
originate in an underlying writer error, Write::write_fmt would return
successfully even if the formatting did not complete (was interrupted by
an `fmt::Error` return).
Now we choose to emit an io::Error with kind Other for formatter errors.
Since this may reveal error returns from `write!()` and similar that
previously passed silently, it's a kind of a [breaking-change].
Alex Crichton [Mon, 8 Feb 2016 18:57:41 +0000 (10:57 -0800)]
mk: Move disable-jemalloc logic into makefiles
The `--disable-jemalloc` configure option has a failure mode where it will
create a distribution that is not compatible with other compilers. For example
the nightly for Linux will assume that it will link to jemalloc by default as
an allocator for executable crates. If, however, a standard library is used
which was built via `./configure --disable-jemalloc` then this will fail
because the jemalloc crate wasn't built.
While this seems somewhat reasonable as a niche situation, the same mechanism is
used for disabling jemalloc for platforms that just don't support it. For
example if the rumprun target is compiled then the sibiling Linux target *also*
doesn't have jemalloc. This is currently a problem for our cross-build nightlies
which build many targets. If rumprun is also built, it will disable jemalloc for
all targets, which isn't desired.
This commit moves the platform-specific disabling of jemalloc as hardcoded logic
into the makefiles that is scoped per-platform. This way when configuring
multiple targets **without the `--disable-jemalloc` option specified** all
targets will get jemalloc as they should.
bors [Fri, 26 Feb 2016 04:38:28 +0000 (04:38 +0000)]
Auto merge of #31857 - jseyfried:fix_scoping, r=nikomatsakis
This fixes a bug (#31845) introduced in #31105 in which lexical scopes contain items from all anonymous module ancestors, even if the path to the anonymous module includes a normal module:
```rust
fn f() {
fn g() {}
mod foo {
fn h() {
g(); // This erroneously resolves on nightly
}
}
}
```
This is a [breaking-change] on nightly but not on stable or beta.
r? @nikomatsakis
Ulrik Sverdrup [Fri, 26 Feb 2016 01:53:47 +0000 (02:53 +0100)]
Make sure formatter errors are emitted by the default Write::write_fmt
Previously, if an error was returned from the formatter that did not
originate in an underlying writer error, Write::write_fmt would return
successfully even if the formatting did not complete (was interrupted by
an `fmt::Error` return).
Now we choose to emit an io::Error with kind Other for formatter errors.
Since this may reveal error returns from `write!()` and similar that
previously passed silently, it's a kind of a [breaking-change].
bors [Fri, 26 Feb 2016 00:53:38 +0000 (00:53 +0000)]
Auto merge of #31749 - nikomatsakis:compiletest-subdir, r=alexcrichton
You can now group tests into directories like `run-pass/borrowck` or `compile-fail/borrowck`. By default, all `.rs` files within any directory are considered tests: to ignore some directory, create a placeholder file called `compiletest-ignore-dir` (I had to do this for several existing directories).
Rollup merge of #31800 - alexcrichton:armv6-plz, r=brson
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.
Rollup merge of #31793 - alexcrichton:add-real-option-gating, r=nikomatsakis
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.
Rollup merge of #31362 - jseyfried:fix_extern_crate_visibility, r=nikomatsakis
This PR changes the visibility of extern crate declarations to match that of items (fixes #26775).
To avoid breakage, the PR makes it a `public_in_private` lint to reexport a private extern crate, and it adds the lint `inaccessible_extern_crate` for uses of an inaccessible extern crate.
The lints can be avoided by making the appropriate `extern crate` declaration public.
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 :-)