Don't error (only warn) on symbol literals under -Xsource:3

[smarter]

Scala 3 still supports symbol literals even if they require a language
import now (cf scala/scala3#11588), so don't
emit an error if we find one under -Xsource:3 as that could
unnecessarily impede cross-compilation as discovered in
scala/scala-dev#769.

[SethTisue]

(I won't have time to think about this until next week, but in the meantime I ask it not be merged because I want to think and respond.)

[som-snytt]

Probably it's useful to backport the language import under -Xsource:3.

That sounds baroque, but this conundrum about symbol lits may be where the language import shines.

[SethTisue]

Probably it's useful to backport the language import under -Xsource:3.

That does sound ideal.

[smarter]

Yeah, but forward bincompat means that likely can't be done without significant custom compiler magic.

[SethTisue]

The tension here is that -Xsource:3 serves two purposes: 1) it facilitates cross-building, 2) it aids migration by telling you when you're doing something that's going to change or go away.

[SethTisue]

More thinking out loud: maybe we should be considering using -Xmigration here?

[smarter]

IMO, deprecation warnings already serve purpose 2 well enough.

[som-snytt]

I'm surprised to see the language vals are not marked compileTimeOnly.

The compiler writer's go-to is always "significant custom compiler magic". :) oh, I just used "go-to" in a non-computer sense.

Since anyone using -Xsource:3 doesn't need beginner's help, it would be nice if we let them add their language import for transition purposes; but maybe they will just use conditional compilation.

[dwijnand]

I'm totally down for this. -Xsource:3 is "Scala 3 lite", not Scala 3 proper, so we can leave Scala 3 to enforce as and when (and/or under what flag) things are hard failures.

[SethTisue]

deprecation warnings already serve purpose 2 well enough

okay, I'm convinced

not supporting the language import makes me sad, though. I guess that forces cross-builders to add the language import via scalacOptions rather than via import in the code...? is that okay?

[smarter]

I guess that forces cross-builders to add the language import via scalacOptions rather than via import in the code...?

Yes that's what I had in mind. And maybe the language import can be added in scala 2 later in some fashion.