Stream: t-compiler/meetings

Topic: [weekly meeting] 2020-07-09 #54818


Santiago Pastorino (Jul 08 2020 at 14:16, on Zulip):

Hi @T-compiler/meeting; the triage meeting will be starting in ~ 23 hours 44 minutes

Santiago Pastorino (Jul 08 2020 at 14:17, on Zulip):

The @WG-prioritization have done pre-triage in #t-compiler/wg-prioritization-alerts

Santiago Pastorino (Jul 08 2020 at 14:17, on Zulip):

@WG-prioritization have prepared the meeting agenda

Santiago Pastorino (Jul 08 2020 at 14:18, on Zulip):

We will have checkins from @WG-async-foundations and @WG-diagnostics

Santiago Pastorino (Jul 08 2020 at 14:18, on Zulip):

@tmandry || @nikomatsakis do you have something you want to share about @WG-async-foundations?

Santiago Pastorino (Jul 08 2020 at 14:19, on Zulip):

@Esteban Küber do you have something you want to share about @WG-diagnostics?

Santiago Pastorino (Jul 08 2020 at 14:58, on Zulip):

@T-compiler/meeting the agenda is kind of short right now, consider nominating issues that you find important or things that you want to raise awareness or move forward

Santiago Pastorino (Jul 08 2020 at 14:59, on Zulip):

if there's nothing important to add, I guess it's ok to leave the agenda in the way it is, we can close the meeting earlier :) but I guessed that is also a nice opportunity to check on issues that you may want to see moving forward

Santiago Pastorino (Jul 08 2020 at 14:59, on Zulip):

Feel free to you point things at me and I can nominate and add some explanations of issues to the agenda :heart:

pnkfelix (Jul 08 2020 at 16:27, on Zulip):

I'm nominating PR's #74127 and #74150 , not because I want to debate their value, but rather because I want to give a general heads up that I think we should just approve them (and if that means we need to discuss our internal culture, so be it)

Félix Fischer (Jul 08 2020 at 17:39, on Zulip):

I have a theory of why people feel extra strongly about the PR.

This is just a guess, but maybe part of why some people feel strongly against it is the issue of naming (remember that saying that naming and cache invalidation are the hardest problems in computer science? :laughing:).

What I mean by "the issue of naming" is that we have this idea that "good names" should feel a certain way: they should be precise, concise and should reflect all of the facets of the idea they represent.

Since the name "whitelist" is old and has been used repeatedly to mean this one thing, it has slowly through the decades molded itself into a "good name" for this role, by that definition. And I think that many people feel strongly about losing one of those, because again, "good names" are hard to come by. This must feel like having a word being ripped away from the dictionary.

Félix Fischer (Jul 08 2020 at 17:41, on Zulip):

If you ask me my opinion, I think that's okay. The new words will mold themselves into their new roles, just like "whitelist" and the others did. But I speak more than one language, and I am old, so to me it doesn't hurt as much to say goodbye to one particular "good word" in English.

Félix Fischer (Jul 08 2020 at 17:43, on Zulip):

Sorry for the intromission, but I think that this idea was missing in the overall discussion. Thank you for bringing it up. @pnkfelix, I think these are, at the very least, a good issue to bring forward.

pnkfelix (Jul 08 2020 at 18:03, on Zulip):

Its also a sensitive topic for some because they see it as providing literal "lip service" that doesn't actually resolve the real problems of inequity

Félix Fischer (Jul 08 2020 at 18:16, on Zulip):

That makes sense. But I also think that language is powerful. It shapes how we think of the world. If we can push that boat a little bit to alter its course, we might be helping a lot of people down the road.

Félix Fischer (Jul 08 2020 at 18:17, on Zulip):

I think we're helping the folks of the future more than ourselves. But I think that's how it is with language. It changes slowly, and it changes us slowly as well.

pnkfelix (Jul 08 2020 at 18:30, on Zulip):

also, I think I have a problem with all of these words (allowlist, whitelist, denylist, blacklist) because people think they are self-documenting, but they are in fact not. They don't document what is being allowed/denied; you still need to determine that from context (or nearby documentation).

pnkfelix (Jul 08 2020 at 18:30, on Zulip):

So that's a way in which I can appreciate the idea that the naive, context-free rename (e.g. to "allowlist") does not provide enough value on its own

pnkfelix (Jul 08 2020 at 18:31, on Zulip):

compared to, as nikomatsakis pointed out, a rename to AssumeUsed (as suggested by Vadim Petrochenkov and was then added to #74127), where now we embed more useful info

Félix Fischer (Jul 08 2020 at 18:38, on Zulip):

Ohh, that's a really good point!

pnkfelix (Jul 08 2020 at 19:00, on Zulip):

(to be clear, I was referring above to the use of e.g. "denylist" as a variable name. My comment wasn't directive to its use within a sentence in a comment, which is a place where you're likely to find the necessary extra information.)

Santiago Pastorino (Jul 09 2020 at 12:58, on Zulip):

Hi @T-compiler/meeting, triage meeting will be starting in ~ 1 hour

Santiago Pastorino (Jul 09 2020 at 12:58, on Zulip):

Check out the meeting agenda

pnkfelix (Jul 09 2020 at 14:01, on Zulip):

Hi @T-compiler/meeting! Add a :wave: emoji to show you're here :)

pnkfelix (Jul 09 2020 at 14:01, on Zulip):

we will start off with 5 minutes for ...

Announcements

pnkfelix (Jul 09 2020 at 14:02, on Zulip):
pnkfelix (Jul 09 2020 at 14:02, on Zulip):
pnkfelix (Jul 09 2020 at 14:02, on Zulip):
pnkfelix (Jul 09 2020 at 14:03, on Zulip):
pnkfelix (Jul 09 2020 at 14:04, on Zulip):
pnkfelix (Jul 09 2020 at 14:04, on Zulip):
pnkfelix (Jul 09 2020 at 14:05, on Zulip):

WG checkins

@WG-async-foundations checkin by @tmandry and @nikomatsakis:

pnkfelix (Jul 09 2020 at 14:05, on Zulip):

(I don't see any checkin report given ahead of time to put into the agena; but feel free to post one now if there's anything to report from @WG-async-foundations ?)

nikomatsakis (Jul 09 2020 at 14:05, on Zulip):

Well so

nikomatsakis (Jul 09 2020 at 14:05, on Zulip):

I can leave a few notes

nikomatsakis (Jul 09 2020 at 14:06, on Zulip):

first off, we're still working on polishing things, but there hasn't been as much people around lately

nikomatsakis (Jul 09 2020 at 14:06, on Zulip):

probably we could advertise a bit more :)

nikomatsakis (Jul 09 2020 at 14:06, on Zulip):

but if people are ever looking for smaller bugs to fix, we've got a queue...

pnkfelix (Jul 09 2020 at 14:07, on Zulip):

we also have a checkin scheduled from @WG-diagnostics by @Esteban Küber (where again there is no text in the agenda supplied ahead of time)

nikomatsakis (Jul 09 2020 at 14:07, on Zulip):

...there is also some work going on that is not really "t-compiler", but there are two RFCs being drafted

nikomatsakis (Jul 09 2020 at 14:07, on Zulip):

last thing:

nikomatsakis (Jul 09 2020 at 14:08, on Zulip):

the queue of issues can be found on the project board, under the "On deck" card

nikomatsakis (Jul 09 2020 at 14:08, on Zulip):

those are the polish-related ones that seem most important

nikomatsakis (Jul 09 2020 at 14:08, on Zulip):

ok, thanks!

eddyb (Jul 09 2020 at 14:08, on Zulip):

(I would not use "safe" for that, tbh)

nikomatsakis (Jul 09 2020 at 14:09, on Zulip):

(that is one of the topics under discussion, actually, finding a better name:)

pnkfelix (Jul 09 2020 at 14:09, on Zulip):

because its not necessarily a safety issue? (Or it should never be a safety issue?)

eddyb (Jul 09 2020 at 14:10, on Zulip):

it should never be if it's a lint, IMO

pnkfelix (Jul 09 2020 at 14:10, on Zulip):

true

nikomatsakis (Jul 09 2020 at 14:10, on Zulip):

Draft RFC is in rust-lang/wg-async-foundations#16 if you want to leave thoughts

lcnr (Jul 09 2020 at 14:10, on Zulip):

(see confusion about UnwindSafe)

pnkfelix (Jul 09 2020 at 14:10, on Zulip):

anyway we can move along, assuming @Esteban Küber is unavailable. (@Esteban Küber , if you have stuff to report and become available during the meeting, PM me and we'll allocate time at the end.)

pnkfelix (Jul 09 2020 at 14:11, on Zulip):

Beta-nominations

T-compiler

libs-impl

pnkfelix (Jul 09 2020 at 14:11, on Zulip):

T-rustdoc

Santiago Pastorino (Jul 09 2020 at 14:13, on Zulip):

an important thing I see there is ...

Santiago Pastorino (Jul 09 2020 at 14:13, on Zulip):

This will need to be backported to beta as that's the first version with this lint.

Santiago Pastorino (Jul 09 2020 at 14:13, on Zulip):

so this lint was never on stable

pnkfelix (Jul 09 2020 at 14:13, on Zulip):

right, I was just going to ask about that

pnkfelix (Jul 09 2020 at 14:13, on Zulip):

if it had been on stable, then I would think we'd have to use a more sophisticated form of the PR that continued to support the old name

Santiago Pastorino (Jul 09 2020 at 14:13, on Zulip):

Santiago Pastorino said:

so this lint was never on stable

at least according to the comments, I didn't check that to be honest

pnkfelix (Jul 09 2020 at 14:13, on Zulip):

so okay, beta accepted then

pnkfelix (Jul 09 2020 at 14:15, on Zulip):

Stable-nominations

T-compiler

libs-impl

T-rustdoc

pnkfelix (Jul 09 2020 at 14:15, on Zulip):

PR's S-waiting-on-team

T-compiler

libs-impl

pnkfelix (Jul 09 2020 at 14:15, on Zulip):

Issues of Note

Short Summary

Santiago Pastorino (Jul 09 2020 at 14:16, on Zulip):

Santiago Pastorino said:

Santiago Pastorino said:

so this lint was never on stable

at least according to the comments, I didn't check that to be honest

just checked and the comment is right, is not in stable so :+1:

pnkfelix (Jul 09 2020 at 14:16, on Zulip):

since there is a release in a week, I suppose its worth noting that those 4 P-medium regression-from-stable-to-beta are going to end up in the stable channel.

pnkfelix (Jul 09 2020 at 14:16, on Zulip):

P-critical

T-compiler

pnkfelix (Jul 09 2020 at 14:17, on Zulip):

I'll just note: I personally don't consider the example on rust#73747 to be a likely Minimal complete verifiable example

pnkfelix (Jul 09 2020 at 14:17, on Zulip):

the code is short, but its hiding a bunch of stuff behind a WinRT specific macro

pnkfelix (Jul 09 2020 at 14:18, on Zulip):

(I tried to reproduce atop the output of --pretty expanded, and unfortunately it did not reproduce with my naive attempt to do so)

pnkfelix (Jul 09 2020 at 14:18, on Zulip):

but yeah, I'm still looking at it.

pnkfelix (Jul 09 2020 at 14:19, on Zulip):

libs-impl

T-rustdoc

pnkfelix (Jul 09 2020 at 14:19, on Zulip):

Unassigned P-high regressions

Beta regressions

Nightly regressions

pnkfelix (Jul 09 2020 at 14:20, on Zulip):

Performance logs

Triage done by njn.
Latest revision: 0c03aee8b81185d65b5821518661c30ecdb42de5.
One unimportant regression, on a rollup; six improvements, two on rollups.

Regressions

Improvements

pnkfelix (Jul 09 2020 at 14:21, on Zulip):

I don't think there's anything we need to discuss here; as noted, the one recorded regression does not seem important.

pnkfelix (Jul 09 2020 at 14:22, on Zulip):

in particular, I'm guessing that if we ever work on automating this performance analysis, we'll need to put in some differing criteria for synthetic benchmarks vs real-world benchmarks in terms of how big a regression needs to be before it should signal alarm bells.

pnkfelix (Jul 09 2020 at 14:22, on Zulip):

so lets move along

pnkfelix (Jul 09 2020 at 14:23, on Zulip):

Nominated Issues

T-compiler

pnkfelix (Jul 09 2020 at 14:23, on Zulip):
pnkfelix (Jul 09 2020 at 14:23, on Zulip):

so lets see, this is part of #65515

pnkfelix (Jul 09 2020 at 14:24, on Zulip):

and unfortunately I do not think @Esteban Küber is here

nikomatsakis (Jul 09 2020 at 14:24, on Zulip):

we definitely need to move or not move on this

nikomatsakis (Jul 09 2020 at 14:24, on Zulip):

I don't actually have a strong opinion one way or the other

eddyb (Jul 09 2020 at 14:24, on Zulip):

I don't think we need to reduce verbosity in libstd

nikomatsakis (Jul 09 2020 at 14:25, on Zulip):

given that nobody has really spoken up strongly in favor, maybe the answer is that we should not do it

eddyb (Jul 09 2020 at 14:25, on Zulip):

if this was exposed to regular user crates, I could see some points for it

Wesley Wiser (Jul 09 2020 at 14:25, on Zulip):

It sounds to me like the stronger motivating factor is how some error messages are being shown

eddyb (Jul 09 2020 at 14:25, on Zulip):

but better-safe-than-sorry seems to work (and we've actually gone in the direction of being more explicit/restricted with things like const fn stabilization)

Wesley Wiser (Jul 09 2020 at 14:26, on Zulip):

See https://github.com/rust-lang/rust/pull/65421#issuecomment-542869234

eddyb (Jul 09 2020 at 14:26, on Zulip):

oh so it is aesthetics

pnkfelix (Jul 09 2020 at 14:26, on Zulip):

there was this past dialog here: https://github.com/rust-lang/rust/issues/65515#issuecomment-548409772

eddyb (Jul 09 2020 at 14:27, on Zulip):

maybe I could see enum variant fields (but keep the attribute on the variant)

Wesley Wiser (Jul 09 2020 at 14:27, on Zulip):

Seems like T-libs is generally in favor?

nikomatsakis (Jul 09 2020 at 14:27, on Zulip):

I had overlooked this aspect

nikomatsakis (Jul 09 2020 at 14:27, on Zulip):

but I do think that's a strong motivation :)

pnkfelix (Jul 09 2020 at 14:28, on Zulip):

I'm actually surprised by how small the fallout on libstd is

pnkfelix (Jul 09 2020 at 14:29, on Zulip):

the fallout is this PR : https://github.com/rust-lang/rust/pull/71482/files

Esteban Küber (Jul 09 2020 at 14:29, on Zulip):

I can see only doing to for fields

Esteban Küber (Jul 09 2020 at 14:29, on Zulip):

And not varianta

pnkfelix (Jul 09 2020 at 14:30, on Zulip):

that would still get the desired improvement to diagnostic output

pnkfelix (Jul 09 2020 at 14:30, on Zulip):

right?

davidtwco (Jul 09 2020 at 14:30, on Zulip):

Could #[stable(..)] be extended with #[stable(.., include_fields)] so that it's still explicit and couldn't (as easily) lead to accidental stabilization of fields? This would still enable the stable attribute to be removed from the field itself which is the diagnostic improvement we're looking for?

Esteban Küber (Jul 09 2020 at 14:30, on Zulip):

That would cover the most egregious cases. Keep in mind that the test suite doesn't have the same frequency for errors as what user experience

pnkfelix (Jul 09 2020 at 14:30, on Zulip):

(because the annotation on the variant is not part of the span that is reported in the diagnostic)

Esteban Küber (Jul 09 2020 at 14:31, on Zulip):

It is in some cases, but much less frequent

pnkfelix (Jul 09 2020 at 14:31, on Zulip):

okay well based on the conversation thus far, it sounds to me like we should not just close this PR

pnkfelix (Jul 09 2020 at 14:32, on Zulip):

but maybe @Esteban Küber can refine the approach

pnkfelix (Jul 09 2020 at 14:32, on Zulip):

@Esteban Küber is there a dedicated zulip thread for this issue and/or PR ?

nagisa (Jul 09 2020 at 14:32, on Zulip):

OTOH nowadays didn’t we move the responsibility of the std implementation to T-compiler?

pnkfelix (Jul 09 2020 at 14:32, on Zulip):

that this conversation could move to?

Esteban Küber (Jul 09 2020 at 14:32, on Zulip):

I'll make obr

pnkfelix (Jul 09 2020 at 14:32, on Zulip):

@nagisa yeah but the public API is T-libs, so I assume their opinion still is (very) relevant here?

Esteban Küber (Jul 09 2020 at 14:32, on Zulip):

One

nagisa (Jul 09 2020 at 14:33, on Zulip):

Hm, yeah, but how verbose is annotation of the implementation shouldn't affect the API much, no?

nagisa (Jul 09 2020 at 14:33, on Zulip):

/me shrugs.

Esteban Küber (Jul 09 2020 at 14:33, on Zulip):

I think the discussion is around verbosity vs potential misuse

pnkfelix (Jul 09 2020 at 14:34, on Zulip):

anyway lets shift this conversation to be outside of this meeting. the people who are interested can go to whatever topic @Esteban Küber creates; just post a link here when you make it, @Esteban Küber

pnkfelix (Jul 09 2020 at 14:34, on Zulip):
pnkfelix (Jul 09 2020 at 14:34, on Zulip):

wow 88.5% is indeed big

nagisa (Jul 09 2020 at 14:35, on Zulip):

runtime perf or compiletime perf?

pnkfelix (Jul 09 2020 at 14:35, on Zulip):

its also like a year and a half old. :sad:

Wesley Wiser (Jul 09 2020 at 14:35, on Zulip):

There's currently no info on this because this was so long ago we've wiped the perf server and the data is gone.

Wesley Wiser (Jul 09 2020 at 14:35, on Zulip):

Compiletime perf

pnkfelix (Jul 09 2020 at 14:35, on Zulip):

nagisa said:

runtime perf or compiletime perf?

I'm assuming compiletime

Wesley Wiser (Jul 09 2020 at 14:35, on Zulip):

It links to perf.rlo so it's compiletime

pnkfelix (Jul 09 2020 at 14:36, on Zulip):

the regression is to incremental performance

Wesley Wiser (Jul 09 2020 at 14:36, on Zulip):

Actually, I wonder if the infamous CGU partitioning issue is to blame?

pnkfelix (Jul 09 2020 at 14:36, on Zulip):

so maybe this can be a topic of investigation for the up-and-coming wg-incr-comp

pnkfelix (Jul 09 2020 at 14:36, on Zulip):

@Wesley Wiser did the blamed commit have any interaction with cgu partitioning?

simulacrum (Jul 09 2020 at 14:37, on Zulip):

seems plausible that we could revert the regressing commit and see if it's still a performance win to revert it

simulacrum (Jul 09 2020 at 14:37, on Zulip):

it looks like it mostly touches rarely-edited code

Wesley Wiser (Jul 09 2020 at 14:37, on Zulip):

I'm just speculating but an 80% regression only on incremental compilation performance sounds suspiciously like that issue

Santiago Pastorino (Jul 09 2020 at 14:37, on Zulip):

yeah that was exactly what we were saying in the prioritization wg meeting

Santiago Pastorino (Jul 09 2020 at 14:37, on Zulip):

just revert and check

Wesley Wiser (Jul 09 2020 at 14:37, on Zulip):

If it changed the order MIR bodies were visited during codegen, it could potentially trigger it

pnkfelix (Jul 09 2020 at 14:38, on Zulip):

I see

Santiago Pastorino (Jul 09 2020 at 14:38, on Zulip):

we were wondering if it would be just reverting or some things would need to be tweaked but we could investigate it

pnkfelix (Jul 09 2020 at 14:38, on Zulip):

the blamed PR, by the way, is: Add a target option "merge-functions", and a corresponding -Z flag (works around #57356) #57268

pnkfelix (Jul 09 2020 at 14:39, on Zulip):

okay lets maybe let wg-incr-comp take point on this

Wesley Wiser (Jul 09 2020 at 14:39, on Zulip):

I thought it got blamed to #57573?

pnkfelix (Jul 09 2020 at 14:39, on Zulip):

oh I was only looking at the issue description

pnkfelix (Jul 09 2020 at 14:39, on Zulip):

oh it had all of those commits in it

pnkfelix (Jul 09 2020 at 14:40, on Zulip):

never mind me

Wesley Wiser (Jul 09 2020 at 14:40, on Zulip):

Local testing suggests that this is due to commit ff19a53 "Querify entry_fn", which seems to cause inc.comp. to hand more code to LLVM. Reverting that patch brings performance back to the old level.

Wesley Wiser (Jul 09 2020 at 14:40, on Zulip):

Regardless, it seems like wg-incr-comp is probably the right team to handle this

pnkfelix (Jul 09 2020 at 14:40, on Zulip):

yeah sounds good to me

pnkfelix (Jul 09 2020 at 14:41, on Zulip):

For what it’s worth, we don’t believe that metaphors identifying lightness as positive and darkness as negative are inherently racist. They certainly didn’t begin that way, though these negative connotations have certainly fed into and reinforced racism over the centuries.

Esteban Küber (Jul 09 2020 at 14:42, on Zulip):

I honestly see no reason not to block that thread to contribs only at the first sign of trouble, like it was done originally.

Esteban Küber (Jul 09 2020 at 14:43, on Zulip):

The PR process did its job, the changes are good after the review.

pnkfelix (Jul 09 2020 at 14:43, on Zulip):

I don't know, we've had some bad experiences in the past with externally linked PR's

pnkfelix (Jul 09 2020 at 14:43, on Zulip):

so I think it was not overzealous of the rust-mods to lock the PR

nagisa (Jul 09 2020 at 14:43, on Zulip):

There were some pushback in other venues against lock, but I too think it was the right call to lock.

Esteban Küber (Jul 09 2020 at 14:44, on Zulip):

I know why that makes people uneasy, but this is an internal nomenclature change that didn't affect the larger community

pnkfelix (Jul 09 2020 at 14:44, on Zulip):

my own thoughts on the PR itself are probably both over-complicated and ignorant.

Wesley Wiser (Jul 09 2020 at 14:44, on Zulip):

I wouldn't have had an issue accepting the PR as it was originally with the allow/deny lists but I love that it was improved to the point pretty much everyone can agree the new names are universally better.

Esteban Küber (Jul 09 2020 at 14:44, on Zulip):

We didn't see this when we renamed Place, did we? :blush:

pnkfelix (Jul 09 2020 at 14:45, on Zulip):

there is one topic that I want to try to touch on

pnkfelix (Jul 09 2020 at 14:45, on Zulip):

some people, perhaps who were acting in bad faith, posted questions about whether some words are going to be explicitly disallowed from the code base

pnkfelix (Jul 09 2020 at 14:45, on Zulip):

now, to be clear, I think we already do have an informal standard here. Like, we don't tend to accept code with swears in it

nagisa (Jul 09 2020 at 14:46, on Zulip):

We _can_ be more rigorous in asking people to use more descriptive names for variables and types.

pnkfelix (Jul 09 2020 at 14:46, on Zulip):

Yes. I see no need for a formal list of words that are disallowed.

nagisa (Jul 09 2020 at 14:46, on Zulip):

This PR did demonstrate that white/black list as a name is usually not great for technical reasons too.

pnkfelix (Jul 09 2020 at 14:47, on Zulip):

that's right, and changing to "allowlist" and "denylist" doesn't fix that

pnkfelix (Jul 09 2020 at 14:47, on Zulip):

to me, that's the important takeaway

pnkfelix (Jul 09 2020 at 14:48, on Zulip):

If future PR's come up and they use the term "whitelist" in a comment, I don't think the reviewers need to worry about it.

pnkfelix (Jul 09 2020 at 14:48, on Zulip):

which I admit may sound contradictory

pnkfelix (Jul 09 2020 at 14:49, on Zulip):

(i.e. Why accept the comment changes here now if we aren't going to impose the standard on future PR's...)

pnkfelix (Jul 09 2020 at 14:49, on Zulip):

and I think the answer is that we probably wouldn't accept a PR that just changed comments

pnkfelix (Jul 09 2020 at 14:49, on Zulip):

or rather, just changed comments via a simple sed -e s/blacklist/denylist/

pnkfelix (Jul 09 2020 at 14:50, on Zulip):

at least, I know we struggled in the past with proposed PR's that just fixed grammar

pnkfelix (Jul 09 2020 at 14:50, on Zulip):

But in this case, the PR is making more substantial improvements, as @nagisa noted.

Wesley Wiser (Jul 09 2020 at 14:50, on Zulip):

I think it's also entirely reasonable to ask the person submitting the code to provide a more descriptive variable name or comment than just "whitelist"/"blacklist" in the same way we would if they had variables named "foo". I suspect most people would simply comply without making an issue of it.

pnkfelix (Jul 09 2020 at 14:51, on Zulip):

Yep, I think that's true too

pnkfelix (Jul 09 2020 at 14:52, on Zulip):

I just wanted to make it clear that I am not planning on outlawing some set of words

pnkfelix (Jul 09 2020 at 14:52, on Zulip):

instead, I trust reviewers to use their best judgement about 1. what kinds of names and comments are intelligible, and 2. what is potentially offensive.

pnkfelix (Jul 09 2020 at 14:54, on Zulip):

finally, I don't regard this sort of PR as representing the sort of significant action that is actually needed to help marginalized groups, so its better if we avoid claims that it does so

pnkfelix (Jul 09 2020 at 14:55, on Zulip):

okay then

pnkfelix (Jul 09 2020 at 14:55, on Zulip):

Oh yeah, and as you can see, I did cross-out my suggestion that we lock the PR's after landing them

pnkfelix (Jul 09 2020 at 14:56, on Zulip):

as @Esteban Küber pointed out, its some changes to internal nomenclature.

pnkfelix (Jul 09 2020 at 14:57, on Zulip):

if the PR's do get trolling comments in the future, we'll handle it like any other moderation activity.

pnkfelix (Jul 09 2020 at 14:57, on Zulip):

libs-impl

pnkfelix (Jul 09 2020 at 14:58, on Zulip):

oh hey we have two minutes left and @Esteban Küber is here now

pnkfelix (Jul 09 2020 at 14:58, on Zulip):

first here's the link to the topic they created for teh #[stable] annotation stuff: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.23.5Bstable.5D.20annotations/near/203393543

pnkfelix (Jul 09 2020 at 14:58, on Zulip):

aka #t-compiler > #[stable] annotations

Santiago Pastorino (Jul 09 2020 at 14:59, on Zulip):

would be nice to add that link to the github issue too if it wasn't done already

pnkfelix (Jul 09 2020 at 14:59, on Zulip):

but also, @Esteban Küber , do you have anything to report for @WG-diagnostics ?

Esteban Küber (Jul 09 2020 at 15:00, on Zulip):

In the past month I've focused on attacking default bounds, both 'static and Sized and creating new targeted diagnostics when they are involved and keeping the backlog categorized (+ various random improvements).

Esteban Küber (Jul 09 2020 at 15:01, on Zulip):

For example

error[E0759]: cannot infer an appropriate lifetime
  --> $DIR/trait-object-nested-in-impl-trait.rs:41:31
   |
LL |     fn iter(&self) -> impl Iterator<Item = Box<dyn Foo>> + '_ {
   |             ----- this data with an anonymous lifetime `'_`...
...
LL |             remaining: self.0.iter(),
   |                        ------ ^^^^
   |                        |
   |                        ...is captured here...
   |
note: ...and is required to live as long as `'static` here
  --> $DIR/trait-object-nested-in-impl-trait.rs:38:23
   |
LL |     fn iter(&self) -> impl Iterator<Item = Box<dyn Foo>> + '_ {
   |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
help: to declare that the trait object captures data from argument `self`, you can add an explicit `'_` lifetime bound
   |
LL |     fn iter(&self) -> impl Iterator<Item = Box<dyn Foo + '_>> + '_ {
   |

and

error[E0277]: the size for values of type `T` cannot be known at compilation time
  --> $DIR/adt-param-with-implicit-sized-bound.rs:25:5
   |
LL | struct X<T>(T);
   |          - required by this bound in `X`
...
LL | struct Struct5<T: ?Sized>{
   |                - this type parameter needs to be `std::marker::Sized`
LL |     _t: X<T>,
   |     ^^^^^^^^ doesn't have a size known at compile-time
   |
   = help: the trait `std::marker::Sized` is not implemented for `T`
   = note: to learn more, visit <https://doc.rust-lang.org/book/ch19-04-advanced-types.html#dynamically-sized-types-and-the-sized-trait>
help: you could relax the implicit `Sized` bound on `T` if it were used through indirection like `&T` or `Box<T>`
  --> $DIR/adt-param-with-implicit-sized-bound.rs:18:10
   |
LL | struct X<T>(T);
   |          ^  - ...if indirection was used here: `Box<T>`
   |          |
   |          this could be changed to `T: ?Sized`...
pnkfelix (Jul 09 2020 at 15:04, on Zulip):

neat! Thanks @Esteban Küber

pnkfelix (Jul 09 2020 at 15:04, on Zulip):

and thanks to everyone in @T-compiler/meeting for attending!

pnkfelix (Jul 09 2020 at 15:04, on Zulip):

stay safe, stay well. :mask:

pnkfelix (Jul 09 2020 at 15:05, on Zulip):

(oh yes, just as a reminder: we have canceled our steering meetings for this cycle, as discussed last week

pnkfelix (Jul 09 2020 at 15:05, on Zulip):

so no meeting at this time tomorrow! :party_ball: )

Last update: Nov 25 2020 at 02:15UTC