Stream: t-compiler

Topic: pre-meeting triage 2019-06-06 #54818


pnkfelix (Jun 06 2019 at 10:43, on Zulip):

I will be doing pre-triage in this channel

pnkfelix (Jun 06 2019 at 11:03, on Zulip):

first up: unprioritized nominated T-compiler issues

pnkfelix (Jun 06 2019 at 11:04, on Zulip):

oldest first

pnkfelix (Jun 06 2019 at 11:05, on Zulip):

first up: "ICE on generic impl trait convergence" #58344

pnkfelix (Jun 06 2019 at 11:08, on Zulip):

this has been nominated, but there is no comment directly stating why. I assume that the nomination is just trying to alert us to the comment that provided a more narrow test case for the second of the two ICE's that were being signalled before

pnkfelix (Jun 06 2019 at 11:08, on Zulip):

but overall I would categorize this as Yet Another Impl Trait Bug

pnkfelix (Jun 06 2019 at 11:12, on Zulip):

and it doesn't strike me as something to treat with higher priority than any of the 21 impl trait ICEs

pnkfelix (Jun 06 2019 at 11:13, on Zulip):

triage: P-medium. (But maybe we should have a WG-impl-trait to provide a structured effort for working through the bugs with impl trait?)

pnkfelix (Jun 06 2019 at 11:15, on Zulip):

next: "ICE when trying to match on non-PartialEq slice." #61188

pnkfelix (Jun 06 2019 at 11:16, on Zulip):

@Matthew Jasper states that this arises during MIR construction. Do we apply A-MIR label to such cases? I'll put it on, seems better than nothing.

pnkfelix (Jun 06 2019 at 11:22, on Zulip):

@Esteban Küber linked the bug to #53708, which has changed its behavior since it was filed

pnkfelix (Jun 06 2019 at 11:22, on Zulip):

that is "ICE: const reference to ADT in match pattern" #53708

pnkfelix (Jun 06 2019 at 11:31, on Zulip):

okay I investigated more.

pnkfelix (Jun 06 2019 at 11:32, on Zulip):

Okay so lets triage both of these bugs

pnkfelix (Jun 06 2019 at 11:32, on Zulip):

#53708 strikes me as P-medium

pnkfelix (Jun 06 2019 at 11:33, on Zulip):

#61188 seems like something that might be interesting to look into, but I don't know if I'd call resolving it high priority...

pnkfelix (Jun 06 2019 at 11:36, on Zulip):

I would like to know why we don't catch the error here earlier

pnkfelix (Jun 06 2019 at 11:36, on Zulip):

so I'm going to triage this as P-high for now.

pnkfelix (Jun 06 2019 at 11:41, on Zulip):

next: "'rustc' panicked at 'internal error: entered unreachable code', src/libsyntax/ast.rs:668:6 while bootstrapping" #61200

pnkfelix (Jun 06 2019 at 11:42, on Zulip):

the reporter says they retried their recipe with a clean build and did not reproduce. I'm no sure whether they tried their whole recipe, or just the last step

pnkfelix (Jun 06 2019 at 11:43, on Zulip):

I'm going to try to check that

pnkfelix (Jun 06 2019 at 12:00, on Zulip):

but I'm not sure there's anything here for us to discuss. The bug reporter themself said that they could not reproduce via their own recipe.

pnkfelix (Jun 06 2019 at 12:00, on Zulip):

@centril are you nominating #61200 just in the hopes that someone on the T-compiler may have some insight into what the problem might be?

pnkfelix (Jun 06 2019 at 12:05, on Zulip):

in any case it seems like it might fall into a similar bucket as #60228

centril (Jun 06 2019 at 12:05, on Zulip):

Can you paste the full link? Cannot seem to click it cause zulip has ui bugs

pnkfelix (Jun 06 2019 at 12:05, on Zulip):

#61200: https://github.com/rust-lang/rust/issues/61200

centril (Jun 06 2019 at 12:06, on Zulip):

Yes so the release team nominates all ices

pnkfelix (Jun 06 2019 at 12:07, on Zulip):

yeah okay

centril (Jun 06 2019 at 12:07, on Zulip):

Except for cases we know are buggy incomplete features (const generics)

pnkfelix (Jun 06 2019 at 12:08, on Zulip):

I'm going to prioritize as P-medium and assign to self, with intent to close if I cannot reproduce over next week or so

centril (Jun 06 2019 at 12:09, on Zulip):

Sgtm

pnkfelix (Jun 06 2019 at 12:10, on Zulip):

by the way, do you know off hand when rustbuild makes use of incremental compilation? There's a setting in the config.toml that says it is defaulted to false, and it controls "Whether to always use incremental compilation when building rustc"

pnkfelix (Jun 06 2019 at 12:11, on Zulip):

but that leaves me wondering when we do use it. I would have thought we otherwise get the current defaults, which, if I understand correctly, are debug ==> incremental build, release ==> non-incremental

pnkfelix (Jun 06 2019 at 12:11, on Zulip):

However, there has been evidence that this is not the correct interpretation to apply to rustbuild

centril (Jun 06 2019 at 12:12, on Zulip):

No I don't sorry

Zoxc (Jun 06 2019 at 12:12, on Zulip):

You have to opt-in to incremental for rustbuild. Not sure about debug builds, but you have to opt-in to those too

pnkfelix (Jun 06 2019 at 12:15, on Zulip):

@Zoxc so you don't see anything in the config.toml at #61200 that would imply incremental would be turned on, right?

pnkfelix (Jun 06 2019 at 12:16, on Zulip):

I suppose I could be conflating two separate things, as well

pnkfelix (Jun 06 2019 at 12:16, on Zulip):

e.g. I've been thinking of some bugs like #60228 as being incremental compilation related, but they may just be "we mishandle scenarios with old build artifacts lying around" ...

Zoxc (Jun 06 2019 at 12:18, on Zulip):

rustbuild definitely has bugs =P

Zoxc (Jun 06 2019 at 12:19, on Zulip):

I have a branch with another build system I should finish =P

pnkfelix (Jun 06 2019 at 12:20, on Zulip):

uh maybe do an RFC first ... ?

pnkfelix (Jun 06 2019 at 12:20, on Zulip):

at least, I can imagine push back against changing the bootstrap's build systems again

pnkfelix (Jun 06 2019 at 12:20, on Zulip):

without some more formal design/requirements work done up front

Zoxc (Jun 06 2019 at 12:21, on Zulip):

I'm happy with just correct builds without manual cleaning =P

Zoxc (Jun 06 2019 at 12:30, on Zulip):

I wanted to make a PoC which statically links rustc before any RFC

pnkfelix (Jun 06 2019 at 13:18, on Zulip):

okay, back at keyboard

pnkfelix (Jun 06 2019 at 13:19, on Zulip):

next: " in comment cause unexpected rustc panic" #61226

pnkfelix (Jun 06 2019 at 13:20, on Zulip):

there's been some investigation, reflected in the comments

pnkfelix (Jun 06 2019 at 13:21, on Zulip):

I'd say this is P-medium. The ICE itself spits out the text, including the character causing the ICE, so it seems easy enough for a user to work around.

pnkfelix (Jun 06 2019 at 13:24, on Zulip):

next: "Creating a recursive type with infinite size leads to internal compiler error" #61323

pnkfelix (Jun 06 2019 at 13:25, on Zulip):

looking at this (and #57373, which seems a likely duplicate), I am inclined to classify as P-high.

pnkfelix (Jun 06 2019 at 13:26, on Zulip):

the only reason I would lower to P-medium would be that, AFAICT, it is only signalled by code that would cause a compilation error anyway. But the diagnostic we are issuing here seems especially bad.

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

(a separate question is whether the fact that it is apparently only triggered by certain incremental compilation should be a potential justification for downgrading priority. But I personally don't subscribe to that notion; if we can reproduce it, then we should try our best to fix it, because incremental compilation bugs are really frustrating to deal with as a user.)

pnkfelix (Jun 06 2019 at 13:29, on Zulip):

next: "ICE when combining unsized locals and async" #61335

pnkfelix (Jun 06 2019 at 13:30, on Zulip):

this depends on an unstable feature. Marking P-medium.

pnkfelix (Jun 06 2019 at 13:31, on Zulip):

next: "error: internal compiler error: inference variables in nalgebra::base::matrix::Matrix<f32, nalgebra::base::dimension::U3, nalgebra::base::dimension::U1, nalgebra::base::array_storage::ArrayStorage<_, _, _>>" #61402

pnkfelix (Jun 06 2019 at 13:43, on Zulip):

I tried to reproduce locally by trying to transcribe a pidgen Vector3 from nalgebra, but I couldn't recreate the ICE

pnkfelix (Jun 06 2019 at 13:44, on Zulip):

don't have more time to spend on it now (probably spent too much time already); triaging as P-high and assigning to self for further investigation.

pnkfelix (Jun 06 2019 at 13:45, on Zulip):

next; "Use const generics for array impls" #61415

pnkfelix (Jun 06 2019 at 13:46, on Zulip):

I think this was nominated for discussion at the T-lang and/or T-libs level, not for T-compiler.

pnkfelix (Jun 06 2019 at 13:49, on Zulip):

I'm not even sure it should be tagged T-compiler (and I left a comment saying so), so I'll leave it out of our triage.

pnkfelix (Jun 06 2019 at 13:49, on Zulip):

next: "rls no longer builds after rust-lang/rust#61276" #61461

pnkfelix (Jun 06 2019 at 13:51, on Zulip):

triage: P-medium

pnkfelix (Jun 06 2019 at 13:51, on Zulip):

next: "ICE: index out of bounds" #61466

pnkfelix (Jun 06 2019 at 13:53, on Zulip):

this is hypothesized to be an incremental compilation bug.

pnkfelix (Jun 06 2019 at 13:53, on Zulip):

(I think this is all leading to a crisis where we need to figure out some way to expose these incr-comp bugs in a reproducible fashion. Maybe some kind of fuzzing strategy could be employed here?)

pnkfelix (Jun 06 2019 at 13:54, on Zulip):

maybe I should propose that latter idea as a streering meeting topic idea

pnkfelix (Jun 06 2019 at 13:54, on Zulip):

next: "1.30 -> 1.31 dylib late-binding regression with less recent Linux distro toolchains." #61539

eddyb (Jun 06 2019 at 13:54, on Zulip):

hi

pnkfelix (Jun 06 2019 at 13:54, on Zulip):

@eddyb is this just on NixOS ?

eddyb (Jun 06 2019 at 13:54, on Zulip):

I still haven't bisected the ld patch that (presumably) fixes this

eddyb (Jun 06 2019 at 13:55, on Zulip):

@pnkfelix no, that's just what I can use multiple versions of (since I can get the packages from those versions and run them on my newer system)

eddyb (Jun 06 2019 at 13:55, on Zulip):

any distro from before ~mid-2018 is pretty much guaranteed to hit this bug AFAIK

pnkfelix (Jun 06 2019 at 13:55, on Zulip):

interesting

eddyb (Jun 06 2019 at 13:55, on Zulip):

I just don't know what change fixed it

pnkfelix (Jun 06 2019 at 13:56, on Zulip):

oh jeez, since it is spawned off of #60593, I guess this is the sort of thing that can secretly infect any procedural macro?

eddyb (Jun 06 2019 at 13:57, on Zulip):

tbh even if NixOS makes it easy to test patched versions of packages and I have a build server, it's still annoying to bisect, maybe I should hook it up to git bisect somehow

eddyb (Jun 06 2019 at 13:57, on Zulip):

@pnkfelix only if you use the unstable proc_macro::quote! first :P

eddyb (Jun 06 2019 at 13:57, on Zulip):

I haven't bothered to repro

pnkfelix (Jun 06 2019 at 13:57, on Zulip):

hmm

pnkfelix (Jun 06 2019 at 13:58, on Zulip):

... so, then, what priority should we assign this? I can leave it nominated if you want to discuss with group at large, regardless of priority

eddyb (Jun 06 2019 at 13:58, on Zulip):

the binary needs to call into proc_macro then load a proc macro dylib

eddyb (Jun 06 2019 at 13:58, on Zulip):

that binary is rustc in our case

pnkfelix (Jun 06 2019 at 13:58, on Zulip):

but do you have any idea of potential range of impact? Seems potentially large, depending on how many people are creating dylibs?

eddyb (Jun 06 2019 at 13:59, on Zulip):

yeah I want to discuss how much we care about this (it only affects dynamic loading, not linking) and if anyone wants to help track down what fixed it in the GNU toolchain

pnkfelix (Jun 06 2019 at 13:59, on Zulip):

okay, lets leave it unprioritized for now then.

eddyb (Jun 06 2019 at 13:59, on Zulip):

you could look at reverse dependencies of crates that wrap dlopen, I guess

eddyb (Jun 06 2019 at 13:59, on Zulip):

@nagisa might know more about that

pnkfelix (Jun 06 2019 at 13:59, on Zulip):

we'll talk about it at meeting. I want to get through rest of list ... oh crum, my time is almost up

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

next: "error updating smallvec in rustc" #61549

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

its hard to tell how bad this is. I'm going to triage as P-high and assign to self.

Last update: Nov 16 2019 at 02:20UTC