Stream: t-compiler/wg-prioritization/alerts

Topic: I-prioritize #73722 Invalid equality check result for usize…


triagebot (Sep 17 2020 at 06:26, on Zulip):

@WG-prioritization/alerts issue #73722 has been requested for prioritization.

Procedure

Stu (Sep 17 2020 at 06:31, on Zulip):

I have a question for this situation. Since they already know the solution / bug. Does this influence the priority level somehow?

LeSeulArtichaut (Sep 17 2020 at 07:01, on Zulip):

@Stu Usually we don’t think as much because the priority isn’t as important

lcnr (Sep 17 2020 at 07:03, on Zulip):

looks like P-medium to me, there is unsoundness here but it seems fairly hard to trigger by accident

triagebot (Sep 17 2020 at 10:09, on Zulip):

Issue #73722's prioritization request has been removed.

Santiago Pastorino (Sep 17 2020 at 12:15, on Zulip):

well for an I-unsound bug I'd have said at least P-high if not P-critical

Santiago Pastorino (Sep 17 2020 at 12:15, on Zulip):

maybe @RalfJ can comment a bit about it

Santiago Pastorino (Sep 17 2020 at 12:16, on Zulip):

LeSeulArtichaut said:

Stu Usually we don’t think as much because the priority isn’t as important

I think it is important

Santiago Pastorino (Sep 17 2020 at 12:16, on Zulip):

so, it's not really important if the issue ends with P-low or P-medium but if the issue is P-critical is important to label and so we can act fast

Santiago Pastorino (Sep 17 2020 at 12:17, on Zulip):

in my opinion a PR open or like in this case a fix in LLVM that is not included in LLVM is not enough to raise awareness of the urgence

Santiago Pastorino (Sep 17 2020 at 12:17, on Zulip):

in this case this LLVM fix should be backported

Santiago Pastorino (Sep 17 2020 at 12:17, on Zulip):

if there's a PR up not merged, labelling the issue as P-critical should show that reviews are more urgent

Santiago Pastorino (Sep 17 2020 at 12:18, on Zulip):

we can have a bunch of back and forth in the PR about decisions on how to solve the problem

Santiago Pastorino (Sep 17 2020 at 12:18, on Zulip):

and this may delay things and the issue could hit the release or something

Santiago Pastorino (Sep 17 2020 at 12:19, on Zulip):

also we try to merge PRs for P-critical as fast as possible so fixes can be tested earlier

Santiago Pastorino (Sep 17 2020 at 12:19, on Zulip):

P-highs are more debatable but I also think those should be handled more or less equivalently to P-criticals

DPC (Sep 17 2020 at 12:20, on Zulip):

this has been an old issue as well and relates to: https://github.com/rust-lang/rust/issues/54685

DPC (Sep 17 2020 at 12:26, on Zulip):

(wrong channel :stuck_out_tongue: )

RalfJ (Sep 18 2020 at 10:42, on Zulip):

DPC said:

this has been an old issue as well and relates to: https://github.com/rust-lang/rust/issues/54685

it relates but unlike that one, this here is a miscompilation

RalfJ (Sep 18 2020 at 10:42, on Zulip):

it's okay if functions compare differently when the same program is compiled multiple times

RalfJ (Sep 18 2020 at 10:43, on Zulip):

it is a big issue when they compare differently when doing the same comparison multiple times during one execution

RalfJ (Sep 18 2020 at 10:44, on Zulip):

Santiago Pastorino said:

maybe RalfJ can comment a bit about it

not sure what to comment on? I have interacted very little with priorization so I don't really know what consequences any given priority would have

Santiago Pastorino (Sep 18 2020 at 13:25, on Zulip):

RalfJ said:

Santiago Pastorino said:

maybe RalfJ can comment a bit about it

not sure what to comment on? I have interacted very little with priorization so I don't really know what consequences any given priority would have

what you've said is already enough :), if you also want to give an opinion about the priority that's fine too

Santiago Pastorino (Sep 18 2020 at 13:26, on Zulip):

or more in general about how critical you think this issue is, I saw you commented on the LLVM issue that we consider this a critical bug, if we were doing so we would better tag it like that or with a bit higher priority

Santiago Pastorino (Sep 18 2020 at 13:26, on Zulip):

right now it's tagged as P-medium

Santiago Pastorino (Sep 18 2020 at 13:27, on Zulip):

I'd agree to bump the priority a bit more to be honest

Santiago Pastorino (Sep 18 2020 at 13:27, on Zulip):

Santiago Pastorino said:

well for an I-unsound bug I'd have said at least P-high if not P-critical

:point_up:

RalfJ (Sep 18 2020 at 17:32, on Zulip):

Santiago Pastorino said:

or more in general about how critical you think this issue is, I saw you commented on the LLVM issue that we consider this a critical bug, if we were doing so we would better tag it like that or with a bit higher priority

I was mostly saying this to convey how serious Rust takes soundness issues, given that LLVM devs mostly come from a C/C++ background where there is no soundness to begin with. I did not mean this to imply "P-critical".

RalfJ (Sep 18 2020 at 17:34, on Zulip):

if you want my personal opinion then all I-unsound are P-critical, but I also know that that's not realistic. ;)
this one here is subtle, it seems unlikely to actually happen in normal code, but it is also hard to detect when it happens. so I could see people doing the judgment call either way.

RalfJ (Sep 18 2020 at 17:35, on Zulip):

this applies to most miscompilation issues so maybe there is some precedent here already

Santiago Pastorino (Sep 18 2020 at 17:57, on Zulip):

@RalfJ yeah I have the same feeling you have :+1:

Santiago Pastorino (Sep 18 2020 at 17:57, on Zulip):

maybe I'd be happier bumping it up to P-high at least, P-medium seems too low for this kind of issues :)

Last update: Apr 15 2021 at 02:45UTC