-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initialization checker doesn't catch uninitialized object call #9176
Comments
Generally, static fields are out of the scope of the checker, as that would require global analysis. However, in this special case, there is room to improve the checker, if it treats the compilation unit as inside a class. For example, if we wrap the code in a class, the checker will be able to detect initialization problems: class CompilationUnit {
class Foo(val opposite: Foo)
case object A extends Foo(B)
case object B extends Foo(A)
A
} Given the code above, the code
Another subtle issue is with the following code: accessing object CompilationUnit {
class Foo(val opposite: Foo)
case object A extends Foo(B)
case object B extends Foo(A)
A
} I think it will be more consistent to make the initialization behavior of |
The problem is illustrated by the example below: ``` Scala class Foo(val opposite: Foo) case object A extends Foo(B) // A -> B case object B extends Foo(A) // B -> A ``` The check aims to be simple for programmers to understand, expressive, fast, and sound. The check is centered around two design ideas: (1) initialization-time irrelevance; (2) partial ordering. The check enforces the principle of _initialization-time irrelevance_, which means that the time when a static object is initialized should not change program semantics. For that purpose, it enforces the following rule: > **The initialization of a static object should not directly or indirectly read or write mutable state owned by another static object**. This principle not only puts the initialization of static objects on a solid foundation but also avoids whole-program analysis. Partial ordering means that the initialization dependencies of static objects form a directed-acyclic graph (DAG). No cycles with length bigger than 1 allowed --- which might lead to deadlocks in the presence of concurrency and strong coupling & subtle contracts between objects. Related Issues: #16152 #9176 #11262 scala/bug#9312 scala/bug#9115 scala/bug#9261 scala/bug#5366 scala/bug#9360
This can now be checked with the experimental option: |
Would it make sense to combine -Ysafe-init and -Ysafe-init-global into one flag eventually? |
From the end-user perspective, it makes sense to have an umbrella option to cover |
When running the following code with
-Ycheck-init
, no warning or error is emitted:But A ends being used when it's uninitialized:
I'm not sure if this is a bug or outside the scope of safe initialization?
The text was updated successfully, but these errors were encountered: