Skip to content
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

Range positions for default arguments are incorrect #4287

Closed
scabug opened this issue Feb 23, 2011 · 12 comments
Closed

Range positions for default arguments are incorrect #4287

scabug opened this issue Feb 23, 2011 · 12 comments

Comments

@scabug
Copy link

scabug commented Feb 23, 2011

=== What steps will reproduce the problem (please be specific and use wikiformatting)? ===

Compile the following code with Scaladoc:

class A(val a: Int = 4) {
   def k1(x:Int = (new B).t ):Int= x
}
class B {
   val t: Int = 0
}

The generated Scaladoc, which uses range positions to extract default arguments from source, has the following signatures for A:

class A(val a: Int) {
   def k1(x:Int = new B).t ):Int
}

Notice:

  • The default argument for the constructor parameter disappeared because a non-ranged position is generated for it (so that its startOrPoint and endOrPoint indices are equal).
  • The default argument for method parameter x has lost its first ( because its startOrPoint index is one too much.

=== Additional information ===

Ranged positions are not generated in a normal compiler run. Scaladoc is a way to demonstrate this issue because it forces the compiler to generate ranged positions, and outputs an artefact based upon them. Running the compiler in interactive mode for an IDE should have the same issue, but I do not know how to visualise the issue in the IDE.

To debug directly on position rather than indirectly through the resulting documentation, a possible entry point is at the beginning of method makeTree in class scala.tools.nsc.doc.model.TreeFactory.

Tested in 2.9 trunk r24334.

@scabug
Copy link
Author

scabug commented Feb 23, 2011

Imported From: https://issues.scala-lang.org/browse/SI-4287?orig=1
Reporter: @dubochet

@scabug
Copy link
Author

scabug commented Aug 6, 2011

Commit Message Bot (anonymous) said:
(kzys in r25451) Some "synthetic" code don't have RangePosition. Related to #4287. Review by heathermiller.

@scabug
Copy link
Author

scabug commented May 18, 2012

@lrytz said:
hi vlad, is this bug still a problem? or can we close that ticket?

@scabug
Copy link
Author

scabug commented Jun 14, 2012

@VladUreche said:
It seems the bug it still with us in 2.10 M4. I can't promise to fix it by the release.

@scabug
Copy link
Author

scabug commented May 20, 2013

@JamesIry said:
2.10.2 is about to be cut. Kicking down the road and un-assigning to foster work stealing.

1 similar comment
@scabug
Copy link
Author

scabug commented May 20, 2013

@JamesIry said:
2.10.2 is about to be cut. Kicking down the road and un-assigning to foster work stealing.

@scabug
Copy link
Author

scabug commented Jun 2, 2013

@dragos said:
This also means hyperlinking does not work for default arguments. See: https://www.assembla.com/spaces/scala-ide/tickets/1001141

@scabug
Copy link
Author

scabug commented Nov 19, 2013

@dotta said (edited on Nov 19, 2013 1:21:57 PM UTC):
I just ran the compiler based on this commit on the code example in the ticket linked by Iulian. Below is the tree printed after typer, with -Yrangepos flag

[[syntax trees at end of                     typer]] // Foo.scala
[0:63]package [0:0]<empty> {
  [0:37]class Baz extends [9:37][39]scala.AnyRef {
    [10:31]<paramaccessor> private[this] val f: [14]Int = _;
    [14]<stable> <accessor> <paramaccessor> def f: [14]Int = [14][14]Baz.this.f;
    [39]def <init>([14]f: [17]<type: [17]scala.Int> = [30]B.a): [9]Baz = [39]{
      [39][39][39]Baz.super.<init>();
      [9]()
    }
  };
  [6]<synthetic> object Baz extends [6][6]AnyRef {
    [6]def <init>(): [9]Baz.type = [6]{
      [6][6][6]Baz.super.<init>();
      [9]()
    };
    [14]<synthetic> def <init>$default$1: [14]Int = [30]B.a
  };
  [39:63]object B extends [48:63][63]scala.AnyRef {
    [63]def <init>(): [48]B.type = [63]{
      [63][63][63]B.super.<init>();
      [48]()
    };
    [52:61]private[this] val a: [56]Int = [60:61]2;
    [56]<stable> <accessor> def a: [56]Int = [56][56]B.this.a
  }
}

Looks like offset position are assigned to the B.a tree, which is why hyperlinking fails.

@scabug
Copy link
Author

scabug commented Nov 20, 2013

@dotta said:
@paul Are you currently working on this? I think I should be able to fix it...

@scabug
Copy link
Author

scabug commented Nov 21, 2013

@dotta said:
I'm assigning this to me, as I would like it to be fixed in time for 2.11.0-M8 (possibly even 2.10.4-RC1, but it may be a bit short). Paul let me know if you want me to pass the ball back.

@scabug
Copy link
Author

scabug commented Nov 21, 2013

@paulp said:
Please enjoy it. My struggles with positions have become ineffectual.

@scabug
Copy link
Author

scabug commented Dec 2, 2013

@dotta said (edited on Dec 12, 2013 4:37:16 PM UTC):
PR opened 3210 I've closed the former, and opened a new one scala/scala#3269

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