Sorry about the conflict -- checksensible needs an update.

• Rebase on top of Improve the tuple adaptation warning message #7683
• List of changes, including anything not aliased, for release notes
• TIghten vertical space by shortening descriptions & redundant info
• More -Y could be -V
• REPL options could be listed only on scala -help
• Update compiler options page
• Update task parser
• Enhance -Werror:value-discard to select warnings to promote to error
• Review this list

this looks fantastic. I would ❤️❤️❤️ to see this make RC1

collecting like flags under -V and -W is 💯

@som-snytt src/compilerOptionsExporter/scala/tools/nsc/ScalaCompilerOptionsExporter.scala needs concomitant changes

and project/ScalaOptionParser.scala

@smarter might like to look this over?

Thanks for the encouragement. I realize I could blow all the good will by suggesting we drop -help in favor of -U for -Usage. Then -U -opt would explain how to enable the optimiszer.

It's usually spelled "optimiser" because it is so parsimonious with its optimal code, that is, a real miser.

I'm all for -Wfoo, as a bonus I'd like to see -Wno-foo to negate a previous -Wfoo (this is what gcc/clang already do, so it's expected behavior for -W flags). I'm not convinced about -V, most of those are still internal debug options that users shouldn't touch, if we want to be able to distinguish them from other -Y options I'd rather use -Ylog- as a prefix.
In any case when a flag is renamed, using the old name should print a warning letting the user know it's been renamed.

I may be too lazy to do -no negation, but I did just alias "-YdisableFlatCpCaching" as "-Yno-flat-classpath-cache". (Scala flags default false, and you can -Yno-flat-classpath-cache:false for explicit negation.)

I also had reservations about -V as a "public" option, even though frankly the distinction between -X and -Y is not terribly coherent. Is it meaningful to deprecate -Xexperimental and -Xfuture when you really just changed the semantics (or voided the semantics)?

As a semi-casual user, I really don't like sifting through the -Ys for all the switches to turn on some debug. Just give me the debug! So I came down in favor of -V even if the deprecation policy is totally meaningless, because of course it is.

(Edit: "semi-casual user" has a type inference problem and has to boost -Ytyper-debug aka -Vtyper.)

Apparently people don't do this anymore, but it's nice to scalac -V and see a list of debug output flags that maybe fits on one screen.

Also: "An extraterrestrial race arrives on Earth with seemingly good intentions, only to slowly reveal their true machinations the more ingrained into society they become. "

What are the stability guarantees around regular options, -X options, and -Y options? Is that documented somewhere? And what's the stability intended for introducing the -W and -V options?

-W is no more stable than -Xlint, which has seen evolving semantics.

I'm sorting what is a "user-facing" verbose option, -Xprint and -Xshow vs -Ylog and -Ydebug.

There will be an update on the options page. Maybe sort the options by Odersky level? With additional levels for "macro nerd", "I report issues on scala/bug", "casual contributer", "I am LARS (lrytz, adriaanm, retronym, smarter)". That would be C1 - C4.

/rebuild

It’s a good point that we should document the stability somewhere. I don’t think we ever did. -X goes through deprecation, -Y is why are you even using this it could change at any time. The new -W should be more stable than -X

They've really spiffied up the docs for javac. I was looking for battle-hardened terminology, but they are still a bit imprecise about "extra" or "non-standard" options, not all of which begin with -X. They "are subject to change in the future", which is tautological.

Maybe I'll submit a PR to promote -Yimports to -X so folks feel like they're allowed to use it.

I had already made -Werror a "front page" option because javac grants it that privilege.

I would be hard-pressed to say what is a "standard option." I was going to suggest: "an option useful for ordinary compilation." But -uniqid? I need -help to remind me how to spell it. And -no-specialization? That strikes me as extraordinary compilation, unless one considers specialization so fragile that it deserves a standard option to disable it. The -opt- options feel somewhat like that portion of sidewalk where some local kids inscribed their initials while the concrete was wet and are now enshrined for all passers-by.

@tpolecat @DavidGregory084 as the chiselers of the compiler-options tablet which is handed down from the mountain, any feedback on this?

This all seems good to me. I will bring in @som-snytt as a consultant for the 2.13 edition.

The current options page puts -opt with "private" options because they are liable to change on a whim. I will follow scalac -help (because it's simpler and more correct). Just because no one knows how to use -opt:l:weirdness, doesn't mean you shouldn't let the concrete set on your build that uses it. Also, today I figured out that the ell stands for Lukas, the only person who knows how to use it. Maybe I'll add a section, "Lukas's Private Options".

I think in general it would be nice if the options had clearer deprecation cycles as they are the public API of scalac, but it's not a particularly onerous task to support several Scala versions at the moment and it doesn't look like this would make things significantly harder 🙂

This looks like a good change to me in any case 💯

Rebased over at an other PR. @som-snytt, assuming that LGTY, could you update your branch to the HEAD of my pr7686-rebased branch?

Rebased and squashed. I'll try to give the task list some attention. That is mostly sanity-checking and documentation.

As 2.13.0-RC1 is getting closer, I am concerned about the state of this PR.
Is it awaiting one more rebase?

Here's a rebase in another PR - #7908

@eed3si9n Thanks! That gives me renewed confidence that I, too, may one day achieve the rebase!

"All your rebase are belong to us."

Merged the Rebased.

@adriaanm kind of annoying. It makes it much harder to manage branches, because this will appear forever in my list of unmerged. I don't think github has a way to make them disappear.

I deciphered your comment as gratitude for the other branch. Had I understood better, I'd have gladly closed the other PR and waited for you to achieve rebase.

@som-snytt submitting a PR so desirable you nerd-sniped Eugene and Adriaan into finishing it for you is an achievement no one can ever take away from you

Sorry about the confusion. I tend to send alternative PRs as a form of code review, so feel free to let me know if it becomes too much.
As per branch management issue, should we consider using merge as opposed to rebase? That will properly retain the original PRs history, so likely GitHub will know.

Sometimes I underestimate the power of sarcasm. I'll reopen this ASAP, rebased, with the other follow-up from the checklist. Git rebase offers that nothing changed, try --skip, so maybe it knows what it is doing; it's a little bit of work to get there.

this will appear forever in my list of unmerged

in fact, I drove by today while revivifying PRs in the old neighborhood.

The detour was worth the bon-mots.