Skip to content

Improve line number information #3

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

Open
retronym opened this issue Aug 5, 2015 · 11 comments
Open

Improve line number information #3

retronym opened this issue Aug 5, 2015 · 11 comments

Comments

@retronym
Copy link
Member

retronym commented Aug 5, 2015

Ensure that standard line number information is kept when inlining from the same file, eliminated otherwise. Write tests.

Next step: add support for JSR-45 debugging info, which allows

  • line numbers of multiple source files within one classfile
  • full (project-relative?) path of source file, not only the file name, should help debuggers in when not using Java's package/directory convention for sources
retronym added a commit that referenced this issue Aug 24, 2015
The log messages intented to chronicle implicit search were
always being filtered out by virtue of the fact that the the tree
passed to `printTyping` was already typed, (e.g. with an implicit
MethodType.)

This commit enabled printing in this case, although it still
filters out trees that are deemed unfit for typer tracing,
such as `()`. In the context of implicit search, this happens
to filter out the noise of:

```
|    |    |    [search #2] start `()`, searching for adaptation to pt=Unit => Foo[Int,Int] (silent: value <local Test> in Test) implicits disabled
|    |    |    [search #3] start `()`, searching for adaptation to pt=(=> Unit) => Foo[Int,Int] (silent: value <local Test> in Test) implicits disabled
|    |    |    \-> <error>
```

... which I think is desirable.

The motivation for this fix was to better display the interaction
between implicit search and type inference. For instance:

```
class Foo[A, B]
class Test {
  implicit val f: Foo[Int, String] = ???
  def t[A, B](a: A)(implicit f: Foo[A, B]) = ???
  t(1)
}
```

````
% scalac -Ytyper-debug sandbox/instantiate.scala
...
|    |-- t(1) BYVALmode-EXPRmode (site: value <local Test> in Test)
|    |    |-- t BYVALmode-EXPRmode-FUNmode-POLYmode (silent: value <local Test> in Test)
|    |    |    [adapt] [A, B](a: A)(implicit f: Foo[A,B])Nothing adapted to [A, B](a: A)(implicit f: Foo[A,B])Nothing
|    |    |    \-> (a: A)(implicit f: Foo[A,B])Nothing
|    |    |-- 1 BYVALmode-EXPRmode-POLYmode (site: value <local Test> in Test)
|    |    |    \-> Int(1)
|    |    solving for (A: ?A, B: ?B)
|    |    solving for (B: ?B)
|    |    [search #1] start `[A, B](a: A)(implicit f: Foo[A,B])Nothing` inferring type B, searching for adaptation to pt=Foo[Int,B] (silent: value <local Test> in Test) implicits disabled
|    |    [search #1] considering f
|    |    [adapt] f adapted to => Foo[Int,String] based on pt Foo[Int,B]
|    |    [search #1] solve tvars=?B, tvars.constr= >: String <: String
|    |    solving for (B: ?B)
|    |    [search #1] success inferred value of type Foo[Int,=?String] is SearchResult(Test.this.f, TreeTypeSubstituter(List(type B),List(String)))
|    |    |-- [A, B](a: A)(implicit f: Foo[A,B])Nothing BYVALmode-EXPRmode (site: value <local Test> in Test)
|    |    |    \-> Nothing
|    |    [adapt] [A, B](a: A)(implicit f: Foo[A,B])Nothing adapted to [A, B](a: A)(implicit f: Foo[A,B])Nothing
|    |    \-> Nothing
```
@lrytz
Copy link
Member

lrytz commented May 17, 2016

@fommil
Copy link

fommil commented Mar 7, 2017

Would this be appropriate for a scala center proposal?

@fommil
Copy link

fommil commented Mar 7, 2017

btw, we already (in ensime) handle the source file lookup issue in ensime using our indexer.

Does this JSR-45 support include information such as expanding line numbers to source ranges? The problem faced when writing a debugger is that we only get line number info, but we want to highlight the block of code (rangepos) that is being evaluated.

Of course, stacktrace demangling is another issue...

@som-snytt
Copy link

som-snytt commented Mar 12, 2017

@fommil
Copy link

fommil commented Mar 12, 2017

This has gone a bit cold, could somebody please help me with technical input to write a proposal?

@fommil
Copy link

fommil commented Mar 12, 2017

GSoC needs a mentor, which would be hard for this. We also have a debugging proposal already :-)

Scala Center is ideal for this if Lightbend's customers aren't prepared to directly fund it, because it really needs somebody working closely with EPFL or core scala team.

@fommil
Copy link

fommil commented Mar 22, 2017

I've put together a draft SC proposal here if anybody has any comments: https://gist.github.com/fommil/1867119e7f184d36342bd5e4b34c7bfe

@SethTisue
Copy link
Member

SethTisue commented Dec 16, 2019

Scala Center proposals in this area:

  • SCP-011 was accepted in 2017, but never really happened
  • SCP-022 proposes resuming work on it (and targeting Scala 3 as well)

@SethTisue
Copy link
Member

SethTisue commented Jul 1, 2020

@dwijnand
Copy link
Member

@errikos does your work on JSR 45 (scala/scala#9121) cover this as well, do you think?

@dwijnand dwijnand added this to the Backlog milestone Oct 22, 2020
@errikos
Copy link

errikos commented Nov 16, 2020

Hello. Sorry for the late reply.

Yes, it covers both bullets. For the second one, we store the fully qualified class name, so not project relative path exactly.

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

7 participants