[6/n] rustc: transition HIR function bodies from Block to Expr. #37412

eddyb · 2016-10-26T00:18:05Z

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 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 #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:

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:

// 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

rust-highfive · 2016-10-26T00:18:19Z

r? @nrc

(rust_highfive has picked a reviewer for you, use r? to override)

eddyb · 2016-10-26T00:22:53Z

src/librustc_typeck/check/mod.rs

+                                hi: original_span.hi,
+                                expn_id: original_span.expn_id
+                            };
+                            err.span_help(span_semi, "consider removing this semicolon:");


cc @GuillaumeGomez I wanted to show this on IRC but you left. This and the report_and_explain_type_error call above is how you can emit type errors with additional information (note/help) attached to them.

Ah nice, thanks!

nrc · 2016-10-26T03:53:39Z

r? @nikomatsakis

bors · 2016-10-26T07:51:18Z

☔ The latest upstream changes (presumably #36421) made this pull request unmergeable. Please resolve the merge conflicts.

Manishearth · 2016-10-26T10:32:58Z

Feel free to merge this early (without a batch), just ping me when you do.

bors · 2016-10-27T04:49:18Z

☔ The latest upstream changes (presumably #36695) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2016-10-30T07:02:32Z

☔ The latest upstream changes (presumably #37400) made this pull request unmergeable. Please resolve the merge conflicts.

nikomatsakis

r=me, presuming that there aren't any backcompat concerns here.

nikomatsakis · 2016-11-02T22:00:25Z

src/librustc_typeck/check/_match.rs

@@ -476,11 +484,12 @@ impl<'a, 'gcx, 'tcx> FnCtxt<'a, 'gcx, 'tcx> {
            };
        }

+        // We won't diverge unless the discriminant or all arms diverge.
+        self.diverges.set(discrim_diverges | all_pats_diverge | all_bodies_diverge);


Not that I care too much here, but I guess plausibly you could have 50% of the patterns diverging and the other 50% of the bodies diverging, right?

i.e., the proper test is discrim_diverges | all_arms_diverge, where all_arms_diverge = pat_diverges | body_diverges

nikomatsakis · 2016-11-02T22:03:30Z

src/libpanic_abort/lib.rs

@@ -53,7 +53,7 @@ pub unsafe extern fn __rust_maybe_catch_panic(f: fn(*mut u8),
 // now hopefully.
 #[no_mangle]
 pub unsafe extern fn __rust_start_panic(_data: usize, _vtable: usize) -> u32 {
-    return abort();
+    abort();


This is to silence a warning? Do we need to be concerned about back-compat? I guess this just causes new warnings, right?

New lint warnings, which only cause problems because we use #![deny(warnings)].

nikomatsakis · 2016-11-02T22:06:57Z

hmm, so I'm not sure how precise the old code was around matches -- is it worth doing a crater run or anything? Probably -- if you are with me -- you should just fix the match imprecision anyhow.

[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://github.com/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).

bors · 2016-11-06T09:53:51Z

☔ The latest upstream changes (presumably #37597) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2016-11-09T23:13:48Z

🔒 Merge conflict

bors · 2016-11-09T23:15:13Z

☔ The latest upstream changes (presumably #37670) made this pull request unmergeable. Please resolve the merge conflicts.

eddyb · 2016-11-10T01:39:16Z

@bors r=nikomatsakis

bors · 2016-11-10T01:39:17Z

📌 Commit 8e9106c has been approved by nikomatsakis

@Manishearth

[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://github.com/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 ```

Rollup of 5 pull requests - Successful merges: #37402, #37412, #37661, #37664, #37667 - Failed merges:

@petrochenkov

[7/n] rustc: desugar UFCS in HIR and don't use DefMap for associated resolutions. _This is part of a series ([prev](#37412) | [next](#37688)) 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://github.com/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> Previously, a path like `T::Assoc::method`, while equivalent to `<<T>::Assoc>::method`, wasn't desugared in any way at the HIR level and everything inspecting it had to either deal with knowing only `T` (before typeck) or knowing only the definition of `method` (after typeck). Such a path also had only one `NodeId` and associated resolution during typeck modified `DefMap`, in a way that would be hard for incremental recompilation to track, and inconvenient for partial type conversions from HIR to `Ty`, which are required to break faux-cycles in on-demand type collection. The desugarings performed by this PR are as follows: * `use a::{b,c};` is flattened to `use a as _; use a::b; use a::c;` * as resolution is complete, `use a as _;` doesn't do anything, except get checked for stability * `Vec::new` (an expression) becomes `Vec<..>::new<..>`, to distinguish it from `<Vec>::new<..>` * the "infer all parameters" `<..>` form is internal and not even pretty-printed * used when there are no type parameters at all, in an expression or pattern path segment * `T::A::B` becomes `<<T>::A>::B` in a type, and `<<T<..>>::A<..>>::B<..>` in an expression/pattern * one additional `hir::Ty` node is created for each prefix, starting with the fully-resolved type (`T`) and extending it with each segment (e.g. `<T>::A`) * fully-resolved paths contain their `Def` in HIR, getting rid of the `DefMap` and absolving incremental recompilation of needing to manually look up nodes to handle that side information Not keeping the `DefMap` around meant that associated resolutions had to be stored somewhere else: * expressions and patterns use a new `NodeId -> Def` map in `ty::Tables` * compatible with the future per-body (constant / `fn` / closure) `Tables` * types are accessible via `Ty` and the usual per-item generics / predicates / type * `rustdoc` and `save-analysis` are the only situations which insist on mapping syntactical types to semantical ones, or at least understand the resolution of associated types, therefore the type conversion cache, i.e. a `NodeId -> Ty` map, is exposed by typeck for this purpose * stability had to be split into a pass that runs on HIR and checks the results of name resolution, and impromptu checks triggered by `typeck` for associated paths, methods, fields, etc. * privacy using semantic types results in accurate reachability for `impl Trait`, which fixes #35870, and thorough introspection of associated types, which may allow relaxing private-in-public checking on bounds, while keeping the intended ban on projections with private type parameters cc @petrochenkov

Don't leak the compiler's internal representation of scopes in error messages. Fixes #37884 (actually fixes #27942, which was made worse by #37412) by handling more node types. Ideally we'd turn the unknown node type situations into ICEs and fix them as they show up in errors. But we might want to backport this patch so I was less aggressive.

rust-highfive assigned nrc Oct 26, 2016

This was referenced Oct 26, 2016

[5/n] rustc: record the target type of every adjustment. #37408

Merged

Separate fn signature from fn body in HIR #35078

Closed

eddyb commented Oct 26, 2016

View reviewed changes

rust-highfive assigned nikomatsakis and unassigned nrc Oct 26, 2016

eddyb force-pushed the lazy-6 branch 2 times, most recently from 73f8338 to 065e10a Compare October 26, 2016 07:43

eddyb force-pushed the lazy-6 branch from 065e10a to b0cdae9 Compare October 26, 2016 21:22

eddyb force-pushed the lazy-6 branch from b0cdae9 to 7d8f770 Compare October 28, 2016 09:00

eddyb force-pushed the lazy-6 branch from 7d8f770 to 4790e25 Compare November 2, 2016 02:46

nikomatsakis approved these changes Nov 2, 2016

View reviewed changes

eddyb force-pushed the lazy-6 branch from 4790e25 to aeb80a6 Compare November 6, 2016 14:24

eddyb mentioned this pull request Nov 7, 2016

Detect missing ; on methods with return type () #36409

Closed

eddyb force-pushed the lazy-6 branch from aeb80a6 to 695e17f Compare November 7, 2016 14:40

eddyb mentioned this pull request Nov 9, 2016

[7/n] rustc: desugar UFCS in HIR and don't use DefMap for associated resolutions. #37676

Merged

eddyb added 5 commits November 10, 2016 01:44

syntax: don't fake a block around closures' bodies during parsing.

49772fb

rustc: use an Expr instead of a Block for function bodies.

ff0830d

rustc_typeck: correctly track "always-diverges" and "has-type-errors".

6b3cc0b

tests: fix fallout in flowgraph graphviz comparison dot files.

9ce1044

tests: fix fallout in pretty-printing output exact-match tests.

8e9106c

eddyb force-pushed the lazy-6 branch from 695e17f to 8e9106c Compare November 9, 2016 23:45

eddyb mentioned this pull request Nov 10, 2016

Rollup of 5 pull requests #37678

Merged

bors added a commit that referenced this pull request Nov 10, 2016

Auto merge of #37678 - eddyb:rollup, r=eddyb

b46ce08

Rollup of 5 pull requests - Successful merges: #37402, #37412, #37661, #37664, #37667 - Failed merges:

bors merged commit 8e9106c into rust-lang:master Nov 10, 2016

eddyb deleted the lazy-6 branch November 10, 2016 08:54

mcarton mentioned this pull request Nov 16, 2016

Rustup to rustc 1.15.0-nightly (0ed951993 2016-11-14) and bump to 0.0.99 rust-lang/rust-clippy#1344

Merged

nrc mentioned this pull request Nov 20, 2016

syntax::ast::Expr_::ExprClosure should have an Expr instead of Block #27872

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[6/n] rustc: transition HIR function bodies from Block to Expr. #37412

[6/n] rustc: transition HIR function bodies from Block to Expr. #37412

eddyb commented Oct 26, 2016 •

edited

Loading

rust-highfive commented Oct 26, 2016

eddyb Oct 26, 2016

GuillaumeGomez Oct 26, 2016

nrc commented Oct 26, 2016

bors commented Oct 26, 2016

Manishearth commented Oct 26, 2016 •

edited

Loading

bors commented Oct 27, 2016

bors commented Oct 30, 2016

nikomatsakis left a comment

nikomatsakis Nov 2, 2016

nikomatsakis Nov 2, 2016

eddyb Nov 3, 2016

nikomatsakis commented Nov 2, 2016

bors commented Nov 6, 2016

bors commented Nov 9, 2016

bors commented Nov 9, 2016

eddyb commented Nov 10, 2016

bors commented Nov 10, 2016

[6/n] rustc: transition HIR function bodies from Block to Expr. #37412

[6/n] rustc: transition HIR function bodies from Block to Expr. #37412

Conversation

eddyb commented Oct 26, 2016 • edited Loading

rust-highfive commented Oct 26, 2016

eddyb Oct 26, 2016

Choose a reason for hiding this comment

GuillaumeGomez Oct 26, 2016

Choose a reason for hiding this comment

nrc commented Oct 26, 2016

bors commented Oct 26, 2016

Manishearth commented Oct 26, 2016 • edited Loading

bors commented Oct 27, 2016

bors commented Oct 30, 2016

nikomatsakis left a comment

Choose a reason for hiding this comment

nikomatsakis Nov 2, 2016

Choose a reason for hiding this comment

nikomatsakis Nov 2, 2016

Choose a reason for hiding this comment

eddyb Nov 3, 2016

Choose a reason for hiding this comment

nikomatsakis commented Nov 2, 2016

bors commented Nov 6, 2016

bors commented Nov 9, 2016

bors commented Nov 9, 2016

eddyb commented Nov 10, 2016

bors commented Nov 10, 2016

eddyb commented Oct 26, 2016 •

edited

Loading

Manishearth commented Oct 26, 2016 •

edited

Loading