-
Notifications
You must be signed in to change notification settings - Fork 14
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
Comments
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 ```
Would this be appropriate for a scala center proposal? |
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... |
Relatedly https://issues.scala-lang.org/browse/SI-8526 for macro API. |
This has gone a bit cold, could somebody please help me with technical input to write a proposal? |
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. |
I've put together a draft SC proposal here if anybody has any comments: https://gist.github.com/fommil/1867119e7f184d36342bd5e4b34c7bfe |
further on SCP-022: https://contributors.scala-lang.org/t/improving-the-scala-debugging-experience/4264 cc @errikos, who might not know about this ticket |
@errikos does your work on JSR 45 (scala/scala#9121) cover this as well, do you think? |
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. |
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
The text was updated successfully, but these errors were encountered: