| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not every application will force these in a single thread; we
have to do our best to avoid cycles between them.
The enclosed test was failing every time before the change.
This commit breaks the cycle by avoiding computing `tupleNames`
in the constructor of `ScalaRuntime`. The new version has the
added benefit of including specialized tuple subclasses, which
is verified with a unit test for `isTuple`.
Are there more of these lurking? It seems likely. I'm more than
a little concerned about the way the `ControlThrowable` fires up
`scala.SystemProperties` to check whether or not to suppress
stack traces; there is already an ugly hack in place:
object NoStackTrace {
final def noSuppression = _noSuppression
// two-stage init to make checkinit happy,
// since sys.SystemProperties.noTraceSupression.value
// calls back into NoStackTrace.noSuppression
final private var _noSuppression = false
_noSuppression = sys.SystemProperties.noTraceSupression.value
}
|
