Create NormalizeTy query #44984

Maaarcocr · 2017-10-02T18:29:08Z

As part of the effort to solve #44891, I've created the normalize_ty query.

As outlined in the issue this meant:

renamed normalize_associated_type() to normalize_associated_type_in()
created the normalize_ty query
substituted the use of memoize with the query

This PR is not ready. While running tests, one of the incremental ones failed. This is the error I got.

rust-highfive · 2017-10-02T18:29:14Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @eddyb (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

eddyb · 2017-10-02T19:00:13Z

r? @nikomatsakis

nikomatsakis

Looks great! I left a few minor nits.

nikomatsakis · 2017-10-03T10:56:56Z

src/librustc/infer/mod.rs

    }

    /// Fully normalizes any associated types in `value`, using an
    /// empty environment and `Reveal::All` mode (therefore, suitable
    /// only for monomorphized code during trans, basically).
-    pub fn normalize_associated_type<T>(self, value: &T) -> T
+    pub fn normalize_associated_type_in<T>(self, value: &T) -> T


Nit: can we call this normalize_associated_types_in (i.e., pluralize type)

I checked the codebase and there already exists a function named this way, here. Would it be a problem if we had 2 different functions with the same name? (Mainly for people reading both of them).

Ideally only one of them would remain as the public API, if I'm not mistaken.

Hmm. So really these functions serve two distinct roles:

The existing normalize_associated_types_in (implemented on Inherited) are used during type-checking, and hence may have a non-empty environment and/or inference variables. That particular one partly exists to silently register the extra obligations that comes from normalization.

The normalize_associated_type function in contrast is intended to be used after monomorphization, and it forces an empty environment and Reveal::All. In this mode, we don't expect extra obligations to matter to the user, so we handle them internally.

I think its pretty clear that the "naming convention" distinguishing the two is... not sufficient. </understatement>

In other parts of the code, we've used the trans_ prefix to distinguish the case of an empty environment with Reveal::All -- or at least code that runs after type-checking. @eddyb doesn't like that for the -- quite correct! -- reason that the code is generally applicable beyond trans. For example, MIR optimizations may want to use these pathways (though those may not have an empty environment, so that's slightly different).

I think a lot of this comes down to whether you are running "before" or "after" typeck -- in particular, after typeck you know that errors should not occur, which can simplify the code and function signatures in various ways. So perhaps we can call this new function normalize_associated_types_after_typeck? We could also rename the existing trans_ things in a similar vein.

Oh if one of them is only in rustc_typeck then I got confused a bit, it certainly feels like the name shows up in a few places.

How about we just propagate the ParamEnv in more places and just make sure that in rustc_trans we give a Reveal::All? That seems simpler and less headache-inducing.

@eddyb the signature currently is T -> T. I agree with changing it to (ParamEnv, T) -> T but that is not enough to remove the need for two functions. In particular, there are also "auxiliary obligations" and we have to decide what to do with them. The FnCtxt version ("during typeck") enrolls them into the fulfillment context. This version we are editing here solves them, assering that there are no errors (because it runs after type-check). The unifier form would probably propagate them back but nobody really wants that.

Right, then, just take a Reveal and don't put trans in the name?

@eddyb I don't see how that solves the problem. First off, taking a parameter environment -- not just reveal -- seems like the right thing to do (and is orthogonal from how we handle subobligations). Second, even if we just took a reveal, I still think we want a naming convention to distinguish these two cases ("expects to run after typeck" vs "does not").

One option would be to use a combinator approach. Something like tcx.post_typeck().normalize_associated_types_in(...)?

nikomatsakis · 2017-10-03T10:57:15Z

src/librustc/ty/maps/config.rs

+
+impl<'tcx> QueryDescription for queries::normalize_ty<'tcx> {
+    fn describe(_tcx: TyCtxt, _: Ty) -> String {
+        format!("normalising types")


Nit: "normalizing"

nikomatsakis · 2017-10-03T10:57:24Z

src/librustc/ty/maps/mod.rs

+
+fn normalize_ty_node<'tcx>(_: Ty<'tcx>) -> DepConstructor<'tcx> {
+    DepConstructor::NormalizeTy
+}


Nit: newline at end of file

nikomatsakis · 2017-10-03T10:57:33Z

src/librustc/ty/maps/config.rs

+    fn describe(_tcx: TyCtxt, _: Ty) -> String {
+        format!("normalising types")
+    }
+}


Nit: newline at end of file

bors · 2017-10-04T23:14:03Z

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

nikomatsakis · 2017-10-09T14:02:12Z

@Maaarcocr needs rebase =)

Maaarcocr · 2017-10-09T14:17:31Z

@nikomatsakis Done 😄 were you able to understand why the error I'm experiencing is happening?

nikomatsakis · 2017-10-10T20:25:34Z

@Maaarcocr yep you need to add the NormalizeTy variant into this list right here

nikomatsakis · 2017-10-11T13:31:58Z

Also, before landing, we really do need to pick a name for this new function I think. I propose we use the trans_ prefix for now -- since it's already in use -- but longer term I think I want to adopt the name post_typeck, since I think that's the important invariant. Or maybe we can find a way to factor it another way so that the distinction isn't even needed.

Maaarcocr · 2017-10-11T17:06:57Z

@nikomatsakis I have used the trans_ prefix. It seems that the failing test has be corrected now in my local setup 😄

bors · 2017-10-12T10:17:17Z

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

bors · 2017-10-13T20:20:53Z

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

nikomatsakis · 2017-10-13T21:08:17Z

@eddyb and I were talking on IRC about following the naming scheme of fully_normalize_or_panic. I'd be happy with calling it fully_normalize_associated_types_in -- which to me implies that we will indeed process all subobligations. I'd also be happy with naming it trans_ and then converting all the trans_ functions together to adopt a different naming scheme.

Maaarcocr · 2017-10-14T12:10:31Z

@nikomatsakis I don't have a strong preference about this. I will rebase the branch now.

nikomatsakis · 2017-10-16T18:19:29Z

@Maaarcocr great! Let's go with the fully_ naming then. We can remove the other trans_ functions at some later time I guess.

nikomatsakis · 2017-10-16T18:19:54Z

@Maaarcocr btw this still needs to be rebased again :(

Maaarcocr · 2017-10-16T18:29:54Z

@nikomatsakis i had a problem while rebasing (with the llvm git submodule) and asked on the main impl period lobby on Gitter. Should I ask this kind of questions on IRC to have a higher chance to get an answer?

nikomatsakis · 2017-10-16T19:10:09Z

@Maaarcocr looks like an unused import

nikomatsakis · 2017-10-16T19:10:21Z

[00:06:08] error: unused import: `util::common::MemoizationMap`

[00:06:08]   --> /checkout/src/librustc/traits/trans/mod.rs:25:5

[00:06:08]    |

[00:06:08] 25 | use util::common::MemoizationMap;

[00:06:08]    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[00:06:08]    |

bors · 2017-10-21T09:38:19Z

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

…ormalizing'

…incremental test-suite.

Maaarcocr · 2017-10-22T18:57:23Z

@michaelwoerister thanks! It seems like now all tests are green 😄 @nikomatsakis are there any other issues that I need to solve before merging this? 😄

michaelwoerister · 2017-10-23T08:30:57Z

@Maaarcocr Excellent :)

nikomatsakis · 2017-10-23T17:48:24Z

@bors r+

bors · 2017-10-23T17:48:25Z

📌 Commit 5c51bf5 has been approved by nikomatsakis

bors · 2017-10-23T19:12:12Z

⌛ Testing commit 5c51bf5 with merge 9ba208b9896b9df8bebebd6cb322fcf09927a08c...

bors · 2017-10-23T22:13:03Z

💔 Test failed - status-travis

kennytm · 2017-10-24T01:20:09Z

@bors retry

macOS 3-hour timed out.

bors · 2017-10-24T03:55:28Z

⌛ Testing commit 5c51bf5 with merge a789fa0...

Create NormalizeTy query As part of the effort to solve #44891, I've created the normalize_ty query. As outlined in the issue this meant: - renamed `normalize_associated_type()` to `normalize_associated_type_in()` - created the `normalize_ty` query - substituted the use of memoize with the query This PR is not ready. While running tests, one of the incremental ones failed. [This](https://pastebin.com/vGhH6bv6) is the error I got.

bors · 2017-10-24T07:06:28Z

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing a789fa0 to master...

rust-highfive assigned eddyb Oct 2, 2017

rust-highfive assigned nikomatsakis and unassigned eddyb Oct 2, 2017

nikomatsakis requested changes Oct 3, 2017

View reviewed changes

Maaarcocr force-pushed the master branch from 0177187 to 3818d55 Compare October 3, 2017 21:57

shepmaster added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Oct 6, 2017

Maaarcocr force-pushed the master branch from 3818d55 to 23395b4 Compare October 9, 2017 14:16

Maaarcocr force-pushed the master branch from 099ab79 to 4b783f4 Compare October 12, 2017 12:23

nikomatsakis approved these changes Oct 16, 2017

View reviewed changes

Maaarcocr force-pushed the master branch from 4b783f4 to 14a092a Compare October 16, 2017 18:36

kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 16, 2017

Maaarcocr force-pushed the master branch from bbfe432 to 4de00bd Compare October 16, 2017 21:02

Maaarcocr force-pushed the master branch from 5cea99e to 6c8e1fb Compare October 21, 2017 21:28

Maaarcocr added 9 commits October 21, 2017 22:50

Create NormalizeTy query

113ebe4

added newlines at the end of the file and changed 'normalising' to 'n…

96a006c

…ormalizing'

added trans_ prefix and pluralised types. Solved failing test on the …

69f5f0d

…incremental test-suite.

tidier

f2ebe96

trans_ -> fully_ prefix

d870a96

removed unused import

73c9543

moved depnode

20ae2d9

anon NormalizeTy DepNode

a3667d3

renamed query

5c51bf5

Maaarcocr force-pushed the master branch from 6c8e1fb to 5c51bf5 Compare October 21, 2017 21:58

kennytm added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 23, 2017

nikomatsakis approved these changes Oct 23, 2017

View reviewed changes

kennytm added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 24, 2017

bors merged commit 5c51bf5 into rust-lang:master Oct 24, 2017

bors mentioned this pull request Oct 24, 2017

Refactor type memory layouts and ABIs, to be more general and easier to optimize. #45225

Merged

Create NormalizeTy query #44984

Create NormalizeTy query #44984

Conversation

Maaarcocr commented Oct 2, 2017

rust-highfive commented Oct 2, 2017

eddyb commented Oct 2, 2017

nikomatsakis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis Oct 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bors commented Oct 4, 2017

nikomatsakis commented Oct 9, 2017

Maaarcocr commented Oct 9, 2017

nikomatsakis commented Oct 10, 2017

nikomatsakis commented Oct 11, 2017

Maaarcocr commented Oct 11, 2017

bors commented Oct 12, 2017

bors commented Oct 13, 2017

nikomatsakis commented Oct 13, 2017

Maaarcocr commented Oct 14, 2017

nikomatsakis commented Oct 16, 2017

nikomatsakis commented Oct 16, 2017

Maaarcocr commented Oct 16, 2017 • edited Loading

nikomatsakis commented Oct 16, 2017

nikomatsakis commented Oct 16, 2017

bors commented Oct 21, 2017

Maaarcocr commented Oct 22, 2017

michaelwoerister commented Oct 23, 2017

nikomatsakis commented Oct 23, 2017

bors commented Oct 23, 2017

bors commented Oct 23, 2017

bors commented Oct 23, 2017

kennytm commented Oct 24, 2017

bors commented Oct 24, 2017

bors commented Oct 24, 2017

nikomatsakis Oct 4, 2017 •

edited

Loading

Maaarcocr commented Oct 16, 2017 •

edited

Loading