Enable stricter pattern binding warnings by default

[griggt]

The first step of a phased-in approach to tighten the rules on pattern bindings, as described at https://docs.scala-lang.org/scala3/reference/changed-features/pattern-bindings.html

In 3.2: (this PR), emit warnings by default for refutable pattern bindings. Keep the existing desugaring of for generators.
In 3.3 (or later), the above warnings become errors, and case is required on for generators to get filtering behavior.

Rewrites are available (under -source 3.2-migration -rewrite) to ease migration.

Closes #13832
Closes #14615

[bishabosha]

looking at the old code future-migration would use the new behaviour, so I don't think we need the "not migrating" check - besides, the current change would return false for future-migration, so I suggest we remove the condition:

Suggested change

	else if sourceVersion.isAtLeast(`3.2`) && !sourceVersion.isMigrating then GenCheckMode.Check
	else if sourceVersion.isAtLeast(`3.2`) then GenCheckMode.Check

[smarter]

If I understand this change correctly, it means that (when -source is not used) a piece of code that previously compiled without warnings can now fail with an error. To ease migration, could we instead emit a warning by default in 3.2 and only turn it into an error in 3.3? I imagine that the alternative is to recommend using -source but this seems much more cumbersome for users (they have to be aware of the flag in the first place, and need to remember to add/remove it when appropriate). This would also potentially give time for the warning to be backported to Scala 2 if someone felt like porting it to give a heads-up to Scala 2 projects that aren't cross-compiled yet.

[griggt]

This has been rebased and review comments addressed. I'm happy to rebase again just prior to merge in case another PR happens to introduce a refutable pattern binding into the codebase.

[bishabosha]

just a couple of points

• automatic patches should only run specifically for the migration versions that we have declared the "grace period" for updating code
• Feature.warnOnMigration should no longer consider 3.2 as equivalent to 3.0

[griggt]

automatic patches should only run specifically for the migration versions that we have declared the "grace period" for updating code

Is this just a policy decision or are there technical reasons behind it? I had left the migration patches open ended as I wanted to avoid -future-migration having different behavior between now and, well, the future, on say a codebase moving from 3.0/3.1.

[bishabosha]

automatic patches should only run specifically for the migration versions that we have declared the "grace period" for updating code

Is this just a policy decision or are there technical reasons behind it? I had left the migration patches open ended as I wanted to avoid -future-migration having different behavior between now and, well, the future, on say a codebase moving from 3.0/3.1.

this is an interesting point, I was saying this because for example patches for 3.0 are only applied for 3.0-migration, i.e. not for future-migration - i.e. once you have gone beyond that version it is no longer valid source so there is nothing to patch. This is also a minor release so source compatibility could be broken. @smarter what do you think?

[smarter]

Honestly I'm not sure, but whatever we do should be documented in https://dotty.epfl.ch/docs/reference/language-versions/source-compatibility.html

[bishabosha]

I had a discussion with @sjrd , I think it is safe to say that future is not meant to adhere to the same compatibility guarantees of a usual language version.

[bishabosha]

need someone else to review my last commit

[sjrd]

The last two commits LGTM.

[bishabosha]

community build c is failing due to #15205