Check of cyclic object initialization v4 #12698
Conversation
liufengyun
force-pushed
the
fix-global4
branch
3 times, most recently
from
3b239f8 to
667c17a
Compare
This goes back to coarse-grained abstraction for parameters, which is trade-off between performance and expressiveness.
This helps reduce more than 20 errors:
[error] -- Error: /Users/fliu/Documents/dotty/compiler/src/dotty/tools/dotc/core/StdNames.scala:665:34
[error] 665 | final val MINUS_STAR : N = "-*"
[error] | ^^^^
[error] |Call method dotty.tools.dotc.core.StdNames.ScalaNames.this.fromString("-*") on a value with an unknown initialization. Calling trace:
[error] | -> package object printing { [ package.scala:6 ]
[error] | -> val AndTypePrec: Int = parsing.precedence(tpnme.raw.AMP) [ package.scala:11 ]
[error] | -> object raw { [ StdNames.scala:649 ]
For traits, its outers will be proxy methods of the class that extends the trait. As the prefix is stable and is a valid value before any super constructor calls. Therefore, we may think the outers for traits are immediately set following the class parameters. Also, when trying promotion of warm values, we never try warm values whose fields are not fully filled -- which corresponds to promote ThisRef with non-initialized fields, and errors will be reported when the class is checked separately.
|
The statistics for 3 different designs when compiling Dotty with the checker: All versions abstract mutable fields or mutable variables by their type. All of the designs above can catch the bugs found in the issue tracker: Fix #9176 The checker does not report a warning when calling a statically resolvable target but TASTy is missing (unlike the checker for class instantiation). It always issues a warning when calling a virtual method that cannot be resolved statically in the analysis (after approximation). The detailed warnings for the 2nd design when compiling Dotty can be found in this gist. |
This is safe because those symbols are already checked when they are compiled. This avoids cycles in reading tasty.
| /** A reference to a static object */ | ||
| case class ObjectRef(klass: ClassSymbol) extends Addr | ||
|
|
||
| /** An ClassAbs of class */ |
There was a problem hiding this comment.
From the comments here, the meanings of TypeAbs and ClassAbs are not clear, and it's not clear what are the differences between TypeAbs, ObjectRef, and ClassAbs. All that's clear is that they are all somehow related to an object.
Also, the abstraction ordering is not documented (although maybe these values are all unrelated by the ordering, except for RefSet in the obvious way).
There was a problem hiding this comment.
One source of possible confusion is that the word "object" is overloaded to mean many different things:
- a runtime instance of some class
- a declaration in the program using the
objectkeyword - probably other meanings as well
It would be useful to precisely define distinct terms for these different meanings.
There was a problem hiding this comment.
Indeed the documentation and naming are confusing. I try to clarify them below:
ClassAbs: abstract a value by its class (outer-sensitive, but not parameter-sensitive, similar toWarm)TypeAbs: abstract a value by its type (primarily used for parameters)ObjectRef: reference to a global object
When ClassAbs gets too complex, we widen to TypeAbs to ensure termination.
|
Close for now, we will try new approaches. |
Supersedes #12122