Question about -Wconf discrepancy between scala 2 and scala 3

[coreywoodfield]

Both scala-2.13.10/bin/scalac -Wconf:help and scala3-3.3.0/bin/scalac -Wconf:help include the text

User-defined configurations are added to the left. The leftmost rule matching
a warning message defines the action.

I'm not sure exactly how "User-defined configurations" is defined, but at least part of the behavior seems to be reversed moving from scala 2 to scala 3.

Illustration of what I mean:
Test.scala

object Main {
  def main(args: Array[String]): Unit = Deprecated.deprecated
}

object Deprecated {
  @deprecated("", "")
  def deprecated = ()
}

Note that Main.main calls Deprecated.deprecated, which is deprecated. Now we try to compile this with various -Wconf settings.
scala 2:

$ scala-2.13.10/bin/scalac -Wconf:cat=deprecation:e -Wconf:cat=deprecation:s Test.scala

$ scala-2.13.10/bin/scalac -Wconf:cat=deprecation:s -Wconf:cat=deprecation:e Test.scala
Test.scala:3: error: method deprecated in object Deprecated is deprecated:
  def main(args: Array[String]): Unit = Deprecated.deprecated
                                                   ^
1 error

scala 3:

$ scala3-3.3.0/bin/scalac -Wconf:cat=deprecation:e -Wconf:cat=deprecation:s Test.scala
-- Error: Test.scala:3:51 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3 |  def main(args: Array[String]): Unit = Deprecated.deprecated
  |                                        ^^^^^^^^^^^^^^^^^^^^^
  |                                        method deprecated in object Deprecated is deprecated since : 
1 error found

$ scala3-3.3.0/bin/scalac -Wconf:cat=deprecation:s -Wconf:cat=deprecation:e Test.scala

In scala 2, with -Wconf:cat=deprecation:e -Wconf:cat=deprecation:s, the compilation succeeds. In scala 3, the same settings fail, but if you reorder them, it succeeds. So it seems like in scala 2, "User-defined configurations are added to the left" meant something like userDefinedConfigurations.foldLeft(existingConfigurations)((list, config) => config :: list), i.e. going left to right, each user-defined configuration is added to the left of all configurations, so the rightmost configuration on the command line will be the leftmost configuration when the configurations are being used/processed. In scala 3, it seems to be userDefinedConfigurations ::: existingConfigurations, i.e. all the user-defined configurations are added to the left of all configurations, retaining their order.

Was this change intentional? Was it documented anywhere? Or was it an oversight or mistake? I greatly preferred the behavior in scala 2. I could configure global scalac options to be used everywhere, and then in individual places, add additional -Wconf settings to the end of the scalac options that would override the global ones. In scala 3, overriding the global settings becomes a lot more complicated and less convenient, as they have to be added to the beginning of the list in reverse order.

I would like to file a bug, as the documentation for the behavior remains exactly the same, but the actual behavior has been reversed. Both behaviors could be interpreted as implementing the documentation though, so I thought I'd start a discussion first and see if this change was intentional

[som-snytt]

I'm pretty sure your intuition is correct, that both versions should work approximately the same way.

The Scala 2 option specifies that it accumulates in prepend mode, with the semantics that "last config wins" because it winds up first in priority.

Scala 3 options are different, so I could not guess without inspection. Probably you're right that they forgot to reverse.

"User config" is as opposed to default config, I assume. So it's handy that "last wins".

To veer off-topic, not all options are "last wins." For example, linting respects if a lint is explicitly turned off, even if some other settings want to turn it on.

In this case, arguably, if I "silence" or "suppress" a category, I don't want some other config making it an error. (Maybe it's turned on by sbt-tpolecat, or maybe I don't understand my complicated build.sbt and where anything is set.)

[coreywoodfield]

To veer off-topic, not all options are "last wins." For example, linting respects if a lint is explicitly turned off, even if some other settings want to turn it on.

In this case, arguably, if I "silence" or "suppress" a category, I don't want some other config making it an error. (Maybe it's turned on by sbt-tpolecat, or maybe I don't understand my complicated build.sbt and where anything is set.)

That's fine by me. My use case is that I want to basically do -Wconf:any:error at the global level (i.e. as the first user-provided Wconf argument) and then be able to selectively silence warnings in specific targets (e.g. if there's an exception or if fixing a particular warning in that target is a work in progress). There aren't any cases where I want to silence something globally and then un-silence it in particular targets.

I'm pretty sure your intuition is correct, that both versions should work approximately the same way.

Thanks for that validation, I'll go ahead and file a bug