Skip to content
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

Closed
smarter opened this issue Jun 12, 2020 · 4 comments
Closed

Initialization checker doesn't catch uninitialized object call #9176

smarter opened this issue Jun 12, 2020 · 4 comments

Comments

@smarter
Copy link
Member

smarter commented Jun 12, 2020

When running the following code with -Ycheck-init, no warning or error is emitted:

class Foo(val opposite: Foo)
case object A extends Foo(B)
case object B extends Foo(A)
object Test {
  def main(args: Array[String]): Unit = {
    println(A.opposite)
    println(B.opposite)
  }
}

But A ends being used when it's uninitialized:

B
null

I'm not sure if this is a bug or outside the scope of safe initialization?

@liufengyun
Copy link
Contributor

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 new CompilationUnit will run forever, thus it's correct for the checker to not issue any warning. There are several possible enhancement:

  • treats the compilation unit as inside a class
  • check possible non-termination in the initialization of lazy fields

Another subtle issue is with the following code: accessing CompilationUnit will not run forever,
and an uninitialized field is accessed.

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 object CompilationUnit and class CompilationUnit consistent in language semantics and compiler implementation.

liufengyun added a commit to dotty-staging/dotty that referenced this issue Nov 30, 2020
@liufengyun liufengyun linked a pull request Nov 30, 2020 that will close this issue
liufengyun added a commit to dotty-staging/dotty that referenced this issue Mar 26, 2021
liufengyun added a commit that referenced this issue Jun 16, 2023
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
@liufengyun
Copy link
Contributor

This can now be checked with the experimental option: -Ysafe-init-global.

@smarter
Copy link
Member Author

smarter commented Jul 19, 2023

Would it make sense to combine -Ysafe-init and -Ysafe-init-global into one flag eventually?

@liufengyun
Copy link
Contributor

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 -Ysafe-init and -Ysafe-init-global (maybe -Yexplicit-nulls as well). Internally, as well know they are different features, having different flags makes testing easier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment