Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
SethTisue opened this issue Aug 5, 2019 · 3 comments

Comments

@SethTisue
Copy link
Member

commented Aug 5, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 5, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Aug 5, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 5, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.