Issue with macros and in-memory (virtual) source files about scala3 HOT 10 OPEN

Where exactly is getJPath defined?

If I type getJPath into the API docs search bar, then I can see that it is an extension method in the same scope that jpath is defined: https://www.scala-lang.org/api/3.4.2/scala/quoted/Quotes$reflectModule$SourceFileMethods.html

What about Scala 2?

Nothing wrong with just wrapping the call in Option.apply?

from scala3.

Well that code is not great either - we now have an optional variant also - getJPath - then if that is empty then you can construct some value from path which won't be null but doesn't have to correspond to a real file

from scala3.

Yes, with respect to this issue.

The underlying problem is that the API is hard to use. But if the genie gave you only three wishes, would you use one on this problem?

from scala3.

I would suggest that it is munit at fault - if the source file path is null then it should recover from this

from scala3.

@bishabosha Can you please comment on the fact that the Scala 3 documentation shows the exact same code, which I presume the MUnit implementation is based on? Thanks.

https://docs.scala-lang.org/scala3/reference/metaprogramming/reflection.html#positions-1

from scala3.

Where exactly is getJPath defined? What about Scala 2?

from scala3.

My technical lead @pavelfatin created a nice reproduction. You have to have MUnit 1.0.0 resolved locally:

dotr -cp ~/.cache/coursier/v1/https/repo1.maven.org/maven2/org/scalameta/munit_3/1.0.0/munit_3-1.0.0.jar
scala> class FooTestSuite extends munit.FunSuite {
     |   test("foo") {
     |     assert(true)
     |   }
     | }
-- Error: 
 3 |    assert(true)
   |                ^
   |                Exception occurred while executing macro expansion.
   |                java.lang.NullPointerException
   |                    at munit.internal.MacroCompat$.locationImpl(MacroCompat.scala:18)
   |Inline stack trace
   |This location contains code that was inlined from MacroCompat.scala:11
1 error found

from scala3.

I would expect code to use path uniformly. The fix on munit tries jpath and then uses path as a fallback, as though jpath were more authentic or reliable.

The Scala 2 usages by munit and sourcecode use path and are unaffected. There is no tempting jpath.

from scala3.

@som-snytt Just to be clear, you're also advocating for making no changes in Scala 2 and 3, instead address specific issues in libraries as they arise?

That's totally fine, I just want to clarify things.

Do you see an issue with the fix in MUnit?
scalameta/munit#795
scalameta/munit#796

Thank you.

from scala3.

Can you please patch the examples using jpath at:

• https://docs.scala-lang.org/scala3/guides/migration/tutorial-macro-cross-building.html
• https://dotty.epfl.ch/docs/reference/metaprogramming/reflection.html
• https://docs.scala-lang.org/scala3/reference/metaprogramming/reflection.html

To avoid future issues related to following them in other libraries

from scala3.