I will be doing pre-triage in this channel
first up: "ICE on generic impl trait convergence" #58344
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
but overall I would categorize this as Yet Another Impl Trait Bug
and it doesn't strike me as something to treat with higher priority than any of the 21 impl trait ICEs
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?)
next: "ICE when trying to match on non-PartialEq slice." #61188
@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.
@Esteban Küber linked the bug to #53708, which has changed its behavior since it was filed
that is "ICE: const reference to ADT in match pattern" #53708
okay I investigated more.
Okay so lets triage both of these bugs
#53708 strikes me as P-medium
#61188 seems like something that might be interesting to look into, but I don't know if I'd call resolving it high priority...
I would like to know why we don't catch the error here earlier
so I'm going to triage this as P-high for now.
next: "'rustc' panicked at 'internal error: entered unreachable code', src/libsyntax/ast.rs:668:6 while bootstrapping" #61200
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
I'm going to try to check that
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.
@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?
in any case it seems like it might fall into a similar bucket as #60228
Can you paste the full link? Cannot seem to click it cause zulip has ui bugs
Yes so the release team nominates all ices
Except for cases we know are buggy incomplete features (const generics)
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
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"
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
However, there has been evidence that this is not the correct interpretation to apply to rustbuild
No I don't sorry
You have to opt-in to incremental for rustbuild. Not sure about debug builds, but you have to opt-in to those too
@Zoxc so you don't see anything in the config.toml at #61200 that would imply incremental would be turned on, right?
I suppose I could be conflating two separate things, as well
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" ...
rustbuild definitely has bugs =P
I have a branch with another build system I should finish =P
uh maybe do an RFC first ... ?
at least, I can imagine push back against changing the bootstrap's build systems again
without some more formal design/requirements work done up front
I'm happy with just correct builds without manual cleaning =P
I wanted to make a PoC which statically links rustc before any RFC
okay, back at keyboard
… in comment cause unexpected rustc panic" #61226
there's been some investigation, reflected in the comments
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.
next: "Creating a recursive type with infinite size leads to internal compiler error" #61323
looking at this (and #57373, which seems a likely duplicate), I am inclined to classify as P-high.
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.
(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.)
next: "ICE when combining unsized locals and async" #61335
this depends on an unstable feature. Marking P-medium.
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
I tried to reproduce locally by trying to transcribe a pidgen Vector3 from nalgebra, but I couldn't recreate the ICE
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.
next; "Use const generics for array impls" #61415
I think this was nominated for discussion at the T-lang and/or T-libs level, not for T-compiler.
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.
next: "ICE: index out of bounds" #61466
this is hypothesized to be an incremental compilation bug.
(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?)
maybe I should propose that latter idea as a streering meeting topic idea
next: "1.30 -> 1.31 dylib late-binding regression with less recent Linux distro toolchains." #61539
@eddyb is this just on NixOS ?
I still haven't bisected the
ld patch that (presumably) fixes this
@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)
any distro from before ~mid-2018 is pretty much guaranteed to hit this bug AFAIK
I just don't know what change fixed it
oh jeez, since it is spawned off of #60593, I guess this is the sort of thing that can secretly infect any procedural macro?
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
@pnkfelix only if you use the unstable
proc_macro::quote! first :P
I haven't bothered to repro
... 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
the binary needs to call into
proc_macro then load a proc macro dylib
that binary is rustc in our case
but do you have any idea of potential range of impact? Seems potentially large, depending on how many people are creating dylibs?
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
okay, lets leave it unprioritized for now then.
you could look at reverse dependencies of crates that wrap
dlopen, I guess
@nagisa might know more about that
we'll talk about it at meeting. I want to get through rest of list ... oh crum, my time is almost up
next: "error updating smallvec in rustc" #61549
its hard to tell how bad this is. I'm going to triage as P-high and assign to self.