Stream: wg-traits

Topic: associate type bounds


nikomatsakis (Jan 25 2019 at 18:42, on Zulip):

@Alexander Regueiro I have a few minutes. I still think it's related to the parent def-id, however. (Though there may be a few other edits required)

In particular, the error that you mention here comes because the TyOpaque was not replaced with an inference variable in the right places. That "instantiation logic" I believe at least interacts with the parent def-id -- but it may be that we also have to invoke it at the right spot

nikomatsakis (Jan 25 2019 at 18:42, on Zulip):

But you mentioned having a bit more debugging to note down?

Alexander Regueiro (Jan 25 2019 at 18:43, on Zulip):

Okay thanks. So I made the change you suggested (and even stopped ConstraintLocator looking within the outermost existential node), but same error...

Alexander Regueiro (Jan 25 2019 at 18:44, on Zulip):

@nikomatsakis what would the "right spot" be here? I haven't done a lot of work with inference.

nikomatsakis (Jan 25 2019 at 18:47, on Zulip):

@Alexander Regueiro have you pushed said changes?

Alexander Regueiro (Jan 25 2019 at 18:47, on Zulip):

@nikomatsakis no, let me do so now

nikomatsakis (Jan 25 2019 at 18:47, on Zulip):

OK. I mean, the next thing is to try and track a bit the origin of the error. It can be an annoying process. One thing that may help is -Ztreat-err-as-bug and RUST_BACKTRACE, which I think in this case should give you a good picture of the backtrace

nikomatsakis (Jan 25 2019 at 18:48, on Zulip):

but if you push I can certainly take a look

Alexander Regueiro (Jan 25 2019 at 18:49, on Zulip):

@nikomatsakis yeah I tried that

Alexander Regueiro (Jan 25 2019 at 18:50, on Zulip):

@nikomatsakis https://gist.github.com/d35867024089dc1c3097307f75c77267

nikomatsakis (Jan 25 2019 at 18:56, on Zulip):

@Alexander Regueiro I don't see any new commits on alexreg/associated_type_bounds yet

nikomatsakis (Jan 25 2019 at 18:57, on Zulip):

also, i'm not sure that gist is what you meant to send...?

Alexander Regueiro (Jan 25 2019 at 19:10, on Zulip):

@nikomatsakis sorry, was cleaning up the commit history for you. pushed now.

Alexander Regueiro (Jan 25 2019 at 19:10, on Zulip):

oops

Alexander Regueiro (Jan 25 2019 at 19:11, on Zulip):

stupid command-line Gist ;-)

Alexander Regueiro (Jan 25 2019 at 19:12, on Zulip):

@nikomatsakis https://gist.github.com/alexreg/6a944716d4bc6b535daa587d31e5afb9

Alexander Regueiro (Jan 25 2019 at 19:26, on Zulip):

@nikomatsakis sorry some nasty debugging code is still in there... hopefully it's okay for you though! you can still pick out the relevant changes easily enough I think.

Alexander Regueiro (Jan 25 2019 at 19:38, on Zulip):

@nikomatsakis so the question is, where do we instantiate the inference var? (if indeed we do) :-)

nikomatsakis (Jan 25 2019 at 22:13, on Zulip):

So @Alexander Regueiro from what I can tell from looking at your branch, the problem is still that you have the wrong parent.

I think at least that the error arises because, when we are running check_fn on the function that winds up defining all the things, it invokes fcx.instantiate_opaque_types_from_value(fn_id, &declared_ret_ty). This will iterate down in the instantiate_opaque_types_in_map fn, walking down the value.

It will encounter the existential type Bar. and then it will check if Bar is "in scope" -- i.e., this is a defining use. It determines yes. So it invokes fold_opaque_ty.

This will create a type inference variable (opaque_types/mod.rs:759, on your branch). It then gets the bounds for the existential type:

 let bounds = predicates_of.instantiate(tcx, substs)

and (later) iterates over them:

        for predicate in bounds.predicates {
            // Change the predicate to refer to the type variable,
            // which will be the concrete type instead of the opaque type.
            // This also instantiates nested instances of `impl Trait`.
            let predicate = self.instantiate_opaque_types_in_map(&predicate);

note that, in the process, it is instantiating any opaque types that appear in those bounds. This should cover your impl Trait -- but I think it doesn't, because the "parent" value is not correct, and so instantiate_opaque_types_in_map does not treat this as a defining use.

Alexander Regueiro (Jan 25 2019 at 22:16, on Zulip):

hmm

Alexander Regueiro (Jan 25 2019 at 22:16, on Zulip):

let me think!

Alexander Regueiro (Jan 25 2019 at 22:16, on Zulip):

sounds like you have a point though, on first sight

Alexander Regueiro (Jan 25 2019 at 22:20, on Zulip):

@nikomatsakis where is the parent node set for the nested existential type node? isn't it where I just edited the code?

Alexander Regueiro (Jan 27 2019 at 02:19, on Zulip):

@nikomatsakis solved. the key was the may_define_existential_type fn. thanks for your help!

nikomatsakis (Jan 28 2019 at 16:31, on Zulip):

@Alexander Regueiro great!

Alexander Regueiro (Jan 28 2019 at 16:32, on Zulip):

@nikomatsakis yeah, seems to be working nicely. (Centril is writing up some test cases, but what I've tested so far looks good. Thanks a lot for the advice.) So, I'm now just working on the last remaining big case for this PR, which is impl Trait in associated types.

Alexander Regueiro (Jan 28 2019 at 16:32, on Zulip):

it's a bit trickier, but I figured out how to do it I think

Alexander Regueiro (Jan 28 2019 at 16:32, on Zulip):

a couple of small questions, which maybe you can help with:

nikomatsakis (Jan 28 2019 at 16:33, on Zulip):

ok

Alexander Regueiro (Jan 28 2019 at 16:34, on Zulip):

can I generate a self Ty during HIR lowering?

Alexander Regueiro (Jan 28 2019 at 16:34, on Zulip):

(and if so, how?)

Alexander Regueiro (Jan 28 2019 at 16:35, on Zulip):

and secondly, I need to generate a unique ident for the fresh associated type. I was thinking of using the "Path" of the impl Trait within the original associated type, but wasn't exactly sure.

Alexander Regueiro (Jan 28 2019 at 16:36, on Zulip):

a nice deterministic way like this would be cool, since I can use that for impls of the trait

nikomatsakis (Jan 28 2019 at 16:36, on Zulip):

can I generate a self Ty during HIR lowering?

what do you mean by a "self ty"?

nikomatsakis (Jan 28 2019 at 16:37, on Zulip):

also, it would help me a bit if you gave me a concrete example of what you are trying to do

nikomatsakis (Jan 28 2019 at 16:37, on Zulip):
trait Foo {
    type Bar: Iterator<Item = impl Display>; // like this, I guess?
}
nikomatsakis (Jan 28 2019 at 16:37, on Zulip):

and secondly, I need to generate a unique ident for the fresh associated type. I was thinking of using the "Path" of the impl Trait within the original associated type, but wasn't exactly sure.

yeah hmm not sure -- say more about the role of this identifier?

Alexander Regueiro (Jan 28 2019 at 16:38, on Zulip):

sorry, yeah, let me be specific

Alexander Regueiro (Jan 28 2019 at 16:39, on Zulip):

for self ty... I want to generate a Path to Self::GeneratedAssocType

Alexander Regueiro (Jan 28 2019 at 16:39, on Zulip):

we're doing desugaring like:

Alexander Regueiro (Jan 28 2019 at 16:40, on Zulip):
trait Foo {
    type Bar: Iterator<Item = impl Display>; // alternatively <Item: Display>
}

to

trait Foo {
    type Bar: Iterator<Item = _0>;
    type _0: Display;
}
nikomatsakis (Jan 28 2019 at 16:40, on Zulip):

right

nikomatsakis (Jan 28 2019 at 16:41, on Zulip):

so you want a path like Self::_0?

Alexander Regueiro (Jan 28 2019 at 16:42, on Zulip):

then we'd have an impl like:

impl Foo for SomeStruct {
    type Bar = ConcreteIterator;
}

desugared to

impl Foo for SomeStruct {
    type Bar = ConcreteIterator;
    type _0 = {inferred};
}
Alexander Regueiro (Jan 28 2019 at 16:42, on Zulip):

yep

Alexander Regueiro (Jan 28 2019 at 16:42, on Zulip):

that

Alexander Regueiro (Jan 28 2019 at 16:43, on Zulip):

at least, that's how I think we want to do desugaring in the impl case

nikomatsakis (Jan 28 2019 at 16:43, on Zulip):

it seems like that should be possible

nikomatsakis (Jan 28 2019 at 16:43, on Zulip):

I'm skimming the HIR structs a bit

Alexander Regueiro (Jan 28 2019 at 16:44, on Zulip):

sure

Alexander Regueiro (Jan 28 2019 at 16:44, on Zulip):

sadly the "usual" way to generate a self ty is through the tcx methods

Alexander Regueiro (Jan 28 2019 at 16:44, on Zulip):

which isn't available during lowering of course

nikomatsakis (Jan 28 2019 at 16:45, on Zulip):

well

nikomatsakis (Jan 28 2019 at 16:45, on Zulip):

that's true

nikomatsakis (Jan 28 2019 at 16:46, on Zulip):

there are some options

nikomatsakis (Jan 28 2019 at 16:46, on Zulip):

I'm debating the best course here

nikomatsakis (Jan 28 2019 at 16:46, on Zulip):

so, for example, when we lower -> impl Foo to -> X (where X is a new existential type), we don't generate a "synthesized" path, but rather make a TyKind:Def(...)

nikomatsakis (Jan 28 2019 at 16:47, on Zulip):

one could imagine adding some similar thing

Alexander Regueiro (Jan 28 2019 at 16:47, on Zulip):

yes

nikomatsakis (Jan 28 2019 at 16:47, on Zulip):

alternatively, you could make a QPath, which is fine

Alexander Regueiro (Jan 28 2019 at 16:47, on Zulip):

I wonder if that may be problematic here though

nikomatsakis (Jan 28 2019 at 16:47, on Zulip):

QPath::Resolved, I imagine

nikomatsakis (Jan 28 2019 at 16:47, on Zulip):

but we need to specify the self type

Alexander Regueiro (Jan 28 2019 at 16:47, on Zulip):

also, the inference for the concrete type is the impl is still not clear to me

nikomatsakis (Jan 28 2019 at 16:48, on Zulip):

which is I think just a path

nikomatsakis (Jan 28 2019 at 16:48, on Zulip):

(when a user types it, anyway)

Alexander Regueiro (Jan 28 2019 at 16:48, on Zulip):

yeah

nikomatsakis (Jan 28 2019 at 16:48, on Zulip):

also, the inference for the concrete type is the impl is still not clear to me

concrete type in the impl?

nikomatsakis (Jan 28 2019 at 16:49, on Zulip):

which is I think just a path

(but you could potentially use TyKind::Def with the id of the Self type parameter)

Alexander Regueiro (Jan 28 2019 at 16:49, on Zulip):

yeah. the concrete type for the associated type

Alexander Regueiro (Jan 28 2019 at 16:49, on Zulip):

(in my above example)

nikomatsakis (Jan 28 2019 at 16:49, on Zulip):

well

nikomatsakis (Jan 28 2019 at 16:50, on Zulip):

your example is probably not the correct desugaring, really

nikomatsakis (Jan 28 2019 at 16:50, on Zulip):

in particular, type _0 = <inferred> is not, I think, what we want

nikomatsakis (Jan 28 2019 at 16:50, on Zulip):

because that was "expose" what _0 is

Alexander Regueiro (Jan 28 2019 at 16:50, on Zulip):

yeah. I was actually wondering about that as soon as I typed it.

Alexander Regueiro (Jan 28 2019 at 16:50, on Zulip):

it's what Centril wrote in his PR.

Alexander Regueiro (Jan 28 2019 at 16:50, on Zulip):

but I'm doubtful now

nikomatsakis (Jan 28 2019 at 16:50, on Zulip):

yes, it's just not correct

Alexander Regueiro (Jan 28 2019 at 16:51, on Zulip):

so how do you propose we do it?

Alexander Regueiro (Jan 28 2019 at 16:51, on Zulip):

I don't thing we can desugar to normal existential types though... can we?

Alexander Regueiro (Jan 28 2019 at 16:51, on Zulip):

(or associated existential types, rather)

nikomatsakis (Jan 28 2019 at 16:51, on Zulip):

I think what we want is something closer to this:

existential type _0;

impl Foo for SomeStruct {
    type Bar = ConcreteIterator;
    type _0 = _0;
}
Alexander Regueiro (Jan 28 2019 at 16:51, on Zulip):

aha

nikomatsakis (Jan 28 2019 at 16:51, on Zulip):

(where the scope of the existential is not the enclosing module, but the impl)

nikomatsakis (Jan 28 2019 at 16:52, on Zulip):

much like how

fn foo() -> impl Blah { .. }

desugars to

existential type X;
fn foo() -> X { .. }

but where X is scoped to the fn

Alexander Regueiro (Jan 28 2019 at 16:52, on Zulip):

HIR and later stages might allow existential types in the module already? not sure. of course, syntax doesn't.

Alexander Regueiro (Jan 28 2019 at 16:52, on Zulip):

only in traits

nikomatsakis (Jan 28 2019 at 16:52, on Zulip):

HIR and later stages might allow existential types in the module already? not sure. of course, syntax doesn't.

why do you say syntax doesn't?

nikomatsakis (Jan 28 2019 at 16:53, on Zulip):

check out e.g. src/test/ui/existential_types/bound_reduction.rs

nikomatsakis (Jan 28 2019 at 16:54, on Zulip):

(just picked at random)

Alexander Regueiro (Jan 28 2019 at 16:55, on Zulip):

that's not scoped to an impl though

Alexander Regueiro (Jan 28 2019 at 16:56, on Zulip):

I mean...

impl Trait for Foo {
    existential type Bar: Send; // not allowed now
}
nikomatsakis (Jan 28 2019 at 16:56, on Zulip):

yes, it is scoped too large

nikomatsakis (Jan 28 2019 at 16:56, on Zulip):

also, this does not compile -- I'm a bit surprised by that.

Alexander Regueiro (Jan 28 2019 at 16:56, on Zulip):

syntax doesn't allow this scoping, is what I mean, but maybe HIR and later copes with it fine?

nikomatsakis (Jan 28 2019 at 16:56, on Zulip):

I suspect it is because of when the impl checks are done

nikomatsakis (Jan 28 2019 at 16:57, on Zulip):

syntax doesn't allow this scoping, is what I mean, but maybe HIR and later copes with it fine?

ah, yes, correct. but that's somehow a secondary problem to the one I just raised =)

nikomatsakis (Jan 28 2019 at 16:57, on Zulip):

right now, the scoping I think is either enclosing mod or -- for impl Trait desugarings -- enclosing fn, I'd have to review the code to see how general the HIR setup is

nikomatsakis (Jan 28 2019 at 16:57, on Zulip):

but we can presumably generalize it

nikomatsakis (Jan 28 2019 at 16:57, on Zulip):

still, scoping the enclosing module should work

nikomatsakis (Jan 28 2019 at 16:57, on Zulip):

(but doesn't)

nikomatsakis (Jan 28 2019 at 16:57, on Zulip):

so I'd probably start by trying to solve that

Alexander Regueiro (Jan 28 2019 at 16:58, on Zulip):

that's a bit worrying yes!

nikomatsakis (Jan 28 2019 at 16:58, on Zulip):

I also think you may be biting off more than you have to chew in this partcular PR

nikomatsakis (Jan 28 2019 at 16:58, on Zulip):

that is, I would encourage you to try to land the PR if it is at a coherent point

nikomatsakis (Jan 28 2019 at 16:58, on Zulip):

vs trying to fix all the things in one PR

Alexander Regueiro (Jan 28 2019 at 16:59, on Zulip):

yeah, maybe a fair point!

nikomatsakis (Jan 28 2019 at 17:00, on Zulip):

gotta run now (meetings), but hopefully that helps a bit :)

Alexander Regueiro (Jan 28 2019 at 17:00, on Zulip):

we don't want another const generics PR

Alexander Regueiro (Jan 28 2019 at 17:00, on Zulip):

one more small questions...

nikomatsakis (Jan 28 2019 at 17:00, on Zulip):

(go for it)

Alexander Regueiro (Jan 28 2019 at 17:00, on Zulip):

(thanks, it does)

Alexander Regueiro (Jan 28 2019 at 17:00, on Zulip):

can you compile those notes on impl-trait-in-bindings soon? :-)

Alexander Regueiro (Jan 28 2019 at 17:00, on Zulip):

from chat, github, etc.

Alexander Regueiro (Jan 28 2019 at 17:00, on Zulip):

gist

Alexander Regueiro (Jan 28 2019 at 17:00, on Zulip):

I can help try to locate them if you like

Alexander Regueiro (Jan 28 2019 at 17:00, on Zulip):

then maybe you could collate them if you don't mind?

Alexander Regueiro (Jan 28 2019 at 17:03, on Zulip):

@nikomatsakis ^

nikomatsakis (Jan 28 2019 at 17:05, on Zulip):

uuuuuuuh ok :) I sort of forgot, were you waiting on notes?

Alexander Regueiro (Jan 28 2019 at 17:17, on Zulip):

@nikomatsakis yeah. just a compilation of your previous notes really, which I think were converging on a good solution. I may have offered some input, but it was mainly you. :-) do you want me to help dig up the various bits and pieces for you to collate into something more coherent and self-contained? I may miss something but happy to try.

Alexander Regueiro (Jan 28 2019 at 21:57, on Zulip):

@nikomatsakis still around by chance? :-)

Alexander Regueiro (Jan 29 2019 at 16:41, on Zulip):

hi @nikomatsakis @scalexm -- did you see https://github.com/rust-lang/rust/issues/57961 by chance?

nikomatsakis (Jan 29 2019 at 17:20, on Zulip):

I didn't see it yet; I do think we want something like it to work, I haven't looked closely at why it doesn't, though I have some theories

Alexander Regueiro (Jan 29 2019 at 18:48, on Zulip):

@nikomatsakis it's basically just because only function return types are currently considered defining uses, like Oli was saying, I think.

Alexander Regueiro (Jan 29 2019 at 18:48, on Zulip):

If you could confirm/deny whether it needs an RFC, that would be great. (Hopefully not, despite what he says, but if we need one, we need one...)

nikomatsakis (Jan 29 2019 at 20:31, on Zulip):

@Alexander Regueiro ok replied

Alexander Regueiro (Jan 29 2019 at 23:39, on Zulip):

@nikomatsakis thanks for that.

Alexander Regueiro (Mar 06 2019 at 15:48, on Zulip):

hey @nikomatsakis... I have a question about this, if you have just a few minutes.

nikomatsakis (Mar 06 2019 at 16:13, on Zulip):

@Alexander Regueiro what's your question

nikomatsakis (Mar 06 2019 at 16:13, on Zulip):

I will be on and off today but I'll try to answer when I can =)

Alexander Regueiro (Mar 06 2019 at 16:14, on Zulip):

so.... for this feature, I want to do something like the following: https://gist.github.com/alexreg/f073d737ae1db10034082e1a3e9c906e

Alexander Regueiro (Mar 06 2019 at 16:14, on Zulip):

@nikomatsakis but ideally (I think) we avoid creating new names for new associated types

Alexander Regueiro (Mar 06 2019 at 16:14, on Zulip):

or do we?

Alexander Regueiro (Mar 06 2019 at 16:14, on Zulip):

the choices seem to be

Alexander Regueiro (Mar 06 2019 at 16:14, on Zulip):

A) embed the desugared associated types within the existing associated types

Alexander Regueiro (Mar 06 2019 at 16:15, on Zulip):

B) generate new ones with unique names (perhaps the name of the DefId for the impl Trait)

Alexander Regueiro (Mar 06 2019 at 16:16, on Zulip):

do you know what I mean?

centril (Mar 06 2019 at 16:17, on Zulip):

btw, in these desugarings, if you gensym, don't forget to ensure that this doesn't creep into diagnostics

nikomatsakis (Mar 06 2019 at 16:19, on Zulip):

@Alexander Regueiro Hmm, I don't think you have to do quite that desugaring

Alexander Regueiro (Mar 06 2019 at 16:19, on Zulip):

@centril I still don't undestand what gensyming is about

centril (Mar 06 2019 at 16:20, on Zulip):

@Alexander Regueiro "generate unique names" is what I mean by that

nikomatsakis (Mar 06 2019 at 16:20, on Zulip):

Presently, if we have:

trait Foo {
    type Bar: Iterator;
}

this is already desugared, to some extent, to the following:

trait Foo
where <Self as Foo>::Bar: Iterator
{
    type Bar;
}
centril (Mar 06 2019 at 16:20, on Zulip):

@nikomatsakis well does that account for implied bounds? if you write the latter explicitly it won't

nikomatsakis (Mar 06 2019 at 16:21, on Zulip):

you could imagine desugaring the example you gave instead to

trait Foo
where <Self as Foo>::Bar: Iterator, <<Self as Foo>::Bar as Iterator>::Item: Send
{
    type Bar;
}
nikomatsakis (Mar 06 2019 at 16:21, on Zulip):

we certainly won't be smart enough to track that all properly right now though

nikomatsakis (Mar 06 2019 at 16:21, on Zulip):

but chalk would, I think

nikomatsakis (Mar 06 2019 at 16:22, on Zulip):

nikomatsakis well does that account for implied bounds? if you write the latter explicitly it won't

I don't recall the specifics, have to check. In chalk, we would handle the implied bounds equivalently in either case (and in fact we don't have a way to represent apart from the desugaring I gave), in rustc maybe not

nikomatsakis (Mar 06 2019 at 16:22, on Zulip):

Point is, I'm not sure that introducing "fictitious" associated types is actually what we want to do

centril (Mar 06 2019 at 16:24, on Zulip):

@nikomatsakis The RFC specified the semantics in terms of generated associated types but noted that with the implied bounds rfc, the usual where clause desugaring would work; I think the latter is ideal and the former is perhaps an acceptable temporary solution

nikomatsakis (Mar 06 2019 at 16:24, on Zulip):

@centril the following compiles:

trait Foo
where <Self as Foo>::Bar: Iterator
{
    type Bar;
}

fn something<T: Foo>(mut x: T::Bar) {
    x.next();
}

fn main() { }
centril (Mar 06 2019 at 16:24, on Zulip):

odd...

nikomatsakis (Mar 06 2019 at 16:24, on Zulip):

(afk for a bit)

centril (Mar 06 2019 at 16:31, on Zulip):

but this doesn't:

trait Foo where
    <Self as Foo>::Bar: Iterator,
    <<Self as Foo>::Bar as Iterator>::Item: Copy
{
    type Bar;
}

fn use_foo<X: Foo>(arg: X) {
    fn assert_copy<T: Copy>() {}
    assert_copy::<<<X as Foo>::Bar as Iterator>::Item>();
}
Alexander Regueiro (Mar 06 2019 at 16:38, on Zulip):

@nikomatsakis are you sure it isn't? I don't see a good alternative, at least until we have implied bounds

centril (Mar 06 2019 at 16:39, on Zulip):

One possible option is the where-clause desugaring as a temporary solution; that gives you worse usability but is probably cleaner... once we get implied bounds we get the usability improvements

Alexander Regueiro (Mar 06 2019 at 16:59, on Zulip):

maybe yes...

Alexander Regueiro (Mar 06 2019 at 16:59, on Zulip):

@centril I may end up going that way in fact, now that you say it

Alexander Regueiro (Mar 06 2019 at 16:59, on Zulip):

it's a good stop-gap

centril (Mar 06 2019 at 17:00, on Zulip):

yup

Alexander Regueiro (Mar 06 2019 at 17:13, on Zulip):

@centril so make sure you note which tests you're writing require the fully-correct implemention, so we can comment them out for now ;-)

centril (Mar 06 2019 at 17:14, on Zulip):

oh dear; I'm focusing on dishing out as many tests as possible now; I think those tests are limited to one file tho

Alexander Regueiro (Mar 06 2019 at 17:33, on Zulip):

heh

Alexander Regueiro (Mar 06 2019 at 17:33, on Zulip):

multiple files is fine to be honest...

Alexander Regueiro (Mar 06 2019 at 17:33, on Zulip):

we can great a new dir

Alexander Regueiro (Mar 06 2019 at 17:39, on Zulip):

@centril so something like this? (desugared-2.rs) -- https://gist.github.com/alexreg/f073d737ae1db10034082e1a3e9c906e

Alexander Regueiro (Mar 06 2019 at 17:39, on Zulip):

does this have any implications for object safety compared to desugared.rs?

centril (Mar 06 2019 at 17:41, on Zulip):
trait Foo where <Self as Foo>::Bar: Iterator, <<Self as Foo>::Bar as Iterator>::Item: Send {
    type Bar;
}

impl Foo for () {
    type Bar = Iteerator<Item = ()>;
}
centril (Mar 06 2019 at 17:41, on Zulip):

(the impl isn't relevant)

Alexander Regueiro (Mar 06 2019 at 17:42, on Zulip):

yeah I know, I just left it in for completeness

Alexander Regueiro (Mar 06 2019 at 17:42, on Zulip):

hmm

centril (Mar 06 2019 at 17:42, on Zulip):

offhand idk about object safety; hear with Niko on that :slight_smile:

Alexander Regueiro (Mar 06 2019 at 17:42, on Zulip):

I think Bar: Iterator is "desugared" at a later point though

Alexander Regueiro (Mar 06 2019 at 17:43, on Zulip):

type Bar: Iterator; is allowed though, surely?

centril (Mar 06 2019 at 17:43, on Zulip):

presumably you do some recursive expansion?

Alexander Regueiro (Mar 06 2019 at 17:43, on Zulip):

no

Alexander Regueiro (Mar 06 2019 at 17:43, on Zulip):

because type Bar: Iterator<Item = Type> is currently left alone during HIR lowerinfg

Alexander Regueiro (Mar 06 2019 at 17:43, on Zulip):

@nikomatsakis yeah, do give us your thoughts on object safety when you're back

centril (Mar 06 2019 at 17:44, on Zulip):

how do you deal with trait Foo { type Assoc: Iterator<Item: Iterator<Item: Copy>>; } if not with a recursive expansion?

Alexander Regueiro (Mar 06 2019 at 17:45, on Zulip):

well, that's recursive... but I mean, only the associated bounds are dealt with specially

centril (Mar 06 2019 at 17:45, on Zulip):

ah; well... it doesn't matter much anyways; they are equivalent ^^

Alexander Regueiro (Mar 06 2019 at 18:01, on Zulip):

okay. :-)

centril (Mar 06 2019 at 18:21, on Zulip):

@Alexander Regueiro there's more work to be done with this, but here's a set of tests that should cover many things: https://gist.github.com/Centril/2470b7f89657da457ed25078a9cdab72 ; it primarily lacks compile-fail tests as well as some of the things noted in the checkboxes... I probably forgot other things too

centril (Mar 06 2019 at 18:22, on Zulip):

but... I've worked enough on this for 2+ days so I need a break :P

Alexander Regueiro (Mar 06 2019 at 19:36, on Zulip):

thanks, will take a look soon :-)

Alexander Regueiro (Mar 06 2019 at 19:36, on Zulip):

oh wow. that long?

Alexander Regueiro (Mar 06 2019 at 19:36, on Zulip):

sounds good anyway!

centril (Mar 06 2019 at 19:47, on Zulip):

There's a lot of cases ;)

centril (Mar 06 2019 at 19:48, on Zulip):

We can iterate on them and add them iteratively ^^

Alexander Regueiro (Mar 06 2019 at 20:58, on Zulip):

heh

Alexander Regueiro (Mar 07 2019 at 01:05, on Zulip):

@nikomatsakis btw, any elaboration on where/how associated types are converted into predicates on traits would be be appreciated. I presume this is only during type checking, and not HIR lowering?

Alexander Regueiro (Mar 07 2019 at 16:36, on Zulip):

@nikomatsakis hey, did you see the above by chance? :-)

nikomatsakis (Mar 07 2019 at 18:30, on Zulip):

nikomatsakis yeah, do give us your thoughts on object safety when you're back

say a bit more -- can you extract the specific question?

nikomatsakis (Mar 07 2019 at 18:30, on Zulip):

nikomatsakis btw, any elaboration on where/how associated types are converted into predicates on traits would be be appreciated. I presume this is only during type checking, and not HIR lowering?

I think this is done during the predicates_of query, let me go look

nikomatsakis (Mar 07 2019 at 18:32, on Zulip):

@Alexander Regueiro this is where we convert the associated type bounds into trait bounds

Alexander Regueiro (Mar 07 2019 at 18:59, on Zulip):

@nikomatsakis do you see the Gist link? are their differences in object safety between the two desugarings?

Alexander Regueiro (Mar 07 2019 at 19:01, on Zulip):

Alexander Regueiro this is where we convert the associated type bounds into trait bounds

that makes perfect sense. I wonder, in the case we have associated type bounds within traits (i.e. within associated type definitions), should we leave things like Iterator<Item: Send> alone until typeck time? i.e. have an HIR representation for it?

Alexander Regueiro (Mar 07 2019 at 19:01, on Zulip):

seems easier...

Alexander Regueiro (Mar 07 2019 at 20:42, on Zulip):

@nikomatsakis btw did you see the issue about trait alias I tagged you in recently?

nikomatsakis (Mar 07 2019 at 22:28, on Zulip):

btw did you see the issue about trait alias I tagged you in recently?

@Alexander Regueiro unlikely, I've had no time for GH notifications in weeks :(

Alexander Regueiro (Mar 07 2019 at 22:28, on Zulip):

heh no worries

nikomatsakis (Mar 07 2019 at 22:28, on Zulip):

do you see the Gist link? are their differences in object safety between the two desugarings?

do you mean this gist?

Alexander Regueiro (Mar 07 2019 at 22:29, on Zulip):

@nikomatsakis no? that links to something in wg-polonius

nikomatsakis (Mar 07 2019 at 22:29, on Zulip):

In that gist, desugared-2.rs doesn't look quite right

nikomatsakis (Mar 07 2019 at 22:30, on Zulip):

no? that links to something in wg-polonius

so it does..fixed

nikomatsakis (Mar 07 2019 at 22:30, on Zulip):

in particular, desugared-2.rs says:

trait Foo where Self::Bar: Send {

but I think it should be

trait Foo where <Self::Bar as Iterator>::Item: Send {
Alexander Regueiro (Mar 07 2019 at 22:30, on Zulip):

@nikomatsakis was just curious what the plan was for trait integrating my changes from that outstanding that detect multi-trait objects via trait aliases (which is permitted but ICEs right now!)

Alexander Regueiro (Mar 07 2019 at 22:31, on Zulip):

@nikomatsakis oh, yes. centril already corrected that. makes sense.

Alexander Regueiro (Mar 07 2019 at 22:31, on Zulip):

is it otherwise equivalent insofar as object safety is concerned?

nikomatsakis (Mar 07 2019 at 22:31, on Zulip):

In any case, I think that .. there are definitely potential differences w/r/t object safety

nikomatsakis (Mar 07 2019 at 22:31, on Zulip):

at present, object types require all the associated types to be named in the object type

Alexander Regueiro (Mar 07 2019 at 22:31, on Zulip):

right

nikomatsakis (Mar 07 2019 at 22:31, on Zulip):

in principle, this restriction can be lifted, but it's tricky

Alexander Regueiro (Mar 07 2019 at 22:32, on Zulip):

doesn't the Self bound affect things too?

nikomatsakis (Mar 07 2019 at 22:32, on Zulip):

so I don't really see any way that the first desugar could be made object-safe

Alexander Regueiro (Mar 07 2019 at 22:32, on Zulip):

mhm

nikomatsakis (Mar 07 2019 at 22:32, on Zulip):

that said, the second one is not object safe either :)

nikomatsakis (Mar 07 2019 at 22:32, on Zulip):

and sort of for the same underlying reason

nikomatsakis (Mar 07 2019 at 22:32, on Zulip):

well, let me think

nikomatsakis (Mar 07 2019 at 22:32, on Zulip):

I take that back somewhat

nikomatsakis (Mar 07 2019 at 22:33, on Zulip):

I suspect the current object safety rules probably would reject it but

nikomatsakis (Mar 07 2019 at 22:33, on Zulip):

I think it would be easier to accept it

nikomatsakis (Mar 07 2019 at 22:33, on Zulip):

in particular, in the first desugaring,

Alexander Regueiro (Mar 07 2019 at 22:33, on Zulip):

yeah. I suppose there are plans to relax object safety rules in the near future?

nikomatsakis (Mar 07 2019 at 22:33, on Zulip):

the compiler doesn't know that _0 is really a "type alias", so to speak

nikomatsakis (Mar 07 2019 at 22:33, on Zulip):

i.e., it is always equal to the Item

nikomatsakis (Mar 07 2019 at 22:33, on Zulip):

of Self::Bar

Alexander Regueiro (Mar 07 2019 at 22:33, on Zulip):

I presume you've seen what dtolnay did with erased-serde? that's kind of interesting, and magical (almost)

Alexander Regueiro (Mar 07 2019 at 22:33, on Zulip):

yeah

nikomatsakis (Mar 07 2019 at 22:34, on Zulip):

whereas that is explicit in the second form, I feel like we could probably permit those sorts of where clauses in object safety and it would work out ok

nikomatsakis (Mar 07 2019 at 22:34, on Zulip):

we might even do so now, though I bet we don't

nikomatsakis (Mar 07 2019 at 22:34, on Zulip):

we have a kind of filter on where Self can appear, I think this falls outside the current rules, but I think (at least off hand...) that the rules could be extended to include this sort of case

Alexander Regueiro (Mar 07 2019 at 22:34, on Zulip):

yeah, I don't know; haven't tested... but I suspect not too

Alexander Regueiro (Mar 07 2019 at 22:34, on Zulip):

okay :-)

nikomatsakis (Mar 07 2019 at 22:34, on Zulip):

the basic idea is

nikomatsakis (Mar 07 2019 at 22:34, on Zulip):

if you were to replace Self with dyn Foo<Bar=X>

nikomatsakis (Mar 07 2019 at 22:35, on Zulip):

would that cause a soundness problem of some kind or get us into "existential types"

nikomatsakis (Mar 07 2019 at 22:35, on Zulip):

in this case, if we did that, we would have <<dyn Foo<Bar=X> as Foo>::Bar as Iterator>::Item: Send

nikomatsakis (Mar 07 2019 at 22:35, on Zulip):

the inner type there is equivalent to just X

nikomatsakis (Mar 07 2019 at 22:35, on Zulip):

so you get <X as Iterator>::Item: Send

nikomatsakis (Mar 07 2019 at 22:36, on Zulip):

basically, the only thing we are doing with Self is projecting associated types out of it

nikomatsakis (Mar 07 2019 at 22:36, on Zulip):

which we already permit

nikomatsakis (Mar 07 2019 at 22:36, on Zulip):

this is my intuition, anyway

nikomatsakis (Mar 07 2019 at 22:36, on Zulip):

(we permit it precisely because their values are all specified in the dyn type)

Alexander Regueiro (Mar 07 2019 at 22:36, on Zulip):

hmm

Alexander Regueiro (Mar 07 2019 at 22:36, on Zulip):

makes sense, I think

nikomatsakis (Mar 07 2019 at 22:36, on Zulip):

(whereas in the other desugaring, we would need to permit projecting an associated type out when its value is not specified in the dyn type)

Alexander Regueiro (Mar 07 2019 at 22:37, on Zulip):

yeah, which sounds harder

Alexander Regueiro (Mar 07 2019 at 22:37, on Zulip):

would this require Chalk in either case?

nikomatsakis (Mar 07 2019 at 22:37, on Zulip):

which we already permit

in particular we permit things like trait Trait where Self::Foo: Bar { .. } to be object safe

nikomatsakis (Mar 07 2019 at 22:37, on Zulip):

would this require Chalk in either case?

well, it's really an existential type sort of situation, I'd certainly rather reason about it in a Chalk-like setting, but I'm not really sure what would be required

nikomatsakis (Mar 07 2019 at 22:38, on Zulip):

it'd be kind of like scala's "path-dependent types"

Alexander Regueiro (Mar 07 2019 at 22:38, on Zulip):

it can certainly be left for a follow-up PR I'd imagine

nikomatsakis (Mar 07 2019 at 22:38, on Zulip):

unless we desugared it somewhere

nikomatsakis (Mar 07 2019 at 22:38, on Zulip):

it can certainly be left for a follow-up PR I'd imagine

what do you mean?

Alexander Regueiro (Mar 07 2019 at 22:38, on Zulip):

making it object-safe

nikomatsakis (Mar 07 2019 at 22:38, on Zulip):

ah, ok, sure

nikomatsakis (Mar 07 2019 at 22:38, on Zulip):

(whereas in the other desugaring, we would need to permit projecting an associated type out when its value is not specified in the dyn type)

this is more than PR :)

nikomatsakis (Mar 07 2019 at 22:38, on Zulip):

but leaving the object safety problem for later seems fine

Alexander Regueiro (Mar 07 2019 at 22:38, on Zulip):

heh

Alexander Regueiro (Mar 07 2019 at 22:39, on Zulip):

okay... good. but I agree with you, that reasoning about projecting associated types out of a dyn seems fine to me.

Alexander Regueiro (Mar 07 2019 at 22:39, on Zulip):

we can note it on the tracking issue when I submit the PR (presuming it doesn't tackle that, which I don't think it will)

Alexander Regueiro (Mar 07 2019 at 22:40, on Zulip):

@nikomatsakis so... the question about desugaring during the typeck phase rather than HIR lowering -- does that make sense to you?

Alexander Regueiro (Mar 07 2019 at 22:40, on Zulip):

(associated type bounds outside of traits would still be desugared in HIR lowering)

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

so... the question about desugaring during the typeck phase rather than HIR lowering -- does that make sense to you?

@Alexander Regueiro which question is that, sorry?

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

Alexander Regueiro this is where we convert the associated type bounds into trait bounds

that makes perfect sense. I wonder, in the case we have associated type bounds within traits (i.e. within associated type definitions), should we leave things like Iterator<Item: Send> alone until typeck time? i.e. have an HIR representation for it?

@nikomatsakis this message I think. (there may have been another one)

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

Ah, I see

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

Hmm

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

I think I would expect to have a HIR representation for it, yes

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

I don't see a "reasonable desugaring" apart from moving the bounds from the associated type up into the trait level

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

and that doesn't .. 100% feel right to me, especially because in GAT-like cases I don't know that we can always do that

Alexander Regueiro (Mar 08 2019 at 20:30, on Zulip):

can't always do what?

Alexander Regueiro (Mar 08 2019 at 20:30, on Zulip):

@nikomatsakis

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

can't always readily do the desugaring at the HIR level

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

maybe you can, but certainly if you were going to do the desugaring, it involves moving things to "different parts of the IR" -- it basically feels a bit too non-local for me

Alexander Regueiro (Mar 08 2019 at 20:58, on Zulip):

@nikomatsakis ah yes, exactly. I mean, I think you could at least in the non-GAT case, but it would be messy

Alexander Regueiro (Mar 08 2019 at 20:59, on Zulip):

@nikomatsakis yes, this is precisely my reasoning. :-)

Alexander Regueiro (Mar 08 2019 at 20:59, on Zulip):

@nikomatsakis still happy with doing HIR-level desugaring for associated type bounds outside of traits though, yeah?

nikomatsakis (Mar 22 2019 at 20:58, on Zulip):

So @Alexander Regueiro -- your PR is almost ready, you were saying?

Alexander Regueiro (Mar 22 2019 at 20:58, on Zulip):

yep!

Alexander Regueiro (Mar 22 2019 at 20:58, on Zulip):

I could do with some advice on a diagnostics message, but that's literally it

nikomatsakis (Mar 22 2019 at 20:59, on Zulip):

Dear @WG-traits, I was thinking that, instead of having me review this solo, maybe we could find somebody else to review it. It could be a good mentoring opportunity. We could do this many ways -- e.g., you could do a pre-pass, find questions, and then we can discuss them together. Or we could schedule some time to do a first review, etc. But I'd like to not be on the hook entirely :) especially as I'll be traveling a lot next week.

Aaron Turon (Mar 22 2019 at 20:59, on Zulip):

I volunteer as tribute :P

nikomatsakis (Mar 22 2019 at 21:00, on Zulip):

sounds good

nikomatsakis (Mar 22 2019 at 21:00, on Zulip):

we can discuss exact strategy next week :)

Alexander Regueiro (Mar 22 2019 at 21:01, on Zulip):

@nikomatsakis in the meanwhile I'll probably move on to investigating the impl Trait lifetime issue

nikomatsakis (Mar 22 2019 at 21:01, on Zulip):

hmm, ok, seems fine, but we should also consider what is best choice

Alexander Regueiro (Mar 22 2019 at 21:07, on Zulip):

@nikomatsakis well you've not really been available for technical discussion the last couple of weeks, and it looks like you won't for at least 10 more days? maybe best for you just to look at it and give a nod or not, since you're so busy. :-)

centril (Mar 22 2019 at 22:05, on Zulip):

@Aaron Turon cool; I made a shit tonne of tests for the PR for you to read :P

tmandry (May 01 2019 at 01:44, on Zulip):

@nikomatsakis okay so I'm almost through with a pre-pass through the code

tmandry (May 01 2019 at 01:45, on Zulip):

maybe we can schedule time to chat through the "interesting" bits

centril (May 01 2019 at 04:15, on Zulip):

@tmandry happy to join you

tmandry (May 06 2019 at 20:22, on Zulip):

@nikomatsakis @centril when are you free to chat this week? I'm free from 1:30-6pm PST today, tomorrow, and most of wednesday

tmandry (May 06 2019 at 20:25, on Zulip):

I can also do friday morning

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

Wednesday seems good

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

I could do 12:30-13:30 Boston time

tmandry (May 06 2019 at 20:30, on Zulip):

that works

centril (May 06 2019 at 20:31, on Zulip):

can we please use UTC? :D

tmandry (May 06 2019 at 20:32, on Zulip):

@centril 16:30-17:30 UTC :)

centril (May 06 2019 at 20:33, on Zulip):

17:30 Monday, Central European Time (CET) works for me

centril (May 06 2019 at 20:33, on Zulip):

(I mean wednesday)

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

I can only do that one slot, basically, or possibly much later.

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

So I think either

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

not that much later

tmandry (May 06 2019 at 20:37, on Zulip):

17:30 CET == 16:30 UTC, so I think we're good

centril (May 06 2019 at 20:38, on Zulip):

@nikomatsakis I believe both times work for me

centril (May 06 2019 at 20:38, on Zulip):

but please make a calendar entry because I'm a forgetful person :D

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

Oh, I didn't notice that @centril switched from UTC to CET =)

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

ok

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

Looks like https://github.com/zulip/zulip/issues/5176 might be close to landing :)

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

/me hopes

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

Hmm, maybe not

tmandry (May 06 2019 at 20:40, on Zulip):

...actually, can we do the second slot @nikomatsakis? :)

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

OK

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

sent calendar invites

centril (May 06 2019 at 20:42, on Zulip):

cheers; btw, I haven't checked the implementation but I wrote a lot of the tests; per my second to last comment on the PR I think some more tests may be needed

centril (May 08 2019 at 18:21, on Zulip):

@nikomatsakis @tmandry are we using Zoom?

centril (May 08 2019 at 18:21, on Zulip):

would be nice

tmandry (May 08 2019 at 18:24, on Zulip):

That works for me. FYI I may be a few minutes late

tmandry (May 08 2019 at 18:35, on Zulip):

Okay I'm around @nikomatsakis @centril

tmandry (May 08 2019 at 18:41, on Zulip):

link to PR: https://github.com/rust-lang/rust/pull/57428

nikomatsakis (May 08 2019 at 18:42, on Zulip):

Hey, I'm here

nikomatsakis (May 08 2019 at 18:42, on Zulip):

Previous meeting ran over

nikomatsakis (May 08 2019 at 18:43, on Zulip):

gimme a second

nikomatsakis (May 08 2019 at 18:47, on Zulip):

ok https://mozilla.zoom.us/j/603998437

nikomatsakis (Jun 05 2019 at 19:39, on Zulip):

So I think that https://github.com/rust-lang/rust/pull/57428 is ready to land, but I'd prefer to leave an "unresovled question" with a link to the test case around nested quantification -- as I noted earlier I think it's probably fine as is, but I haven't had time to think deeply or examine the code about it and I don't know that I will for a bit. @Alexander Regueiro or @centril do you have a link to the test? (I think maybe it was removed from the repo? I'd probably prefer to keep it in...)

centril (Jun 05 2019 at 19:39, on Zulip):

@nikomatsakis https://github.com/rust-lang/rust/pull/57428/commits/8b23ecf34225a916529e50ccc1eacacdcefe1c3d

nikomatsakis (Jun 05 2019 at 19:40, on Zulip):

I guess as long as we keep it in the history we can link to that =)

nikomatsakis (Jun 05 2019 at 19:40, on Zulip):

There is probably an alternate desugaring that would

centril (Jun 05 2019 at 19:40, on Zulip):

@nikomatsakis I would suggest preemptively copying the test =P

centril (Jun 05 2019 at 19:41, on Zulip):

and storing a backup elsewhere

nikomatsakis (Jun 05 2019 at 19:41, on Zulip):
fn nested_bounds_desugared<_0, _1, _2, D>()
where
    D: Clone + Iterator<Item = _2>,
    _2: Send + for<'a> Iterator,
    for<'a, 'b> <_2 as Iterator>::Item: Lam<&'a &'b u8, App = _0>,
    //~^ ERROR nested quantification of lifetimes [E0316]
    _0: Debug,
{}
nikomatsakis (Jun 05 2019 at 19:41, on Zulip):

basically that

nikomatsakis (Jun 05 2019 at 19:41, on Zulip):

I think what I would prefer is to keep the test with an alternate desugaring

nikomatsakis (Jun 05 2019 at 19:41, on Zulip):

(and hence no error)

centril (Jun 05 2019 at 19:41, on Zulip):

seems slightly more complicated

nikomatsakis (Jun 05 2019 at 19:41, on Zulip):

I'm actually not even sure if we need more follow-up -- I mostly wanted to trace through the code to convince myself it was handling the binders correctly, I guess

centril (Jun 05 2019 at 19:41, on Zulip):

but sure

centril (Jun 05 2019 at 19:42, on Zulip):

maybe we should lift the syntactic restriction around nesting everywhere?

nikomatsakis (Jun 05 2019 at 19:42, on Zulip):

plausibly

centril (Jun 05 2019 at 19:42, on Zulip):

@nikomatsakis there are other tests missing: https://github.com/rust-lang/rust/pull/57428#issuecomment-489336637

centril (Jun 05 2019 at 19:42, on Zulip):

but we can add those later

centril (Jun 05 2019 at 19:42, on Zulip):

a checkbox for that would be nice

nikomatsakis (Jun 05 2019 at 19:44, on Zulip):

sounds right

nikomatsakis (Jun 05 2019 at 19:44, on Zulip):

it seems like we should land this branch

nikomatsakis (Jun 05 2019 at 19:44, on Zulip):

I'd be happy with some checkboxes listing tests we want (possibly including the above one)

nikomatsakis (Jun 05 2019 at 19:44, on Zulip):

and not blocking this branch anymore

nikomatsakis (Jun 05 2019 at 19:45, on Zulip):

( maybe you or @Alexander Regueiro can do that? )

centril (Jun 05 2019 at 19:46, on Zulip):

@nikomatsakis Yep; I've been meaning to write those tests but as always one wishes one had 4 hands :P

centril (Jun 05 2019 at 19:46, on Zulip):

I agree we should land ASAP

centril (Jun 05 2019 at 19:46, on Zulip):

and then iterate

nikomatsakis (Jun 05 2019 at 19:48, on Zulip):

just making a list of the tests that are needed seems fine

nikomatsakis (Jun 05 2019 at 19:48, on Zulip):

and putting them in the tracking issue header

Alexander Regueiro (Jun 05 2019 at 19:51, on Zulip):

@nikomatsakis @centril sounds fair on both counts

centril (Jun 05 2019 at 19:57, on Zulip):

@nikomatsakis added to the tracking issue, https://github.com/rust-lang/rust/issues/52662

nikomatsakis (Jun 05 2019 at 20:02, on Zulip):

seems like I broke the branch @Alexander Regueiro -- kind of disappointed to learn that a function named xxx_inner is public

nikomatsakis (Jun 05 2019 at 20:02, on Zulip):

but I guess that's most likely pre-existing

centril (Jun 05 2019 at 20:03, on Zulip):

@nikomatsakis btw, did y'all split the feature gates in the end?

centril (Jun 05 2019 at 20:03, on Zulip):

(dyn, not dyn)

Alexander Regueiro (Jun 05 2019 at 20:10, on Zulip):

@nikomatsakis yeah that was pre-existing heh. inner is a bad name for it I think.

Alexander Regueiro (Jun 05 2019 at 20:10, on Zulip):

want me to change it?

Alexander Regueiro (Jun 05 2019 at 20:11, on Zulip):

@centril thanks fro adding the checkboxoes

centril (Jun 05 2019 at 20:11, on Zulip):

np

Alexander Regueiro (Jun 05 2019 at 20:12, on Zulip):

@nikomatsakis should I just make it pub(super) for now?

Alexander Regueiro (Jun 05 2019 at 20:18, on Zulip):

ah, that's what it was beforee

Alexander Regueiro (Jun 05 2019 at 20:18, on Zulip):

just remove this commit for now?

nikomatsakis (Jun 05 2019 at 20:25, on Zulip):

sure

Last update: Nov 18 2019 at 01:55UTC