Stream: t-compiler

Topic: pre-meeting triage 2020-01-16 #54818


pnkfelix (Jan 16 2020 at 02:33, on Zulip):

starting the pre-triage process many hours before the meeting again this week

pnkfelix (Jan 16 2020 at 02:45, on Zulip):

we have 9 nominated unprioritized issues

pnkfelix (Jan 16 2020 at 02:47, on Zulip):

nom unpri 1/9: "Mutex and RwLock are unsound in presence of discriminant elision" #68206

pnkfelix (Jan 16 2020 at 02:48, on Zulip):

this is probably going to end up being a T-lang + T-libs issue. I cannot imagine it being something that we try to resolve in the compiler itself.

pnkfelix (Jan 16 2020 at 02:49, on Zulip):

Though the compiler team can fix the immediate soundness issue by "just" disallowing UnsafeCell<T> to expose the same niche as T.

pnkfelix (Jan 16 2020 at 02:50, on Zulip):

(The only other option I can imagine is to say that it is the duty of library authors to figure out what combination of UnsafeCell :: * -> * and MaybeUninitialized :: * -> * they need for their particular abstract data type...)

pnkfelix (Jan 16 2020 at 02:56, on Zulip):

anyway lets call this P-high, there is at least one clear way to address the soundness issue here; the only question is whether it is the way we want (i.e. whether we can swallow losing the niche optimization for Cell<T>)

pnkfelix (Jan 16 2020 at 02:57, on Zulip):

(gotta pause for family stuff)

pnkfelix (Jan 16 2020 at 03:35, on Zulip):

so yeah, #68206 is P-high but I'm leaving the I-nominated tag.

pnkfelix (Jan 16 2020 at 03:35, on Zulip):

nom unpri 2/9: "SystemV ABI Mismatch on x86 with a repr(C) enum for extern "C"/FFI functions." #68190

pnkfelix (Jan 16 2020 at 03:36, on Zulip):

This is probably T-lang too as well. Adding tag.

pnkfelix (Jan 16 2020 at 03:39, on Zulip):

(though its possible its "just" a compiler bug. Cannot tell yet.)

pnkfelix (Jan 16 2020 at 03:39, on Zulip):

anyway, I'm leaving the nominated tag on this, and explicitly not attempting to triage it

pnkfelix (Jan 16 2020 at 03:43, on Zulip):

(and I put it on the explicit list of nominated issues on the hackmd I just allocated.)

pnkfelix (Jan 16 2020 at 03:43, on Zulip):

nom unpri 3/9: "[spurious] thread 'rustc' panicked at 'slice index starts at 24722962 but ends at 13279232', src/libcore/slice/mod.rs:2680:5" #68132

pnkfelix (Jan 16 2020 at 03:45, on Zulip):

not sure we're going to be able to do much with this bug as written...

pnkfelix (Jan 16 2020 at 03:46, on Zulip):

there is at least a backtrace, but the problem itself is arising with a "custom codegen backend". The failure happens while compiling hashbrown but who knows what overall context is for actual reproduction.

pnkfelix (Jan 16 2020 at 03:49, on Zulip):

wrote a comment. Not really willing to put a priority label down yet.

pnkfelix (Jan 16 2020 at 03:50, on Zulip):

nom unpri 4/9: "rustc panics when compiling code that uses tokio's LocalSet" #68109

pnkfelix (Jan 16 2020 at 03:50, on Zulip):

this is believed to be fixed

pnkfelix (Jan 16 2020 at 03:50, on Zulip):

#68109: P-high, removing nomination label.

pnkfelix (Jan 16 2020 at 03:51, on Zulip):

nom unpri 5/9: "broken MIR (NoSolution) in closure with a parameter whose type is an alias for a reference to an associated type" #68090

pnkfelix (Jan 16 2020 at 03:54, on Zulip):

#68090: P-high, removing nomination label

pnkfelix (Jan 16 2020 at 04:13, on Zulip):

nom unpri 6/9: "miri no longer builds after rust-lang/rust#68078" #68081

pnkfelix (Jan 16 2020 at 04:13, on Zulip):

#68081: P-medium, removing nomination label.

pnkfelix (Jan 16 2020 at 04:14, on Zulip):

nom unpri 7/9: "rls no longer builds after rust-lang/rust#68047" #68068

pnkfelix (Jan 16 2020 at 04:14, on Zulip):

#68068: P-medium, removing nomination label.

pnkfelix (Jan 16 2020 at 04:17, on Zulip):

nom unpri 8/9: "Project fails to link when using dylibs and the -Zshare-generics flag" #67276

pnkfelix (Jan 16 2020 at 04:21, on Zulip):

based on the comment thread, I don't think this is (currently) a T-compiler issue.

pnkfelix (Jan 16 2020 at 04:23, on Zulip):

@centril why did you remove the T-libs tag from the above? I missed the relevant T-lang meeting last week so maybe there is relevant context I'm missing.

centril (Jan 16 2020 at 04:24, on Zulip):

which one?

centril (Jan 16 2020 at 04:25, on Zulip):

@pnkfelix

pnkfelix (Jan 16 2020 at 04:26, on Zulip):

#67276

pnkfelix (Jan 16 2020 at 04:26, on Zulip):

or wait

pnkfelix (Jan 16 2020 at 04:26, on Zulip):

did I jump ahead ...

pnkfelix (Jan 16 2020 at 04:26, on Zulip):

ugh sorry

pnkfelix (Jan 16 2020 at 04:26, on Zulip):

my fault, its too late at night

pnkfelix (Jan 16 2020 at 04:27, on Zulip):

everything from the "based on the comment thread, I don't think this is (currently) a T-compiler issue." and after that was regarding the last nom unpri issue, namely

pnkfelix (Jan 16 2020 at 04:28, on Zulip):

nom unpri 9/8: "PartialEq implementation for RangeInclusive is unsound" #67194

pnkfelix (Jan 16 2020 at 04:28, on Zulip):

so @centril my Q was regarding #67194

centril (Jan 16 2020 at 04:28, on Zulip):

@pnkfelix t-lang decided what to do (see Niko's comment) and now it needs execution

pnkfelix (Jan 16 2020 at 04:29, on Zulip):

but the thing to do was to remove a specialization impl

centril (Jan 16 2020 at 04:29, on Zulip):

right

pnkfelix (Jan 16 2020 at 04:29, on Zulip):

that's a T-libs take task, not a T-compiler one, right?

pnkfelix (Jan 16 2020 at 04:29, on Zulip):

in terms of determining fallout etc?

pnkfelix (Jan 16 2020 at 04:30, on Zulip):

I'm happy to go and try to do it, in terms of making a quick PR and requesting a perf run

centril (Jan 16 2020 at 04:30, on Zulip):

@pnkfelix my take is that "implementation details" are t-compiler and "specification / public API" matters are T-lang & t-libs respectively

pnkfelix (Jan 16 2020 at 04:30, on Zulip):

hmm I don't know, implementation details of the stdlib I always figured was the domain of T-libs, at least if it doesn't involve adding/using compiler intrinstics...

centril (Jan 16 2020 at 04:32, on Zulip):

I suppose it can be both? Anyways; t-compiler feels more active so I thought it would get things done quicker

pnkfelix (Jan 16 2020 at 04:32, on Zulip):

I'm going to put T-libs back on just so they remain in the loop. The nomination can maybe be removed, I guess.

pnkfelix (Jan 16 2020 at 04:32, on Zulip):

and I'll call this P-high

centril (Jan 16 2020 at 04:32, on Zulip):

sgtm

pnkfelix (Jan 16 2020 at 04:32, on Zulip):

as in

pnkfelix (Jan 16 2020 at 04:33, on Zulip):

#67194: P-high, removing nomination label, adding T-libs label.

pnkfelix (Jan 16 2020 at 04:33, on Zulip):

thanks for filling me in

centril (Jan 16 2020 at 04:33, on Zulip):

:slight_smile:

centril (Jan 16 2020 at 04:33, on Zulip):

/me tunes out to watch the last democratic debate

pnkfelix (Jan 16 2020 at 04:38, on Zulip):

(I wonder if we could make a lint to catch the pattern that niko described in their comment)

centril (Jan 16 2020 at 04:39, on Zulip):

(iirc that was suggested in the meeting -- sounds like a good idea potentially)

centril (Jan 16 2020 at 04:58, on Zulip):

pnkfelix: there is at least a backtrace, but the problem itself is arising with a "custom codegen backend". The failure happens while compiling hashbrown but who knows what overall context is for actual reproduction.
pnkfelix: wrote a comment. Not really willing to put a priority label down yet.

I would say P-medium and let bjorn3 figure it out as part of integrating cranelift

centril (Jan 16 2020 at 04:59, on Zulip):

Though the compiler team can fix the immediate soundness issue by "just" disallowing UnsafeCell<T> to expose the same niche as T.

If it isn't a big hassle, I think it would be worthwhile to do this before the language team meeting experimentally for perf to have that data available in the meeting

pnkfelix (Jan 16 2020 at 05:00, on Zulip):

If it isn't a big hassle, I think it would be worthwhile to do this before the language team meeting experimentally for perf to have that data available in the meeting

yeah I'm trying to put together that PR now

pnkfelix (Jan 16 2020 at 05:32, on Zulip):

Now I'm curious if this breaks the guarantees of #[repr(transparent)] on struct UnsafeCell. I'll have to go and review that RFC.

pnkfelix (Jan 16 2020 at 05:36, on Zulip):

ah i'm getting all kinds of deja vu

pnkfelix (Jan 16 2020 at 05:53, on Zulip):

specifically this note from @RalfJ : "repr(transparent) in struct and enum guarantees that all three of them are the same, but on unions it can only guarantee that the first two are the same"

pnkfelix (Jan 16 2020 at 05:54, on Zulip):

Including the desirata that #[repr(transparent)] passes the niche through to the surrounding context may have been premature. Or at least, I don't see the motivation yet.

Charles Lew (Jan 16 2020 at 14:24, on Zulip):

https://github.com/rust-lang/rust/issues/67743 has been blocking Rust Playground nightly version's build for a few (14+) days. Very personally i wish it be nominated a little...

pnkfelix (Jan 16 2020 at 14:25, on Zulip):

well lets add that to the nominated issues

mati865 (Jan 16 2020 at 14:40, on Zulip):

When T-compiler nominated PRs are usually discussed?
https://github.com/rust-lang/rust/pulls?q=is%3Aopen+is%3Apr+label%3AT-compiler+label%3AI-nominated

oli (Jan 16 2020 at 14:48, on Zulip):

when/if we get to them, they are the last thing before check ins

oli (Jan 16 2020 at 14:48, on Zulip):

see https://hackmd.io/ruw4k37lSJ6RDVOFfhdQ7Q?edit

oli (Jan 16 2020 at 14:48, on Zulip):

oh wait, that is issues

mati865 (Jan 16 2020 at 14:50, on Zulip):

that's why I asked :sweat_smile:

oli (Jan 16 2020 at 14:52, on Zulip):

I added them

Last update: Feb 25 2020 at 02:50UTC