scala-library-next
scala-library-next copied to clipboard
scala
Library support for getting source file / line / other position information
There have been several mentions of "we should have something like https://github.com/lihaoyi/sourcecode in the standard library" but apparently no ticket. It has come up again in the context of https://github.com/scala/scala-dev/issues/411.
What should the API look like? The full implicit machineray from sourcecode or just a few methods that give you the key information?
The implementation itself is quite simple. We already have several fast-track macro implementations that are hardcoded in the compiler, so this could be done the same way.
Old related proposal: https://docs.scala-lang.org/sips/source-locations.html
A simple implementation I hacked together on the train just now : https://github.com/scala/scala/compare/2.13.x...szeiger:wip/sourcecode
@lihaoyi what's your take on this ? e.g. if you could redesign the sourcecode API, would you do it any differently ?
Not much. It works great.
Just poke through the open issues if you want to see what needs fixing. There are a few things that can be done better, e.g. making sourcecode.Text work robustly in the presence of parens or multi-statement blocks.
On Sat, 10 Nov 2018 at 12:24 AM, Guillaume Martres [email protected] wrote:
@lihaoyi https://github.com/lihaoyi what's your take on this ? e.g. if you could redesign the sourcecode API, would you do it any differently ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scala/scala-dev/issues/579#issuecomment-437413039, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5A_FxfDJ1db-mfVqtTHrwrmbk32cjuks5utaxHgaJpZM4YW2uj .
Honestly i think that all the sourcecode functions are useful and wouldn’t want to leave out any of them, and would want a handful more (sourcecode.Caller?) but would be quite happy just copy pasting the macros into the std lib. They’re pretty stable and havent changed much at all, and work great. No idea what hardcoding them into the compiler would give over what’s already there
On Sat, 10 Nov 2018 at 6:55 AM, Haoyi Li [email protected] wrote:
Not much. It works great.
Just poke through the open issues if you want to see what needs fixing. There are a few things that can be done better, e.g. making sourcecode.Text work robustly in the presence of parens or multi-statement blocks.
On Sat, 10 Nov 2018 at 12:24 AM, Guillaume Martres < [email protected]> wrote:
@lihaoyi https://github.com/lihaoyi what's your take on this ? e.g. if you could redesign the sourcecode API, would you do it any differently ?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scala/scala-dev/issues/579#issuecomment-437413039, or mute the thread https://github.com/notifications/unsubscribe-auth/AA5A_FxfDJ1db-mfVqtTHrwrmbk32cjuks5utaxHgaJpZM4YW2uj .
No idea what hardcoding them into the compiler would give over what’s already there
Scalatest has similar macros and if I recall correctly, @jvican found that they had a pretty severe impact on compilation time.
Why would inlining a single string/int literal and factory-function call result in a severe impact on compilation time?
+1 for including this in the standard library.
one thing, though: iirc i've seen one slightly problematic behaviour with my own source location code: when the source code contains tab characters, the reported position is as if tabs had been expanded to spaces. am i right, and is this happening elsewhere, too?
Currently, sourcecode.File returns c.enclosingPosition.source.path which can be problematic
- it's an absolute path depending on what the build tool passes in
- string is OS-dependent
- awkward to extract only filename
Most of the time I only want the name of the file so a Filename combinator would avoid those problems.
The full implicit machinery from sourcecode or just a few methods that give you the key information?
The implicits are useful, I almost never call Line.generate directly.
Why would inlining a single string/int literal and factory-function call result in a severe impact on compilation time?
More details on the performance challenge: https://github.com/scalatest/scalatest/issues/1418#issuecomment-495543079
https://github.com/scala/nanotest-strawman/ is already cross built against 2.x, Dotty, Scala.JS; and contains a fork of Minitest, Expecty, and SourceCode.
this proposal (that we should have library support; not the particulars of the implementation) seems fairly well accepted based on the reactions to the issue description, so I think we should use that to gauge acceptance (👍 in favour, 👎 against; reacting to the issue description).
