Stream: t-compiler

Topic: steering meeting 2019-06-28


centril (Jun 27 2019 at 20:30, on Zulip):

So we need to discuss a possible immediate backport of https://github.com/rust-lang/rust/pull/61207 to 1.36.0 stable due to forward compat concerns with the second to last case in https://gist.github.com/nikomatsakis/c5c8e585989924e8485df48ab6bbc3dd

centril (Jun 27 2019 at 20:30, on Zulip):

cc @pnkfelix @Taylor Cramer @nikomatsakis

centril (Jun 27 2019 at 20:31, on Zulip):

and @Pietro Albini

centril (Jun 27 2019 at 20:31, on Zulip):

(for tomorrow)

Pietro Albini (Jun 27 2019 at 20:31, on Zulip):

and @simulacrum

Pietro Albini (Jun 27 2019 at 20:31, on Zulip):

especially because I'm not sure if I'll able to be online that much tomorrow

pnkfelix (Jun 27 2019 at 20:31, on Zulip):

I might as well cc @T-compiler, right?

centril (Jun 27 2019 at 20:36, on Zulip):

Some context:
- We discussed this on the language team meeting today. Attendance was me, Felix, Taylor, and Josh. Our conclusion was to attempt a backport.
- This is particularly problematic due to case 7 and 10 being weird together.
- This was tested on crater with zero regressions.

centril (Jun 27 2019 at 20:37, on Zulip):

@eddyb seems to have already reviewed the PR; they said:

I like how simple this is!

However, it would be good if as many as possible can give the PR a thorough review and add additional test cases if you believe it to be necessary.

centril (Jun 27 2019 at 20:37, on Zulip):

Ideally that should happen ASAP because we need this done before the 30th is over

pnkfelix (Jun 27 2019 at 20:54, on Zulip):

(I will note that I did express a slight misgiving, in the sense of "it doesn't seem like it would be the end of the world to not have this backport"; but I do appreciate the motivation that with the stabilization of the Future API's, code like this will become more commonplace)

pnkfelix (Jun 27 2019 at 20:55, on Zulip):

and I think @Taylor Cramer made the point that it would be a disaster to not address this <= the point when async-await is stabilized.

Taylor Cramer (Jun 27 2019 at 21:01, on Zulip):

Yeah, it for sure needs to be in by 1.37 / 1.38, but missing 1.36 probably isn't the end of the world

simulacrum (Jun 28 2019 at 04:01, on Zulip):

I won't personally be able to manage backporting until Saturday (which is technically not too late, but gives us essentially no margin for error). I am not against backporting, really, especially given crater run. I would backport directly onto stable branch... we might need to delete artifacts for them to get properly copied to dev-static, but that can happen at any point: we always publish to rust-ci-2(naming?) bucket first IIRC.

simulacrum (Jun 28 2019 at 04:03, on Zulip):

(I will not be able to attend tomorrow's meeting either -- unfortunately -- but don't block on me for any decisions wrt to backport)

nikomatsakis (Jun 28 2019 at 12:22, on Zulip):

Let me try to find a better way to summarize the results here. I am concerned that the PR doesn't have the behavior I think we want, but I want to double check.

pnkfelix (Jun 28 2019 at 12:25, on Zulip):

at the T-lang meeting last night, @Taylor Cramer said several times that they did not understand, in your gist, why lines 2+3 have differing static semantics under "Niko's (preferred?) rule"

pnkfelix (Jun 28 2019 at 12:26, on Zulip):

and more generally, the group at large seemed to basically say that "Niko's rule" is a non-starter due to its regressing behavior for lines 2 and 5.

pnkfelix (Jun 28 2019 at 12:27, on Zulip):

So, @nikomatsakis , you may want to spell out somewhere what you see as the motivation/justification for "Niko's rule", if that is indeed what you want.

pnkfelix (Jun 28 2019 at 12:27, on Zulip):

(Also, it would probably be good to add explicit row numbers to that table. It was very annoying trying to describe the entries last night.)

nikomatsakis (Jun 28 2019 at 12:29, on Zulip):

Yeah, no, Niko's rule wasn't meant to be seen by the public =)

nikomatsakis (Jun 28 2019 at 12:29, on Zulip):

actually the gist itself wasn't really ready

pnkfelix (Jun 28 2019 at 12:30, on Zulip):

You didn't hold onto your &mut gist long enough.

nikomatsakis (Jun 28 2019 at 12:37, on Zulip):

OK, I will revamp the table, but I think my take is that the PR is indeed an improvement, but I think we may want to deprecate some of the things that we currently accept

nikomatsakis (Jun 28 2019 at 12:37, on Zulip):

I just did some more testing, but I have to run right now

nikomatsakis (Jun 28 2019 at 13:02, on Zulip):

OK here is a revised gist that I believe is accurate.

pnkfelix (Jun 28 2019 at 13:08, on Zulip):

(I assume X means "rustc issues an error due to ambiguous lifetime")

centril (Jun 28 2019 at 13:23, on Zulip):

S3 and N1 are symmetrical. Only change is Pin to Box.

centril (Jun 28 2019 at 13:24, on Zulip):

And the mut bit but that's irrelevant

nikomatsakis (Jun 28 2019 at 14:01, on Zulip):

S3 and N1 are symmetrical. Only change is Pin to Box.

this is intentional :)

centril (Jun 28 2019 at 14:01, on Zulip):

@nikomatsakis but why does it say X then?

pnkfelix (Jun 28 2019 at 14:01, on Zulip):

hello @T-compiler/meeting

nikomatsakis (Jun 28 2019 at 14:02, on Zulip):

nikomatsakis but why does it say X then?

(correct, typo, should be self for 61207)

centril (Jun 28 2019 at 14:02, on Zulip):

@nikomatsakis phew :slight_smile:

centril (Jun 28 2019 at 14:02, on Zulip):

the world is alright again

pnkfelix (Jun 28 2019 at 14:03, on Zulip):

So I'd like to establish up front

nikomatsakis (Jun 28 2019 at 14:03, on Zulip):

(I assume X means "rustc issues an error due to ambiguous lifetime")

actually it's that it gets a kind of "unrelated error" -- I was just double checking the behavior in weird cases

pnkfelix (Jun 28 2019 at 14:04, on Zulip):

I'd like to establish up front whether we plan to have the topic of this meeting change to discussion of the last minute backporting of #61207, or if we are planning to bound how much time we spend discussing that

centril (Jun 28 2019 at 14:04, on Zulip):

(imo #61207 should take as much time as is necessary)

pnkfelix (Jun 28 2019 at 14:04, on Zulip):

@centril I think you are missing my point

pnkfelix (Jun 28 2019 at 14:05, on Zulip):

if we anticipate that it will take up the whole meeting slot, then fine

pnkfelix (Jun 28 2019 at 14:05, on Zulip):

but there are people who may be interested in the triage/maintenance issues who might not be as interested in the particulars of this

pnkfelix (Jun 28 2019 at 14:05, on Zulip):

Out of respect for those people's time, I would like to at least try to guess whether this is going to be a "quick" 5-10 minute thing

pnkfelix (Jun 28 2019 at 14:06, on Zulip):

or if we simply need to punt on the triage/maintenance discussion, due to the timing pressure that we have for this backport question

centril (Jun 28 2019 at 14:07, on Zulip):

So I think we have 2 issues to think about:
1. Do we think the PR is a step in the right direction?
2. Do we backport to 1.36.0, to 1.37.0, are we fine with 1.38.0?

centril (Jun 28 2019 at 14:07, on Zulip):

Possibly:
3. Is there any way in which the PR is a step in the wrong direction?

centril (Jun 28 2019 at 14:08, on Zulip):

I don't know how much that will take; but 8 minutes have already passed, so let's not waste more time.

pnkfelix (Jun 28 2019 at 14:08, on Zulip):

Okay then, based on this, I'm willing to guess that this will take up the whole meeting slot. @nikomatsakis , what do you think? Should we officially change the topic of the whole meeting to be about #61207 slash dealing with Pin and lifetime elision?

nikomatsakis (Jun 28 2019 at 14:09, on Zulip):

Sure, why not.

pnkfelix (Jun 28 2019 at 14:11, on Zulip):

okay

centril (Jun 28 2019 at 14:11, on Zulip):

Here is my understanding of the function elision rules based on the gist, the reference, some tests, the code in the PR, etc..


1. Each elided lifetime in the parameters becomes a distinct lifetime parameter.
2. If there is exactly one lifetime used in the parameters (elided or not), that lifetime is assigned to all elided output lifetimes.
In method signatures there is another rule:

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

So yes let's start with describing the behavior. I don't think that fully meets the tests

centril (Jun 28 2019 at 14:12, on Zulip):

That is, on stable we just look at the type expression of the receiver; with the PR we look at any type expression inside the receiver

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

Notably, this case does not behave as described:

impl Foo<'a> { fn(self: Box<Foo<'a>>, f: &u8) -> &u8 }

nikomatsakis (Jun 28 2019 at 14:13, on Zulip):

under both stable and #61207, this resolves the -> &u8 to the type of f

nikomatsakis (Jun 28 2019 at 14:13, on Zulip):

and yet there are multiple lifetimes (so rule 2 does not apply) and there is no &Self (so self rule does not apply)

nikomatsakis (Jun 28 2019 at 14:13, on Zulip):

I do not however necessarily think that has to block the PR

nikomatsakis (Jun 28 2019 at 14:13, on Zulip):

Because (as I said) it is also the behavior on stable

nikomatsakis (Jun 28 2019 at 14:14, on Zulip):

(I am running one other test re: the PR which seems a bit odd; in particular, the PR uses an "awfully shallow" test to decide if &Self has been found, though stable does as well)

nikomatsakis (Jun 28 2019 at 14:15, on Zulip):

I think this could only ever be an issue, however, under the more generalized forms of arbitrary-self-types

nikomatsakis (Jun 28 2019 at 14:15, on Zulip):

So it also not likely to be a blocker to backporting

pnkfelix (Jun 28 2019 at 14:16, on Zulip):

I did notice the tests in your gist did not include more complex compositions such as Box<Box<Foo>>

centril (Jun 28 2019 at 14:16, on Zulip):

Right, I agree; -- the current/PR behavior does not conform exactly with the specification I gave above, but importantly we move in all respects towards that spec and never away from it, I think.

pnkfelix (Jun 28 2019 at 14:16, on Zulip):

my understanding is that such cases today are not handled, at least not without a feature-flag

nikomatsakis (Jun 28 2019 at 14:17, on Zulip):

that is correct, @pnkfelix, although I think they would not yield any surprises over (e.g.) Box<&Self>

centril (Jun 28 2019 at 14:18, on Zulip):

@pnkfelix actually we have:

fn pin_pin_pin_ref(self: Pin<Pin<Pin<&Self>>>) -> Pin<Pin<Pin<&Self>>> { self }
pnkfelix (Jun 28 2019 at 14:18, on Zulip):

well... Box<&Self> is one of the cases that changes its behavior in #61207

pnkfelix (Jun 28 2019 at 14:18, on Zulip):

and therefore that is not putting much of a bound on how much surprise I might suffer

nikomatsakis (Jun 28 2019 at 14:18, on Zulip):

sorry, what I mean is that adding additional layers of Box does not change anything

nikomatsakis (Jun 28 2019 at 14:18, on Zulip):

but it'd be good to show at least one more :)

centril (Jun 28 2019 at 14:19, on Zulip):

The only stable recursive case is for Pin per snippet above

pnkfelix (Jun 28 2019 at 14:19, on Zulip):

pnkfelix actually we have:

fn pin_pin_pin_ref(self: Pin<Pin<Pin<&Self>>>) -> Pin<Pin<Pin<&Self>>> { self }

So that is supported without a feature gate?

centril (Jun 28 2019 at 14:19, on Zulip):

@pnkfelix yes, there's a test for it in the PR

pnkfelix (Jun 28 2019 at 14:19, on Zulip):

okay

centril (Jun 28 2019 at 14:19, on Zulip):

(and I think this is correct)

centril (Jun 28 2019 at 14:20, on Zulip):

Checking the PR quickly it also has tests for aliases and whatnot

centril (Jun 28 2019 at 14:21, on Zulip):

It doesn't test for more feature gated cases, but we can follow up for that

pnkfelix (Jun 28 2019 at 14:21, on Zulip):

@nikomatsakis so, what are the misgivings you'd like to discuss? Are they misgivings with PR #61207? Or are they misgivings with the current state of affairs, i.e. a desire for us to make breaking changes in the future ?

nikomatsakis (Jun 28 2019 at 14:23, on Zulip):

I dont' think I have misgivings with the PR as is. I have misgivings around our current behavior

nikomatsakis (Jun 28 2019 at 14:23, on Zulip):

and the PR does not correct all of those misgivings

pnkfelix (Jun 28 2019 at 14:23, on Zulip):

Okay. So that's fine, that's an argument that more work needs to be done in the long term

pnkfelix (Jun 28 2019 at 14:23, on Zulip):

potentially with, e.g., warning-cycled changes

nikomatsakis (Jun 28 2019 at 14:23, on Zulip):

correct

nikomatsakis (Jun 28 2019 at 14:24, on Zulip):

So I guess then the question is whether to backport: the changes seem fairly self-contained

centril (Jun 28 2019 at 14:24, on Zulip):

OK so we've answered 1. "we think the PR is a strict improvement"

pnkfelix (Jun 28 2019 at 14:25, on Zulip):

So I guess then the question is whether to backport: the changes seem fairly self-contained

and also, whether to backport to 1.36? Or if the backport can target 1.37 instead. (As @centril stated up above in the list of questions to resolve)

pnkfelix (Jun 28 2019 at 14:25, on Zulip):

I am pretty convinced from what e.g. @Taylor Cramer has said that we do want something landed in time for 1.37

pnkfelix (Jun 28 2019 at 14:26, on Zulip):

and @centril was saying last night at the T-lang meeting that they were willing to take the heat on the release team for trying to get PR #61207 backported into 1.36

nikomatsakis (Jun 28 2019 at 14:26, on Zulip):

I think we should target 1.37 personally

nikomatsakis (Jun 28 2019 at 14:26, on Zulip):

Er, wait

nikomatsakis (Jun 28 2019 at 14:26, on Zulip):

Sorry, 1.36 is current beta, correct?

pnkfelix (Jun 28 2019 at 14:26, on Zulip):

shall we perhaps briefly discuss the pros and cons of 1.36 vs 1.37 ?

pnkfelix (Jun 28 2019 at 14:27, on Zulip):

1.36 is the imminent release

nikomatsakis (Jun 28 2019 at 14:27, on Zulip):

Yes, so the argument for 1.36 in particular (since the behavior in question is already stabilized) is that Future trait is stabilized there

nikomatsakis (Jun 28 2019 at 14:27, on Zulip):

We have a clean crater run

nikomatsakis (Jun 28 2019 at 14:28, on Zulip):

But it's pretty plausible that there a lot more code that relies on the stable behavior would be producd between 1.36 and 1.37

centril (Jun 28 2019 at 14:28, on Zulip):

Pietro and Mark were OK with backport it seems -- but we have some CI problems and making a new stable release after the 30th will be hard; so we need to act fast, basically

pnkfelix (Jun 28 2019 at 14:28, on Zulip):

I hate to ask the question, but I feel like I must: It would be a non-starter to unstabilize Future in 1.36 based on this, right?

centril (Jun 28 2019 at 14:28, on Zulip):

eheheh :D

pnkfelix (Jun 28 2019 at 14:28, on Zulip):

(I mean as an alternative to landing #61207 right now into 1.36)

nikomatsakis (Jun 28 2019 at 14:29, on Zulip):

Interesting, I had not considered that. :)

nikomatsakis (Jun 28 2019 at 14:29, on Zulip):

It seems somehow riskier

centril (Jun 28 2019 at 14:29, on Zulip):

socially or technically?

nikomatsakis (Jun 28 2019 at 14:29, on Zulip):

I guess it's just adding a stability attribute on

nikomatsakis (Jun 28 2019 at 14:29, on Zulip):

I meant technically but also socially :)

pnkfelix (Jun 28 2019 at 14:29, on Zulip):

I don't know what other components we are landing rely on it being stable

nikomatsakis (Jun 28 2019 at 14:29, on Zulip):

Like, we have a PR with a crater run

nikomatsakis (Jun 28 2019 at 14:29, on Zulip):

It is relatively contained

nikomatsakis (Jun 28 2019 at 14:30, on Zulip):

the chance of a "whooops, we didn't think of that" with destabilizing Future trait seems higher

centril (Jun 28 2019 at 14:30, on Zulip):

I guess it depends on the confidence with which we claim the PR is a strict improvement

centril (Jun 28 2019 at 14:30, on Zulip):

Destabilizing Future seems easy tho if we must

nikomatsakis (Jun 28 2019 at 14:31, on Zulip):

I've perhaps just been burned too many times by breaking the build with a "harmless change that could never break anything" :)

nikomatsakis (Jun 28 2019 at 14:31, on Zulip):

In any case, there are also social considerations to consider, yes :)

nikomatsakis (Jun 28 2019 at 14:32, on Zulip):

that'd be a much bigger announcement to be planned

nikomatsakis (Jun 28 2019 at 14:32, on Zulip):

the stable surface area of arbitrary self types is, I believe, restrained to compositions of Box, &, &mut, and Pin

centril (Jun 28 2019 at 14:32, on Zulip):

(Box is not recursive, Pin is)

pnkfelix (Jun 28 2019 at 14:35, on Zulip):

and what does Box<Pin<&Self>> do?

nikomatsakis (Jun 28 2019 at 14:35, on Zulip):

what do you mean not recursive?

nikomatsakis (Jun 28 2019 at 14:35, on Zulip):

and what does Box<Pin<&Self>> do?

testing that now :)

centril (Jun 28 2019 at 14:36, on Zulip):

@nikomatsakis self: Box<Box<Self>> is an error on stable, I think?

nikomatsakis (Jun 28 2019 at 14:36, on Zulip):

ah, I see

nikomatsakis (Jun 28 2019 at 14:36, on Zulip):

yes, that is correct

centril (Jun 28 2019 at 14:36, on Zulip):

(correct, it is)

nikomatsakis (Jun 28 2019 at 14:36, on Zulip):

and what does Box<Pin<&Self>> do?

with the feature-gate, it matches against the & from &Self (as I would expect)

nikomatsakis (Jun 28 2019 at 14:37, on Zulip):

point is, the stable surface is more shallow than I thought, @centril ?

centril (Jun 28 2019 at 14:37, on Zulip):

@nikomatsakis yup

centril (Jun 28 2019 at 14:38, on Zulip):

This test (src/test/ui/self/self_lifetime.rs) looks strange:

struct Foo<'a>(&'a ());
impl<'a> Foo<'a> {
    fn foo<'b>(self: &'b Foo<'a>) -> &() { self.0 }
}

type Alias = Foo<'static>;
impl Alias {
    fn bar<'a>(self: &Alias, arg: &'a ()) -> &() { arg }
}
centril (Jun 28 2019 at 14:38, on Zulip):

(added in the PR, but the behavior is the same on stable)

nikomatsakis (Jun 28 2019 at 14:38, on Zulip):

I agree that behavior is strange

nikomatsakis (Jun 28 2019 at 14:38, on Zulip):

this is the case I was pointing out

centril (Jun 28 2019 at 14:38, on Zulip):

right

nikomatsakis (Jun 28 2019 at 14:38, on Zulip):

rwell

nikomatsakis (Jun 28 2019 at 14:38, on Zulip):

well

nikomatsakis (Jun 28 2019 at 14:38, on Zulip):

actually it's not quite

nikomatsakis (Jun 28 2019 at 14:39, on Zulip):

that surprises me a little

nikomatsakis (Jun 28 2019 at 14:39, on Zulip):

I think that &Alias does not count as "self" type

nikomatsakis (Jun 28 2019 at 14:39, on Zulip):

this is a distinct case

nikomatsakis (Jun 28 2019 at 14:40, on Zulip):

regardless I do not think the PR changes anything in this regard

pnkfelix (Jun 28 2019 at 14:40, on Zulip):

indeed

nikomatsakis (Jun 28 2019 at 14:40, on Zulip):

except extending the strangeness to things like Pin<&Alias>

pnkfelix (Jun 28 2019 at 14:40, on Zulip):
impl Alias {
    fn bar<'a>(self: &Self, arg: &'a ()) -> &() { arg }
}

gets rejected

nikomatsakis (Jun 28 2019 at 14:40, on Zulip):

(I'm actually not sure this is bad, I think I might prefer to deprecate all cases around elision except with the keyword Self, personally)

nikomatsakis (Jun 28 2019 at 14:41, on Zulip):

(but that's more the long-term question)

pnkfelix (Jun 28 2019 at 14:41, on Zulip):

we were having a hard time trying to explain that to @Taylor Cramer last night

pnkfelix (Jun 28 2019 at 14:41, on Zulip):

(about why one might treat Self differently from Foo<'a> when Self = Foo<'a>)

centril (Jun 28 2019 at 14:41, on Zulip):

@nikomatsakis right; I think we should either be entirely semantic in determining is_self_type or entirely syntactic (the literal Self)

pnkfelix (Jun 28 2019 at 14:42, on Zulip):

that does at least sound like something we can emit a nice diagnostic for

pnkfelix (Jun 28 2019 at 14:42, on Zulip):

and have rustfix fix up

nikomatsakis (Jun 28 2019 at 14:43, on Zulip):

I've updated the chart to include this case

nikomatsakis (Jun 28 2019 at 14:43, on Zulip):

(S9)

nikomatsakis (Jun 28 2019 at 14:44, on Zulip):

so I personally think a backport is ok

nikomatsakis (Jun 28 2019 at 14:44, on Zulip):

I think I would prefer that to destabilizing future

nikomatsakis (Jun 28 2019 at 14:44, on Zulip):

which feels like a heavier lift, socially plus technically, plus still leaves "undesirable" behavior on stable longer

pnkfelix (Jun 28 2019 at 14:44, on Zulip):

and specifically, you mean a backport to 1.36

nikomatsakis (Jun 28 2019 at 14:44, on Zulip):

yes

centril (Jun 28 2019 at 14:45, on Zulip):

OK; so based on this discussion and reviewing the tests in the PR I am confident that it's a strict improvement that is also well tested. Coupled with the crater run with no regressions... I agree that a backport is OK (and personally I think it's desirable and within our time constraints).

pnkfelix (Jun 28 2019 at 14:46, on Zulip):

okay then. So I'll go mark the PR as beta-accepted (and include a note that we're talking about 1.36)

nikomatsakis (Jun 28 2019 at 14:46, on Zulip):

who will prep the beta backport PR?

nikomatsakis (Jun 28 2019 at 14:46, on Zulip):

it should be straightforward

centril (Jun 28 2019 at 14:46, on Zulip):

Can any of you two?

nikomatsakis (Jun 28 2019 at 14:46, on Zulip):

I can do it now

centril (Jun 28 2019 at 14:46, on Zulip):

:heart:

nikomatsakis (Jun 28 2019 at 14:46, on Zulip):

I also have a bevy of tests to add

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

but I will not do that as part of backport

centril (Jun 28 2019 at 14:47, on Zulip):

awesome!

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

one other thing I want to bring up but only briefly

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

is that I think we should try to "follow up" with deprecation warnings for some of the other behaviors

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

i.e., let's put this "to bed"

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

this doesn't have the "time pressure" aspect

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

and maybe wants an RFC

centril (Jun 28 2019 at 14:48, on Zulip):

I'm not sure about the semantic/syntactic Self question personally but I agree with "let's settle the matter permanently"

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

I'm sort of inclined to just "deprecate" weird behaviors for now, maybe remove in an edition or something

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

I'm not sure about the semantic/syntactic Self question personally but I agree with "let's settle the matter permanently"

I agree

nikomatsakis (Jun 28 2019 at 14:49, on Zulip):

there are a few other minor things; e.g., right now you can do fn foo<'a>(x: &'a self) -> &u8, which I think should be forbidden (use 'a)

nikomatsakis (Jun 28 2019 at 14:49, on Zulip):

well, I think should be linted

centril (Jun 28 2019 at 14:49, on Zulip):

Linting on that one seems reasonable at least imo

nikomatsakis (Jun 28 2019 at 14:49, on Zulip):

many of these were already discussed on and off

nikomatsakis (Jun 28 2019 at 14:50, on Zulip):

this is more something to put on lang team agenda I think, though

nikomatsakis (Jun 28 2019 at 14:50, on Zulip):

as a possible "focus topic" for some group to go and take care of

nikomatsakis (Jun 28 2019 at 14:50, on Zulip):

let me go prep that PR

nikomatsakis (Jun 28 2019 at 14:50, on Zulip):

before I get distraced :P

centril (Jun 28 2019 at 14:50, on Zulip):

Yeah; I think this fn foo example has the problem of being confusing when you don't know the rules by heart

pnkfelix (Jun 28 2019 at 14:51, on Zulip):

before I get distraced :P

or even DTraced

pnkfelix (Jun 28 2019 at 14:51, on Zulip):

(can you tell I was up until 3am)

nikomatsakis (Jun 28 2019 at 14:51, on Zulip):

BTW @centril I refined your description

centril (Jun 28 2019 at 14:51, on Zulip):

@pnkfelix great blog post btw!

nikomatsakis (Jun 28 2019 at 14:51, on Zulip):
nikomatsakis (Jun 28 2019 at 14:52, on Zulip):

great blog post btw!

where was it posted?

nikomatsakis (Jun 28 2019 at 14:52, on Zulip):

it's not possible for this to be relevant on stable, but it matters with the feature gate enabled

pnkfelix (Jun 28 2019 at 14:52, on Zulip):

where was it posted?

http://blog.pnkfx.org/

centril (Jun 28 2019 at 14:52, on Zulip):

@nikomatsakis http://blog.pnkfx.org/blog/2019/06/26/breaking-news-non-lexical-lifetimes-arrives-for-everyone/

nikomatsakis (Jun 28 2019 at 14:52, on Zulip):

<3

pnkfelix (Jun 28 2019 at 14:53, on Zulip):

I continue to be quite proud of getting those Tufte margin notes to work

centril (Jun 28 2019 at 14:54, on Zulip):

@nikomatsakis the description probably needs a definition of "semantic type" also since aliases didn't work

centril (Jun 28 2019 at 14:54, on Zulip):

(which I expected it would when I wrote this)

centril (Jun 28 2019 at 14:55, on Zulip):

@nikomatsakis btw, the backport target should be the stable branch, I think

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

nikomatsakis the description probably needs a definition of "semantic type" also since aliases didn't work

yes so the actual test is "the path Self or a path that resolves to the struct/enum/union"

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

nikomatsakis btw, the backport target should be the stable branch, I think

oh, ok

centril (Jun 28 2019 at 14:56, on Zulip):

(because we have already done the beta -> stable promotion)

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

yes so the actual test is "the path Self or a path that resolves to the struct/enum/union"

note that this is not necessarily Self (as I noted in the gist below)

centril (Jun 28 2019 at 14:56, on Zulip):

(that is, stable and beta point at the same place atm)

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

they...don't

nikomatsakis (Jun 28 2019 at 14:57, on Zulip):

at least I don't think they do

pnkfelix (Jun 28 2019 at 14:57, on Zulip):

(that is, stable and beta point at the same place atm)

but won't he need to land it in both places?

centril (Jun 28 2019 at 14:57, on Zulip):

@pnkfelix yes, but land on stable first, then nightly

centril (Jun 28 2019 at 14:57, on Zulip):

and then nightly gets promoted to beta

pnkfelix (Jun 28 2019 at 14:57, on Zulip):

ah right, we haven't promoted nightly to beta yet

pnkfelix (Jun 28 2019 at 14:57, on Zulip):

okay

nikomatsakis (Jun 28 2019 at 14:58, on Zulip):
athena. git log rust-lang/stable | head
commit 09a353c529064185aab3fee18128cf1cc697c11e
Merge: 83167c47939 32055e1cd98
Author: bors <bors@rust-lang.org>
Date:   Wed Jun 26 22:52:15 2019 +0000

    Auto merge of #62162 - Mark-Simulacrum:stable-next, r=Mark-Simulacrum

    [stable] 1.36 stable release

    cc @rust-lang/release
centril (Jun 28 2019 at 14:58, on Zulip):

@nikomatsakis oh yeah, you are correct

centril (Jun 28 2019 at 14:58, on Zulip):

but that's just switching the "is it stable"

nikomatsakis (Jun 28 2019 at 14:58, on Zulip):

Not sure if that means I should target stable or not

nikomatsakis (Jun 28 2019 at 14:58, on Zulip):

right

nikomatsakis (Jun 28 2019 at 14:58, on Zulip):

ok

nikomatsakis (Jun 28 2019 at 14:58, on Zulip):

so they are morally equivalent

centril (Jun 28 2019 at 14:58, on Zulip):

yep

centril (Jun 28 2019 at 14:58, on Zulip):

==> target stable

nikomatsakis (Jun 28 2019 at 14:59, on Zulip):

so should I use rust-lang/stable as the basis for my PR?

nikomatsakis (Jun 28 2019 at 14:59, on Zulip):

I guess the merge will only bring in the fresh commits

nikomatsakis (Jun 28 2019 at 14:59, on Zulip):

so it's fine

nikomatsakis (Jun 28 2019 at 15:01, on Zulip):

OK I opened https://github.com/rust-lang/rust/pull/62209

nikomatsakis (Jun 28 2019 at 15:01, on Zulip):

I would be ok with r+'ing #61207

centril (Jun 28 2019 at 15:03, on Zulip):

r+ed

pnkfelix (Jun 28 2019 at 15:04, on Zulip):

@nikomatsakis did you want to push your bevy of new tests to #61207 first before r+'ing?

centril (Jun 28 2019 at 15:04, on Zulip):

good idea

centril (Jun 28 2019 at 15:04, on Zulip):

@nikomatsakis What a nice and clean backport :D

nikomatsakis (Jun 28 2019 at 15:04, on Zulip):

nikomatsakis did you want to push your bevy of new tests to #61207 first before r+'ing?

I was going to ask whether I should do that

centril (Jun 28 2019 at 15:04, on Zulip):

I'll babysit it

nikomatsakis (Jun 28 2019 at 15:04, on Zulip):

I would be happy to do so

nikomatsakis (Jun 28 2019 at 15:05, on Zulip):

I have a dentist appointment soon so I'll be afk for a bit but I'll try do those tests now before I go

pnkfelix (Jun 28 2019 at 15:05, on Zulip):

I think it would be a good idea to get those tests in

pnkfelix (Jun 28 2019 at 15:05, on Zulip):

okay thanks

centril (Jun 28 2019 at 15:05, on Zulip):

Yeah, thanks

centril (Jun 28 2019 at 15:10, on Zulip):

@simulacrum So I r+ed https://github.com/rust-lang/rust/pull/62209 but I'm not familiar with dev-static and the other stuff

centril (Jun 28 2019 at 15:18, on Zulip):

also cc @Pietro Albini

Pietro Albini (Jun 28 2019 at 15:18, on Zulip):

@centril ping me once it's merged

centril (Jun 28 2019 at 15:19, on Zulip):

will do

Pietro Albini (Jun 28 2019 at 15:19, on Zulip):

nuking the dev-static's channel toml should be enough

nikomatsakis (Jun 28 2019 at 18:58, on Zulip):

@centril I pushed tests to #61207

centril (Jun 28 2019 at 19:01, on Zulip):

@nikomatsakis I saw; taking a look

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

@nikomatsakis in case you didn't see on Discord, https://github.com/rust-lang/rust/pull/62209 failed and probably needs --bless --compare-mode=nll

centril (Jun 28 2019 at 20:42, on Zulip):

Pushed a fix to your branch

Last update: Nov 16 2019 at 01:15UTC