Stream: wg-traits

Topic: lazy normalization


Alexander Regueiro (Dec 03 2018 at 01:15, on Zulip):

hey @scalexm, how's the chalk integration going? I'm eager for lazy normalisation parts to get integrated, so work can begin in fixing type aliases :-)

nikomatsakis (Feb 26 2019 at 20:03, on Zulip):

So I spent some time today -- not as much as I would like =) -- digging into lazy normalization as promised. I still feel like I don't have a "crisp" answer to what "the core problem" is when it comes to const generics etc. But it quickly became clear that a useful thing would be to just try to document and layout how the existing normalization code works. So I've started working on that, taking some notes in this dropbox paper over here (those aren't that complete yet).

I was thinking I will put some more effort into that this week and then maybe try to schedule a public presentation to talk it over. Ideally, I'll have time to sketch out how associated types are handled, and then some time to sketch out to show what happens with constants and where we (potentially?) run into trouble and what we might do to fix it.

nikomatsakis (Mar 08 2019 at 20:17, on Zulip):

OK, I've been digging more into this.

nikomatsakis (Mar 08 2019 at 20:17, on Zulip):

I'm going to drop a few live notes here.

nikomatsakis (Mar 08 2019 at 20:27, on Zulip):

OK, so, I'm a bit confused still. I'm trying to trace out the cycle. I've confirmed that this is the test case

fn foo<T>(
    _: [u8; size_of::<T>()],
) {}
nikomatsakis (Mar 08 2019 at 20:29, on Zulip):

however, rustc as currently implemented doesn't cause a cycle because we don't have the 100% correct setup

nikomatsakis (Mar 08 2019 at 20:29, on Zulip):

in particular, the parent generics of the size_of::<T> "anonymous constant" (AnonConst) are currently not linked

nikomatsakis (Mar 08 2019 at 20:29, on Zulip):

but they should be the foo function itself

nikomatsakis (Mar 08 2019 at 20:33, on Zulip):

that said, when I try to trace through what will happen, I don't yet see the cycle

nikomatsakis (Mar 08 2019 at 20:33, on Zulip):

/me tempted to give it a try

nikomatsakis (Apr 16 2019 at 20:07, on Zulip):

@eddyb I have a question for you -- how hard do you think it would be to rejuvenate your old branch that uses the correct parents of constants for generics (and which was hitting cycle errors)?

eddyb (Apr 17 2019 at 07:13, on Zulip):

#59409

eddyb (Apr 17 2019 at 07:14, on Zulip):

@nikomatsakis yes, it's literally adding | Node::AnonConst(_) to the first arm of the first match in generics_of, that's what "correct parents" amounts to

eddyb (Apr 17 2019 at 07:14, on Zulip):

anyway, it can't even build libcore. I have a weirder version that idk how to update, and which is probably unsound, that left ParamEnvs kind of "less eagerly normalized"

eddyb (Apr 17 2019 at 07:15, on Zulip):

but that still breaks, because rustc_typeck::check really wants a normalized ParamEnv, just in some tests instead of libcore

nikomatsakis (Apr 17 2019 at 09:33, on Zulip):

@eddyb ok -- is that really all I have to do to observe the problem? in that case, I'll take some time on friday to investigate, I feel like I have a hunch of how to do things but I wanted to see the errors in action. If it's easy for you to do, having a branch I can start from would be great (preferably not the version doing the hacky, unsound thing)

eddyb (Apr 17 2019 at 09:33, on Zulip):

yes!

eddyb (Apr 17 2019 at 09:34, on Zulip):

the entire compiler supports all of the usecases, except for the cycles caused by lazy normalization

eddyb (Apr 17 2019 at 09:34, on Zulip):

and that missing bit is basically commented out as a hack :P

eddyb (Apr 17 2019 at 09:34, on Zulip):

(except we haven't actually added it as a comment yet)

nikomatsakis (Apr 19 2019 at 17:34, on Zulip):

@eddyb ok so I applied this patch

modified   src/librustc_typeck/collect.rs
@@ -888,6 +888,7 @@ fn generics_of<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>, def_id: DefId) -> &'tcx ty

     let node = tcx.hir().get_by_hir_id(hir_id);
     let parent_def_id = match node {
+        Node::AnonConst(_) |
         Node::ImplItem(_) | Node::TraitItem(_) | Node::Variant(_) |
         Node::Ctor(..) | Node::Field(_) => {
             let parent_id = tcx.hir().get_parent_item(hir_id);

but I'm getting unwrap errors now from [this code in project.rs]:

 let substs = tcx.lift_to_global(&substs).unwrap();

presumably because the substs now includes some details from the surrounding context, and there are inference variables in there.

nikomatsakis (Apr 19 2019 at 17:34, on Zulip):

I'm not sure if you had an intended patch there or if I am, indeed, looking at (a facet of) the problem =)

eddyb (Apr 21 2019 at 14:01, on Zulip):

ugh

eddyb (Apr 21 2019 at 14:02, on Zulip):

that stuff is supposed to be resilient to inference variables

eddyb (Apr 21 2019 at 14:02, on Zulip):

I wonder if @oli's PR where he fixed some of this stuff went through

eddyb (Apr 21 2019 at 14:02, on Zulip):

basically it's supposed to attempt to evaluate... well

eddyb (Apr 21 2019 at 14:03, on Zulip):

@nikomatsakis I think actually, the problem is the const_eval query is not canonicalizing, and we needed your help to figure out how to do that :P

eddyb (Apr 21 2019 at 14:04, on Zulip):

https://github.com/rust-lang/rust/pull/59369#discussion_r269151886

eddyb (Apr 21 2019 at 14:04, on Zulip):

there you go :D

eddyb (Apr 21 2019 at 14:04, on Zulip):

but that's the PR that tries to fix some stuff

pnkfelix (May 02 2019 at 13:28, on Zulip):

Hey is there a tracking issue for lazy normalization?

pnkfelix (May 02 2019 at 13:28, on Zulip):

I'd like to downgrade priority on issue #54940, which is blocked by Lazy Normalization, but I don't want to do the downgrade without at least making a link to a tracking issue

pnkfelix (May 02 2019 at 13:33, on Zulip):

I settled on creating "lazy normalization" #60471

simulacrum (May 03 2019 at 00:35, on Zulip):

@pnkfelix to my knowledge no such issue existed - many, though not all, of the maybe related bugs likely have been at least semi-duplicate closed/cross-linked when I noticed; unfortunately at least to me lazy norm is somewhat nebulous, i.e., I don't actually know what it will / won't affect, so I was hesitant to label or otherwise strongly associate things

nikomatsakis (May 06 2019 at 21:19, on Zulip):

I think actually, the problem is the const_eval query is not canonicalizing, and we needed your help to figure out how to do that :P

@eddyb so I was finally looking at this again, and basically I came to the same conclusion. This should be canonicalization

nikomatsakis (May 06 2019 at 21:20, on Zulip):

Reading these comments, I guess I need to read that PR a bit

nikomatsakis (May 06 2019 at 21:20, on Zulip):

I could probably help you setup a canon path though

Last update: Nov 12 2019 at 15:40UTC