Skip to content

An NPE in TypeTree.setOriginal #7284

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
scabug opened this issue Mar 22, 2013 · 7 comments
Closed

An NPE in TypeTree.setOriginal #7284

scabug opened this issue Mar 22, 2013 · 7 comments
Assignees

Comments

@scabug
Copy link

scabug commented Mar 22, 2013

import scala.language.experimental.macros
import scala.reflect.macros.Macro

object TypeOf {
  type TypeOf[T](s: T) = macro TypeOfMacro.TypeOf[T]
}
trait TypeOfMacro extends Macro {
  import c.universe._

  def TypeOf[T: WeakTypeTag](s: Expr[T]): Tree = {
    c.echo(NoPosition, "T " + weakTypeOf[T])
    tq"${weakTypeOf[T]}"
  }
}
import TypeOf._

trait A {
  val i: Int
  val j: TypeOf(i)
}
@scabug
Copy link
Author

scabug commented Mar 22, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7284?orig=1
Reporter: @xeno-by

@scabug
Copy link
Author

scabug commented Mar 22, 2013

@xeno-by said (edited on Mar 22, 2013 9:20:16 AM UTC):
The TypeTree produced by the macro expansion has a null original. Therefore when the result of its typedType, a TypeTree, calls setOriginal passing that tree as an argument, the following code NPEs:

def setOriginal(tree: Tree): this.type = {
  def followOriginal(t: Tree): Tree = t match {
    case tt: TypeTree => followOriginal(tt.original)
    case t => t
  }

  orig = followOriginal(tree); setPos(tree.pos)
  this
}

@scabug
Copy link
Author

scabug commented Apr 21, 2013

@paulp said:
Can you offer a reproduction which doesn't use code which isn't in master? I can easily fix the code but I am not interested in reverse engineering a test.

@scabug
Copy link
Author

scabug commented Apr 21, 2013

@xeno-by said:
Will try to find one.

@scabug
Copy link
Author

scabug commented Apr 25, 2013

@xeno-by said:
Don't think this particular issue is reproducible if we don't have macro types.

The problematic scenario is caused by the weird combination of:

  1. Input of typedTypeTree having a non-null original (application of a type macro)
  2. The result of typedType on the input having a null original (the result of the expansion).

Probably the correct fix here would be setting the type macro application tree as original for the result of macro expansion, which would prevent #2 from happening, making the bug impossible.

That said, I think we still should fix the NPE in setOriginal. It's just we don't have an integration test triggering that NPE.

@scabug
Copy link
Author

scabug commented Apr 25, 2013

@paulp said:
I think we should fix it also, and I already did the patch, except I'll be hassled for a test.

@scabug
Copy link
Author

scabug commented Dec 11, 2013

@xeno-by said:
I'm closing this bug since type macros have been discontinued.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants