Rollup merge of #35874 - CensoredUsername:stmt_let_typed_fix, r=Manishearth
This commit makes the return type of AstBuilder.stmt_let_typed match the return type of other AstBuilder.stmt* functions. This avoids unnecessary boxing/unboxing whenever Stmt's are stored in a Vec, which is the default use case.nnThis is a potentially plugin breaking change.
Rollup merge of #36877 - solson:rustc-version-build-issue, r=eddyb
Fix RUSTC_VERSION for 'documenting' build stage.
Previously the `env!("RUSTC_VERSION")` requirement would break the "Documenting rustc_metadata" stage of the rustc build, since that environment variable is only defined during the main build.
bors [Sat, 1 Oct 2016 02:00:36 +0000 (19:00 -0700)]
Auto merge of #36339 - brson:emscripten-new, r=alexcrichton
Working asmjs and wasm targets
This patch set results in a working standard library for the asmjs-unknown-emscripten and wasm32-unknown-emscripten targets. It is based on the work of @badboy and @rschulman.
It does a few things:
- Updates LLVM with the emscripten [fastcomp](https://github.com/rust-lang/llvm/pull/50) patches, which include the pnacl IR legalizer and the asm.js backend. This patch is thought not to have any significant effect on existing targets.
- Teaches rustbuild to correctly link C code with emscripten
- Updates gcc-rs to work correctly with emscripten
- Teaches rustbuild to run crate tests for emscripten with node
- Modifies Thread::new to return an error on emscripten, to facilitate debugging a common failure mode
- Modifies libtest to run in single-threaded mode for emscripten
- Ignores a host of tests that don't work yet, mostly dealing with threads and I/O
- Updates libc with wasm32 definitions (presently the same as asmjs)
- Adds a wasm32-unknown-emscripten target that feeds the output of LLVM's asmjs backend through emcc to generate wasm
Notes and caveats:
- This is only known to work with `--enable-rustbuild`.
- The wasm32 target can't be tested correctly yet because of issues in compiletest and limitations in node https://github.com/kripken/emscripten/issues/4542, but hello.rs does seem to work when run on node via the binaryen interpreter
- This requires an up to date installation of the emscripten sdk from its incoming branch
- Unwinding is very broken
- When enabling the emscripten targets jemalloc is disabled for all targets, which results in test failures for the host
Next steps are to fix the jemalloc issue, start building the two emscripten targets on the auto builders, then start producing nightlies.
https://github.com/rust-lang/rust/issues/36317 tracks work on this.
Auto merge of #36866 - alexcrichton:fix-hash-again, r=eddyb
rustc: More fixes for arch-independent hashing
In another attempt to fix #36793 this commit attempts to head off any future
problems by adding a custom `WidentUsizeHasher` which will widen any hashing of
`isize` and `usize` to a `u64` as necessary. This obviates the need for a
previous number of `as u64` annotations and will hopefully protect us against
future problems here.
Scott Olson [Fri, 30 Sep 2016 22:24:50 +0000 (16:24 -0600)]
Fix RUSTC_VERSION for 'documenting' build stage.
Previously the `env!("RUSTC_VERSION")` requirement would break the
"Documenting rustc_metadata" stage of the rustc build, since that
environment variable is only defined during the main build.
Alex Crichton [Fri, 30 Sep 2016 18:06:51 +0000 (11:06 -0700)]
rustc: More fixes for arch-independent hashing
In another attempt to fix #36793 this commit attempts to head off any future
problems by adding a custom `WidentUsizeHasher` which will widen any hashing of
`isize` and `usize` to a `u64` as necessary. This obviates the need for a
previous number of `as u64` annotations and will hopefully protect us against
future problems here.
Brian Anderson [Tue, 27 Sep 2016 21:27:22 +0000 (21:27 +0000)]
Build a dummy alloc_jemalloc crate on platforms that don't support it
This is a hack to support building targets that don't support jemalloc
alongside hosts that do. The jemalloc build is controlled by a feature
of the std crate, and if that feature changes between targets, it
invalidates the fingerprint of std's build script (this is a cargo
bug); so we must ensure that the feature set used by std is the same
across all targets, which means we have to build the alloc_jemalloc
crate for targets like emscripten, even if we don't use it.
Steve Klabnik [Fri, 30 Sep 2016 17:44:46 +0000 (13:44 -0400)]
Rollup merge of #36711 - pcn:patch-1, r=steveklabnik
Suggesting a change to a comment that puzzled me
While reading this, the comment made it difficult for me to simply absorb the concept. It interrupted my reading flow, and I think this expresses the same meaning, but reads a bit better. It's trivial, but makes it easier for me to move on to the next line.
Auto merge of #36823 - durka:discriminant_value, r=nagisa
add wrapper for discriminant_value, take 2
[This is #34785 reopened, since @bors apparently gave up on that thread.]
add wrapper for discriminant_value intrinsic
Implementation of [RFC 1696](https://github.com/rust-lang/rfcs/blob/master/text/1696-discriminant.md).
Wraps the `discriminant_value` intrinsic under the name `std::mem::discriminant`. In order to avoid prematurely leaking information about the implementation of enums, the return value is an opaque type, generic over the enum type, which implements Copy, Clone, PartialEq, Eq, Hash, and Debug (notably not PartialOrd). There is currently no way to get the value out excepting printing the debug representation.
The wrapper is safe and can be stabilized soon as per discussion in #24263.
Auto merge of #36822 - Aatch:resolve-callee-expr, r=luqmana
Resolve the callee type in check_call before autoderef
If the callee type is an associated type, then it needs to be normalized
before trying to deref it. This matches the behaviour of
`check_method_call` for autoderef behaviour in calls.
Auto merge of #36557 - sfackler:fix-hashdos-docs, r=alexcrichton
Clean up hasher discussion on HashMap
* We never want to make guarantees about protecting against attacks.
* "True randomness" is not the right terminology to be using in this
context.
* There is significantly more nuance to the performance of SipHash than
"somewhat slow".
Auto merge of #36752 - jonas-schievink:vartmparg, r=eddyb
Move MIR towards a single kind of local
This PR modifies MIR to handle function arguments (`Arg`), user-defined variable bindings (`Var`), compiler-generated temporaries (`Tmp`), as well as the return value pointer equally. All of them are replaced with a single `Local` type, a few functions for iterating over different kinds of locals, and a way to get the kind of local we're dealing with (mainly used in the constant qualification/propagation passes).
~~I haven't managed to fix one remaining issue: A `StorageDead` not getting emitted for a variable (see the `TODO` in the test). If that's fixed, this is basically good to go.~~ Found the issue (an off-by-one error), fix incoming.
r? @eddyb for changes to constant qualification and propagation I'm not quite sure about
Andre Bogus [Mon, 12 Sep 2016 21:35:20 +0000 (23:35 +0200)]
impl {Add, AddAssign}<{str, Cow<str>}> for Cow<str>
This does not actually add anything that wasn't there, but is merely an
optimization for the given cases, which would have incurred additional
heap allocation for adding empty strings, and improving the ergonomics
of `Cow` with strings.
James Miller [Thu, 29 Sep 2016 04:07:03 +0000 (17:07 +1300)]
Resolve the callee type in check_call before autoderef
If the callee type is an associated type, then it needs to be normalized
before trying to deref it. This matches the behaviour of
`check_method_call` for autoderef behaviour in calls.
Jonathan Turner [Thu, 29 Sep 2016 03:21:52 +0000 (20:21 -0700)]
Rollup merge of #36794 - japaric:target-panic, r=alexcrichton
add a panic-strategy field to the target specification
Now a target can define its panic strategy in its specification. If a
user doesn't specify a panic strategy via the command line, i.e. '-C
panic', then the compiler will use the panic strategy defined by the
target specification.
Custom targets can pick their panic strategy via the "panic-strategy"
field of their target specification JSON file. If omitted in the
specification, the strategy defaults to "unwind".
closes #36647
---
I checked that compiling an executable for a custom target with "panic-strategy" set to "abort" doesn't need the "eh_personality" lang item and also that standard crates compiled for that custom target didn't contained undefined symbols to _Unwind_Resume. But this needs an actual unit test, any suggestion on how to test this?
Most of the noise in the diff is due to moving `PanicStrategy` from the `rustc` to the `rustc_back` crate.
projects / rust.git / log