Make initialization checker see through synthetic applys

[liufengyun]

Make initialization checker see through synthetic applys

The initialization checker supports non-hot arguments to constructors, but not for methods.
For Scala to benefit from the expressiveness, we need to make the initialization checker see through synthetic applys.

We currently don't allow parameter-sensitivity for normal method arguments, as they would require complications of the abstract domains and it may cause unexpected usability/performance issues. Instead, we expect users to use inline def or @unchecked for such complex initialization code.

case class A(b: B)

object A:
  def foo(b: B) = new A(b)
  inline def bar(b: B) = new A(b)

class B:
  val a = A(this)
  val a2 = A.foo(this)   // error
  val a3 = A.bar(this)

An alternative to #13999.

[olhotak]

LGTM

[olhotak]

I wondered whether it would make sense to instantiate a synthetic apply even if target.hasSource is false. But if we don't have source for the synthetic apply, then we probably also don't have source for the class constructor, so instantiate wouldn't be useful.

[liufengyun]

I wondered whether it would make sense to instantiate a synthetic apply even if target.hasSource is false. But if we don't have source for the synthetic apply, then we probably also don't have source for the class constructor, so instantiate wouldn't be useful.

Yes, exactly.

I found one bug in the code above: the outer for instantiate is incorrect. I'll come up with a test to show the bug and fix it in this PR.

[olhotak]

Why not outer.instantiate(...)?

[liufengyun]

Thanks for the catch, this is now updated.