Scala -Xplugin optiions more finicky in 2.11?

[Josh Suereth]

Hey guys -

SO, the community build flushed out an issue in sbt (see https://github.com/sbt/sbt/issues/757 - -Xplugin specified twice in tests).

Just curious on

 (a) if scala should allow specifying multiple -Xplugin with the same jar (I'm not certain I understand why this causes continuations not to work.   However, I know I can specify the same jar repeatedly ina classpath string with no ill effects but for my reputation), 

(b) If Scala should issue a warning that "Hey dawg, you're being silly.  So I put an error in your error so you can fix while you fix".   That is, with the behavior change, maybe we go the extra mile to tell people while their continuations aren't compiling (HEY you specified the plugin twice and we accidentally instantiated it twice, but only allow flags to touch the first instance) or something like that.

(c) Should I open a ticket about the issue on Scala as well?  No harm in fixing everywhere right?

[Som Snytt]

> Should I open a ticket about the issue on Scala as well?

Please.  That was supposed to be less finicky.

The code was touched for plugin tests, so at least a test for this might be possible.

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Josh Suereth]

Well, I think the issue is that the same plugin gets added twice, and the enabling flag is parsed by one and not the other, hence the failue.

Again, it's dumb to specify the same plugin twice, but I feel there should be a warning, error or some note of what happened besides silent death.   "less finicky" != "explode at runtime".

Perhaps at least a WARNING would be useful here...

[Som Snytt]

There is a PR.  I went ahead and opened a ticket.  Is anyone sufficiently invested to take a look as reviewer?

https://github.com/scala/scala/pull/2562

Teaser: there is still no warning (as before), but the fix is to be even more finickier.  Instead of just ignoring duplicate locations, as it used to do, it ignores duplicate plug-in class names.

The second commit finds some old pending tests from the last decade and restores them like an old car (that is, mostly original parts, new paint job).

One question: phase assembly panics with FatalError if you munge your dependencies sufficiently.  Par-Test abhors a crash, especially since Paul noticed that it would update a check file with the crash.  My idea implemented here is to allow a crash on FatalError if a checkfile is present -- in other words, --update-check will fail until you touch an empty check file -- but that doesn't totally cover Paul's use case, which maybe calls for a special --force option instead of a secret handshake.

Or, perhaps you will recommend that I do the sane thing and change that FatalError to a global.error like the rest of the things that may go wrong occasionally.  Yes, munged phases would mean exiting gracefully without running any phases.  Unless that is already done at the MungedPhaseChecker phase.

https://github.com/som-snytt/scala/commit/4ab66d1613da276712692001ed8f9f3c009736ab