TailRec phase and tests for it.

[DarkDimius]

Ported tailcall phase from scalac with such changes:

• all transformation is done in the phase itself
  (previously half of the work was done in backend)
• it is now able to run before uncurry
• it is now a treeTransform
• renamed to tailrec to make it more obvious that
  this phase transforms only recursive calls.

For now this is a single phase which speculatively
transforms DefDefs.
Speculation can be potentially removed by
splitting into 2 phases:
one detecting which methods should be transformed
second performing transformation.

But, as transformation requires as same amount of work
as detection, I believe it will be simpler to maintain
it as a single phase.

[DarkDimius]

@odersky @gzm0 please review

[sjrd]

The parameter ddef should clearly be typed as DefDef, not as Tree.

[DarkDimius]

I'd prefer to leave it as is, as otherwise callsite will be responsible for cast, and match will reside in callsite.
This way we can simplify error handling, and have it in single place for a very common case when particular type of tree is expected and modified.

[sjrd]

In all the call sites that are in this PR, the caller already has a statically typed version of the tree that it can use to pass to these methods.

For example here:
https://github.com/lampepfl/dotty/pull/117/files#diff-374479fca6aeeda64b2b850c4c611cc5R267
the identifier tree can be rebound in the pattern so that its static type becomes CaseDef.

[DarkDimius]

Yes, as TailRec reconstructs execution flow, it pattern matches on type of the tree, and is able to use it this way. But common usecase in scalac(that I like) is that those methods replace trivial match-and-transform clauses.

[sjrd]

those methods replace trivial match-and-transform clauses.

Except they don't: they replace a .asInstanceOf[DefDef], not a match. They only work when the type of the argument is exactly the expected type, and fail with an error that is no better than a ClassCastException if it doesn't. I would like to see a compelling call-site reason to do this before losing type-safety.

[retronym]

AFAICT, the reason that scalac tends to weaken the type requirements to Tree comes from the fact that typed /typedPos and a few others return Tree, even in cases when you know that you'll get back the same tree.

   val t: Tree = typedPos(pos)(DefDef(.....))
   deriveDefDef(t)(pos)

Maybe that calls for variants of those methods instead:

  def typedPosExact[T <: Tree](t: T): T
  val t: DefDef = typedPosExact(pos)(DefDef(.....))

A while back, I thought that TreeCopy was obviously too liberal in accepting Trees, but it often makes sense to use that with different trees:

val vd : ValDef = ...
treeCopy.DefDef(vd, .., ...)

In short, it might be worth starting with more restrictive types.

[gzm0]

LGTM

[DarkDimius]

@odersky is there anything except hasAnnotation?

[odersky]

annotations gives you the list of all annotations.

[DarkDimius]

@odersky I've removed deriveXXX methods