Stream: t-compiler/wg-prioritization/alerts

Topic: I-prioritize #77586 `use dep1::foo as dep1` is considered a…


triagebot (Oct 06 2020 at 00:36, on Zulip):

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

Procedure

Joshua Nelson (Oct 06 2020 at 00:38, on Zulip):

So, this is a weird case - it looks like expected breakage, but I think the code it broke wasn't ever intended to compile?

lzutao (Oct 06 2020 at 01:08, on Zulip):

https://github.com/rust-lang/rust/issues/77586#issuecomment-703812974

Strictly speaking, #77421 is not a bug fix, but rather an implementation of a slightly more conservative language rule giving us some more freedom in the future.
If it causes a noticeable amount of regressions in practice, then we can return to the 1.44-1.46 rules and declare #74556 as not-an-issue.

Joshua Nelson (Oct 06 2020 at 01:08, on Zulip):

well right but I don't think that's something wg-prioritization can decide

Joshua Nelson (Oct 06 2020 at 01:09, on Zulip):

maybe a crater run would be helpful? but I still don't think this belongs here because it's not a bug

lzutao (Oct 06 2020 at 01:14, on Zulip):

because although it is expected breakage, it does break code that already compiled on stable (1.44 - 1.46 frame ).

maybe tag the related bug fix PR as relnotes.
Then wait until we have next stable crater (1.48) result and decide.

in the meantime, P-medium looks sensible to me.

Joshua Nelson (Oct 06 2020 at 01:15, on Zulip):

I don't think it makes sense to prioritize this before deciding whether it should be fixed or not

Joshua Nelson (Oct 06 2020 at 01:15, on Zulip):

and I don't think wg-prioritization should be the one making that decision

lzutao (Oct 06 2020 at 01:16, on Zulip):

so what about pinging t-release member? they care about stability alot so they would want to be informed about this.

lzutao (Oct 06 2020 at 01:18, on Zulip):

also, the fixed issue #74556 is tagged P-high, it turned code successfully compiled -> Compilation error.

lzutao (Oct 07 2020 at 10:15, on Zulip):

@Camelid Why did you tag it with requires-nightly ? It doesn't gate by any features so it will eventually get to stable channel.

apiraino (Oct 07 2020 at 10:24, on Zulip):

if this the case of a recent patch breaking some code in two stable releases (1.44 and 1.46) - and this is an expected side effect?

LeSeulArtichaut (Oct 07 2020 at 12:08, on Zulip):

lzutao said:

Camelid Why did you tag it with requires-nightly ? It isn't gated by any features so it will eventually get to stable channel.

Tagged as regression-from-stable-to-nightly and removed requires-nightly

Camelid (Oct 07 2020 at 15:53, on Zulip):

lzutao said:

Camelid Why did you tag it with requires-nightly ? It isn't gated by any features so it will eventually get to stable channel.

@lzutao For some reason, I didn't tag it with a regression label and requires-nightly is something that says this is currently only on nightly. Is that not how requires-nightly is used?

lzutao (Oct 07 2020 at 15:55, on Zulip):

Yeah, requires-nightly is kind of require specific feature only allowed on nightly, never on stable. The bug we talked about will hit stable.

LeSeulArtichaut (Oct 07 2020 at 16:42, on Zulip):

requires-nightly means it requires a nightly compiler, e.g. #![feature] gates and -Z flags

Camelid (Oct 07 2020 at 16:47, on Zulip):

I see, I guess I thought it meant "requires a nightly (aka, recent) version of the compiler"

DPC (Oct 07 2020 at 17:10, on Zulip):

that too, depending on the context since stuff can break on nightly at any time

apiraino (Oct 07 2020 at 22:12, on Zulip):

I have the feeling that this is issue can be assigned a P-low-ish priority. Reason is this comment from the reporter that states that the regression appeared when migrating the crate to edition=2018 (edition=2015 still compiles) and the fix to make it compile on edition=2018 seems easy to implement

apiraino (Oct 07 2020 at 22:13, on Zulip):

I would also agree on a P-medium (as suggested by lzutao ) if that makes more sense (I dont have anyway enough context to bikeshed)

Joshua Nelson (Oct 08 2020 at 00:19, on Zulip):

I still think this should not be a decision wg-prioritization makes

Joshua Nelson (Oct 08 2020 at 00:19, on Zulip):

either it's expected breakage and we close it as wontfix or it's not

Joshua Nelson (Oct 08 2020 at 00:19, on Zulip):

we shouldn't make that decision

Camelid (Oct 08 2020 at 00:51, on Zulip):

How about we remove I-prioritize (or keep it) and add I-nominate?

Camelid (Oct 08 2020 at 00:51, on Zulip):

Should it be T-lang or T-compiler -- or both?

apiraino (Oct 08 2020 at 07:32, on Zulip):

right, maybe I-nominate is a better good choice. The agenda looks (imo) to still have a bit of room to allocate for a brief discussion. After the meeting we can then update the issue status.

Joshua Nelson said:

maybe a crater run would be helpful?

this also looks interesting, I don't know the craterbot very well, from its documentation I don't understand if can be triggered from the reporter code repository or from the issue itself and by whom (maybe the ICE-breakers group?)

Vadim Petrochenkov (Oct 08 2020 at 09:41, on Zulip):

I think this needs a crater run first of all, the decision can then be made based on it.
Not sure whether it should be a dedicated run or the regular beta run would be enough, the crater queue is not empty now, but isn't too long either.

triagebot (Oct 08 2020 at 15:01, on Zulip):

Issue #77586's prioritization request has been removed.

apiraino (Oct 08 2020 at 15:09, on Zulip):

ok, pnkfelix will mention this issue at the next T-lang meeting

triagebot (Oct 20 2020 at 14:17, on Zulip):

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

Procedure

Mason Stallmo (Oct 20 2020 at 15:50, on Zulip):

I'm on the fence here about if we should add a priority to this at all. It seems like the lang team discussed this already and settled on the fact that it's a bug fix and to let it ride.

I'm not sure that the handful of crater failures would move the needle very far from the decision reached previously. I could be miss-reading this though.

LeSeulArtichaut (Oct 20 2020 at 16:14, on Zulip):

I see nothing we can do about this, this is ultimately a T-lang decision

LeSeulArtichaut (Oct 20 2020 at 16:15, on Zulip):

simulacrum has re-nominated this issue for T-lang to look at the crater data, I think it's fair to say this issue is being taken care of already

LeSeulArtichaut (Oct 20 2020 at 16:15, on Zulip):

As T-lang doesn't use I-prioritize I think we should remove the label

triagebot (Oct 20 2020 at 16:16, on Zulip):

Issue #77586's prioritization request has been removed.

Last update: Apr 16 2021 at 23:00UTC