Stream: wg-async-foundations

Topic: Lifetime Fixes


Taylor Cramer (Mar 13 2019 at 23:39, on Zulip):

So I've made it a decent ways into getting async fnreturn types to lower using existential type directly rather than going through the existing machinery for -> impl Trait

Taylor Cramer (Mar 13 2019 at 23:40, on Zulip):

however, I've hit some bits that I'm not quite sure the best way to resolve and I wanted to post about them here while I thought to check if anyone had any brilliant ideas

Taylor Cramer (Mar 13 2019 at 23:40, on Zulip):

One of them is that the return type for an async fn can itself be an impl Trait

Taylor Cramer (Mar 13 2019 at 23:41, on Zulip):

today we lower the return type using the function's DefId in order to resolve its generic parameters

Taylor Cramer (Mar 13 2019 at 23:41, on Zulip):

Ideally it would shift to (at least conceptually) have its parent generics provided by the existential type used for async fn

Taylor Cramer (Mar 13 2019 at 23:42, on Zulip):

however, we assume in a bunch of places that impl Trait types have a parent that is a function (specifically a function) in order to pull out its generics

Taylor Cramer (Mar 13 2019 at 23:43, on Zulip):

and changing all of that feels rather more intrusive than what I'd originally hoped.

Taylor Cramer (Mar 13 2019 at 23:50, on Zulip):

One option would be to leave impl_trait_fn for the ExistTy set to the parenting function, which would cause it to pick up generic parameters from it directly

Taylor Cramer (Mar 13 2019 at 23:51, on Zulip):

But I haven't tried that yet, so I'm not sure what it'll destroy ;)

Nemo157 (Mar 14 2019 at 06:12, on Zulip):

Sounds like having the extension to allow nested impl Trait in existential types would be useful

Taylor Cramer (Mar 14 2019 at 16:29, on Zulip):

@Nemo157 presumably that would desugar away at lowering time, which is where I am anyways

Taylor Cramer (Mar 14 2019 at 16:29, on Zulip):

But I think the fix I was suggesting worked

Taylor Cramer (Mar 14 2019 at 16:29, on Zulip):

the generics still seem to be getting picked up properly

Taylor Cramer (Mar 15 2019 at 00:19, on Zulip):

This function is an interesting case:
fn foo<'a>(x: &u8, _: &'a u8) -> (&u8, &'a u8) { (x, &5) }

Taylor Cramer (Mar 15 2019 at 00:19, on Zulip):

because it compiles if you remove the second argument

Taylor Cramer (Mar 15 2019 at 00:20, on Zulip):

so we actually need to track whether or not named lifetimes are used in the arguments when deciding whether or not it's valid to replace elided lifetimes in the output with the name of the fresh lifetime we introduced for the argument-position elided lifetime

Taylor Cramer (Mar 15 2019 at 00:21, on Zulip):

If there's exactly one fresh elided lifetime introduced in the arguments, we replace the non-dyn elided lifetimes in the output

Taylor Cramer (Mar 15 2019 at 00:22, on Zulip):

but if there are zero or more than one fresh lifetimes introduced, or if any named lifetimes are introduced, we want to error if we see an elided lifetime in the output

Taylor Cramer (Mar 19 2019 at 00:58, on Zulip):

I've opened https://github.com/rust-lang/rust/pull/59286 with the refactoring we discussed

existential type Foo<'a, 'b>:;
fn foo<'a, 'b>(_: &'a u8, _: &'b u8) -> Foo<'a, 'b> { () }
Taylor Cramer (Mar 19 2019 at 00:58, on Zulip):

however this code doesn't compile ^

Taylor Cramer (Mar 19 2019 at 00:58, on Zulip):

so naturally the async fn that I just made desugar to that also does not compile XD

Taylor Cramer (Mar 19 2019 at 01:00, on Zulip):

@nikomatsakis and @oli do either of you have thoughts on the best approach to fixing that error? I'm not aware of a "minimal intersection of the following lifetimes" function or a way to write it today, but I can continue to hunt around.

oli (Mar 19 2019 at 08:23, on Zulip):

Do you have a -Ztreat-err-as-bug backtrace on that error?

nikomatsakis (Mar 19 2019 at 15:10, on Zulip):

@Taylor Cramer

WIP because this doesn't currently successfully allow multiple
argument-position elided lifetimes since existential type
doesn't yet support multiple lifetimes where neither outlive
the other:

Oh yeah, that's true =) argh

nikomatsakis (Mar 19 2019 at 15:10, on Zulip):

for some reason we overlooked this earlier, I guess

nikomatsakis (Mar 19 2019 at 15:11, on Zulip):

@Taylor Cramer to confirm, though, if you have a relationship between them (e.g., 'a: 'b) then it does work?

nikomatsakis (Mar 19 2019 at 15:13, on Zulip):

To put this another way, there were a variety of lifetime-related limitations, I think this refactoring should improve at least some of them, right? (and hopefully fixes the interactions with dyn trait objects)

Taylor Cramer (Mar 19 2019 at 15:15, on Zulip):

Yes, this refactoring fixes a number of things

nikomatsakis (Mar 19 2019 at 15:15, on Zulip):

Anyway, there is no "minimal intersection" of the lifetimes fn to find, indeed. That particular example is not a very good one in terms of showing the challenge.

nikomatsakis (Mar 19 2019 at 15:15, on Zulip):

i.e., the "hidden" type there is (), iiuc

nikomatsakis (Mar 19 2019 at 15:15, on Zulip):

which of course has no lifetimes at all

nikomatsakis (Mar 19 2019 at 15:15, on Zulip):

iirc this error .. hmm. I had better look back and not rely on my memory.

Taylor Cramer (Mar 19 2019 at 15:16, on Zulip):

I'm not at my computer just now but would be happy to supply more info when I finish breakfast :)

nikomatsakis (Mar 19 2019 at 15:19, on Zulip):

the relevant code (which I am re-reading now) is this fn, constrain_opaque_types

nikomatsakis (Mar 19 2019 at 15:20, on Zulip):

I think we could change how this check works

nikomatsakis (Mar 19 2019 at 15:20, on Zulip):

In a way that might help

Taylor Cramer (Mar 19 2019 at 15:23, on Zulip):

Yeah. It seems to me that the thing you want is to express that the existential type may not outlive either lifetime, with no particular relationship between the two

Taylor Cramer (Mar 19 2019 at 15:23, on Zulip):

Whereas today it seems like it's trying to identify a single lifetime that the existential type outlives

nikomatsakis (Mar 19 2019 at 15:24, on Zulip):

OK, so, here is what I am presently thinking

nikomatsakis (Mar 19 2019 at 15:24, on Zulip):

the challenge here is that sometimes we don't have enough constraints in inference

nikomatsakis (Mar 19 2019 at 15:25, on Zulip):

Whereas today it seems like it's trying to identify a single lifetime that the existential type outlives

yes, it is-- this was a simplification we put in to delay having to deal with this problem :)

nikomatsakis (Mar 19 2019 at 15:25, on Zulip):

but I guess the bill comes due

nikomatsakis (Mar 19 2019 at 15:25, on Zulip):

or maybe we can skip it a bit longer :)

nikomatsakis (Mar 19 2019 at 15:26, on Zulip):

can we dig a bit into the async fn example..

nikomatsakis (Mar 19 2019 at 15:26, on Zulip):

so we have something like

async fn async_fn_multiple_args(x: &u8, _y: &u8) -> u8 {
  *x + *y
}
nikomatsakis (Mar 19 2019 at 15:27, on Zulip):

this gets desugared to something like

existential type Foo<'a, 'b>: Future<Output = u8>;

fn async_fn_multiple_args<'a, 'b>(x: &'a u8, _y: &'a u8) -> Foo<'a, 'b> {
    async { *x + *y } // say
}
nikomatsakis (Mar 19 2019 at 15:27, on Zulip):

so the hidden type will be some kind of generator with two upvars

nikomatsakis (Mar 19 2019 at 15:28, on Zulip):

hmm, yeah, this is the hard case :)

nikomatsakis (Mar 19 2019 at 15:29, on Zulip):

the generator type will be something like Generator<&'0 u8, &'1 u8> for some fresh variables '0 and '1

nikomatsakis (Mar 19 2019 at 15:29, on Zulip):

and we ought to have some constraints that (e.g.)

&'a u8 <: &'0 u8
&'b u8 <: &'1 u8

based on the fact that the first captured variable (x) has type &'a u8 etc

nikomatsakis (Mar 19 2019 at 15:30, on Zulip):

which means we have region constraints

'a: '0
'b: '1
nikomatsakis (Mar 19 2019 at 15:30, on Zulip):

the challenge here is that '0 could (for example) be inferred to 'empty

nikomatsakis (Mar 19 2019 at 15:30, on Zulip):

which will give us an error later on

nikomatsakis (Mar 19 2019 at 15:31, on Zulip):

specifically, in the infer_opaque_definition_from_instantiation function -- it is looking to make sure that all the regions in the hidden type are 'a or 'b or otherwise something externally nameable

nikomatsakis (Mar 19 2019 at 15:31, on Zulip):

the challenge here is that '0 could (for example) be inferred to 'empty

this is probably not quite right, there is probably some bound that it must outlive the fn body

nikomatsakis (Mar 19 2019 at 15:32, on Zulip):

so '0 and '1 would get inferred to the fn body, but that's not an "externally nameable region", which is why we would get an error

nikomatsakis (Mar 19 2019 at 15:33, on Zulip):

so this is why we are looking to add a constraint like '0: 'a etc. But that's a bit .. tricky for us to do. The easy case is when there is some "minimal" region amongst the set of named regions -- then we can just make sure everything at least outlives that

nikomatsakis (Mar 19 2019 at 15:33, on Zulip):

but what we really want is a constraint like

('0: 'a || '0: 'b)

since choosing '0: 'b would lead to an error, we'd pick the first half.

nikomatsakis (Mar 19 2019 at 15:33, on Zulip):

the region solver doesn't really like ||, but I think we could plausibly extend it to handle this specific case better

nikomatsakis (Mar 19 2019 at 15:34, on Zulip):

this was the work I was hoping to put off =)

nikomatsakis (Mar 19 2019 at 15:41, on Zulip):

However, I could imagine some kind of simple check -- the idea would be that we have constraints of the form '0 in ('a || 'b), which means "'0 must be one of the following regions". We can then do an elaboration step where we look over the relations to try and rule things out. So, for example, 'a: '0 means that '0 = 'b is going to be an error. If we can reduce that set from in to a singleton set (as we can do here), then we can easily handle it.

This is a bit tricky because it's not really how our inference normally operates, it doesn't fit in super naturally. (Also, we'd have to integrate it into NLL too, but I guess it would work quite similarly.)

nikomatsakis (Mar 19 2019 at 15:42, on Zulip):

(Perhaps those constraints are more like '0: ('a || 'b), which is a subset of equality.)

nikomatsakis (Mar 19 2019 at 15:42, on Zulip):

e.g., '0 = 'static would also be ok

Taylor Cramer (Mar 19 2019 at 17:52, on Zulip):

@nikomatsakis did you still want to chat here?

Taylor Cramer (Mar 19 2019 at 17:52, on Zulip):

(following up from your comment in the mtg)

Taylor Cramer (Mar 19 2019 at 19:18, on Zulip):

'0 in ('a || 'b) should actually be '0 in ('a || 'b || 'empty), right?

Taylor Cramer (Mar 19 2019 at 19:19, on Zulip):

but I'd have suspected this logic would already exist for type parameters

Taylor Cramer (Mar 19 2019 at 19:20, on Zulip):

related to the bits @oli and I had discussed before about the rules around e.g. type parameters all being left generic in the scope of the definition site

Taylor Cramer (Mar 19 2019 at 19:20, on Zulip):

all the same rules would apply here

nikomatsakis (Mar 19 2019 at 21:39, on Zulip):

but I'd have suspected this logic would already exist for type parameters

there is some similar-ish logic for projections

nikomatsakis (Mar 19 2019 at 21:39, on Zulip):

'0 in ('a || 'b) should actually be '0 in ('a || 'b || 'empty), right?

'empty no, but 'static yes

nikomatsakis (Mar 19 2019 at 21:39, on Zulip):

I mean maybe 'empty "maybe" is a better version

nikomatsakis (Mar 19 2019 at 21:40, on Zulip):

oh I guess maybe you mean logic to pick the type parameters .. I guess i'm not quite sure what you mean about type parametesr

Taylor Cramer (Mar 19 2019 at 21:51, on Zulip):

@nikomatsakis there are rules around e.g. fn foo<A, B>(a: A, b: B) -> Foo<A, B> { .. } being allowed with all the following bodies: (a, b), a, and b

Taylor Cramer (Mar 19 2019 at 21:52, on Zulip):

but fn foo<A>(a: A) -> Foo<A, A> { ... } is not allowed, since it's unknown whether or not from a body like (a, a) the underlying type varies with respect to the first type parameter, the second, or both

Taylor Cramer (Mar 19 2019 at 21:53, on Zulip):

(e.g. it could be type Foo<A, B> = (A, B);, type Foo<A, B> = (B, A);, type Foo<A, B> = (A, A), or type Foo<A, B> = (B, B);)

Taylor Cramer (Mar 19 2019 at 21:53, on Zulip):

all are equally valid

Taylor Cramer (Mar 19 2019 at 21:54, on Zulip):

for the generalized version in existential type Foo<'a, 'b> = (&'a u8, &'b u8) we have the same problem

Taylor Cramer (Mar 19 2019 at 23:33, on Zulip):

i've pushed up a new version of https://github.com/rust-lang/rust/pull/59286 which has some more tests as well as an improved error message for the multiple-lifetimes case.

Taylor Cramer (Mar 19 2019 at 23:34, on Zulip):

Getting that in fixes all of the outstanding lifetime bugs around async fn except for the multiple lifetimes issue.

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

@Taylor Cramer I'll try to respond to these comments tomorrow or so, btw, and maybe do some experimenting with the region solver

Taylor Cramer (Mar 20 2019 at 20:53, on Zulip):

@nikomatsakis okay, sg

Taylor Cramer (Mar 21 2019 at 16:31, on Zulip):

@varkor do you have time to look at https://github.com/rust-lang/rust/pull/59286 today? I'm headed out of town soon and wanted to make sure I'd done everything I could to try and get this all fixed up before then.

varkor (Mar 21 2019 at 17:02, on Zulip):

I should be able to review in about 5 hours, if that's soon enough

varkor (Mar 21 2019 at 17:02, on Zulip):

sorry, the past couple of days have been a little busy

Taylor Cramer (Mar 21 2019 at 17:47, on Zulip):

@varkor no worries, 5 hours is fine!

Charles Lew (Mar 29 2019 at 02:37, on Zulip):

For a practical usage scenario of multiple lifetime async functions: see
https://rust-lang.zulipchat.com/#narrow/stream/193127-wg-database/topic/async.20database.20interface

nikomatsakis (Apr 08 2019 at 21:19, on Zulip):

OK so @Taylor Cramer -- we should schedule a time to talk about this -- I wonder if I should do some experimentation first

nikomatsakis (Apr 08 2019 at 21:19, on Zulip):

Are there days that work better for you?

Taylor Cramer (Apr 08 2019 at 21:20, on Zulip):

I'm pretty busy on Thursdays but besides that my schedule is generally pretty light

nikomatsakis (Apr 09 2019 at 21:07, on Zulip):

@Taylor Cramer what about this Friday at (say) 13:00 Boston time?

nikomatsakis (Apr 09 2019 at 21:07, on Zulip):

actually, maybe tomorrow at 2pm?

nikomatsakis (Apr 09 2019 at 21:07, on Zulip):

given that you said your schedule is light, i'm going to hope that works :)

nikomatsakis (Apr 09 2019 at 21:09, on Zulip):

Link to calendar event

nikomatsakis (Apr 10 2019 at 17:58, on Zulip):

@Taylor Cramer so I think i may have trouble getting a room for a video call

nikomatsakis (Apr 10 2019 at 17:58, on Zulip):

let me go double check

nikomatsakis (Apr 10 2019 at 18:01, on Zulip):

well I'll just find a secluded corner

nikomatsakis (Apr 10 2019 at 18:04, on Zulip):

ok, don't see anyone there anyway

nikomatsakis (Apr 10 2019 at 18:04, on Zulip):

so I'll just try to do this on my own and leave some notes :)

Taylor Cramer (Apr 10 2019 at 18:06, on Zulip):

@nikomatsakis heh

Taylor Cramer (Apr 10 2019 at 18:06, on Zulip):

I must've joined the call just after you left

Taylor Cramer (Apr 10 2019 at 18:07, on Zulip):

@nikomatsakis did you want to chat here, in zulip, on a doc somewhere?

Taylor Cramer (Apr 10 2019 at 18:07, on Zulip):

or in zoom?

nikomatsakis (Apr 10 2019 at 18:07, on Zulip):

oh, no worries

nikomatsakis (Apr 10 2019 at 18:07, on Zulip):

we could chat in zoom or here

nikomatsakis (Apr 10 2019 at 18:07, on Zulip):

I was just re-reading what I wrote before and trying to remember wtf was going on

nikomatsakis (Apr 10 2019 at 18:08, on Zulip):

let's just do zoom

Taylor Cramer (Apr 10 2019 at 18:08, on Zulip):

should we make a paper?

Taylor Cramer (Apr 10 2019 at 18:09, on Zulip):

https://paper.dropbox.com/doc/Multiple-Unrelated-Lifetimes-in-Existential-Types--Aa9M~6y6bRQ_y1eiaCzMpZgyAQ-AuCQq4Ewy39j8Hnj3n9Qg

nikomatsakis (Apr 10 2019 at 18:10, on Zulip):

for some reason

nikomatsakis (Apr 10 2019 at 18:10, on Zulip):

zoom doesn't want to start for me

nikomatsakis (Apr 10 2019 at 18:10, on Zulip):

/me grumbles

Taylor Cramer (Apr 10 2019 at 18:10, on Zulip):

heh, it just kicked me out

nikomatsakis (Apr 10 2019 at 18:11, on Zulip):

ok sorry

nikomatsakis (Apr 10 2019 at 18:11, on Zulip):

that was my fault

nikomatsakis (Apr 10 2019 at 18:11, on Zulip):

try to join again, should be good now

nikomatsakis (Apr 10 2019 at 18:12, on Zulip):

@Taylor Cramer :point_up:

nikomatsakis (Apr 16 2019 at 21:15, on Zulip):

left some initial notes here, @Taylor Cramer -- I guess not a ton new there, but I did go refresh my memory as to how the NLL solver works

Taylor Cramer (Apr 16 2019 at 21:27, on Zulip):

thanks! :)

Taylor Cramer (Apr 16 2019 at 21:28, on Zulip):

(@nikomatsakis )

Taylor Cramer (Apr 24 2019 at 19:35, on Zulip):

@nikomatsakis thanks for the comment https://github.com/rust-lang/rust/issues/56238#issuecomment-486392893

nikomatsakis (May 07 2019 at 17:44, on Zulip):

@Taylor Cramer ps, if I were to carve out time for this, I think it would be on Friday

Taylor Cramer (May 07 2019 at 17:53, on Zulip):

@nikomatsakis okay

Taylor Cramer (May 07 2019 at 17:53, on Zulip):

I'll continue to investigate later today, but my expectation would be that I wouldn't get very far :(

Taylor Cramer (May 20 2019 at 17:43, on Zulip):

@nikomatsakis did you push on this any further?

Taylor Cramer (May 22 2019 at 15:16, on Zulip):

ping @nikomatsakis

Taylor Cramer (May 29 2019 at 21:07, on Zulip):

@nikomatsakis

nikomatsakis (May 29 2019 at 21:54, on Zulip):

@Taylor Cramer I started working on it, yeah.

nikomatsakis (May 29 2019 at 21:55, on Zulip):

I didn't get too far but I plan to spend more time tomorrow/Friday

nikomatsakis (Jun 03 2019 at 20:15, on Zulip):

@Taylor Cramer so I think I have the interation into the lexical solver basically working.

nikomatsakis (Jun 03 2019 at 20:15, on Zulip):

Not the most efficient thing ever, but probably good enough.

nikomatsakis (Jun 03 2019 at 20:15, on Zulip):

Though I've .. actually not tested it on the async example, I should do that

nikomatsakis (Jun 03 2019 at 20:15, on Zulip):

I still have to do the integration into the NLL solver though

nikomatsakis (Jun 10 2019 at 21:32, on Zulip):

OK, the NLL Solver integration is like 50% done

nikomatsakis (Jun 12 2019 at 01:05, on Zulip):

@Taylor Cramer this test is passing now

trait Trait<'a, 'b> { }
impl<T> Trait<'_, '_> for T { }

// Here we wind up selecting `'a` and `'b` in the hidden type because
// those are the types that appear inth e original values.

fn upper_bounds<'a, 'b>(a: &'a u8, b: &'b u8) -> impl Trait<'a, 'b> {
    // In this simple case, you have a hidden type `(&'0 u8, &'1 u8)` and constraints like
    //
    // ```
    // 'a: '0
    // 'b: '1
    // '0 in ['a, 'b]
    // '1 in ['a, 'b]
    // ```
    //
    // We use the fact that `'a: 0'` must hold (combined with the in
    // constraint) to determine that `'0 = 'a` must be the answer.
    (a, b)
}
Taylor Cramer (Jun 12 2019 at 05:59, on Zulip):

\o/

nikomatsakis (Jun 12 2019 at 14:47, on Zulip):

Update: this test is passing too (actually, it probably was before, but I wasn't running it)

// edition:2018
// run-pass

// Test that we can use async fns with multiple arbitrary lifetimes.

#![feature(arbitrary_self_types, async_await, await_macro)]

use std::ops::Add;

async fn multiple_named_lifetimes<'a, 'b>(_: &'a u8, _: &'b u8) {}

async fn multiple_hrtb_and_single_named_lifetime_ok<'c>(
    _: impl for<'a> Add<&'a u8>,
    _: impl for<'b> Add<&'b u8>,
    _: &'c u8,
) {}

async fn multiple_elided_lifetimes(_: &u8, _: &u8) {}

fn main() {}
nikomatsakis (Jun 12 2019 at 14:48, on Zulip):

I just need to dot some i's and cross some t's I guess

nikomatsakis (Jun 12 2019 at 14:48, on Zulip):

I realized a complication around things like let x: impl Trait -- but for now I think i'll just force the old behavior in such cases

nikomatsakis (Jun 12 2019 at 14:54, on Zulip):

Argh, that existing code is just ICEing though when I try to make tests (lotsa bugs lurking there)

nikomatsakis (Jun 12 2019 at 14:55, on Zulip):

I guess maybe I'll just file an issue for now

nikomatsakis (Jun 12 2019 at 14:56, on Zulip):

I guess I'm basically hitting https://github.com/rust-lang/rust/issues/60473

nikomatsakis (Jun 12 2019 at 15:51, on Zulip):

Posted https://github.com/rust-lang/rust/pull/61775

centril (Jun 12 2019 at 16:03, on Zulip):

The problem here is that every region R in the hidden type must be equal to either 'a or 'b (or 'static) -- in the past, the only kinds of constraints we had were outlives constraints, and since 'a and 'b are unrelated, there was no outlives constraint we could issue that would enforce that (R: 'a and R: 'b are both too strict, for example). But now we can issue a pick constraint: pick R from ['a, 'b].

Can you discuss this more in depth and in relation to exists<...> ?

nikomatsakis (Jun 19 2019 at 15:22, on Zulip):

oh btw @Taylor Cramer I tried to add the feature gate but was surprised to find that the return type spans for async fn didn't seem to have the "desugaring" option on them

nikomatsakis (Jun 19 2019 at 15:22, on Zulip):

I have to look at a bit more deeply at that

nikomatsakis (Jun 19 2019 at 15:22, on Zulip):

(I was going to make it feature-gated unless part of the desugaring)

Taylor Cramer (Jun 19 2019 at 16:00, on Zulip):

@nikomatsakis indeed, there are a few other nodes that could be marked with CompilerDesugaringKind::Async here: https://github.com/rust-lang/rust/blob/master/src/librustc/hir/lowering.rs#L2601

Taylor Cramer (Jun 19 2019 at 16:01, on Zulip):

today it only does that for the existential type

Taylor Cramer (Jun 19 2019 at 16:02, on Zulip):

I can send a PR for that if you'd like, otherwise it seems like a fine small thing to include in your change

nikomatsakis (Jun 19 2019 at 16:54, on Zulip):

the PR is at that annoying stage where it's accumulating a long list of "random commits"

nikomatsakis (Jun 19 2019 at 16:54, on Zulip):

this is just one more I guess :)

centril (Jun 19 2019 at 17:29, on Zulip):

@nikomatsakis It's a good idea to do break-out PRs ^^

nikomatsakis (Jun 20 2019 at 15:22, on Zulip):

I have pushed the feature gate as well as a first draft of a rustc-guide chapter, though I see the PR needs to be updated

centril (Jun 25 2019 at 15:11, on Zulip):

@nikomatsakis what's with the arbitrary_self_types and await_macro in https://github.com/rust-lang/rust/pull/61775/commits/256abeffcdc1b1eb79a98baf07b870a045933147 -- are those needed?

centril (Jun 25 2019 at 15:12, on Zulip):

also btw, in case it was lost in the sea of nits I had... ( :P ) : https://github.com/rust-lang/rust/pull/61775#discussion_r295907400

nikomatsakis (Jun 25 2019 at 16:36, on Zulip):

what's with the arbitrary_self_types and await_macro in https://github.com/rust-lang/rust/pull/61775/commits/256abeffcdc1b1eb79a98baf07b870a045933147 -- are those needed?

no, they're just cargo culted. I fixed some of the tests but not all.

nikomatsakis (Jun 25 2019 at 16:36, on Zulip):

also btw, in case it was lost in the sea of nits I had... ( :P ) : https://github.com/rust-lang/rust/pull/61775#discussion_r295907400

it was not, I was just waiting to address the important question in a bit more depth

nikomatsakis (Jun 25 2019 at 16:37, on Zulip):

though the TL;DR is that I don't see a problem

centril (Jun 25 2019 at 17:04, on Zulip):

Thanks for the tl;dr; I'll wait for the elaboration in the code-comment/the PR :slight_smile:

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

OK so I think I am ready to land this PR. :)

nikomatsakis (Jun 28 2019 at 19:47, on Zulip):

I keep having this feeling like I could write more thorough tests, though I'm not sure -- I guess I could dig into making sure that each of the scenarios is covered.

Last update: Nov 18 2019 at 01:10UTC