Compiler crash with a dash in a parameter of a lambda

[mrerrormessage]

I have run into a curious bug, which I have attempted to minimize in this github project. It occurs when using macros with a dashy identifier. The macros work fine when compiled with stock scala, but they error when compiled with scala-js. The exception begins:

java.lang.IllegalArgumentException: requirement failed: a-b is not a valid identifier
        at scala.Predef$.require(Predef.scala:219)
        at org.scalajs.core.ir.Trees$.requireValidIdent(Trees.scala:61)
        at org.scalajs.core.ir.Trees$Ident.<init>(Trees.scala:45)
        at org.scalajs.core.compiler.JSEncoding$class.freshLocalIdent(JSEncoding.scala:71)
        at org.scalajs.core.compiler.GenJSCode.freshLocalIdent(GenJSCode.scala:31)
        at org.scalajs.core.compiler.GenJSCode$JSCodePhase$$anonfun$78.apply(GenJSCode.scala:3864)
        at org.scalajs.core.compiler.GenJSCode$JSCodePhase$$anonfun$78.apply(GenJSCode.scala:3858)
        at scala.collection.TraversableLike$WithFilter$$anonfun$map$2.apply(TraversableLike.scala:728)
        at scala.collection.immutable.List.foreach(List.scala:381)
        at scala.collection.TraversableLike$WithFilter.map(TraversableLike.scala:727)

I would be happy to contribute if there's anything I can do to help fix the issue, but I'm not sure where to start.

[sjrd]

Thanks for the report. So I guess dashes are OK for the JVM, eh? Well, I guess we have to mangle them (to _ maybe).

You're welcome to work on a fix, but otherwise I'll take care of it. The place to go is in the stack trace: freshLocalIdent(JSEncoding.scala:71), i.e., here, which means fixing freshName to mangle dashes in base. It might be tricky to write an appropriate unit test, since we can't really have macros in our test suite. But you can try a quoted identifier like \a-b``.

The same issue likely also applies to class names and methods names.

[sjrd]

Well, it turns out that, according to the JVM, pretty much any character is valid (except [ and a couple others), which means that macros can probably get away with arbitrary names for about anything. So it seems that we have to re-encode every name that reaches our back-end.

[sjrd]

So, actually, that had nothing to do with any of that. We were simply inventing identifier based on arbitrary strings as found in the original names of symbols.

[mrerrormessage]

Thanks for the fix! looking forward to 0.6.5.