Skip to content

/rust

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 5 commits into from Nov 10, 2016

Conversation

Reviewers

@GuillaumeGomez GuillaumeGomez

@nikomatsakis nikomatsakis

Assignees

@nikomatsakis nikomatsakis

Labels
None yet
Projects
None yet
Milestone
No milestone
8 participants
@eddyb @rust-highfive @nrc @bors @Manishearth @nikomatsakis @alexcrichton @GuillaumeGomez
@eddyb
Copy link
Member

eddyb commented Oct 26, 2016 •
edited

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 rust-highfive assigned nrc Oct 26, 2016

@rust-highfive

This comment has been minimized.

Sign in to view
Copy link
Collaborator

rust-highfive commented Oct 26, 2016

r? @nrc

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

This was referenced Oct 26, 2016

Merged
Closed
@eddyb

eddyb reviewed Oct 26, 2016
View changes

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:");

This comment has been minimized.

Sign in to view
Copy link
@eddyb

eddyb Oct 26, 2016

Author Member

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.

This comment has been minimized.

Sign in to view
Copy link
@GuillaumeGomez

GuillaumeGomez Oct 26, 2016

Member

Ah nice, thanks!
@nrc

This comment has been minimized.

Sign in to view
Copy link
Member

nrc commented Oct 26, 2016

r? @nikomatsakis

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

@eddyb eddyb force-pushed the eddyb:lazy-6 branch 2 times, most recently from 73f8338 to 065e10a Oct 26, 2016

@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Oct 26, 2016

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

This comment has been minimized.

Sign in to view
Copy link
Member

Manishearth commented Oct 26, 2016 •
edited

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

@eddyb eddyb force-pushed the eddyb:lazy-6 branch from 065e10a to b0cdae9 Oct 26, 2016

@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Oct 27, 2016

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

@eddyb eddyb force-pushed the eddyb:lazy-6 branch from b0cdae9 to 7d8f770 Oct 28, 2016

@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Oct 30, 2016

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

@eddyb eddyb force-pushed the eddyb:lazy-6 branch from 7d8f770 to 4790e25 Nov 2, 2016

@nikomatsakis

nikomatsakis approved these changes Nov 2, 2016
View changes

Copy link
Contributor

nikomatsakis left a comment

r=me, presuming that there aren't any backcompat concerns here.
src/librustc_typeck/check/_match.rs Outdated
@@ -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);

This comment has been minimized.

Sign in to view
Copy link
@nikomatsakis

nikomatsakis Nov 2, 2016

Contributor

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
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 comment has been minimized.

Sign in to view
Copy link
@nikomatsakis

nikomatsakis Nov 2, 2016

Contributor

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

This comment has been minimized.

Sign in to view
Copy link
@eddyb

eddyb Nov 3, 2016

Author Member

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

This comment has been minimized.

Sign in to view
Copy link
Contributor

nikomatsakis commented Nov 2, 2016

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.

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

@bors
Auto merge of #37408 - eddyb:lazy-5, r=nikomatsakis 
[5/n] rustc: record the target type of every adjustment.

_This is part of a series ([prev](#37404) | [next](#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).
Loading status checks…
09f94eb

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Nov 4, 2016

@alexcrichton
Rollup merge of rust-lang#37408 - eddyb:lazy-5, r=nikomatsakis 
[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).
1a09632

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

@bors
Auto merge of #37408 - eddyb:lazy-5, r=nikomatsakis 
[5/n] rustc: record the target type of every adjustment.

_This is part of a series ([prev](#37404) | [next](#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).
Loading status checks…
d3b3b20

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

@bors
Auto merge of #37408 - eddyb:lazy-5, r=nikomatsakis 
[5/n] rustc: record the target type of every adjustment.

_This is part of a series ([prev](#37404) | [next](#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).
Loading status checks…
6c1c47f

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

@bors
Auto merge of #37408 - eddyb:lazy-5, r=nikomatsakis 
[5/n] rustc: record the target type of every adjustment.

_This is part of a series ([prev](#37404) | [next](#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).
Loading status checks…
be724fc

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

@bors
Auto merge of #37408 - eddyb:lazy-5, r=nikomatsakis 
[5/n] rustc: record the target type of every adjustment.

_This is part of a series ([prev](#37404) | [next](#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).
Loading status checks…
884c93a

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

@bors
Auto merge of #37408 - eddyb:lazy-5, r=nikomatsakis 
[5/n] rustc: record the target type of every adjustment.

_This is part of a series ([prev](#37404) | [next](#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).
Loading status checks…
dce5eca
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Nov 6, 2016

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

@eddyb eddyb force-pushed the eddyb:lazy-6 branch from 4790e25 to aeb80a6 Nov 6, 2016

@eddyb eddyb referenced this pull request Nov 7, 2016

Closed

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

@eddyb eddyb force-pushed the eddyb:lazy-6 branch from aeb80a6 to 695e17f Nov 7, 2016

@eddyb eddyb referenced this pull request Nov 9, 2016

Merged

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

@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Nov 9, 2016

🔒 Merge conflict
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Nov 9, 2016

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

@eddyb eddyb force-pushed the eddyb:lazy-6 branch from 695e17f to 8e9106c Nov 9, 2016

@eddyb

This comment has been minimized.

Sign in to view
Copy link
Member Author

eddyb commented Nov 10, 2016

@bors r=nikomatsakis
@bors

This comment has been minimized.

Sign in to view
Copy link
Contributor

bors commented Nov 10, 2016

📌 Commit 8e9106c has been approved by nikomatsakis

eddyb added a commit to eddyb/rust that referenced this pull request Nov 10, 2016

@eddyb
Rollup merge of rust-lang#37412 - eddyb:lazy-6, r=nikomatsakis 
[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
```
368281a

@eddyb eddyb referenced this pull request Nov 10, 2016

Merged

Rollup of 5 pull requests #37678

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

@bors
Auto merge of #37678 - eddyb:rollup, r=eddyb 
Rollup of 5 pull requests

- Successful merges: #37402, #37412, #37661, #37664, #37667
- Failed merges:
Loading status checks…
b46ce08

@bors bors merged commit 8e9106c into rust-lang:master Nov 10, 2016
1 check passed

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@eddyb eddyb deleted the eddyb:lazy-6 branch Nov 10, 2016

@mcarton mcarton referenced this pull request Nov 16, 2016

Merged

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

@nrc nrc referenced this pull request Nov 20, 2016

Closed

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

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

@bors
Auto merge of #37676 - eddyb:lazy-7, r=nikomatsakis 
[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
Loading status checks…
d70e167

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

@bors
Auto merge of #37676 - eddyb:lazy-7, r=nikomatsakis 
[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
Loading status checks…
607bdf5

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

@bors
Auto merge of #37676 - eddyb:lazy-7, r=nikomatsakis 
[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
Loading status checks…
ca4af79

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

@bors
Auto merge of #37676 - eddyb:lazy-7, r=nikomatsakis 
[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
Loading status checks…
e012eae

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

@bors
Auto merge of #37676 - eddyb:lazy-7, r=nikomatsakis 
[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
Loading status checks…
81e427c

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

@bors
Auto merge of #37676 - eddyb:lazy-7, r=nikomatsakis 
[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
Loading status checks…
0b399e5

This was referenced Dec 22, 2016

Closed
Merged

bors added a commit that referenced this pull request Dec 27, 2016

@bors
Auto merge of #38552 - eddyb:bad-blocks, r=arielb1 
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.
Loading status checks…
a1708c2

bors added a commit that referenced this pull request Dec 27, 2016

@bors
Auto merge of #38552 - eddyb:bad-blocks, r=arielb1 
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.
Loading status checks…
9fc4005

bors added a commit that referenced this pull request Dec 30, 2016

@bors
Auto merge of #38552 - eddyb:bad-blocks, r=arielb1 
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.
Loading status checks…
abd4aa7

bors added a commit that referenced this pull request Jan 4, 2017

@bors
Auto merge of #38552 - eddyb:bad-blocks, r=arielb1 
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.
Loading status checks…
e06ce71
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.