@T-compiler/meeting ; the triage meeting will be starting in slightly more than 40 minutes
Pre-triage is here.
@T-compiler/meeting lets begin, shall we? Starting with 5 mins for announcements.
we are still looking to fill the experts map https://github.com/rust-lang/compiler-team/issues/87, with experts, knowledgeable people and directories of the different parts of the compiler, even commenting on the issue if easier would work :)
I will note that there will not be a checkin this week either, but there appears to be progress towards making schedule available.
Okay, so without further ado, issues. I have pre-triaged some
I-nominated issues, but two are remaining
Bug running cargo check #63150
P-high, probably. Is there any guesses as to whom would be the best person to look into this?
Appears to be related to dependency tracking stuff, so perhaps @mw? It has been a while since I’ve last seen them
Okay, marked P-high, without assignee.
Next is [MIR] [ICE] Associated types, impl traits and closures; oh my, an ICE. #63154
Appears to be related to dependency tracking stuff, so perhaps mw? It has been a while since I’ve last seen them
I believe mw is still on leave until some time in August.
For the MIR issue, it seems like a typical insufficient normalization issue.
The fact that
miri check does work suggests that all that’s needed here will be a normalize() call somewhere.
Marked as P-high, wrote a comment. Moving on.
Our list of
P-high issues is longer than we could hope to handle, so I picked only a few that appear to have had something interesting happen.
internal error: entered unreachable code #63164
I wrote a comment there about how it would be great to have a reproducer that did not depend on plugin codegen, but I also suspect that it may not be possible to write such an example.
Not sure what else is there to discuss.
@Esteban Küber also noted a possible area in code where this is likely coming out from.
FWIW using all sorts of procedural macros did lead to all weird error conditions in my experience, but never an ICE.
I-nominated and moves on seeing as there are few opinions on the topic.
libcore fails to compile for thumbv6m-none-eabi #62932 has had nice progress, LLVM bug reported, so skipping this one.
Segfault compiling libc on nightly-armv7-unknown-linux-gnueabihf #62896 related to LLVM upgrade as well, but the root cause has not yet been pinned down.
For this issue the backtraces are incorrect as they are for the SIGUSR1 signal, not sigsegv one.
but people did narrow it down to LLVM.
I suspect that this is gonna be a LLVM assertion
would be good for somebody to get it.
Wrote a comment to that effect.
Undefined symbol _fltused when compiling to x86_64-unknown-uefi #62785 No update since last week, skip.
Recent nightly versions break thumb* targets #62781
Now this is a good issue to discuss our policy on
namely, does adding or removing sections emitted by the compiler constitute a breaking change?
I’m strongly of the opinion that it does not, but it appears that other people think otherwise.
If we do consider that to be an acceptable change, then this issue is technically not a bug.
It may make sense to ask T-lang to have their say on the topic.
Okay, we have no backports to investigate
and I just got a page to go and put out some fires.
So I’ll wrap this meeting early.
Thanks for doing pre-triage and driving @nagisa
Thanks everybody for participating!
@nagisa Did you want to nominate #62781 for the lang team?
nagisa Did you want to nominate #62781 for the lang team?
Maybe. I don’t mind if it is not discussed ASAP as long as y'all ever get to it to make a decision :slight_smile:
@nagisa I'll take that as a "yes, if you have time" :P