diff options
author | Jason Zaugg <jzaugg@gmail.com> | 2013-09-05 15:27:15 +0200 |
---|---|---|
committer | Jason Zaugg <jzaugg@gmail.com> | 2013-09-05 16:13:44 +0200 |
commit | fb43ec8dc28625c929beaf28767a955388700d0d (patch) | |
tree | 1ece2ca12eacf4878839bb35a9b85d9306ffa6f6 /test/instrumented | |
parent | d46519da657ada39d9928308709cdb80ddcd53ce (diff) | |
download | scala-fb43ec8dc28625c929beaf28767a955388700d0d.tar.gz scala-fb43ec8dc28625c929beaf28767a955388700d0d.tar.bz2 scala-fb43ec8dc28625c929beaf28767a955388700d0d.zip |
SI-7814 Avoid init cycle between Predef, `package`, ScalaRuntime
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
}
Diffstat (limited to 'test/instrumented')
0 files changed, 0 insertions, 0 deletions