Turn given loop prevention on for -source future

[odersky]

Drop the experimental language import. I believe everybody agrees that this is a desirable improvement, and type inference and implicit search have traditionally been in the realm of the compiler implementers.

Experimental language imports have to live forever (albeit as deprecated once the feature is accepted as standard). So they are rather heavyweight and it is unergonomic to require them for smallish improvements to type inference.

The new road map is as follows:

• In 3.4: warning if behavior would change in the future.
• In 3.5: error if behavior would change in the future
• In 3.future (at the earliest 3.6): new behavior.

[dwijnand]

Do we want to make sure that fatal warning users have a way to upgrade? I would hope that it's possible to Wconf the warning away, but I'm not 100% confident. Should we double-check with a test?

LGTM for the rest

[odersky]

Suppressing the warning would only be a temporary fix since in 3.5 we emit an error in the same situation. The warning does give hints how to work around the problem, and the sooner people apply them the better. So I think we are as good as we could be.

[sjrd]

Of course suppressing a warning is a temporary fix. But temporary fixes are good!

The typical scenario that users face is: they upgrade, they get plenty of new warnings-that-are-errors. These warnings come not only from this PR, but from all the other stuff that is newly a warning. What do they do?

• If no Wconf escape:
  • Try to address everything at the same time -> may need a giant commit; hard to know the cause of breakage if they face any.
  • Disable fatal-warnings -> can do multiple commits, but it's hard to tell whether they've addressed all the issues of one kind, or whether fixes introduce new unexpected warnings in the meantime; cannot do multiple PRs because they understandably won't accept non-fatal-warnings in main
• If Wconf escape is available:
  • Upgrade and Wconf-away all the new warnings. Commit, PR and merge. Then, progressively, with individual PRs and reviews, fix all the occurrences of each new kind of warning.

There is substantial value to users to having the ability to temporarily, selectively ignore new warnings. Even if it works only within a single minor release.

[odersky]

@sjrd OK. Can one of you suggest a WConf test or fix? I have not experience with that area.

[som-snytt]

In Scala 2.13.13, these migratory behaviors are controlled by -Xsource:3 where the stages are warning, soft error, and then new behavior with no message about it.

-Xsource:3migration gives you a warning, -Xsource:3 issues the same message but with -Wconf that bumps it to error, and -Xsource:3cross introduces the new behavior. So the difference is between a "hard error" and a "warning configured as a soft error" so it can be detuned by -Wconf. Scala 2 doesn't have actual future versions because of the decision about 2.14, but if you want the new behavior, you don't get a warning about it (because you're living in the future). Short of that, you get warning or warning boosted to error.

One may joke that the alternative is to change all warnings to language imports.

[odersky]

I added a test, which shows that @nowarn works.

I am sure -Wconf would work also, since it's very general.

[dwijnand]

Thank you!

[WojciechMazur]

Question:
I wonder what should be behaviour under usage of -source:future-migration, should it fail similarly as under -source:future or give a warning? Right now it is failing
I've just found a project in OpenCB failing due to this change, which is expected now, but lack of context was confusing. Maybe under future-migration we should still produce a warning?