Steve Klabnik [Tue, 2 Feb 2016 05:32:18 +0000 (00:32 -0500)]
Rollup merge of #31339 - rthomas:doc, r=alexcrichton
When trying to run a specific test, I found the contributing docs a bit confusing and through a bit of googling found out that TESTNAME takes the fully qual'd name of the test.
I'm unsure if this can also take the source file, but I was unable to get that to work.
Steve Klabnik [Tue, 2 Feb 2016 05:32:18 +0000 (00:32 -0500)]
Rollup merge of #31327 - dirk:dirk/process-child-safety-docs, r=alexcrichton
`Drop` is not implemented for `Child`, so if it goes out of scope in Rust-land and gets deallocated the child process will continue to exist and execute. If users want a guarantee that the process has finished running and exited they must manually use `kill`, `wait`, or `wait_with_output`.
Steve Klabnik [Tue, 2 Feb 2016 05:32:18 +0000 (00:32 -0500)]
Rollup merge of #31270 - ruud-v-a:improve-e0507, r=steveklabnik
E0507 can occur when you try to move out of a member of a mutably borrowed struct, in which case `mem::replace` can help. Mentioning that here hopefully saves future users a trip to Google.
Steve Klabnik [Tue, 2 Feb 2016 05:32:17 +0000 (00:32 -0500)]
Rollup merge of #30971 - SDX2000:docfixes, r=steveklabnik
Updated documentation to clarify the difference between `and_then` and `map`. This also explains why we need `and_then` in addition to `map`. Please look at the diff for more information.
bors [Mon, 1 Feb 2016 14:26:48 +0000 (14:26 +0000)]
Auto merge of #31317 - jseyfried:remove_external_module_children, r=nrc
This PR refactors away `Module`'s `external_module_children` and instead puts `extern crate` declarations in `children` like other items, simplifying duplicate checking and name resolution.
This PR also allows values to share a name with extern crates, which are only defined in the type namespace. Other than that, it is a pure refactoring.
bors [Mon, 1 Feb 2016 12:24:01 +0000 (12:24 +0000)]
Auto merge of #31303 - alexcrichton:mips-warnings, r=aturon
Currently any compilation to MIPS spits out the warning:
'generic' is not a recognized processor for this target (ignoring processor)
Doesn't make for a great user experience! We don't encounter this in the normal
bootstrap because the cpu/feature set are set by the makefiles. Instead let's
just propagate these to the defaults for the entire target all the time (still
overridable from the command line) and prevent warnings from being emitted by
default.
bors [Mon, 1 Feb 2016 04:52:12 +0000 (04:52 +0000)]
Auto merge of #30866 - jseyfried:fix_shadowed_use_visibility, r=nrc
This reverts PR #30324, fixing bug #30159 in which a public a glob import makes public any preceding imports that share a name with an item in the module being glob imported from.
For example,
```rust
pub fn f() {}
pub mod foo {
fn f() {}
}
mod bar {
use f;
use f as g;
pub use foo::*; // This makes the first import public but does not affect the second import.
}
```
bors [Sun, 31 Jan 2016 23:06:01 +0000 (23:06 +0000)]
Auto merge of #31331 - petevine:master, r=alexcrichton
The target was meant as a modern generic `armv7` option, therefore a few changes were necessary:
- gcc's `-march=armv7` was causing compilation failures on modern linux systems
- rust codegen defaulted to `cortex-a7` causing illegal instruction crashes on previous `armv7-a` processors (e.g, cortex-a5, cortex-a8)
Dirk Gadsden [Sun, 31 Jan 2016 19:50:22 +0000 (11:50 -0800)]
Safety docs about `std::process::Child` going out of scope
There is no `Drop` implemented for `Child`, so if it goes out
of scope in Rust-land and gets deallocated, the child process
will continue to exist and execute. If users want a guarantee
that the process has finished running and exited they must
manually use `kill`, `wait`, or `wait_with_output`.
bors [Sun, 31 Jan 2016 12:27:06 +0000 (12:27 +0000)]
Auto merge of #31298 - japaric:mips-musl, r=alexcrichton
This target covers MIPS devices that run the trunk version of OpenWRT.
The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.
As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.
bors [Sat, 30 Jan 2016 18:51:13 +0000 (18:51 +0000)]
Auto merge of #30778 - fhahn:issue-21195-expect-help, r=nikomatsakis
This is a PR for #21195. It changes the way unspecified `help` and `ǹote` messages are handled in compile-fail tests as suggested by @oli-obk in the issue: if there are some `note` or `help` annotations, there must be annotations for all `help` or `note` messages of this test. Maybe it makes also sense to add an option to specify that the this test should fail if there are unspecified `help` or `note` messages.
Rollup merge of #31292 - alexcrichton:osx-dtors-in-dtors-in-dtors, r=aturon
This test has been deadlocking and causing problems on the bots basically since
its inception. Some memory safety issues were fixed in 987dc84b, but the
deadlocks remained afterwards unfortunately.
After some investigation, I've concluded that this is just a situation where OSX
is not guaranteed to run destructors. The fix in 987dc84b observed that OSX was
rewriting the backing TLS memory to its initial state during destruction while
we weren't looking, and this would have the effect of canceling the destructors
of any other initialized TLS slots.
While very difficult to pin down, this is basically what I assume is happening
here, so there doesn't seem to really be anythig we can do to ensure the test
robustly passes on OSX, so just ignore it for now.
Rollup merge of #31280 - raindev:patch-1, r=steveklabnik
Perhaps, it makes more sense to link straight to [Installing on Linux or Mac](https://doc.rust-lang.org/book/getting-started.html#installing-on-linux-or-mac) and [Installing on Windows](https://doc.rust-lang.org/book/getting-started.html#installing-on-windows) sections. Platform Support section could be skipped in case of *quick* start.
bors [Sat, 30 Jan 2016 10:16:55 +0000 (10:16 +0000)]
Auto merge of #30843 - jseyfried:no_per_ns, r=nikomatsakis
This commit refactors the field `Module::children` from mapping `Name` -> `NameBindings` to mapping `(Name, Namespace)` -> `NameBinding` and refactors the field `Module::import_resolutions` from mapping `Name` -> `ImportResolutionPerNamespace` to mapping `(Name, Namespace)` -> `ImportResolution`.
This allows the duplicate checking code to be refactored so that `NameBinding` no longer needs ref-counting or a RefCell (removing the need for `NsDef`).
Alex Crichton [Sat, 30 Jan 2016 07:44:46 +0000 (23:44 -0800)]
rustc: Set MIPS cpu/features in the compiler
Currently any compilation to MIPS spits out the warning:
'generic' is not a recognized processor for this target (ignoring processor)
Doesn't make for a great user experience! We don't encounter this in the normal
bootstrap because the cpu/feature set are set by the makefiles. Instead let's
just propagate these to the defaults for the entire target all the time (still
overridable from the command line) and prevent warnings from being emitted by
default.
bors [Sat, 30 Jan 2016 00:25:44 +0000 (00:25 +0000)]
Auto merge of #30448 - alexcrichton:llvmup, r=nikomatsakis
These commits perform a few high-level changes with the goal of enabling i686 MSVC unwinding:
* LLVM is upgraded to pick up the new exception handling instructions and intrinsics for MSVC. This puts us somewhere along the 3.8 branch, but we should still be compatible with LLVM 3.7 for non-MSVC targets.
* All unwinding for MSVC targets (both 32 and 64-bit) are implemented in terms of this new LLVM support. I would like to also extend this to Windows GNU targets to drop the runtime dependencies we have on MinGW, but I'd like to land this first.
* Some tests were fixed up for i686 MSVC here and there where necessary. The full test suite should be passing now for that target.
In terms of landing this I plan to have this go through first, then verify that i686 MSVC works, then I'll enable `make check` on the bots for that target instead of just `make` as-is today.
Alex Crichton [Sat, 24 Oct 2015 01:18:44 +0000 (18:18 -0700)]
trans: Reimplement unwinding on MSVC
This commit transitions the compiler to using the new exception handling
instructions in LLVM for implementing unwinding for MSVC. This affects both 32
and 64-bit MSVC as they're both now using SEH-based strategies. In terms of
standard library support, lots more details about how SEH unwinding is
implemented can be found in the commits.
In terms of trans, this change necessitated a few modifications:
* Branches were added to detect when the old landingpad instruction is used or
the new cleanuppad instruction is used to `trans::cleanup`.
* The return value from `cleanuppad` is not stored in an `alloca` (because it
cannot be).
* Each block in trans now has an `Option<LandingPad>` instead of `is_lpad: bool`
for indicating whether it's in a landing pad or not. The new exception
handling intrinsics require that on MSVC each `call` inside of a landing pad
is annotated with which landing pad that it's in. This change to the basic
block means that whenever a `call` or `invoke` instruction is generated we
know whether to annotate it as part of a cleanuppad or not.
* Lots of modifications were made to the instruction builders to construct the
new instructions as well as pass the tagging information for the call/invoke
instructions.
* The translation of the `try` intrinsics for MSVC has been overhauled to use
the new `catchpad` instruction. The filter function is now also a
rustc-generated function instead of a purely libstd-defined function. The
libstd definition still exists, it just has a stable ABI across architectures
and leaves some of the really weird implementation details to the compiler
(e.g. the `localescape` and `localrecover` intrinsics).
Alex Crichton [Fri, 23 Oct 2015 05:07:19 +0000 (22:07 -0700)]
trans: Upgrade LLVM
This brings some routine upgrades to the bundled LLVM that we're using, the most
notable of which is a bug fix to the way we handle range asserts when loading
the discriminant of an enum. This fix ended up being very similar to f9d4149c
where we basically can't have a range assert when loading a discriminant due to
filling drop, and appropriate flags were added to communicate this to
`trans::adt`.
Jorge Aparicio [Mon, 25 Jan 2016 21:23:31 +0000 (16:23 -0500)]
add support for mips(el)-unknown-linux-musl
This target covers MIPS devices that run the trunk version of OpenWRT.
The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.
As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.
Alex Crichton [Fri, 29 Jan 2016 21:46:47 +0000 (13:46 -0800)]
std: Ignore dtors_in_dtors_in_dtors on OSX
This test has been deadlocking and causing problems on the bots basically since
its inception. Some memory safety issues were fixed in 987dc84b, but the
deadlocks remained afterwards unfortunately.
After some investigation, I've concluded that this is just a situation where OSX
is not guaranteed to run destructors. The fix in 987dc84b observed that OSX was
rewriting the backing TLS memory to its initial state during destruction while
we weren't looking, and this would have the effect of canceling the destructors
of any other initialized TLS slots.
While very difficult to pin down, this is basically what I assume is happening
here, so there doesn't seem to really be anythig we can do to ensure the test
robustly passes on OSX, so just ignore it for now.
bors [Fri, 29 Jan 2016 20:58:09 +0000 (20:58 +0000)]
Auto merge of #31283 - dotdash:32_64_cc, r=alexcrichton
When cross compiling for a target that has a larger usize type than the
host system, we use a truncated value to mark data as dropped,
eventually leading to drop calls on already dropped data. To properly
handle this, the drop pattern needs to be of type u64.
Since C_integral truncates its given value to the requested size anyway,
we can also drop the function that chose between the u32 and u64 values,
and always use the u64 constant.
Alex Crichton [Fri, 29 Jan 2016 20:36:45 +0000 (12:36 -0800)]
mk: Fix cross-compiling to armv7-unknown-linux-gnu
The cross prefix was not likely the actual compiler that needed to be used, but
rather the standard `arm-linux-gnueabihf-gcc` compiler can just be used with
`-march=armv7`.
Rollup merge of #31275 - alexcrichton:fix-rumprun, r=brson
Looks like the rumprun build has bitrotted over time, so this includes some libc
fixes and some various libstd fixes which gets it back to bootstrapping.
Rollup merge of #31264 - est31:block_coment_parent, r=alexcrichton
Block comments don't have to be in the format `/*! ... !*/`
in order to be read as doc comments about the parent block.
The format `/*! ... */` is enough.
Rollup merge of #31252 - alexcrichton:ios-old-mac, r=brson
Unfortunately older clang compilers don't support this argument, so the
bootstrap will fail. We don't actually really need to optimized the C code we
compile, however, as currently we're just compiling jemalloc and not much else.
bors [Fri, 29 Jan 2016 13:45:03 +0000 (13:45 +0000)]
Auto merge of #31212 - jseyfried:fix_ICE_in_resolve, r=nrc
This fixes an ICE introduced by #31065 that occurs when a path cannot be resolved because of a certain class of unresolved import (`Indeterminate` imports).
For example, this currently causes an ICE:
```rust
mod foo { pub use self::*; }
fn main() { foo::f() }
```
Björn Steinbrink [Thu, 28 Jan 2016 20:54:09 +0000 (21:54 +0100)]
Fix truncated drop pattern on 32bit -> 64bit cross compilation
When cross compiling for a target that has a larger usize type than the
host system, we use a truncated value to mark data as dropped,
eventually leading to drop calls on already dropped data. To properly
handle this, the drop pattern needs to be of type u64.
Since C_integral truncates its given value to the requested size anyway,
we can also drop the function that chose between the u32 and u64 values,
and always use the u64 constant.
bors [Fri, 29 Jan 2016 11:21:58 +0000 (11:21 +0000)]
Auto merge of #31144 - jseyfried:remove_import_ordering_restriction, r=nrc
We no longer require `use` and `extern crate` items to precede other items in modules thanks to [RFC #385](https://github.com/rust-lang/rfcs/pull/385), but we still require `use` and `extern crate` items to precede statements in blocks (other items can appear anywhere in a block).
I think that this is a needless distinction between imports and other items that contradicts the intent of the RFC.