- 28 1月, 2018 5 次提交
-
-
由 bors 提交于
Correctly format `extern crate` conflict resolution help Closes #45799. Follow up to @Cldfire's #45820. If the `extern` statement that will have a suggestion ends on a `;`, synthesize a new span that doesn't include it.
-
由 bors 提交于
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.
-
由 Alex Crichton 提交于
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.
-
由 bors 提交于
Fix never-type rvalue ICE This fixes #43061. r? @nikomatsakis A small post-mortem as a follow-up to our investigations in https://github.com/rust-lang/rust/pull/47291: The problem as I understand it is that when `NeverToAny` coercions are made, the expression/statement that is coerced may be enclosed in a block. In our case, the statement `x;` was being transformed to something like: `NeverToAny( {x;} )`. Then, `NeverToAny` is transformed into an expression: https://github.com/rust-lang/rust/blob/000fbbc9b8f88adc6a417f1caef41161f104250f/src/librustc_mir/build/expr/into.rs#L52-L59 Which ends up calling `ast_block_stmts` on the block `{x;}`, which triggers this condition: https://github.com/rust-lang/rust/blob/000fbbc9b8f88adc6a417f1caef41161f104250f/src/librustc_mir/build/block.rs#L141-L147 In our case, there is no return expression, so `push_assign_unit` is called. But the block has already been recorded as _diverging_, meaning the result of the block will be assigned to a location of type `!`, rather than `()`. This causes the MIR error. I'm assuming the `NeverToAny` coercion code is doing what it's supposed to (there don't seem to be any other problems), so fixing the issue simply consists of checking that the destination for the return value actually _is_ supposed to be a unit. (If no return value is given, the only other possible type for the return value is `!`, which can just be ignored, as it will be unreachable anyway.) I checked the other cases of `push_assign_unit`, and it didn't look like they could be affected by the divergence issue (blocks are kind of special-cased in this regard as far as I can tell), so this should be sufficient to fix the issue.
-
由 bors 提交于
Fix off-by-one spans in MIR borrowck errors Fixes #46885. r? @nikomatsakis
-
- 27 1月, 2018 27 次提交
-
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 David Wood 提交于
-
由 bors 提交于
Libtest json output A revisit to my [last PR](https://github.com/rust-lang/rust/pull/45923). Events are now more atomic, printed in a flat hierarchy. For the normal test output: ``` running 1 test test f ... FAILED failures: ---- f stdout ---- thread 'f' panicked at 'assertion failed: `(left == right)` left: `3`, right: `4`', f.rs:3:1 note: Run with `RUST_BACKTRACE=1` for a backtrace. failures: f test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out ``` The JSON equivalent is: ``` { "type": "suite", "event": "started", "test_count": "1" } { "type": "test", "event": "started", "name": "f" } { "type": "test", "event": "failed", "name": "f" } { "type": "suite", "event": "failed", "passed": 0, "failed": 1, "allowed_fail": 0, "ignored": 0, "measured": 0, "filtered_out": "0" } { "type": "test_output", "name": "f", "output": "thread 'f' panicked at 'assertion failed: `(left == right)` left: `3`, right: `4`', f.rs:3:1 note: Run with `RUST_BACKTRACE=1` for a backtrace. " } ```
-
由 Gilad Naaman 提交于
-
由 bors 提交于
For E0277 on `for` loops, point at the "head" expression When E0277's span points at a `for` loop, the actual issue is in the element being iterated. Instead of pointing at the entire loop, point only at the first line (when possible) so that the span ends in the element for which E0277 was triggered.
-
由 bors 提交于
Match libunwind's EABI selection with libpanic_unwind Currently, the `libunwind` crate will only select the ARM EABI if it is compiling for ARM/Linux or Android targets. `libpanic_unwind`, however, will choose the ARM EABI if the target arch is ARM and the OS is not iOS. This means that if one tries to enable unwinding for a non-standard ARM target (such as implementing a custom stdlib via Xargo, for example), then the two crates can potentially disagree about which EABI is being targeted. This PR makes `libunwind` use the [same logic](https://github.com/rust-lang/rust/blob/master/src/libpanic_unwind/gcc.rs#L139-L146) as `libpanic_unwind` when choosing the EABI. I noticed there are a few comments about certain functions only differing on Android or ARM/Linux, but I *think* that those differences apply to the ARM EABI in general. Let me know if I'm wrong about that.
-
由 Esteban Küber 提交于
-
由 Esteban Küber 提交于
-
由 Esteban Küber 提交于
Modify the spans used for `for`-loop expression expansion, instead of creating a new span during error creation.
-
由 Gilad Naaman 提交于
-
由 Gilad Naaman 提交于
-
由 Gilad Naaman 提交于
libtest: Split HumanFormatter into {Pretty,Terse} libtest: Fixed padding of benchmarks when not benchmarking libtest: Fixed benchmarks' names not showing in terse-mode libtest: Formatting
-
由 Gilad Naaman 提交于
libtest: Remove usage of jq libtest: Fixed UI tests - Now comparing to the right file. - A python script checks for validity of JSON documents
-
由 Gilad Naaman 提交于
libtest: Whoops
-
由 Gilad Naaman 提交于
-
由 Gilad Naaman 提交于
libtest: Added the -Z option for unstable options
-
由 Gilad Naaman 提交于
libtest: Json format now outputs failed tests' stdouts. libtest: Json format now outputs failed tests' stdouts. libtest: Json formatter now spews individiual events, not as an array libtest: JSON fixes libtest: Better JSON escaping libtest: Test start event is printed on time
-
由 Gilad Naaman 提交于
-
由 bors 提交于
Rollup of 19 pull requests - Successful merges: #47415, #47437, #47439, #47453, #47460, #47502, #47529, #47600, #47607, #47618, #47626, #47656, #47668, #47696, #47701, #47705, #47710, #47711, #47719 - Failed merges: #47455, #47521
-
由 Alex Crichton 提交于
-
- 26 1月, 2018 8 次提交
-
-
由 varkor 提交于
-
由 Alex Crichton 提交于
-
-
-
-
-
-
-