Notice
This bug seems to be specific to Scala v2.13.7. After writing most of this report, I tested with Scala v2.13.12 and v2.13.14 and I couldn't reproduce this issue in those versions.
That being the case, this report is mostly for your information (i.e. very low priority). Feel free to close this as irrelevant if it's of no use to you.
Bug Description
Whenever I include this import statement: import smile.data.type.StructType in my code, Scala compiler crashes. ("type" looks like that because it's a Scala keyword and is surrounded by backticks in the code, messing up the markdown)
All other imports resolve correctly.
This also occurs if I import smile.data.type._ and then refer to StructType in my code. I can refer to other types, such as StructField just fine.
Expected behavior
I expected the compiler to build the project / file normally.
Actual behavior
Scala compiler crashes with the following message (slightly abbreviated):
scala: ## Exception when compiling 2 sources to /home/...
scala.reflect.internal.FatalError:
bad constant pool index: 0 at pos: 8966
while compiling: /home/.../test/ImportStuctTypeTest.scala
during phase: globalPhase=typer, enteringPhase=namer
library version: version 2.13.7
compiler version: version 2.13.7
...
last tree to typer: Ident(smile)
tree position: line 5 of /home/...test/ImportStuctTypeTest.scala
tree tpe: smile.type
symbol: final package smile
symbol definition: final package smile (a ModuleSymbol)
symbol package: <none>
symbol owners: package smile
call site: object ImportStuctTypeTest in package test in package test
== Source file context for tree position ==
2
3 object ImportStuctTypeTest
4 {
5 import smile.data.`type`.StructType
6 }
7
All I needed to reproduce this issue was this piece of code. No additional imports are needed.
Input data
No data is needed to reproduce this issue
Additional context
Used Java version: 1.8.0_402
Java provider: OpenJDK
Scala version: 2.13.7
Smile version: 3.1.1
At Maven: github.haifengl.smile.scala_2.13
IDE: IntelliJ IDEA Community Edition 2024.1.4
Java compiler: Javac
I'm using IDEA's internal scala compiler
OS: Ubuntu 22.04.4 LTS
Yes, I do have StructType in my class path. The IDE recognizes the class and its source code as if there was nothing wrong. References to other class files within the same jar build fine. Also, as mentioned above, the same code & setup builds fine after changing the Scala version used.
Thanks for report. It is probably some issue with scala back compatibility. We suggest using latest scala versions as we do so to compile smile-scala package.
Notice This bug seems to be specific to Scala v2.13.7. After writing most of this report, I tested with Scala v2.13.12 and v2.13.14 and I couldn't reproduce this issue in those versions.
That being the case, this report is mostly for your information (i.e. very low priority). Feel free to close this as irrelevant if it's of no use to you.
Bug Description Whenever I include this import statement:
import smile.data.
type.StructType
in my code, Scala compiler crashes. ("type" looks like that because it's a Scala keyword and is surrounded by backticks in the code, messing up the markdown)All other imports resolve correctly.
This also occurs if I import smile.data.
type
._ and then refer to StructType in my code. I can refer to other types, such as StructField just fine.Expected behavior I expected the compiler to build the project / file normally.
Actual behavior Scala compiler crashes with the following message (slightly abbreviated):
Code snippet
All I needed to reproduce this issue was this piece of code. No additional imports are needed.
Input data No data is needed to reproduce this issue
Additional context Used Java version: 1.8.0_402 Java provider: OpenJDK Scala version: 2.13.7 Smile version: 3.1.1 At Maven: github.haifengl.smile.scala_2.13 IDE: IntelliJ IDEA Community Edition 2024.1.4 Java compiler: Javac I'm using IDEA's internal scala compiler OS: Ubuntu 22.04.4 LTS
Yes, I do have StructType in my class path. The IDE recognizes the class and its source code as if there was nothing wrong. References to other class files within the same jar build fine. Also, as mentioned above, the same code & setup builds fine after changing the Scala version used.