Stream: t-compiler

Topic: weekly meeting 2019-12-05 #54818


pnkfelix (Dec 05 2019 at 13:38, on Zulip):

Hi @T-compiler/meeting ; the triage meeting will be starting in 1 hour 22 minutes.

pnkfelix (Dec 05 2019 at 13:39, on Zulip):

I will be doing pre-triage in a parallel topic

pnkfelix (Dec 05 2019 at 13:39, on Zulip):

this week we have checkin's scheduled from WG-learning and WG-llvm

pnkfelix (Dec 05 2019 at 13:40, on Zulip):

@Santiago Pastorino , you around to provide an update from WG-learning?

pnkfelix (Dec 05 2019 at 13:40, on Zulip):

(I don't see a zulip stream for wg-learning, maybe I'm overlooking it)

pnkfelix (Dec 05 2019 at 13:41, on Zulip):

@nagisa , I think last time I asked you about WG-llvm, you noted you had a lot of other things going on in life (i think). Do you think we should try to find a co-lead for WG-llvm?

Santiago Pastorino (Dec 05 2019 at 14:01, on Zulip):

Santiago Pastorino , you around to provide an update from WG-learning?

yes, that happens at the end of the meeting, right?

Santiago Pastorino (Dec 05 2019 at 14:01, on Zulip):

(I don't see a zulip stream for wg-learning, maybe I'm overlooking it)

#t-compiler/wg-learning

nagisa (Dec 05 2019 at 14:05, on Zulip):

nagisa , I think last time I asked you about WG-llvm, you noted you had a lot of other things going on in life (i think). Do you think we should try to find a co-lead for WG-llvm?

According to https://github.com/rust-lang/team/blob/master/teams/wg-llvm.toml it seems that I’m the workgroup :sweat_smile:

nagisa (Dec 05 2019 at 14:07, on Zulip):

(I don't see a zulip stream for wg-learning, maybe I'm overlooking it)

This is something that has happening to me as well, the new streams just don’t show up.

pnkfelix (Dec 05 2019 at 14:07, on Zulip):

and I don't see an announcement for this on https://rust-lang.zulipchat.com/#narrow/stream/122649-announce/topic/new.20streams/near/175794042

pnkfelix (Dec 05 2019 at 14:07, on Zulip):

oh here it is: https://rust-lang.zulipchat.com/#narrow/stream/122649-announce/topic/Streams/near/164077391

pnkfelix (Dec 05 2019 at 14:08, on Zulip):

topic changed.

davidtwco (Dec 05 2019 at 14:28, on Zulip):

You don’t get subscribed to new streams by default, they should show up if you click the cog icon next to the “Streams” header on the left sidebar and then the all tab on the dialog that shows up.

davidtwco (Dec 05 2019 at 14:29, on Zulip):

(e.g. that would be the only place that #t-compiler/wg-polymorphization should show up, I just created it a day or two ago with only a few members by default)

lqd (Dec 05 2019 at 14:34, on Zulip):

(seems it still is private though @davidtwco)

Esteban Küber (Dec 05 2019 at 14:35, on Zulip):

(btw, I'll be airborne during the meeting, wont be able to attend)

pnkfelix (Dec 05 2019 at 15:02, on Zulip):

:construction_worker: request for bug fix: "Const generic ICE: constant in type had an ignored error: TooGeneric" #66962

pnkfelix (Dec 05 2019 at 15:03, on Zulip):

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

pnkfelix (Dec 05 2019 at 15:04, on Zulip):

sorry for starting late; wanted to get through making agenda

pnkfelix (Dec 05 2019 at 15:04, on Zulip):

agenda: https://hackmd.io/4AaN_0u5Re-OhM48FWg7CQ?both

pnkfelix (Dec 05 2019 at 15:04, on Zulip):

so lets have five minutes for

pnkfelix (Dec 05 2019 at 15:04, on Zulip):

Announcements

centril (Dec 05 2019 at 15:05, on Zulip):

- I'm working on some major refactoring of the expression, statement, and item parsers in librustc_parse

Santiago Pastorino (Dec 05 2019 at 15:06, on Zulip):

- I'm working on some major refactoring of the expression, statement, and item parsers in librustc_parse

do you have a WIP branch or open draft PR?, interested in seeing what you're doing :)

Santiago Pastorino (Dec 05 2019 at 15:06, on Zulip):

otherwise please share when you're done

eddyb (Dec 05 2019 at 15:07, on Zulip):

#56231 landed which unblocks optimizing MIR while preserving debuginfo for variables (copy propagation can already make two user variables share a MIR local, and inlining works with closure captures now)

centril (Dec 05 2019 at 15:08, on Zulip):

@Santiago Pastorino https://github.com/rust-lang/rust/pull/66994 for stmt & expression parser part 1

centril (Dec 05 2019 at 15:09, on Zulip):

https://github.com/Centril/rust/tree/item-merge for some work on item parsers

centril (Dec 05 2019 at 15:09, on Zulip):

but still WIP

pnkfelix (Dec 05 2019 at 15:09, on Zulip):

okay. If anyone has any more announcements for the team, privmsg me and we'll allocate time at the end

pnkfelix (Dec 05 2019 at 15:10, on Zulip):

first up, beta-nominations

pnkfelix (Dec 05 2019 at 15:10, on Zulip):

beta-nom 1/2: "E0023: handle expected != tuple pattern type" #67044

pnkfelix (Dec 05 2019 at 15:13, on Zulip):

ah gotta love good old match (e1, e2, e3) ...

pnkfelix (Dec 05 2019 at 15:13, on Zulip):

(I'm not saying that sarcastically, though I do know "some people" who have undid code of mine using that sort of pattern)

centril (Dec 05 2019 at 15:13, on Zulip):

:heart: using more pattern matching

pnkfelix (Dec 05 2019 at 15:13, on Zulip):

anyway looks good beta-accepted

centril (Dec 05 2019 at 15:13, on Zulip):

(and wohoo, slice patterns, [x, tail @ ..] are almost ready to ship!)

pnkfelix (Dec 05 2019 at 15:14, on Zulip):

beta-nom 2/2: "Fix some issues with attributes on unnamed fields" #66669

nikomatsakis (Dec 05 2019 at 15:14, on Zulip):

ah gotta love good old match (e1, e2, e3) ...

heh, I was just thinking "man I always find that pattern hard to read" :P

nikomatsakis (Dec 05 2019 at 15:15, on Zulip):

(but no criticism of the PR, I know others feel differently)

centril (Dec 05 2019 at 15:15, on Zulip):

@nikomatsakis I will go to great lengths to avail myself of slice patterns ;)

pnkfelix (Dec 05 2019 at 15:17, on Zulip):

of note: PR #66669 fixes "tuple structs with all-public fields can not be instantiated if one of the fields has an external attribute" #66555, which is a stable-to-stable regression, and a pretty nasty one at that.

pnkfelix (Dec 05 2019 at 15:17, on Zulip):

so yeah, I think beta-accepted too

pnkfelix (Dec 05 2019 at 15:17, on Zulip):

next, stable-nominations

nikomatsakis (Dec 05 2019 at 15:18, on Zulip):

I can't really udnerstand #66669 but I guess "small-ish, seems good" :)

pnkfelix (Dec 05 2019 at 15:18, on Zulip):

stable-nom 1/2: "Fix some issues with attributes on unnamed fields" #66669

pnkfelix (Dec 05 2019 at 15:18, on Zulip):

i.e. the PR we were just discussing

centril (Dec 05 2019 at 15:18, on Zulip):

feels potentially more risky for stable?

pnkfelix (Dec 05 2019 at 15:19, on Zulip):

so lets take a moment and double-check this, since if niko says "I can't really understand ..." , its worth pausing, especially for stsble

centril (Dec 05 2019 at 15:19, on Zulip):

(cause it has hacks?)

mw (Dec 05 2019 at 15:19, on Zulip):

the next release is in two weeks, so backporting to beta now is almost like backporting to stable

nikomatsakis (Dec 05 2019 at 15:20, on Zulip):

seems like we can prob just backport to beta

nikomatsakis (Dec 05 2019 at 15:20, on Zulip):

but I guess that's release team's decision

nikomatsakis (Dec 05 2019 at 15:20, on Zulip):

just because I don't understand it doesn't mean much, I'm not familiar with that code

nikomatsakis (Dec 05 2019 at 15:20, on Zulip):

but the changes are not like an obvious mapping

nikomatsakis (Dec 05 2019 at 15:21, on Zulip):

(at least to me)

pnkfelix (Dec 05 2019 at 15:22, on Zulip):

I don't even know what an expansion placeholder is

pnkfelix (Dec 05 2019 at 15:22, on Zulip):

and that's like, all of the PR

nikomatsakis (Dec 05 2019 at 15:23, on Zulip):

heh yes

mw (Dec 05 2019 at 15:23, on Zulip):

I think we can trust the reviewers, right?

pnkfelix (Dec 05 2019 at 15:23, on Zulip):

so on the one hand, since release is so close, a beta approval is essentially like a stable-approval

pnkfelix (Dec 05 2019 at 15:23, on Zulip):

so that's an argument for just using same approval decision for both. But its not a great argument.

pnkfelix (Dec 05 2019 at 15:24, on Zulip):

I am willing to trust reviewers. And this does seem like a pretty bad bug, i.e. worth fixing

centril (Dec 05 2019 at 15:24, on Zulip):

(t-compiler is supposed to do technical reviews for stable approvals & assess risk, but from T-release's POV I believe we said that a point release is unlikely 2 weeks to a new release)

eddyb (Dec 05 2019 at 15:25, on Zulip):

(ignore me)

pnkfelix (Dec 05 2019 at 15:26, on Zulip):

okay well lets wrap this up

pnkfelix (Dec 05 2019 at 15:26, on Zulip):

the main argument against a stable backport is that this contains self-described Hacks

nikomatsakis (Dec 05 2019 at 15:26, on Zulip):

(I trust the reviewrs, I'm :+1: to backport)

pnkfelix (Dec 05 2019 at 15:26, on Zulip):

but I think those Hacks are likely to live on, until someone goes through and, like, re-writes all of this

pnkfelix (Dec 05 2019 at 15:27, on Zulip):

so I too am :thumbs_up: to backport

pnkfelix (Dec 05 2019 at 15:27, on Zulip):

so okay, lets go with stable-accepted on PR #66669

pnkfelix (Dec 05 2019 at 15:27, on Zulip):

stable-nom 2/2: "Do not ICE in if without else in async fn" #66391

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

it would be nice if we actually knew if this fixes #66618.

nikomatsakis (Dec 05 2019 at 15:30, on Zulip):

it seems safe enough, in an case

pnkfelix (Dec 05 2019 at 15:30, on Zulip):

it certainly seems very low risk

pnkfelix (Dec 05 2019 at 15:30, on Zulip):

stable-accepted

pnkfelix (Dec 05 2019 at 15:31, on Zulip):

I didn't have time today to traverse the P-high issues

pnkfelix (Dec 05 2019 at 15:31, on Zulip):

and we're not going to do it live, despite what Bill O'Reilly might say

mw (Dec 05 2019 at 15:31, on Zulip):

it would be nice if we actually knew if this fixes #66618.

it ICEs on stable and beta, not on nightly

centril (Dec 05 2019 at 15:31, on Zulip):

(what's the reference?)

pnkfelix (Dec 05 2019 at 15:31, on Zulip):

I'll just mention we have 44 open P-high issues and 25 unassigned open P-high issues

pnkfelix (Dec 05 2019 at 15:32, on Zulip):

(what's the reference?)

letmegooglethatforyou

pnkfelix (Dec 05 2019 at 15:32, on Zulip):

anyway that's all a way for me to just slide directly to Nominated issues

pnkfelix (Dec 05 2019 at 15:32, on Zulip):

see agenda: https://hackmd.io/4AaN_0u5Re-OhM48FWg7CQ?view#Nominated-Issues

pnkfelix (Dec 05 2019 at 15:33, on Zulip):

I've curated five nominated issues for today

pnkfelix (Dec 05 2019 at 15:33, on Zulip):

nom 1/5: "Regression in Error conversion from Infallible" #66757

pnkfelix (Dec 05 2019 at 15:33, on Zulip):

seven options are laid out in this comment

nikomatsakis (Dec 05 2019 at 15:34, on Zulip):

Ah yeah. I think we need to take action quickly here. I am inclined to revert while we work it out.

pnkfelix (Dec 05 2019 at 15:34, on Zulip):

the actual decision won't be made here alone; or at least, some options also need T-lang approval

pnkfelix (Dec 05 2019 at 15:34, on Zulip):

but I figured it would be good to at least take temperature of people here

nikomatsakis (Dec 05 2019 at 15:34, on Zulip):

(I am reminded I had a comment started..somewhere..suggesting how we could adjust type fallback in more detail; not sure yet if I like the idea)

pnkfelix (Dec 05 2019 at 15:34, on Zulip):

(just saying "revert" is not precise enough; at least three options include that word)

pnkfelix (Dec 05 2019 at 15:35, on Zulip):

I am personally included to go with option 7: "We revert Infallible to an empty enum and the stabilization of the never type"

centril (Dec 05 2019 at 15:35, on Zulip):

I might be biased, but I'm in favor of 1/3.

pnkfelix (Dec 05 2019 at 15:35, on Zulip):

that is, I don't see a reason to rush ! out the door

centril (Dec 05 2019 at 15:36, on Zulip):

still reading niko's last comment tho

pnkfelix (Dec 05 2019 at 15:36, on Zulip):

if other people have different opinions, I guess post them on the issue

nikomatsakis (Dec 05 2019 at 15:37, on Zulip):

I am personally included to go with option 7: "We revert Infallible to an empty enum and the stabilization of the never type"

yes, sorry, this is what I meant

pnkfelix (Dec 05 2019 at 15:37, on Zulip):

In any case lets move along. I don't think this needs synchronous discussion amongst T-compiler

pnkfelix (Dec 05 2019 at 15:37, on Zulip):

nom 2/5: "Necromancing (putting back some removed error codes explanations)" #66836

pnkfelix (Dec 05 2019 at 15:38, on Zulip):

the high level story here is as imperio put it in the PR: "Even if the error code isn't used by the compiler anymore, we should keep the explanations in case people using old versions of the compiler want to read them."

pnkfelix (Dec 05 2019 at 15:38, on Zulip):

I agree people reading old diagnostics may want the explanatory information

nagisa (Dec 05 2019 at 15:38, on Zulip):

Also, so that the error numbers are not reused in the future.

pnkfelix (Dec 05 2019 at 15:38, on Zulip):

but I don't think it needs to live in the compiler object code (binary and libraries)

pnkfelix (Dec 05 2019 at 15:39, on Zulip):

reserving the errors number is a fine idea to me

centril (Dec 05 2019 at 15:39, on Zulip):

@nagisa we have a system for that

centril (Dec 05 2019 at 15:39, on Zulip):

keeping old error numbers ostensibly is technical debt and keeps us from e.g using a more tree-like structure that @eddyb wants

nagisa (Dec 05 2019 at 15:39, on Zulip):

@centril in my memory the system was to keep the numbers in in the macros, with or without explanations. From the PR it appears to be re-adding the numbers back.

eddyb (Dec 05 2019 at 15:39, on Zulip):

we sometimes treat error codes as if they're a deliberate diagnostic catalog system

pnkfelix (Dec 05 2019 at 15:40, on Zulip):

keeping old error numbers ostensibly is technical debt and keeps us from e.g using a more tree-like structure that eddyb wants

wait, that sounds like we should not even reserve the error numbers?

pnkfelix (Dec 05 2019 at 15:40, on Zulip):

is this not something we can resolve quickly? Do we need a design meeting about our long-term approach to error diagnostic cataloguing?

eddyb (Dec 05 2019 at 15:40, on Zulip):

and without revising every single diagnostic to improve this, the meaningfulness of individual error codes is all over the place

centril (Dec 05 2019 at 15:41, on Zulip):

@pnkfelix my point is that if we readd these then what's a pretty strong "let's not change into a tree structure for existing diagnostics because it will make links outdated"

nikomatsakis (Dec 05 2019 at 15:41, on Zulip):

I'm trying to understand the use case exactly

nikomatsakis (Dec 05 2019 at 15:41, on Zulip):

if I'm using an old version of the compiler

nikomatsakis (Dec 05 2019 at 15:41, on Zulip):

then why am I running --explain on the new one?

pnkfelix (Dec 05 2019 at 15:41, on Zulip):

if I'm using an old version of the compiler

I don't think this made sense

nikomatsakis (Dec 05 2019 at 15:41, on Zulip):

I guess maybe it's running on travis or something

pnkfelix (Dec 05 2019 at 15:41, on Zulip):

I was trying to be charitable by rephrasing in my high level description

nikomatsakis (Dec 05 2019 at 15:41, on Zulip):

but it seems like it's easy enough to use rustup

pnkfelix (Dec 05 2019 at 15:41, on Zulip):

by acting like you're looking at an old diagnostic (e.g. in a blog post)

centril (Dec 05 2019 at 15:42, on Zulip):

blogs & stack overflow do seem more likely

nagisa (Dec 05 2019 at 15:42, on Zulip):

The error codes were added so that they are easibly searchable on the internet and I suppose if you found E123 on stackoverflow and wanted to read its explanation, it doesn’t matter which version of the compiler you’re running

centril (Dec 05 2019 at 15:42, on Zulip):

but still, you can google and there are archives

eddyb (Dec 05 2019 at 15:42, on Zulip):

IMO exposing error codes to users was a mistake because some now expect to be able to use them as something that they're really not

pnkfelix (Dec 05 2019 at 15:42, on Zulip):

so there it sounds like there are two topics here:

nikomatsakis (Dec 05 2019 at 15:42, on Zulip):

OK. I don't really have a strong opinion on this, but I think that saying "this error code is no longer emitted by the compiler" probably suffices personally

pnkfelix (Dec 05 2019 at 15:42, on Zulip):
  1. are error codes meant to be reserved for all time?
eddyb (Dec 05 2019 at 15:43, on Zulip):

and I keep seeing error codes in places where two-three words would be infinitely more useful

pnkfelix (Dec 05 2019 at 15:43, on Zulip):
  1. are the diagnostic messages (for reserved error codes) meant to be reserved for all time?
centril (Dec 05 2019 at 15:43, on Zulip):
  1. ouch... no diagnostics improvements for you :sweat_smile:
nikomatsakis (Dec 05 2019 at 15:43, on Zulip):

well, the "extended" descriptions etc

pnkfelix (Dec 05 2019 at 15:43, on Zulip):

well, 2 modulo "improvements"

pnkfelix (Dec 05 2019 at 15:44, on Zulip):

anyway this is taking more time than I expected.

centril (Dec 05 2019 at 15:44, on Zulip):

I personally don't even bother with error codes for new diagnostics myself

pnkfelix (Dec 05 2019 at 15:44, on Zulip):

but I suspect we should collective r- this

pnkfelix (Dec 05 2019 at 15:44, on Zulip):

and say "we're not sure what our exact plan is, but its probably not this."

nikomatsakis (Dec 05 2019 at 15:44, on Zulip):

maybe a good design topic

centril (Dec 05 2019 at 15:44, on Zulip):

cc @GuillaumeGomez

nikomatsakis (Dec 05 2019 at 15:44, on Zulip):

that is, I think it'd be worth trying to formulate a plan around diagnostic codes

nikomatsakis (Dec 05 2019 at 15:44, on Zulip):

like @eddyb I have my concerns :)

centril (Dec 05 2019 at 15:45, on Zulip):

(and around internationalization!)

nikomatsakis (Dec 05 2019 at 15:45, on Zulip):

I personally don't even bother with error codes for new diagnostics myself

and then there are comments like this

nikomatsakis (Dec 05 2019 at 15:45, on Zulip):

(with which I sympathsize)

pnkfelix (Dec 05 2019 at 15:45, on Zulip):

okay. maybe eddyb can draft whatever this error-code tree is

eddyb (Dec 05 2019 at 15:45, on Zulip):

what we should've done (hindsight 2020) is do a top-down error grouping, and then reduce the coarseness of the granularity over time, to the point where individual diagnostics are designed to be meaningfully distinct and can be associated their own identifier

pnkfelix (Dec 05 2019 at 15:45, on Zulip):

I didn't even know it was an option to not use an error code

eddyb (Dec 05 2019 at 15:45, on Zulip):

idk what @centril meant, btw, @pnkfelix

centril (Dec 05 2019 at 15:45, on Zulip):

and then there are comments like this

to elaborate, it's a time sink, better spent on improving the diagnostics in rustc itself

eddyb (Dec 05 2019 at 15:45, on Zulip):

@Manish Goregaokar was talking about some stuff that has had more thought put into it than I have spent on the matter

centril (Dec 05 2019 at 15:45, on Zulip):

@eddyb meant by?

eddyb (Dec 05 2019 at 15:46, on Zulip):

the "tree" thing

pnkfelix (Dec 05 2019 at 15:46, on Zulip):

okay lets move along

pnkfelix (Dec 05 2019 at 15:46, on Zulip):

maybe allocate a separate zulip topic for this

pnkfelix (Dec 05 2019 at 15:46, on Zulip):

after meeting is over

centril (Dec 05 2019 at 15:46, on Zulip):

@eddyb a more semantic categorization of errors

pnkfelix (Dec 05 2019 at 15:46, on Zulip):

nom 3/5: "[WIP] [DO NOT MERGE] combine #66020 and #66821." #66838

pnkfelix (Dec 05 2019 at 15:47, on Zulip):

@eddyb can you provide background context here?

pnkfelix (Dec 05 2019 at 15:47, on Zulip):

heh "Even if these PRs may not be perfectly sound" well there's a scary note

nikomatsakis (Dec 05 2019 at 15:47, on Zulip):

that probably doesn't need to be nominated?

pnkfelix (Dec 05 2019 at 15:47, on Zulip):

"cc @rust-lang/compiler @rust-lang/wg-traits I'm nominating this for discussion, so that we can find a way to land at least some of these changes."

pnkfelix (Dec 05 2019 at 15:47, on Zulip):

maybe it was meant to be targetted at just wg-traits?

eddyb (Dec 05 2019 at 15:47, on Zulip):

@nikomatsakis do you want to provide context? or should I

nikomatsakis (Dec 05 2019 at 15:48, on Zulip):

(I think the approach is sound, though as I told @eddyb I was kind of holding that optimization in reserve for chalk :stuck_out_tongue:)

pnkfelix (Dec 05 2019 at 15:48, on Zulip):

@WG-traits ^

nikomatsakis (Dec 05 2019 at 15:48, on Zulip):

(but it's right to do it now)

centril (Dec 05 2019 at 15:48, on Zulip):

Given the number of soundness holes in the type system specifically I think we should be careful with changing WF rules themselves

nikomatsakis (Dec 05 2019 at 15:48, on Zulip):

that's not what this PR is

eddyb (Dec 05 2019 at 15:48, on Zulip):

the important thing is that there's huge perf wins that we've been just not getting for years

GuillaumeGomez (Dec 05 2019 at 15:48, on Zulip):

hi

nikomatsakis (Dec 05 2019 at 15:48, on Zulip):

basically the tl;dr is that we used to only cache results without considering the "environment" (i.e., where clauses in scope) -- therefore, we only cached if there are no where clauses in scope

GuillaumeGomez (Dec 05 2019 at 15:49, on Zulip):

so to answer: yes they are supposed reserved ad vitam

nikomatsakis (Dec 05 2019 at 15:49, on Zulip):

but one of the ideas of chalk was to incorporate the environment into the cache key

nikomatsakis (Dec 05 2019 at 15:49, on Zulip):

which is the approach we're using now in borrowck etc

pnkfelix (Dec 05 2019 at 15:49, on Zulip):

this: "avoid checking Trait's predicates for WF(<T as Trait>::X). " sounds like it could be changing WF rules

nikomatsakis (Dec 05 2019 at 15:49, on Zulip):

eddyb is extending that

nikomatsakis (Dec 05 2019 at 15:49, on Zulip):

ah, ok, I didn't realize that commit was in there too :)

nikomatsakis (Dec 05 2019 at 15:49, on Zulip):

my bad

GuillaumeGomez (Dec 05 2019 at 15:49, on Zulip):

also, a long time ago, we wanted to replace the long explanations with some more interactive explanations

pnkfelix (Dec 05 2019 at 15:49, on Zulip):

that's the thing, this PR is doing both

centril (Dec 05 2019 at 15:49, on Zulip):

there are 3 PRs, no?

eddyb (Dec 05 2019 at 15:49, on Zulip):

@nikomatsakis the nominated PR is explicitly a combination of the two fix attempts

GuillaumeGomez (Dec 05 2019 at 15:49, on Zulip):

they'd take the erroneous user code and based on it, generate some specific explanations

nikomatsakis (Dec 05 2019 at 15:49, on Zulip):

ok, that one I have to ponder a bit, I still favor a different (harder) approach

centril (Dec 05 2019 at 15:49, on Zulip):

"this PR is rather ambiguous" :P

eddyb (Dec 05 2019 at 15:49, on Zulip):

(sorry for the confusion)

nikomatsakis (Dec 05 2019 at 15:50, on Zulip):

"this PR" == the PR that @pnkfelix cited

pnkfelix (Dec 05 2019 at 15:50, on Zulip):

they'd take the erroneous user code and based on it, generate some specific explanations

@GuillaumeGomez okay, sorry for misleading you; we've put that topic aside

pnkfelix (Dec 05 2019 at 15:50, on Zulip):

(backscroll)

mw (Dec 05 2019 at 15:50, on Zulip):

if the two PRs are really orthogonal, we can just merge the uncontroversial one for now?

GuillaumeGomez (Dec 05 2019 at 15:50, on Zulip):

I just received the messages
slow connection T_T

nikomatsakis (Dec 05 2019 at 15:50, on Zulip):

(though I agree, @GuillaumeGomez, that generating "extended' errors instead of having separate codes seems better)

GuillaumeGomez (Dec 05 2019 at 15:50, on Zulip):

sorry for the disturbance, leaving again o/

eddyb (Dec 05 2019 at 15:51, on Zulip):

if the two PRs are really orthogonal, we can just merge the uncontroversial one for now?

yes, #66821 has become even less controversial since the nomination

nikomatsakis (Dec 05 2019 at 15:51, on Zulip):

if the two PRs are really orthogonal, we can just merge the uncontroversial one for now?

I was assuming we would start with the 'extended caching' ones and I'll try to put more energy into validating the final one, or experimenting with an alternae approach

pnkfelix (Dec 05 2019 at 15:51, on Zulip):

okay

pnkfelix (Dec 05 2019 at 15:51, on Zulip):

I think there's general agreement that we should invest effort in landing the caching chasnges

pnkfelix (Dec 05 2019 at 15:51, on Zulip):

but hold off on the WF changes?

pnkfelix (Dec 05 2019 at 15:51, on Zulip):

(maybe "general agreement" is too strong a word)

eddyb (Dec 05 2019 at 15:52, on Zulip):

I think that's fine with me and sufficient for the client I did this for

eddyb (Dec 05 2019 at 15:52, on Zulip):

the wins are in the same ballpark

pnkfelix (Dec 05 2019 at 15:52, on Zulip):

I really just mean that its premature to discuss WF changes in this meeting

pnkfelix (Dec 05 2019 at 15:52, on Zulip):

okay great

pnkfelix (Dec 05 2019 at 15:52, on Zulip):

lets move along then

centril (Dec 05 2019 at 15:52, on Zulip):

(I'm basically a bit wary of "I think it's sound" reasoning not checked by things consistent-as-a-logic, because I feel we've gotten this wrong before...)

eddyb (Dec 05 2019 at 15:52, on Zulip):

(I'm basically a bit wary of "I think it's sound" reasoning not checked by things consistent-as-a-logic, because I feel we've gotten this wrong before...)

see 1.0

pnkfelix (Dec 05 2019 at 15:52, on Zulip):

nom 4/5: another eddyb PR "rustc: include ParamEnv in global trait select/eval cache keys." #66963

centril (Dec 05 2019 at 15:53, on Zulip):

@eddyb as in Rust 1.0?

eddyb (Dec 05 2019 at 15:53, on Zulip):

(yes)

eddyb (Dec 05 2019 at 15:53, on Zulip):

oh this one is nominated because the caching PR uncovered a bug

pnkfelix (Dec 05 2019 at 15:53, on Zulip):

what is here to discuss? Seems like perf regressions are acceptable?

eddyb (Dec 05 2019 at 15:53, on Zulip):

we were poisoning trait caches with the wrong Reveal mode sometimes

eddyb (Dec 05 2019 at 15:54, on Zulip):

this could mean that type-checking could e.g. see impl Trait concrete types, potentially

centril (Dec 05 2019 at 15:54, on Zulip):

(yes)

not sure what you mean by seeing 1.0... that practicality and shipping requires taking risks?

eddyb (Dec 05 2019 at 15:54, on Zulip):

it's unclear yet what the fallout would be, we're mostly saved by the compiler still doing things in a certain order

pnkfelix (Dec 05 2019 at 15:54, on Zulip):

do you think there is a further latent bug here that is not being addressed by this PR ?

eddyb (Dec 05 2019 at 15:54, on Zulip):

(yes)

not sure what you mean by seeing 1.0... that practicality and shipping requires taking risks?

the first year after 1.0 was spent fixing the trait system. IIRC the WF system was added some time after 1.0

eddyb (Dec 05 2019 at 15:55, on Zulip):

@pnkfelix doubtful, unless there is more than the Reveal that can affect the result that's being cached (I'm not aware of anything, but I'm not a trait system expert)

pnkfelix (Dec 05 2019 at 15:56, on Zulip):

okay well I'm not sure what there is for the team to discuss here. Especially if the caching changes improve things more than PR #66963 regresses them. :)

eddyb (Dec 05 2019 at 15:56, on Zulip):

I nominated it because it scared me but we're probably fine

pnkfelix (Dec 05 2019 at 15:56, on Zulip):

I mostly want to make sure we get to the last nomination

pnkfelix (Dec 05 2019 at 15:56, on Zulip):

okay lets push on, I don't see people clamoring to burn you at the stake

centril (Dec 05 2019 at 15:56, on Zulip):

I nominated it because it scared me but we're probably fine

in the sense that it might cause breakage?

pnkfelix (Dec 05 2019 at 15:57, on Zulip):

nom 5/5: "Limit dylib symbols" #59752

pnkfelix (Dec 05 2019 at 15:57, on Zulip):

this is nominated for revert

eddyb (Dec 05 2019 at 15:57, on Zulip):

I nominated it because it scared me but we're probably fine

in the sense that it might cause breakage?

no, the bug itself

pnkfelix (Dec 05 2019 at 15:57, on Zulip):

because multiple issues have identified it as injecting a bug

pnkfelix (Dec 05 2019 at 15:57, on Zulip):

see e..g this comment: https://github.com/rust-lang/rust/pull/59752#issuecomment-554628486

eddyb (Dec 05 2019 at 15:58, on Zulip):

it's been argued some (all?) of those usecases were abusing unspecified behavior

mw (Dec 05 2019 at 15:58, on Zulip):

this is nominated for revert

it's actually nominated for confirming that we don't want to revert because it breaks projects that relied on unspecified behavior

pnkfelix (Dec 05 2019 at 15:58, on Zulip):

that... was not my reading

pnkfelix (Dec 05 2019 at 15:58, on Zulip):

let me go double-check

mw (Dec 05 2019 at 15:58, on Zulip):

plus for finding people that can help look into whether there are actual bugs there

pnkfelix (Dec 05 2019 at 15:58, on Zulip):

" It looks like we should do something. It's not clear to me, however, if the reported breakage is due to code relying on unspecified implementation details or if this should be considered a bug."

pnkfelix (Dec 05 2019 at 15:59, on Zulip):

this bug certainly sounds scary: "dylib shared libraries will not make public symbols that may be necessary to link inlined code" #65610

eddyb (Dec 05 2019 at 15:59, on Zulip):

@Zoxc wrote:

#66265 seems like it should result in a linker error even if exit was exported from Rust since there's multiple definitions of exit. It's not really something that should be supported without explicit support for shadowing symbols (which we don't have).

centril (Dec 05 2019 at 16:00, on Zulip):

didn't the PR have some perf wins also?

mw (Dec 05 2019 at 16:00, on Zulip):

yeah, this just affects a number of things that we don't specify anywhere, so we need a team-wide decision on what to do about breakage

pnkfelix (Dec 05 2019 at 16:00, on Zulip):

okay, how about this

mw (Dec 05 2019 at 16:00, on Zulip):

in principle the PR is the right thing to do

pnkfelix (Dec 05 2019 at 16:00, on Zulip):

I just finished investing a nasty inlining bug

pnkfelix (Dec 05 2019 at 16:00, on Zulip):

I'll assign myself to look at these three bugs

pnkfelix (Dec 05 2019 at 16:01, on Zulip):

or at least #65610

eddyb (Dec 05 2019 at 16:01, on Zulip):

@pnkfelix I think that issue is about FFI-ing to a dylib, which isn't supported explicitly

centril (Dec 05 2019 at 16:01, on Zulip):

@pnkfelix aren't you over-extended as-is?

pnkfelix (Dec 05 2019 at 16:01, on Zulip):

@centril of course I am

centril (Dec 05 2019 at 16:01, on Zulip):

(or maybe you should drop something else)

eddyb (Dec 05 2019 at 16:01, on Zulip):

I don't think Rust dependencies are broken

pnkfelix (Dec 05 2019 at 16:01, on Zulip):

I'm hoping to tie off two items today

pnkfelix (Dec 05 2019 at 16:01, on Zulip):

maybe a third tomorrow

mw (Dec 05 2019 at 16:02, on Zulip):

I'm volunteering to spend a fixed amount of time on https://github.com/rust-lang/rust/issues/64340

pnkfelix (Dec 05 2019 at 16:02, on Zulip):

so we're over time (again)

pnkfelix (Dec 05 2019 at 16:02, on Zulip):

I was hoping to get a checkin from @Santiago Pastorino on WG-learning

eddyb (Dec 05 2019 at 16:02, on Zulip):

wait, the #65610 example is about a C library being privatized behind a dylib?!

Santiago Pastorino (Dec 05 2019 at 16:03, on Zulip):

WG-Learning check-in (2019-12-05)

Acomplished:

- We have a chapter about Salsa, it was summarized from this lecture
- We have a PR for the ty chapter PR, it summarizes this lecture
- We had a planning meeting, where we come up with a document with ideas and next steps for the rustc-guide. We've basically defined kind of a roadmap and a way to work towards those goals.

Next steps:

- Start writing an Overview chapter
- Organize a lecture about codegen mir -> llvm IR (@nagisa, maybe?)
- Organize a lecture about LLVM (@Alex Crichton, maybe?)
- Organize a lecture about monomorphization/type memory layout (@oli, maybe?)

nikomatsakis (Dec 05 2019 at 16:03, on Zulip):

Wow, that's awesome progress

pnkfelix (Dec 05 2019 at 16:03, on Zulip):

Thanks @Santiago Pastorino !

pnkfelix (Dec 05 2019 at 16:04, on Zulip):

@nagisa I assume there's nothing to report from WG-llvm (since you posted recently there that maybe it needs to change its classification)

nagisa (Dec 05 2019 at 16:04, on Zulip):

Yeah.

mw (Dec 05 2019 at 16:04, on Zulip):

@Santiago Pastorino oh sorry, btw, for never replying to your message. I don't have time to prepare lectures but I can do a Q&A on zulip if that helps

nikomatsakis (Dec 05 2019 at 16:04, on Zulip):

(Question: are we going to be discussing the linking breakage in a separate topic?)

pnkfelix (Dec 05 2019 at 16:04, on Zulip):

(Question: are we going to be discussing the linking breakage in a separate topic?)

we probably should. lets fork that off

nikomatsakis (Dec 05 2019 at 16:05, on Zulip):

@Santiago Pastorino do you have thoughts on how to proceed with the overview chapter?

nikomatsakis (Dec 05 2019 at 16:05, on Zulip):

It seems like that would require some interaction with an expert, and I'm curious if you all discussed an idea of what it looks like

nikomatsakis (Dec 05 2019 at 16:05, on Zulip):

also I will try to proof read rust-lang/rustc-guide#530

pnkfelix (Dec 05 2019 at 16:06, on Zulip):

spawned off https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/dylib.20linking.20breakage/near/182674053

Santiago Pastorino (Dec 05 2019 at 16:06, on Zulip):

also I will try to proof read rust-lang/rustc-guide#530

I can let you know when that should be proof read, we are polishing a very tiny thing

centril (Dec 05 2019 at 16:06, on Zulip):

@nikomatsakis @Santiago Pastorino speaking of docs and learning... I was thinking of adding some typing rules to e.g. check_expr_foobarkind -- I started a bit with https://github.com/Centril/rust/commit/6d2467ddf6ff2901f7e5f3522435d635db2daa9f but maybe that's not the right approach there... we sorta mainly have synthesizing bidirectional judgements but with hints...

Santiago Pastorino (Dec 05 2019 at 16:06, on Zulip):

it may be ready tomorrow maybe, but I'd let you know

centril (Dec 05 2019 at 16:06, on Zulip):

could use some input :slight_smile:

Santiago Pastorino (Dec 05 2019 at 16:07, on Zulip):

Santiago Pastorino do you have thoughts on how to proceed with the overview chapter?

about this we have ... https://hackmd.io/j8EsXGI1RiOnjZSiSRf3ng

eddyb (Dec 05 2019 at 16:07, on Zulip):

@centril you should probably use a different case convention for judgements than expressions and types

Santiago Pastorino (Dec 05 2019 at 16:07, on Zulip):

we'd definitely need help, I'm going to ping somebody about it soon, the idea was to start with something first

eddyb (Dec 05 2019 at 16:07, on Zulip):

IsPlaceExpr(lhs) or some variant thereof looks nicer IMO

eddyb (Dec 05 2019 at 16:08, on Zulip):

lhs IsPlaceExpr

nikomatsakis (Dec 05 2019 at 16:08, on Zulip):

we'd definitely need help, I'm going to ping somebody about it soon, the idea was to start with something first

ok

Santiago Pastorino (Dec 05 2019 at 16:08, on Zulip):

nikomatsakis Santiago Pastorino speaking of docs and learning... I was thinking of adding some typing rules to e.g. check_expr_foobarkind -- I started a bit with https://github.com/Centril/rust/commit/6d2467ddf6ff2901f7e5f3522435d635db2daa9f but maybe that's not the right approach there... we sorta mainly have synthesizing bidirectional judgements but with hints...

@centril why don't you write a bigger rustc-guide chapter :smiley:

nikomatsakis (Dec 05 2019 at 16:08, on Zulip):

I've been thinking that it makes sense to base it on a particular example

centril (Dec 05 2019 at 16:08, on Zulip):

@eddyb probably; needs a lot of iteration, and there should probably be a name for the rule on the ----- line

Santiago Pastorino (Dec 05 2019 at 16:08, on Zulip):

yes

centril (Dec 05 2019 at 16:08, on Zulip):

@Santiago Pastorino I wanted inline comments in the code as a start to keep it updated

nikomatsakis (Dec 05 2019 at 16:09, on Zulip):

anyway ok over time for meeting I guess :) very cool stuff!

nikomatsakis (Dec 05 2019 at 16:09, on Zulip):

(I'll take a look, @centril)

centril (Dec 05 2019 at 16:09, on Zulip):

thanks

pnkfelix (Dec 05 2019 at 16:15, on Zulip):

yeah. bye to everyone in @T-compiler/meeting ! Thanks for attending. I gotta go do child care now

Manish Goregaokar (Dec 05 2019 at 18:07, on Zulip):

Yeah the diagnostics stuff is in https://github.com/rust-lang/rust/issues/61132 , we just need to implement that syntax extension

Last update: Jan 21 2020 at 08:20UTC