macwire fails to find lazy vals for injection if there is a block comment above them in the publish phase

[jschaul]

This is using macwire 0.7.1 and scala 2.11.2.

When we have a code block like this:

/**
  * some comment what this service does.
  */
  lazy val service: Service = MyService

as part of the dependencies, then

• compiling normally works as expected
• the publish command, which re-compiles everything, fails to find service in the compilation phase.

The reason is the block comment which seems to interfere with the macros somehow. When the block comment is deleted everything works as expected. Still, this bug is rather annoying when wanting to publish a well-commented library....

publish
[info] Packaging /Users/joe/Documents/git/brokenMacwireParsing/target/scala-2.11/brokenmacwireparsing_2.11-1.0-sources.jar ...
[info] Done packaging.
[info] Packaging /Users/joe/Documents/git/brokenMacwireParsing/target/scala-2.11/brokenmacwireparsing_2.11-1.0.jar ...
[info] Main Scala API documentation to /Users/joe/Documents/git/brokenMacwireParsing/target/scala-2.11/api...
[info] Wrote /Users/joe/Documents/git/brokenMacwireParsing/target/scala-2.11/brokenmacwireparsing_2.11-1.0.pom
[info] Done packaging.
[info] :: delivering :: brokenmacwireparsing#brokenmacwireparsing_2.11;1.0 :: 1.0 :: release :: Fri Oct 10 17:04:11 CEST 2014
[info]  delivering ivy file to /Users/joe/Documents/git/brokenMacwireParsing/target/scala-2.11/ivy-1.0.xml
[debug] Trying to find parameters to create new instance of: [com.example.Hello]
   [debug] Trying to find value [service] of type: [com.example.Service]
      [debug] Looking in the enclosing method
      [debug] Looking in the enclosing class/trait
      [debug] Checking def: [$init$]
      [debug] Checking val: [hello]
      [debug] Looking in parents
      [debug] Checking parent: [AnyRef]
[error] /Users/joe/Documents/git/brokenMacwireParsing/src/main/scala/com/example/Hello.scala:18: Cannot find a value of type: [com.example.Service]
[error]   lazy val hello: Hello = wire[Hello]
[error]  

See the specially created repo reproducing this bug here, including macwire debug output:

https://github.com/jschaul/macwire-bug-demonstration

[mkubala]

Problem occurs at doc task execution, when regular ValDef node is wrapped within DocDef node which currently isn't present in a public Trees' API.

It looks to me as a compiler bug, because these nodes should be eliminated (or more precisely - flattened) by analizer (see comment for DocDef case class: https://github.com/scala/scala/blob/2.11.x/src/compiler/scala/tools/nsc/ast/Trees.scala#L24-L32).

Guys from scala compiler team encountered very similar problem some time ago (scala/scala@c4561c1), but they were in more comfortable position, with access to DocDef's extractor.

I have some idea (currently only an idea, not sure if it will work for us) about how to make a temporary workaround in macwire, but it will be highly coupled with current DocDef implementation (not sure if @adamw will agree to do that, even I'm not fully convinced about doing such hacks..).

Anyway, I'll report this problem to the Scala team.

I'll inform you about eventual progresses :)

[mkubala]

Good news to you, @jschaul!
You can ommit compiler bug with simply adding following setting to your build.sbt:

scalacOptions in (Compile,doc) ++= Seq("-Ymacro-expand:none")

Above line will disable macro expansion during compile:doc.

[adamw]

That must be the weirdest bug ever :) @mkubala thanks for looking into it! Did you post on some mailing list?

Temporary workaround sounds good, it's probably easier to introduce this than wait for a patched compiler :)

[mkubala]

@adamw not yet. I'm going to report it today.

My original workaround for this issue was to use quasiquotes in partial function - maybe it would be able to match DocDef nodes.. But then I realized that there is much simpler solution - not in code, but at 'build processes' level ;)

[adamw]

Well, still would be nice to relieve users from finding out about such weird behavior in the first place ;) Anyway, let me know when you mail onto scala's user group - or I can do it if you don't have time.

[mkubala]

Bug reported: https://issues.scala-lang.org/browse/SI-8904

[adamw]

Thanks! :)

[jschaul]

Thanks for reporting this and letting me know about the -Ymacro-expand:none!

[jgrowl]

-Ymacro-expand:none worked for me also.

[sbchapin]

When using gradle, you can apply the scalac parameters thusly:

scaladoc {
  scalaDocOptions.additionalParameters = ["-Ymacro-expand:none"]
}

I realize this thread is an ancient artifact, but it remains at the top of the search history when going down this rabbit hole.

Leaving this here for the fellow scala-gradle folks who are affected.