Fields phase expands lazy vals like modules

They remain ValDefs until then.

- remove lazy accessor logic
  now that we have a single ValDef for lazy vals,
  with the underlying machinery being hidden until the fields phase
  leave a `@deprecated def lazyAccessor` for scala-refactoring

- don't skolemize in purely synthetic getters,
  but *do* skolemize in lazy accessor during typers

  Lazy accessors have arbitrary user code, so have to skolemize.
  We exempt the purely synthetic accessors (`isSyntheticAccessor`)
  for strict vals, and lazy accessors emitted by the fields phase
  to avoid spurious type mismatches due to issues with existentials
  (That bug is tracked as https://github.com/scala/scala-dev/issues/165)

  When we're past typer, lazy accessors are synthetic,
  but before they are user-defined to make this hack less hacky,
  we could rework our flag usage to allow for
  requiring both the ACCESSOR and the SYNTHETIC bits
  to identify synthetic accessors and trigger the exemption.

  see also https://github.com/scala/scala-dev/issues/165

  ok 7 - pos/existentials-harmful.scala
  ok 8 - pos/t2435.scala
  ok 9 - pos/existentials.scala

  previous attempt: skolemize type of val inside the private[this] val

  because its type is only observed from inside the
  accessor methods (inside the method scope its existentials are skolemized)

- bean accessors have regular method types, not nullary method types

- must re-infer type for param accessor
  some weirdness with scoping of param accessor vals and defs?

- tailcalls detect lazy vals, which are defdefs after fields

- can inline constant lazy val from trait

- don't mix in fields etc for an overridden lazy val

- need try-lift in lazy vals: the assign is not seen in uncurry
  because fields does the transform (see run/t2333.scala)

- ensure field members end up final in bytecode

- implicit class companion method: annot filter in completer

- update check: previous error message was tangled up with unrelated
  field definitions (`var s` and `val s_scope`),
  now it behaves consistently whether those are val/vars or defs

- analyzer plugin check update seems benign, but no way to know...

- error message gen: there is no underlying symbol for a deferred var
  look for missing getter/setter instead

- avoid retypechecking valdefs while duplicating for specialize
  see pos/spec-private

- Scaladoc uniformly looks to field/accessor symbol

- test updates to innerClassAttribute by Lukas

1 files changed, 2 insertions, 2 deletions

diff --git a/src/compiler/scala/tools/nsc/typechecker/TypeDiagnostics.scala b/src/compiler/scala/tools/nsc/typechecker/TypeDiagnostics.scala
index bee327c760..b66dbf21c0 100644
--- a/src/compiler/scala/tools/nsc/typechecker/TypeDiagnostics.scala
+++ b/src/compiler/scala/tools/nsc/typechecker/TypeDiagnostics.scala
@@ -97,7 +97,7 @@ trait TypeDiagnostics {
   /** An explanatory note to be added to error messages
    *  when there's a problem with abstract var defs */
   def abstractVarMessage(sym: Symbol): String =
-    if (underlyingSymbol(sym).isVariable)
+    if (sym.isSetter || sym.isGetter && sym.setterIn(sym.owner).exists)
       "\n(Note that variables need to be initialized to be defined)"
     else ""
 
@@ -140,7 +140,7 @@ trait TypeDiagnostics {
     * TODO: is it wise to create new symbols simply to generate error message? is this safe in interactive/resident mode?
     */
   def underlyingSymbol(member: Symbol): Symbol =
-    if (!member.hasAccessorFlag || member.owner.isTrait) member
+    if (!member.hasAccessorFlag || member.accessed == NoSymbol) member
     else if (!member.isDeferred) member.accessed
     else {
       val getter = if (member.isSetter) member.getterIn(member.owner) else member