Refactor MoveStatic

[liufengyun]

Currently, the phase MoveStatic has two functionality:

• Move @static members from the companion object A to the class A
• Create static constructor for static fields of the class A

In an earlier phase, CheckStatic checks that @static members only locate in the companion object A. This restriction is just for semantic-correctness of user-written programs (to avoid changing the typer). For code that is synthesized from compiler phases, this restriction is annoying.

We can make @static a general mechanism in the compiler by splitting MoveStatic into two phases:

• one phase that performs the moving (can be merged with CheckStatic)
• one phase StaticConstructors that synthesize the static constructor for static fields.

The phase CompleteJavaEnums will benefit from the refactoring #8008.

[smarter]

I think we should just forbid user-code from using @static, it's a language feature which has not been properly specified and is currently really hard to use correctly (for example, if a lambda appears in a @static def, it will be translated to a non-static def, thus defeating the purpose of using @static)

[liufengyun]

Then we can change @static to be an internal annotation.

[odersky]

I would not be so rash throwing out @static. It solves real pain points of interop and getting the last drop of performance. It could need some attention to spec what it does and change the implementation to be more explicit when @static cannot be implemented correctly.