derivation of shapeless tagging causes compiler to fail

[TimPigden]

the attached example causes the compiler to fail with message

[info] Compiling 3 Scala sources to /home/tim/tmp/magnolia-json/target/scala-2.12/classes ...
[error] 
[error]   bad qualifier received: mkAttributedQualifier(<notype>, <none>)
[error]      while compiling: /home/tim/tmp/magnolia-json/src/main/scala/optrak/scalautils/mjson/CompoundParsers.scala
[error]         during phase: globalPhase=typer, enteringPhase=namer
[error]      library version: version 2.12.4-bin-typelevel-4
[error]     compiler version: version 2.12.4-bin-typelevel-4

In the worst case (my real code) this is all you get:

[warn] Found version conflict(s) in library dependencies; some are suspected to be binary incompatible:
[warn]     * org.postgresql:postgresql:42.1.4 is selected over 9.4.1208.jre7
[warn]         +- com.optrak:scala-sql_2.12:0.1-SNAPSHOT             (depends on 9.4.1208.jre7)
[warn]         +- net.postgis:postgis-jdbc:2.2.1                     (depends on 9.4.1208.jre7)
[warn] Run 'evicted' to see detailed eviction warnings
[info] Non-compiled module 'compiler-bridge_2.12' for Scala 2.12.4-bin-typelevel-4. Compiling...
[info]   Compilation completed in 7.941s.
[error] bad qualifier received: mkAttributedQualifier(<notype>, <none>)
[error] bad qualifier received: mkAttributedQualifier(<notype>, <none>)
[error] two errors found
[error] (erp-model/compile:compileIncremental) Compilation failed

No file, no line indicator, nothing. SBT just gives up.

However, in this boiled down case you do get sufficient info to identify the problem line.
Also in the real case the behaviour of what will and won't work is different (the Option version doesn't compile whereas here it does).

magnolia-json.zip

[joroKr21]

Maybe the issue is here: https://github.com/propensive/magnolia/blob/master/core/shared/src/main/scala/globalutil.scala#L74

[propensive]

Thanks for the report, @TimPigden! I'm still only connected to the Internet with my smartphone, but I will take a look soon. On the face of it, I have no idea what the issue is, but it looks like the sort of thing we might be able to get a handle on, and maybe hack a bit to make it work... but not necessarily easily.

[propensive]

@joroKr21 It looks like a good candidate! I'll try to take a look later today.

[TimPigden]

Hi Jon, good talking to you today. Here's the latest version which illustrates both the bug and the implicits I'd like to make both
magnolia-json.zip

[TimPigden]

I've found something else out which may be relevant. A different generic but the pattern is similar

class CompanyHash extends SpecValidated with LazyLogging {
  val hasher = hashBuilder[TestData]
  val hasherOpt = hashBuilder[TestDataOpt]
  "taggehed" should {
    "hash ok" in {

      val h1 = hasher.simplyHash(testData1)
      val h2 = hasher.simplyHash(testData2)
      val h1Again = hasher.simplyHash(testData1)

      // h1 !== h2
      h1 ==== h1Again
    }
  }

compiles whereas

class CompanyHash extends SpecValidated with LazyLogging {
  "taggehed" should {
    "hash ok" in {
  val hasher = hashBuilder[TestData]
  val hasherOpt = hashBuilder[TestDataOpt]

      val h1 = hasher.simplyHash(testData1)
      val h2 = hasher.simplyHash(testData2)
      val h1Again = hasher.simplyHash(testData1)

      // h1 !== h2
      h1 ==== h1Again
    }
  }

causes the compiler to blow up. Those shoulds/in are from specs2 btw.
So I don't know what the specs stuff does in turns of context or whatever, but it looks like the immediate context of the implicit is a factor

[propensive]

Thanks, @TimPigden! I promise I'll take a look as soon as I'm past the next extremely busy week. :)

[joroKr21]

Wow even old bugs can be fixed. Closing this one as duplicate of #165.
Keeping the newer ticket because it identifies where the problem is.