Stream: t-compiler

Topic: weekly meeting 2019-06-27 #54818


pnkfelix (Jun 27 2019 at 13:22, on Zulip):

Hi @T-compiler/meeting ; the triage meeting will be starting in 28 minutes

pnkfelix (Jun 27 2019 at 13:22, on Zulip):

I will be doing pre-triage in a parallel topic

oli (Jun 27 2019 at 13:51, on Zulip):

I'll be 30 minutes late :bike: location change

oli (Jun 27 2019 at 13:54, on Zulip):

Oh wait I have mobile internet nowadays. Nevermind

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

Okay, hi again @T-compiler/meeting

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

We'll be starting the meeting now, lets open the floor to announcements for the first few minutes.

eddyb (Jun 27 2019 at 14:02, on Zulip):

/me *chirp* *chirp*

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

My personal hope is that we'll actually get through all the nominated issues today; but since I am hoping to focus on those, I want to first draw attention a different set of issues we found during pre-triage: unassigned, P-high, and unnominated

centril (Jun 27 2019 at 14:03, on Zulip):

(I would personally like https://github.com/rust-lang/rust/issues/21934 to get bumped)

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

there are "only" five of them left. Since they are not nominated, we aren't going to talk about them. But since they're P-high, they are surely hoping that someone will take them home and make them their pet issue

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

/me watched Toy Story 4 last night and has been musing on making some sort of joke there

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

@pnkfelix as long as there are no spoilers :slight_smile:

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

okay, if there aren't any announcements, lets see

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

we have 8 nominated T-compiler issues today

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

lets start with "Rustdoc recursion limit issue" #62059

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

it seems like @nagisa , who was looking into this, might not be here right now

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

oh wait, is this just a stable-to-nightly regression right now? Not a stable-to-beta one?

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

For some reason I thought this was something that was going to affect the imminent release

eddyb (Jun 27 2019 at 14:08, on Zulip):

can we maybe, uhhh, just silently swallow the recursion limit tripping, during rustdoc?

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

I was thinking more along the lines of raising the limit for rustdoc alone

eddyb (Jun 27 2019 at 14:09, on Zulip):

missing Unpin or w/e synthetic impls in the docs is less problematic than rustdoc not being able to build docs

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

so they take the performance hit/blame

eddyb (Jun 27 2019 at 14:09, on Zulip):

even if no limit would suffice (but otherwise, yeah, rustdoc should just set higher limits anyway)

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

oh, by swallow, you mean just treat it as "trait is not implemented", without signalling anything?

eddyb (Jun 27 2019 at 14:10, on Zulip):

pretty much yeah

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

I suppose that's a third option beyond the ones that @nagisa outlined

eddyb (Jun 27 2019 at 14:10, on Zulip):

it could hit an infinite recursion, which is what I meant earlier by "no limit would suffice"

eddyb (Jun 27 2019 at 14:10, on Zulip):

even if the code itself doesn't normally trigger it

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

"no limit would suffice" is an ambiguous phrase.

eddyb (Jun 27 2019 at 14:11, on Zulip):

oh dear that took a bit to register

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

I literally parsed it as "(no limit) aka infinity would suffice", not

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

not "\not \exists limit such that limit suffices"

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

anyway

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

I think I'll assign this to @nagisa for now

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

okay I left a comment, assigned to @nagisa, and removed the nomination.

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

next: "Incorrect span / broken rustfix: help: use dyn: dyn #[dom_struct]" #61963

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

hmm does this actualy have anything to be discussed here?

eddyb (Jun 27 2019 at 14:15, on Zulip):

"how do we actually even figure out if spans are good"

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

I don't know; I saw some suggest code in the borrow checker this week using string-matching that made me a sad :panda:

eddyb (Jun 27 2019 at 14:16, on Zulip):

(I'm guessing some combination of looking at the sub-structure and making sure that the leftmost path component is in the snippet matching the span)

eddyb (Jun 27 2019 at 14:16, on Zulip):

I wish I could solve this at a more foundational level but it would take forever and proc macros might still find a way to screw with it

eddyb (Jun 27 2019 at 14:17, on Zulip):

(this is irrelevant to fixing that bug now though)

centril (Jun 27 2019 at 14:17, on Zulip):

David is assigned anyways

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

@davidtwco you were just recently assigned to this issue; do you want to ask any Q's or add anything else while we are on this topic?

centril (Jun 27 2019 at 14:17, on Zulip):

Move on

davidtwco (Jun 27 2019 at 14:17, on Zulip):

I'm good for just now, thanks.

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

okay next up: "Soundness hole in pattern matching on enums with an uninhabited variant" #61696

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

but this again probably doesn't need nomination anymore, right @eddyb ?

eddyb (Jun 27 2019 at 14:18, on Zulip):

yeah we know the cause and I'm assigned

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

okay. removing nominatino

eddyb (Jun 27 2019 at 14:19, on Zulip):

(why does math have to be so hard :P)

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

next: "Self as default type isnt typechecked" #61631

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

okay well this seems tricky

centril (Jun 27 2019 at 14:22, on Zulip):

struct Bug<F: Fn(&u8) = fn() -> &'static u8> { being accepted is really weird

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

based on the last comment from alexreg, my most immediate question is: Should we indeed just focus on use-site issues and not worry about the the definition site ones?

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

It leaves a bad taste in my mouth and a funny feeling in my stomach

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

but maybe that's love

eddyb (Jun 27 2019 at 14:23, on Zulip):

ugh this is like the type alias stuff

centril (Jun 27 2019 at 14:23, on Zulip):

@pnkfelix if so then there's no bug?

eddyb (Jun 27 2019 at 14:23, on Zulip):

/me goes and cries in a corner

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

I personally don't want to give up on definition site checks without looking into it a bit more first

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

@pnkfelix should we discuss some more at t-lang mtg?

eddyb (Jun 27 2019 at 14:24, on Zulip):

we should introduce warnings at the very least even if we can't ever make them hard errors, etc.

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

@centril I don't know, it depends on whether we think we have enough information.

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

at the very least, I'd want @nikomatsakis to weigh in

eddyb (Jun 27 2019 at 14:25, on Zulip):

same for type aliases, I need to put my old PRs somewhere on my TODO list :(

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

(before we allocate a T-lang meeting slot to it)

eddyb (Jun 27 2019 at 14:25, on Zulip):

unless we have someone who wants to work on adding warnings to things

centril (Jun 27 2019 at 14:25, on Zulip):

@pnkfelix but niko will be there...? so they can weigh in?

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

((I attempted to clarify that if possible, I dont' want to make niko have to respond on this matter without giving them the chance to investigate on their own.))

centril (Jun 27 2019 at 14:26, on Zulip):

ah

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

okay, well, it sounds like @eddyb has thoughts on this

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

@eddyb maybe I can assign you and myself to this issue

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

OK; Let's postpone it for the t-lang meeting then and maybe @eddyb and @nikomatsakis can investigate

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

to try to ensure that we follow up on it? (And Ill cc @nikomatsakis on it too, I guess)

eddyb (Jun 27 2019 at 14:27, on Zulip):

as with type aliases, I feel like at the very least we should warn about unusable things

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

(type X = Vec<[u8]>; and struct Foo<X = [u8]>(X); as examples of both)

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

okay, next nominated issue: "Incremental compilation results in linker error when method use is removed" #59535

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

I'd give this to @mw but they are on leave

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

@Zoxc perhaps?

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

I'm not sure; @Zoxc did a bunch of parallel rustc stuff, of course; but have they done much with incremental?

eddyb (Jun 27 2019 at 14:33, on Zulip):

(yes)

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

okay then, I'll tentatively assign to @Zoxc and see

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

(i am as usual in a general state of concern about how these bugs with incr-comp come up.)

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

next nomination: 'Coherence can be bypassed by an indirect impl for a trait object' #57893

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

this has gotten a lot of recent discussion, both on issue and on zulip

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

it seems like @RalfJ and @Ariel Ben-Yehuda are making progress in defining what the problem is and the options for resolving it

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

@centril too :P

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

We've booked a t-lang meeting slot for it

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

should I remove T-compiler from the issue?

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

at this point, is there much hope for a compier-based solution?

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

(as opposed to some sort of language change...?)

centril (Jun 27 2019 at 14:40, on Zulip):

don't think so

centril (Jun 27 2019 at 14:40, on Zulip):

seems like a fundamental "type theory" based hole

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

(here's link to associated zulip discussion)

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

Okay well my current inclination is to assign this to either @RalfJ or @centril or both

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

just in terms of having someone charged with seeing progress made on this issue

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

Niko was going to think about it iirc

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

(I don't want to assign @Ariel Ben-Yehuda nor @Ariel Ben-Yehuda since I do not know what their availability is)

centril (Jun 27 2019 at 14:42, on Zulip):

I told them about our language team meeting on the 11th

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

@centril I'm going to assign it to you, not because I expect you to implement a solution, but because I trust you will get fires going under peoples' butts about it.

centril (Jun 27 2019 at 14:42, on Zulip):

sgtm :P

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

niko's assigned but they were supposed to delegate. I'm going to unassign niko.

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

next nominated issue: "The compiler should report publicly exported type names if possible" #21934

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

Another case where this is a big problem: https://internals.rust-lang.org/t/type-level-programming-how-to-provide-better-compiler-errors/10466/2

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

so this is the classic issue with our diagnostics reporting an item according to the path to its definition, and not the path for how the local code is actually able to use it.

Esteban Küber (Jun 27 2019 at 14:45, on Zulip):

(that's the one I brought to your attention during all hands in Berlin)

Esteban Küber (Jun 27 2019 at 14:45, on Zulip):

Yep

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

I had mused on the ticket about whether we could work around this in a limited fashion via an attribute on such items

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

(also reporting the RHS of type aliases rather than the alias name)

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

that obviously would not resolve the problem for crates in the wild that re-export items from other crates

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

but: How many cases do we think such an attribute could resolve?

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

Feels like a compiler bug, not something a language change should fix

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

yes, but if you're saying its high priority to fix,and its hard to fix

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

then sometimes band-aids are the right worse-is-better type approach, at least for short-term?

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

@pnkfelix if it's a rustc_ attribute, sure :slight_smile:

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

so maybe a reasonable next step could be to try to estimate how many of the issues that point to this ticket could be resolved by that.

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

I.e. if its almost always a core/std thing

eddyb (Jun 27 2019 at 14:48, on Zulip):

this is related to printing shorter paths when a prefix is in scope, isn't it?

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

then a rustc_ attribute would be reasonable.

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

@eddyb I suppose its related to that

eddyb (Jun 27 2019 at 14:49, on Zulip):

(with the elephant in the room being propagating that information around)

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

but I think the real point is that we often print paths that are simply unusable -- and its not a matter of trying to provide the minimal path

Wesley Wiser (Jun 27 2019 at 14:50, on Zulip):

(Friendly time check: there are 10 minutes left in the meeting)

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

the final question is whether this should be P-high for the compiler team

eddyb (Jun 27 2019 at 14:50, on Zulip):

yeah but if we printed contextual paths then they would likely end up with an usable path being printed

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

Ideally we would print the path in scope; -- it says E-hard but there's not a lot of info about why that is

eddyb (Jun 27 2019 at 14:50, on Zulip):

(you could argue there are cases in which it's hard to pick a good context)

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

yeah but if we printed contextual paths then they would likely end up with an usable path being printed

yes of course; but I think the point is that is the E-hard approach

eddyb (Jun 27 2019 at 14:50, on Zulip):

@centril massive amounts of infrastructure needed to track and propagate the information

eddyb (Jun 27 2019 at 14:51, on Zulip):

it's like adding Spans to a compiler without them, almost :P

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

Personally, I think this should be P-super-high for wg-diagnostics, but that's just me :slight_smile:

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

right, and this might reflect a weakness in our labelling system

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

is WG-diagnostics the same thing as WG-compiler-errors ?

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

anyway I do want to move along

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

so that we can actually get through the whole list of nominated issues (!)

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

so I'll leave the nominated tag on #21934

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

and maybe we can make more progress in this discussion asychronously before next week

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

last nominated issue: ""immutable field" errors are confusing when the handle is mutable, should describe why it is immutable" #18150

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

I nominated this because I was not convinced that it warranted a P-high prioritization

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

Though since I nominated it, I think I looked at a potentially related issue

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

namely of how our diagnosics fall down hard when you have e.g. a coercion from &mut &T to &T

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

(and it ends up suggesting that you write &mut mut expr)

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

the main connection I'm seeing is that this may come down to having better infrastructure for explaining where auto-ref and auto-derefs are injected and why

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

Still doesn't necessary mean that its P-high, though ...

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

@centril , what do you think of this case (#18150) for WG-diagnostics ?

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

Not sure :slight_smile:

Esteban Küber (Jun 27 2019 at 14:58, on Zulip):

I think it is high prio for diagnostics but we're operating on a best effort basis, don't know how long it'll take for us to reach this

Esteban Küber (Jun 27 2019 at 14:58, on Zulip):

It is super misleading when you get it

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

One thing I'm definitely taking away from this discussion

Esteban Küber (Jun 27 2019 at 14:58, on Zulip):

Per wg prio labels?

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

is, on a meta level, the P labels are failing when it comes to per-WG vs per-team priorities

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

yes, exactly

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

luckily we can talk about that tomorrow.

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

which reminds me

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

I should have included this in the announcements, sorry all

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

last minute announcement

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

(literally)

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

tomorrow we have a steering meeting

pnkfelix (Jun 27 2019 at 15:00, on Zulip):

topic is triage and maintenance

pnkfelix (Jun 27 2019 at 15:00, on Zulip):

meta data for meeting is here : https://github.com/rust-lang/compiler-team/issues/90

pnkfelix (Jun 27 2019 at 15:00, on Zulip):

and some notes (I think at this point authored by niko myself and centril) are here: https://hackmd.io/dvgegmdgQVSMbC4rcjG6EA

pnkfelix (Jun 27 2019 at 15:01, on Zulip):

so I'm going to go ahead and add this WG-/T - prioritization as sub-bullet there now

pnkfelix (Jun 27 2019 at 15:01, on Zulip):

but, before I do that:

pnkfelix (Jun 27 2019 at 15:01, on Zulip):

Thank you to everyone in @T-compiler/meeting for attending today!

davidtwco (Jun 27 2019 at 15:02, on Zulip):

Thanks for running the meeting @pnkfelix!

nagisa (Jun 27 2019 at 15:24, on Zulip):

even if no limit would suffice (but otherwise, yeah, rustdoc should just set higher limits anyway)

@eddyb do you happen to know how to selectively ignore errors like that in Rust? The methods do not return a Result here and use your typical rustc diagnostics mechanism.

eddyb (Jun 27 2019 at 15:42, on Zulip):

@nagisa I'd ask @pnkfelix or @nikomatsakis. it should be possible but you might have to go around some of the higher-level APIs (there is code in rustc::traits::auto_traits btw that exists only for rustdoc, and was lifted from it, that could be doing something with results internally)

Last update: Nov 20 2019 at 01:20UTC