kennytm [Fri, 2 Feb 2018 08:29:19 +0000 (16:29 +0800)]
Rollup merge of #47898 - Aaron1011:static-ref-nll, r=nikomatsakis Fix ICE when assigning references to a static mut with NLL is_unsafe_place only filters out statics in the rhs, not the lhs. Since it's possible to reach that 'Place::Static', we handle statics the same way as we do locals. Fixes #47789
kennytm [Fri, 2 Feb 2018 08:29:16 +0000 (16:29 +0800)]
Rollup merge of #47829 - estebank:break-in-for, r=cramertj Suggest removing value from `break` when invalid When attempting to use `break` with a value in a type of loop where it'd be invalid (any non-`loop`), suggest using `break` on its own. Close #34359.
bors [Fri, 2 Feb 2018 01:27:14 +0000 (01:27 +0000)]
Auto merge of #47102 - Diggsey:wasm-syscall, r=alexcrichton
Implement extensible syscall interface for wasm
Currently it's possible to run tests with the native wasm target, but it's not possible to tell whether they pass or to capture the output, because libstd throws away stdout, stderr and the exit code. While advanced libstd features should probably require more specific targets (eg. wasm-unknown-web) I think even the unknown target should at least support basic I/O.
Any solution is constrained by these factors:
- It must not be javascript specific
- There must not be too strong coupling between libstd and the host environment (because it's an "unknown" target)
- WebAssembly does not allow "optional" imports - all imports *must* be resolved.
- WebAssembly does not support calling the host environment through any channel *other* than imports.
The best solution I could find to these constraints was to give libstd a single required import, and implement a syscall-style interface through that import. Each syscall is designed such that a no-op implementation gives the most reasonable fallback behaviour. This means that the following import table would be perfectly valid:
```javascript
imports.env = { rust_wasm_syscall: function(index, data) {} }
```
Currently I have implemented these system calls:
- Read from stdin
- Write to stdout/stderr
- Set the exit code
- Get command line arguments
- Get environment variable
- Set environment variable
- Get time
It need not be extended beyond this set if being able to run tests for this target is the only goal.
edit:
As part of this PR I had to make a further change. Previously, the rust entry point would be automatically called when the webassembly module was instantiated. This was problematic because from the javascript side it was impossible to call exported functions, access program memory or get a reference to the instance.
To solve this, ~I changed the default behaviour to not automatically call the entry point, and added a crate-level attribute to regain the old behaviour. (`#![wasm_auto_run]`)~ I disabled this behaviour when building tests.
bors [Thu, 1 Feb 2018 07:33:35 +0000 (07:33 +0000)]
Auto merge of #47738 - nikomatsakis:issue-47139-master, r=arielb1
remove intercrate ambiguity hints
The scheme was causing overflows during coherence checking (e.g. #47139). This is sort of a temporary fix; the proper fix I think involves reworking trait selection in deeper ways.
cc @sgrif -- this *should* fix diesel
cc @qnighy -- I'd like to discuss you with alternative techniques for achieving the same end. =) Actually, it might be good to put some energy into refactoring traits first.
bors [Thu, 1 Feb 2018 04:47:46 +0000 (04:47 +0000)]
Auto merge of #47540 - Manishearth:suggestion, r=nrc
Add approximate suggestions for rustfix
This adds `span_approximate_suggestion()` that lets you emit a
suggestion marked as "non-machine applicable" in the JSON output. UI
users see no difference. This is for when rustc and clippy wish to
emit suggestions which will make sense to the reader (e.g. they may
have placeholders like `<type>`) but are not source-applicable, so that
rustfix/etc can ignore these.
warning: unused variable: `registrar`
--> /dev/null:0:1
|
|
= note: #[warn(unused_variables)] on by default
= note: to avoid this warning, consider using `_registrar` instead
```
The panic is due to the unused variable warning being spanned to `/dev/null:0:1`. When `render_source_line` subtracts 1 from the line number to look up the source line it panics due to underflow. Without debug assertions this would wrap and cause us to return a blank string instead.
Fix by explicitly testing for 0 and exiting early. I'm unsure how to automatically test this now that rust-lang/rust#46655 has been approved.
kennytm [Wed, 31 Jan 2018 08:36:17 +0000 (16:36 +0800)]
Rollup merge of #47890 - pftbest:no_trap, r=alexcrichton
[MSP430] Don't enable trap_unreachable option by default on msp.
Since MSP430 doesn't meaningfully support faulting on illegal
instructions, LLVM generates a call to abort() function instead
of a trap instruction. Such calls are 4 bytes long, and that is
too much overhead for such small target.
kennytm [Wed, 31 Jan 2018 08:36:15 +0000 (16:36 +0800)]
Rollup merge of #47889 - alexcrichton:wasm-hidden-by-default, r=cramertj
rustc: Add an option to default hidden visibility
This commit adds a new option to target specifictions to specify that symbols
should be "hidden" visibility by default in LLVM. While there are no existing
targets that take advantage of this the `wasm32-unknown-unknown` target will
soon start to use this visibility. The LLD linker currently interprets `hidden`
as "don't export this from the wasm module" which is what we want for 90% of our
functions. While the LLD linker does have a "export this symbol" argument which
is what we use for other linkers, it was also somewhat easier to do this change
instead which'll involve less arguments flying around. Additionally there's no
need for non-`hidden` visibility for most of our symbols!
This change should not immediately impact the wasm targets as-is, but rather
this is laying the foundations for soon integrating LLD as a linker for wasm
code.
kennytm [Wed, 31 Jan 2018 08:36:09 +0000 (16:36 +0800)]
Rollup merge of #47874 - jcowgill:mips-from_raw_os_error, r=dtolnay
std: use more portable error number in from_raw_os_error docs
On MIPS, error number 98 is not `EADDRINUSE` (it is `EPROTOTYPE`). To fix the resulting test failure this causes, use a more portable error number in the example documentation. `EINVAL` shold be more reliable because it was defined in the original Unix as 22 so hopefully most derivatives have defined it the same way.
Aaron Hill [Wed, 31 Jan 2018 02:44:35 +0000 (21:44 -0500)]
Fix ICE when assigning references to a static mut with NLL
is_unsafe_place only filters out statics in the rhs, not the lhs. Since
it's possible to reach that 'Place::Static', we handle statics the same
way as we do locals.
[MSP430] Don't enable trap_unreachable option by default on msp.
Since MSP430 doesn't meaningfully support faulting on illegal
instructions, LLVM generates a call to abort() function instead
of a trap instruction. Such calls are 4 bytes long, and that is
too much overhead for such small target.
Alex Crichton [Tue, 30 Jan 2018 19:54:07 +0000 (11:54 -0800)]
rustc: Add an option to default hidden visibility
This commit adds a new option to target specifictions to specify that symbols
should be "hidden" visibility by default in LLVM. While there are no existing
targets that take advantage of this the `wasm32-unknown-unknown` target will
soon start to use this visibility. The LLD linker currently interprets `hidden`
as "don't export this from the wasm module" which is what we want for 90% of our
functions. While the LLD linker does have a "export this symbol" argument which
is what we use for other linkers, it was also somewhat easier to do this change
instead which'll involve less arguments flying around. Additionally there's no
need for non-`hidden` visibility for most of our symbols!
This change should not immediately impact the wasm targets as-is, but rather
this is laying the foundations for soon integrating LLD as a linker for wasm
code.
James Cowgill [Tue, 23 Jan 2018 14:47:30 +0000 (14:47 +0000)]
std: use more portable error number in from_raw_os_error docs
On MIPS, error number 98 is not EADDRINUSE (it is EPROTOTYPE). To fix the
resulting test failure this causes, use a more portable error number in
the example documentation. EINVAL shold be more reliable because it was
defined in the original Unix as 22 so hopefully most derivatives have
defined it the same way.
kennytm [Tue, 30 Jan 2018 09:10:56 +0000 (17:10 +0800)]
Rollup merge of #47826 - gnzlbg:patch-2, r=alexcrichton
Whitelist v7 feature for ARM and AARCH64.
Needed for `v7` features in `coresimd`.
See https://github.com/rust-lang-nursery/stdsimd/blob/b2f7be24d5043a88427f9a5258ca9a51ede6d029/coresimd/src/arm/v7.rs#L40 which used to work but doesn't anymore.
kennytm [Tue, 30 Jan 2018 09:10:54 +0000 (17:10 +0800)]
Rollup merge of #47780 - varkor:cross-file-errors-line-col, r=estebank
Add line numbers and columns to error messages spanning multiple files
If an error message is emitted that spans several files, only the
primary file currently has line and column data attached. This is
useful information, even in files other than the one in which the error
occurs. We can often work out which line and column the error
corresponds to in other files — in this case it is helpful to add them
(in the case of ambiguity, the first relevant line/column is picked,
which is still helpful than none).
kennytm [Tue, 30 Jan 2018 09:10:49 +0000 (17:10 +0800)]
Rollup merge of #47603 - mark-i-m:markim_comments_0000, r=jseyfried
Run rustfmt and add doc comments to libsyntax/ext/tt/quoted.rs
I was already going to try to understand this code to try to implement rust-lang/rfcs#2298. I figured I would put that knowledge into comments and share... This PR contains _no changes_ to the code itself -- just formatting and comments.
I'm not sure what the best way to do this is. I plan to make more such PR for other files, but I figured it would have fewer conflicts if I do it file by file...
bors [Tue, 30 Jan 2018 08:23:41 +0000 (08:23 +0000)]
Auto merge of #45294 - petrochenkov:prioplus, r=nikomatsakis
syntax: Lower priority of `+` in `impl Trait`/`dyn Trait`
Now you have to write `Fn() -> (impl A + B)` instead of `Fn() -> impl A + B`, this is consistent with priority of `+` in trait objects (`Fn() -> A + B` means `(Fn() -> A) + B`).
To make this viable I changed the syntax to also permit `+` in return types in function declarations
```
fn f() -> dyn A + B { ... } // OK, don't have to write `-> (dyn A + B)`
// This is acceptable, because `dyn A + B` here is an isolated type and
// not part of a larger type with various operator priorities in play
// like `dyn A + B` in `Fn() -> dyn A + B` despite syntax similarities.
```
but you still have to use `-> (dyn A + B)` in function types and function-like trait object types (see this PR's tests for examples).
This can be a breaking change for code using `impl Trait` on nightly. The thing that is most likely to break is `&impl A + B`, it needs to be rewritten as `&(impl A + B)`.
cc https://github.com/rust-lang/rust/issues/34511 https://github.com/rust-lang/rust/issues/44662 https://github.com/rust-lang/rfcs/pull/438
This adds `span_approximate_suggestion()` that lets you emit a
suggestion marked as "approximate" in the JSON output. UI
users see no difference. This is for when rustc and clippy wish to
emit suggestions which will make sense to the reader (e.g. they may
have placeholders like `<type>`) but are not source-applicable, so that
rustfix/etc can ignore these.
bors [Mon, 29 Jan 2018 04:55:47 +0000 (04:55 +0000)]
Auto merge of #47730 - alexcrichton:multitrans, r=Mark-Simulacrum
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
Alex Crichton [Wed, 24 Jan 2018 16:22:34 +0000 (08:22 -0800)]
rustc: Split Emscripten to a separate codegen backend
This commit introduces a separately compiled backend for Emscripten, avoiding
compiling the `JSBackend` target in the main LLVM codegen backend. This builds
on the foundation provided by #47671 to create a new codegen backend dedicated
solely to Emscripten, removing the `JSBackend` of the main codegen backend in
the process.
A new field was added to each target for this commit which specifies the backend
to use for translation, the default being `llvm` which is the main backend that
we use. The Emscripten targets specify an `emscripten` backend instead of the
main `llvm` one.
There's a whole bunch of consequences of this change, but I'll try to enumerate
them here:
* A *second* LLVM submodule was added in this commit. The main LLVM submodule
will soon start to drift from the Emscripten submodule, but currently they're
both at the same revision.
* Logic was added to rustbuild to *not* build the Emscripten backend by default.
This is gated behind a `--enable-emscripten` flag to the configure script. By
default users should neither check out the emscripten submodule nor compile
it.
* The `init_repo.sh` script was updated to fetch the Emscripten submodule from
GitHub the same way we do the main LLVM submodule (a tarball fetch).
* The Emscripten backend, turned off by default, is still turned on for a number
of targets on CI. We'll only be shipping an Emscripten backend with Tier 1
platforms, though. All cross-compiled platforms will not be receiving an
Emscripten backend yet.
This commit means that when you download the `rustc` package in Rustup for Tier
1 platforms you'll be receiving two trans backends, one for Emscripten and one
that's the general LLVM backend. If you never compile for Emscripten you'll
never use the Emscripten backend, so we may update this one day to only download
the Emscripten backend when you add the Emscripten target. For now though it's
just an extra 10MB gzip'd.
bors [Sun, 28 Jan 2018 23:30:15 +0000 (23:30 +0000)]
Auto merge of #47663 - malbarbo:mips-crt-static, r=alexcrichton
Do not assume dynamic linking for musl/mips[el] targets
All musl targets except mips[el] assume static linking by default. This can be [confusing](https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084).
When the musl/mips[el] targets was [added](https://github.com/rust-lang/rust/pull/31298), dynamic linking was chosen because of binary size concerns, and probably also because libunwind [didn't](https://users.rust-lang.org/t/static-cross-compiled-binaries-arent-really-static/6084/8) supported mips.
Now that we have `crt-static` target-feature (the user can choose dynamic link for musl targets), and libunwind [6.0](https://github.com/llvm-mirror/libunwind/commits/release_60) add support to mips, we do not need to assume dynamic linking.
gnzlbg [Sun, 28 Jan 2018 17:50:03 +0000 (18:50 +0100)]
Whitelist v7 feature for ARM and AARCH64.
Needed for `v7` features in `coresimd`.
See https://github.com/rust-lang-nursery/stdsimd/blob/b2f7be24d5043a88427f9a5258ca9a51ede6d029/coresimd/src/arm/v7.rs#L40 which used to work but doesn't anymore.
bors [Sun, 28 Jan 2018 13:24:47 +0000 (13:24 +0000)]
Auto merge of #47794 - etaoins:fix-ice-on-const-eval-of-union-field, r=eddyb
Fix ICE on const eval of union field
MIR's `Const::get_field()` attempts to retrieve the value for a given field in a constant. In the case of a union constant it was falling through to a generic `const_get_elt` based on the field index. As union fields don't have an index this caused an ICE in `llvm_field_index`.
Fix by simply returning the current value when accessing any field in a union. This works because all union fields start at byte offset 0.
The added test uses `const_fn` it ensure the field is extracted using MIR's const evaluation. The crash is reproducible without it, however.
bors [Sun, 28 Jan 2018 03:40:26 +0000 (03:40 +0000)]
Auto merge of #47671 - alexcrichton:trans-c-api-only, r=Mark-Simulacrum
rustc: Load the `rustc_trans` crate at runtime
Building on the work of #45684 this commit updates the compiler to
unconditionally load the `rustc_trans` crate at runtime instead of linking to it
at compile time. The end goal of this work is to implement #46819 where rustc
will have multiple backends available to it to load.
This commit starts off by removing the `extern crate rustc_trans` from the
driver. This involved moving some miscellaneous functionality into the
`TransCrate` trait and also required an implementation of how to locate and load
the trans backend. This ended up being a little tricky because the sysroot isn't
always the right location (for example `--sysroot` arguments) so some extra code
was added as well to probe a directory relative to the current dll (the
rustc_driver dll).
Rustbuild has been updated accordingly as well to have a separate compilation
invocation for the `rustc_trans` crate and assembly it accordingly into the
sysroot. Finally, the distribution logic for the `rustc` package was also
updated to slurp up the trans backends folder.
A number of assorted fallout changes were included here as well to ensure tests
pass and such, and they should all be commented inline.
projects / rust.git / log