scalac lacks isolation for behavioral-altering method calls

[scabug]

(This ticket was originally about being unable to build with both -Ydebug and -verbose enabled.)

Either option can be used alone, but attempting to build with both leads to almost immediate failure along the lines of:

[scalacfork] error: error while loading Class, class file '/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar(java/lang/Class.class)' is broken
[scalacfork] (No class file for /scala/trunk/src/library/scala/Array.scala was found

Unfortunately some of the thornier issues I'm trying to debug have interesting data spread out among these two outputs so I'd really like to be able to see both at once all the way from bootstrap. Even commenting out all the spots in the source which say "if (settings.debug.value && settings.verbose.value)" did not enable it to proceed, so I'm thinking something is being initialized earlier than expected or in the wrong order because of a combination of code paths.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-1709?orig=1
Reporter: @paulp

[scabug]

@paulp said:
Of course that last comment makes no sense because I hadn't rebuilt starr. In that case I'm assuming for the moment that building a new starr with those lines commented out does solve the problem, but it's laborious to have to maintain a local fork of starr.

[scabug]

@lrytz said:
there are many debug messages which force types to be computed too early. this can cause the compiler to fail. one would have to go through all the debug code of the compiler.

[scabug]

@paulp said:
In my opinion it speaks to a larger and more significant issue that outputting debug messages can change the compiler behavior. It is not just the debug messages at issue here, it is that there is (as far as I can tell) no way to tell which operations are safe and which are not at any given point. I realize it would be a large undertaking to even partially address this, but the alternative is going to be (in my view) scalac soon reaching its complexity ceiling, where little can be done inside the compiler without introducing new bugs, and only people willing to invest months learning its quirks able to modify it.

I have multiple patches for open tickets now which fix the ticket under investigation but cannot be committed because they cause seemingly unrelated test cases to fail. I expect this collection to grow.

I'm modifying the title and summary of this ticket to express the larger issue. There has been talk of an effects system for scala being developed, and this is the very first use that comes to mind... I'm setting it low-priority enhancement but my personal view is closer to medium-priority defect.

[scabug]

@adriaanm said:
Grzegorz, I think a good debugging/diagnostics API is going to be relevant to optimizing the compiler.

[scabug]

@gkossakowski said:
I don't have plans to work on that any time soon so I'm unassigning it from myself.

[scabug]

@adriaanm said:
Unassigning as milestone deadline was reached.