wrong position for selectDynamic call

[Simon Schäfer]

I tried to implement semantic highlighting for calls to scala.Dynamic in
the Scala IDE. But I didn't came up with the correct position objects
for the transformations.

I looked in detail only to selectDynamic yet, thus the following may be
true for the other dynamic methods as well.

It seems that after a transformation of `d.foo` to
`d.selectDynamic("foo")` the string literal points to the same location
as the identifier `d`.

I can't reproduce the behavior in the REPL, I always get NoPosition
after creating an AST with reify or ToolBox (see code below).

The IDE still works with 2.10, and I have no idea how to get an AST
otherwise, thus I can't test if the behavior is different in 2.11.

The behavior seems to be a bug, it should point to the `foo` field call
before the transformation, is that correct? If yes, I'm interested in
fixing it (if no one else has the time to do it).

Any hints where to start searching for the bug. I assume it is somewhere
in Typers.

And is it possible to typecheck a string (or a file) in the REPL with
correct Positions?


The code used to find positions in the REPL:


import reflect.runtime.universe._
import scala.reflect.runtime.{currentMirror => m}
import scala.tools.reflect.ToolBox

/*
val in = reify{object X {
D.foo
import language.dynamics
object D extends Dynamic { def selectDynamic(s: String) = s }
}}
val Block(List(ModuleDef(_, _, Template(_, _, _ :: Apply(_, List(lit:
Literal)) :: _))), _) = in.tree
*/

val tb = m.mkToolBox()

val in = """object X {
D.foo
import language.dynamics
object D extends Dynamic { def selectDynamic(s: String) = s }
}"""

val tree = tb.typeCheck(tb.parse(in))
val ModuleDef(_, _, Template(_, _, _ :: Apply(_, List(lit: Literal)) ::
_)) = tree

lit.pos == NoPosition

[Eugene Burmako]

Currently parse doesn't produce positions. That's a known issue documented here: https://issues.scala-lang.org/browse/SI-6489.

Btw you might find -Xprint-pos quite useful when debugging position generation.

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-internals+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jason Zaugg]

On Thu, Apr 4, 2013 at 10:34 PM, Simon Schäfer <ma...@antoras.de> wrote:

I tried to implement semantic highlighting for calls to scala.Dynamic in the Scala IDE. But I didn't came up with the correct position objects for the transformations.

 

The IDE still works with 2.10, and I have no idea how to get an AST otherwise, thus I can't test if the behavior is different in 2.11.

You can use `scalac -Yrangepos -Xprint-pos -Xprint:parser,typer src.scala` to print the positions:

As a red-herring, positioning of constructors seems to be in flux:

diff <(RUNNER=scalac scala-hash 2.10.x -Yrangepos -Xprint-pos -Xprint:typer sandbox/test.scala ) <(RUNNER=scalac scala-hash master -Yrangepos -Xprint-pos -Xprint:typer sandbox/test.scala )

[info] 2.10.x => /Users/jason/usr/scala-v2.10.0-608-g2952d0f

[info] c0b3e586e3 => /Users/jason/usr/scala-v2.11.0-M2-151-gc0b3e58

4,5c4,5

<     [9]def <init>(): [9]X.type = [9]{

<       [9][9][9]X.super.<init>();

---

>     [111]def <init>(): [9]X.type = [111]{

>       [111][111][111]X.super.<init>();

11,12c11,12

<       [57]def <init>(): [57]X.D.type = [57]{

<         [57][57][57]D.super.<init>();

---

>       [65]def <init>(): [57]X.D.type = [65]{

>         [65][65][65]D.super.<init>();

In both versions, the dynamic call is positioned:

// after parser

[13:18]D.foo;

// after typer

[13:14][13:14][13]X.this.D.selectDynamic([13]"foo");

Here's a quick attempt to improve the position:

https://github.com/retronym/scala/compare/topic/dyn-pos

// after typer

[13:14][13:14][13]X.this.D.selectDynamic(<15:18>"foo");

Please feel free to experiment with this and test it out with a variety of dynamic calls, and with the IDE.

-jason

[Eugene Burmako]

Actually that's a different problem, and I created a bug for it:
https://issues.scala-lang.org/browse/SI-7331

On Apr 5, 12:11 am, Eugene Burmako <xeno...@gmail.com> wrote:
> Currently parse doesn't produce positions. That's a known issue documented
> here:https://issues.scala-lang.org/browse/SI-6489.
>
> Btw you might find -Xprint-pos quite useful when debugging position
> generation.
>

> On 4 April 2013 23:34, Simon Schäfer <m...@antoras.de> wrote:
>
>
>
>
>
>
>
> > I tried to implement semantic highlighting for calls to scala.Dynamic in
> > the Scala IDE. But I didn't came up with the correct position objects for
> > the transformations.
>
> > I looked in detail only to selectDynamic yet, thus the following may be
> > true for the other dynamic methods as well.
>
> > It seems that after a transformation of `d.foo` to
> > `d.selectDynamic("foo")` the string literal points to the same location as
> > the identifier `d`.
>
> > I can't reproduce the behavior in the REPL, I always get NoPosition after
> > creating an AST with reify or ToolBox (see code below).
>
> > The IDE still works with 2.10, and I have no idea how to get an AST
> > otherwise, thus I can't test if the behavior is different in 2.11.
>
> > The behavior seems to be a bug, it should point to the `foo` field call
> > before the transformation, is that correct? If yes, I'm interested in
> > fixing it (if no one else has the time to do it).
>
> > Any hints where to start searching for the bug. I assume it is somewhere
> > in Typers.
>
> > And is it possible to typecheck a string (or a file) in the REPL with
> > correct Positions?
>
> > The code used to find positions in the REPL:
>
> > import reflect.runtime.universe._

> > import scala.reflect.runtime.{**currentMirror => m}

> > import scala.tools.reflect.ToolBox
>
> > /*
> > val in = reify{object X {
> >   D.foo
> >   import language.dynamics
> >   object D extends Dynamic { def selectDynamic(s: String) = s }
> > }}
> > val Block(List(ModuleDef(_, _, Template(_, _, _ :: Apply(_, List(lit:
> > Literal)) :: _))), _) = in.tree
> > */
>
> > val tb = m.mkToolBox()
>
> > val in = """object X {
> >   D.foo
> >   import language.dynamics
> >   object D extends Dynamic { def selectDynamic(s: String) = s }
> > }"""
>
> > val tree = tb.typeCheck(tb.parse(in))
> > val ModuleDef(_, _, Template(_, _, _ :: Apply(_, List(lit: Literal)) ::
> > _)) = tree
>
> > lit.pos == NoPosition
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "scala-internals" group.
> > To unsubscribe from this group and stop receiving emails from it, send an

> > email to scala-internals+unsubscribe@**googlegroups.com<scala-internals%2Bunsu...@googlegroups.com>
> > .
> > For more options, visithttps://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> > .

[Simon Schäfer]

Thanks for the quick fix, I'll try it out in the IDE and let you know if it works.

-jason

--
You received this message because you are subscribed to a topic in the Google Groups "scala-internals" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scala-internals/RgHUcvfh9aU/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to scala-interna...@googlegroups.com.

[Simon Schäfer]

On 04/04/2013 11:25 PM, Eugene Burmako wrote:
> Actually that's a different problem, and I created a bug for it:
> https://issues.scala-lang.org/browse/SI-7331

Interesting to see how fast some things can be fixed. ;)

[Simon Schäfer]

Jason, your fix works fine. I could implement semantic highlighting for all four dynamic methods.

Because the code base of the IDE is still on 2.10 (and it will probably stay there for the next months)
I had to cherry-pick the changes to 2.10.x (I got merge errors only for the whitespace change).

I can't open a PR to the IDE unless the changes are in the compiler, could you please open a PR to scala and backport it to 2.10.x?

Btw, while trying to get position information to `applyDynamicNamed` scalac crashed: https://gist.github.com/sschaef/5319290
And the position range for the named argument doesn't look correct too.

Greetings and thanks for the fast fixes,
Simon

On 04/04/2013 11:18 PM, Jason Zaugg wrote: