`-Xsource:...` should be documented as not for use in production/publishing

[SethTisue]

I have seen it come up many many times on Gitter and elsewhere, that people thought -Xfuture (which doesn't exist anymore) or -Xsource:... was something it was just fine to sprinkle on their scalacOptions without thinking too much about it

for example, -Xfuture is included in https://tpolecat.github.io/2017/04/25/scalac-flags.html , which is widely referred to (/cc @tpolecat)

over at https://docs.scala-lang.org/overviews/compiler-options/index.html the entry for -Xsource just says:

Treat compiler input as Scala source for the specified version, see #8126

I suggest that -Xsource:... be documented as something that should only be used for experimenting and to get migration information, you shouldn't enable it when building something you're going to deploy or publish

why? because these flags enable poorly-tested combinations of possibly half-baked stuff, the version of the compiler you get when you enable this hasn't been QA'ed anywhere near as heavily as the default one has

and since we have published the reference to #8126, I would also suggest that the description on that ticket be improved so that anyone consulting it will see the same warning text

[eed3si9n]

I actually think more people would be happier if they used -Xlint, -deprecation, and -Xfatal-warnings (on whatever the main Scala version you work with the most), similar to what Rob suggests, and I'd include -Xsource:2.14.

If testedness of -Xsource:2.14 is somehow the problem (do you have specific behavior in mind like #11657 and #11644?), then we should fix that instead.

[SethTisue]

I don't have specific behavior in mind. It's just we don't run the Scala test suite with -Xsource:2.14 enabled, and we don't run the community build that way either, and (re "we should fix that"), doing that seems like an impractical expansion in scope to me.

[eed3si9n]

To expand on my "then we should fix that instead" position, I think we should be fairly conservative on what we include into -Xsource:2.14. For example, in scala/scala#6325 I deprecated the procedure syntax and dropped it completely in -Xsource:2.14. If you can bring your code base up to that, there's no reason not to recommend that behavior for use in production/publishing. This is an example that also highlights the integration testing to be difficult because it would require large-but-clean code base with zero procedure syntax.