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

Procedure

• Priority?
• Regression?
• Notify people/groups?
• Needs I-nominated?

I don't get it. Perhaps a P-medium because it involves a 3rd party lib that is being updated these days (prompted by this issue)?

(or perhaps is just on the 3rd party lib)

I just posted this:

@apiraino and I both feel unclear about this: Is this a Rust regression or a regression in a library that was then picked up by Crater?

I think the answer is that crater is picking a library for the fourier tranform (for its test runs) that didnt release the last updates, so the maintainer is now pushing an update

iiuc that should solve the issue

This is a regression in the Rust compiler.

(From simulacrum)

IIUC the fourier thing was not a rustc bug, but the tiger one is.

I see. I was confused, I admit this stuff is above my head :smiley:

@Camelid @apiraino it is unclear to me how bad this is

it doesn't seem too bad to deserve a P-critical but maybe it worth a P-high

I don't have clear either what is broken but ... ok for a P-high out of caution.

or maybe wait for a clearer mcve? can the team reason about this issue without a repro?

in general my reasoning is ... I try to add a priority to issues with the information we have and then maybe adjust later

mainly because we shouldn't miss something that looks like a P-critical or P-high because we still don't have a lot of information

I'd rather tag as high priority and then lower to just raise awareness

but unsure how others feels about this

cc @Joshua Nelson

I think we should find if it affects crates other than fourier

the conversation we were just having is also about this I think :point_up:

@Santiago Pastorino no, https://github.com/rust-lang/rust/issues/79904 is about trait bounds, not macros

Joshua Nelson said:

Santiago Pastorino no, https://github.com/rust-lang/rust/issues/79904 is about trait bounds, not macros

unsure what you meant :)

Joshua Nelson said:

I think we should find if it affects crates other than fourier

looks like yes: https://github.com/rust-lang/rust/issues/79908#issuecomment-742733375

I was trying to say that in previous issues we were kind of discussing the same thing, like should we prioritize without a lot of info or should we wait

Santiago Pastorino said:

the conversation we were just having is also about this I think :point_up:

I'm confused what this means then :sweat_smile: which conversation?

ah ok

in another thread about another issue

that you were saying ... let's wait to prioritize and I was kind of preemptively trying to prioritize

I think either P-high or wait for an MCVE

but the fact that this affects multiple crates is slightly concerning

right, in general I guess I prefer to prioritize and then change

because it won't hurt anybody prioritizing this

and maybe somebody sees the issue and say, this is P-high then I'm going to pay closer attention

my guess is that by doing so ... we may get faster responses, results, fixes

we can even jump and try to fix them :)

for this one in particular then let's go with P-high

but I think this discussion is interesting

and I'd like to hear more thoughts :)

Issue #79908's prioritization request has been removed.

@Camelid nicely reduced to a small mcve, cool!

Santiago Pastorino said:

my guess is that by doing so ... we may get faster responses, results, fixes

my reasoning (perhaps incorrect) is that an incomplete issue (without a clear analysis), even with a P-high label, is less useful for the team. it's like we're just signaling "hey look at this but we don't have a lot to say about it"

yes

let's create a topic about this conversation because it's basically the same thing we were just talking with @Joshua Nelson

#t-compiler/wg-prioritization > to prioritize or not to prioritize, that is the question

Joshua Nelson said:

I think we should find if it affects crates other than fourier

@Joshua Nelson IIUC the fourier thing is totally unrelated.