Fields phase

One step towards teasing apart the mixin phase, making
each phase that adds members to traits responsible for
mixing in those members into subclasses of said traits.

Another design tenet is to not emit symbols or trees
only to later remove them. Therefore, we model a
val in a trait as its accessor. The underlying field
is an implementation detail. It must be mixed into
subclasses, but has no business in a trait (an interface).

Also trying to reduce tree creation by changing less in subtrees
during tree transforms.

A lot of nice fixes fall out from this rework:

  - Correct bridges and more precise generic signatures for
    mixed in accessors, since they are now created before erasure.

  - Correct enclosing method attribute for classes nested in trait fields.

    Trait fields are now created as MethodSymbol (no longer TermSymbol).
    This symbol shows up in the `originalOwner` chain of a class declared
    within the field initializer. This promoted the field getter to
    being the enclosing method of the nested class, which it is not
    (the EnclosingMethod attribute is a source-level property).

  - Signature inference is now more similar between vals and defs

  - No more field for constant-typed vals, or mixed in accessors
    for subclasses. A constant val can be fully implemented in a trait.

TODO:
  - give same treatment to trait lazy vals (only accessors, no fields)
  - remove support for presuper vals in traits
    (they don't have the right init semantics in traits anyway)
  - lambdalift should emit accessors for captured vals in traits,
    not a field

Assorted notes from the full git history before squashing below.

Unit-typed vals: don't suppress field

it affects the memory model -- even a write of unit to a field is relevant...
unit-typed lazy vals should never receive a field
this need was unmasked by test/files/run/t7843-jsr223-service.scala,
which no longer printed the output expected from the `0 to 10 foreach`

Use getter.referenced to track traitsetter

reify's toolbox compiler changes the name of the trait
that owns the accessor between fields and constructors (`$` suffix),
so that the trait setter cannot be found when doing mkAssign in constructors
this could be solved by creating the mkAssign tree immediately during fields

anyway, first experiment: use `referenced` now that fields runs closer
to the constructors phase (I tried this before and something broke)

Infer result type for `val`s, like we do for `def`s

The lack of result type inference caused pos/t6780 to fail
in the new field encoding for traits, as there is no separate accessor,
and method synthesis computes the type signature based on the ValDef tree.
This caused a cyclic error in implicit search, because now the
implicit val's result type was not inferred from the super member,
and inferring it from the RHS would cause implicit search to consider
the member in question, so that a cycle is detected and type checking fails...

Regardless of the new encoding, we should consistently infer result types
for `def`s and `val`s.

Removed test/files/run/t4287inferredMethodTypes.scala and test/files/presentation/t4287c,
since they were relying on inferring argument types from "overridden" constructors
in a test for range positions of default arguments. Constructors don't override,
so that was a mis-feature of -Yinfer-argument-types.

Had to slightly refactor test/files/presentation/doc, as it was relying
on scalac inferring a big intersection type to approximate the anonymous
class that's instantiated for `override lazy val analyzer`.
Now that we infer `Global` as the expected type based on the overridden val,
we make `getComment` private in navigating between good old Skylla and Charybdis.
I'm not sure why we need this restriction for anonymous classes though;
only structural calls are restricted in the way that we're trying to avoid.

The old behavior is maintained nder -Xsource:2.11.

Tests:
  - test/files/{pos,neg}/val_infer.scala
  - test/files/neg/val_sig_infer_match.scala
  - test/files/neg/val_sig_infer_struct.scala

need NMT when inferring sig for accessor
Q: why are we calling valDefSig and not methodSig?
A: traits use defs for vals, but still use valDefSig...
keep accessor and field info in synch

1 files changed, 87 insertions, 0 deletions

diff --git a/test/files/neg/trait_fields_conflicts.scala b/test/files/neg/trait_fields_conflicts.scala
new file mode 100644
index 0000000000..92fc106e44
--- /dev/null
+++ b/test/files/neg/trait_fields_conflicts.scala
@@ -0,0 +1,87 @@
+trait Val { val x: Int = 123 }
+trait Var { var x: Int = 123 }
+trait Lazy { lazy val x: Int = 123 }
+
+trait ValForVal extends Val { val x: Int = 1 } // needs override
+trait VarForVal extends Val { var x: Int = 1 } // needs override
+trait DefForVal extends Val { def x: Int = 1 } // needs override
+trait ValForVar extends Var { val x: Int = 1 } // needs override
+trait VarForVar extends Var { var x: Int = 1 } // needs override
+trait DefForVar extends Var { def x: Int = 1 } // needs override
+trait ValForLazy extends Lazy { val x: Int = 1 } // needs override
+trait VarForLazy extends Lazy { var x: Int = 1 } // needs override
+trait DefForLazy extends Lazy { def x: Int = 1 } // needs override
+
+trait ValForValOvr extends Val { override val x: Int = 1 } // override ok
+trait VarForValOvr extends Val { override var x: Int = 1 } // bad override
+trait DefForValOvr extends Val { override def x: Int = 1 } // bad override
+trait ValForVarOvr extends Var { override val x: Int = 1 } // bad override -- unsound if used in path and var changes
+trait VarForVarOvr extends Var { override var x: Int = 1 } // bad override -- why?
+trait DefForVarOvr extends Var { override def x: Int = 1 } // bad override -- why?
+trait ValForLazyOvr extends Lazy { override val x: Int = 1 } // bad override -- why?
+trait VarForLazyOvr extends Lazy { override var x: Int = 1 } // bad override -- why?
+trait DefForLazyOvr extends Lazy { override def x: Int = 1 } // bad override -- why?
+
+class CValForVal extends Val { val x: Int = 1 } // needs override
+class CVarForVal extends Val { var x: Int = 1 } // needs override
+class CDefForVal extends Val { def x: Int = 1 } // needs override
+class CValForVar extends Var { val x: Int = 1 } // needs override
+class CVarForVar extends Var { var x: Int = 1 } // needs override
+class CDefForVar extends Var { def x: Int = 1 } // needs override
+class CValForLazy extends Lazy { val x: Int = 1 } // needs override
+class CVarForLazy extends Lazy { var x: Int = 1 } // needs override
+class CDefForLazy extends Lazy { def x: Int = 1 } // needs override
+
+class CValForValOvr extends Val { override val x: Int = 1 } // override ok
+class CVarForValOvr extends Val { override var x: Int = 1 } // bad override
+class CDefForValOvr extends Val { override def x: Int = 1 } // bad override
+class CValForVarOvr extends Var { override val x: Int = 1 } // bad override -- unsound if used in path and var changes
+class CVarForVarOvr extends Var { override var x: Int = 1 } // bad override -- why?
+class CDefForVarOvr extends Var { override def x: Int = 1 } // bad override -- why?
+class CValForLazyOvr extends Lazy { override val x: Int = 1 } // bad override -- why?
+class CVarForLazyOvr extends Lazy { override var x: Int = 1 } // bad override -- why?
+class CDefForLazyOvr extends Lazy { override def x: Int = 1 } // bad override -- why?
+
+class CVal { val x: Int = 123 }
+class CVar { var x: Int = 123 }
+class CLazy { lazy val x: Int = 123 }
+
+trait ValForCVal extends CVal { val x: Int = 1 } // needs override
+trait VarForCVal extends CVal { var x: Int = 1 } // needs override
+trait DefForCVal extends CVal { def x: Int = 1 } // needs override
+trait ValForCVar extends CVar { val x: Int = 1 } // needs override
+trait VarForCVar extends CVar { var x: Int = 1 } // needs override
+trait DefForCVar extends CVar { def x: Int = 1 } // needs override
+trait ValForCLazy extends CLazy { val x: Int = 1 } // needs override
+trait VarForCLazy extends CLazy { var x: Int = 1 } // needs override
+trait DefForCLazy extends CLazy { def x: Int = 1 } // needs override
+
+trait ValForCValOvr extends CVal { override val x: Int = 1 } // override ok
+trait VarForCValOvr extends CVal { override var x: Int = 1 } // bad override
+trait DefForCValOvr extends CVal { override def x: Int = 1 } // bad override
+trait ValForCVarOvr extends CVar { override val x: Int = 1 } // bad override -- unsound if used in path and var changes
+trait VarForCVarOvr extends CVar { override var x: Int = 1 } // bad override -- why?
+trait DefForCVarOvr extends CVar { override def x: Int = 1 } // bad override -- why?
+trait ValForCLazyOvr extends CLazy { override val x: Int = 1 } // bad override -- why?
+trait VarForCLazyOvr extends CLazy { override var x: Int = 1 } // bad override -- why?
+trait DefForCLazyOvr extends CLazy { override def x: Int = 1 } // bad override -- why?
+
+class CValForCVal extends CVal { val x: Int = 1 } // needs override
+class CVarForCVal extends CVal { var x: Int = 1 } // needs override
+class CDefForCVal extends CVal { def x: Int = 1 } // needs override
+class CValForCVar extends CVar { val x: Int = 1 } // needs override
+class CVarForCVar extends CVar { var x: Int = 1 } // needs override
+class CDefForCVar extends CVar { def x: Int = 1 } // needs override
+class CValForCLazy extends CLazy { val x: Int = 1 } // needs override
+class CVarForCLazy extends CLazy { var x: Int = 1 } // needs override
+class CDefForCLazy extends CLazy { def x: Int = 1 } // needs override
+
+class CValForCValOvr extends CVal { override val x: Int = 1 } // override ok
+class CVarForCValOvr extends CVal { override var x: Int = 1 } // bad override
+class CDefForCValOvr extends CVal { override def x: Int = 1 } // bad override
+class CValForCVarOvr extends CVar { override val x: Int = 1 } // bad override -- unsound if used in path and var changes
+class CVarForCVarOvr extends CVar { override var x: Int = 1 } // bad override -- why?
+class CDefForCVarOvr extends CVar { override def x: Int = 1 } // bad override -- why?
+class CValForCLazyOvr extends CLazy { override val x: Int = 1 } // bad override -- why?
+class CVarForCLazyOvr extends CLazy { override var x: Int = 1 } // bad override -- why?
+class CDefForCLazyOvr extends CLazy { override def x: Int = 1 } // bad override -- why?