[5/n] rustc: record the target type of every adjustment. #37408
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
eddyb
force-pushed
the
lazy-5
branch
2 times, most recently
from
0595cca
to
f1e7983
Compare
|
☔ The latest upstream changes (presumably #37270) made this pull request unmergeable. Please resolve the merge conflicts. |
eddyb
force-pushed
the
lazy-5
branch
2 times, most recently
from
8eb737b
to
89a28f6
Compare
|
☔ The latest upstream changes (presumably #36695) made this pull request unmergeable. Please resolve the merge conflicts. |
|
☔ The latest upstream changes (presumably #37389) made this pull request unmergeable. Please resolve the merge conflicts. |
|
r=me |
|
@bors r=nikomatsakis |
|
📌 Commit 0d7201e has been approved by |
|
⌛ Testing commit 0d7201e with merge 09f94eb... |
|
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
|
@bors: retry |
[5/n] rustc: record the target type of every adjustment. _This is part of a series ([prev](rust-lang#37404) | [next](rust-lang#37412)) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https:/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well. If any motivation is unclear, please ask for additional PR description clarifications or code comments._ <hr> The first commit rearranges `tcx.tables` so that all users go through `tcx.tables()`. This in preparation for per-body `Tables` where they will be requested for a specific `DefId`. Included to minimize churn. The rest of the changes focus on adjustments, there are some renamings, but the main addition is the target type, always available in all cases (as opposed to just for unsizing where it was previously needed). Possibly the most significant effect of this change is that figuring out the final type of an expression is now _always_ just one successful `HashMap` lookup (either the adjustment or, if that doesn't exist, the node type).
|
⌛ Testing commit 0d7201e with merge d3b3b20... |
|
💔 Test failed - auto-win-gnu-32-opt-rustbuild |
|
@bors: retry On Fri, Nov 4, 2016 at 5:43 PM, bors [email protected] wrote:
|
|
⌛ Testing commit 0d7201e with merge 6c1c47f... |
|
⛄ The build was interrupted to prioritize another pull request. |
|
⌛ Testing commit 0d7201e with merge be724fc... |
|
⛄ The build was interrupted to prioritize another pull request. |
|
⌛ Testing commit 0d7201e with merge 884c93a... |
|
💔 Test failed - auto-win-msvc-64-opt-rustbuild |
|
@bors: retry On Fri, Nov 4, 2016 at 10:19 PM, bors [email protected] wrote:
|
|
⌛ Testing commit 0d7201e with merge dce5eca... |
|
💔 Test failed - auto-win-gnu-32-opt |
[4/n] rustc: harden against InferOk having obligations in more cases. _This is part of a series ([prev](#37402) | [next](#37408)) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https:/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well. If any motivation is unclear, please ask for additional PR description clarifications or code comments._ <hr> This adds more asserts that `InferOk` results have no obligations, pending completion of #32730. Each of these could accidentally drop obligations on the floor if they start getting produced by unification, and a future change does just that, in order to produce a "shallow success" (hopefully leading to ambiguities during trait selection), _without_ the possibility of an eventual success - mostly guarded by ICEs for now.
[6/n] rustc: transition HIR function bodies from Block to Expr. _This is part of a series ([prev](rust-lang#37408) | [next](rust-lang#37676)) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https:/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well. If any motivation is unclear, please ask for additional PR description clarifications or code comments._ <hr> The main change here is that functions and closures both use `Expr` instead of `Block` for their bodies. For closures this actually allows a honest representation of brace-less closure bodies, e.g. `|x| x + 1` is now distinguishable from `|x| { x + 1 }`, therefore this PR is `[syntax-breaking]` (cc @Manishearth). Using `Expr` allows more logic to be shared between constant bodies and function bodies, with some small such changes already part of this PR, and eventually easing rust-lang#35078 and per-body type tables. Incidentally, there used to be some corners cut here and there and as such I had to (re)write divergence tracking for type-checking so that it is capable of understanding basic structured control-flow: ``` rust fn a(x: bool) -> i32 { // match also works (as long as all arms diverge) if x { panic!("true") } else { return 1; } 0 // "unreachable expression" after this PR } ``` And since liveness' "not all control paths return a value" moved to type-checking we can have nice things: ``` rust // before & after: fn b() -> i32 { 0; } // help: consider removing this semicolon // only after this PR fn c() -> i32 { { 0; } } // help: consider removing this semicolon fn d() { let x: i32 = { 0; }; } // help: consider removing this semicolon fn e() { f({ 0; }); } // help: consider removing this semicolon ```
This is part of a series (prev | next) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. MIR-based early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments.
The first commit rearranges
tcx.tablesso that all users go throughtcx.tables(). This in preparation for per-bodyTableswhere they will be requested for a specificDefId. Included to minimize churn.The rest of the changes focus on adjustments, there are some renamings, but the main addition is the target type, always available in all cases (as opposed to just for unsizing where it was previously needed).
Possibly the most significant effect of this change is that figuring out the final type of an expression is now always just one successful
HashMaplookup (either the adjustment or, if that doesn't exist, the node type).