Stick TASTy reading behind a -Ytasty-reader flag #9293
Conversation
src/compiler/scala/tools/nsc/symtab/classfile/ClassfileParser.scala
Outdated
Show resolved
Hide resolved
SethTisue
added
prio:blocker
dwijnand
force-pushed
the
tasty-reading-behind-a-flag
branch
from
8e65c3b
to
3743cad
Compare
| @@ -1114,6 +1116,8 @@ abstract class ClassfileParser(reader: ReusableInstance[ReusableDataReader]) { | |||
| case tpnme.ScalaATTR => | |||
| isScalaRaw = true | |||
| i = numAttrs | |||
| case tpnme.TASTYATTR if !YtastyReader => | |||
| MissingRequirementError.signal(s"Add -Ytasty-reader to scalac options to parse the TASTy in $file") | |||
There was a problem hiding this comment.
@dwijnand Why is it an error to unpickle a class file that has TASTY while running without -Ytasty-reader? How about silently skipping the attribute in this case?
There was a problem hiding this comment.
IIRC, the idea was to fail eagerly when people unknowingly end up with Scala 3 classfiles on their classpath.
Skipping the attribute would mean the compiler treats Scala 3 classfiles like Java classfiles, I cannot imagine this would lead to a usable behavior?
There was a problem hiding this comment.
Ah, thanks! So, there cannot be a scenario where there's regular Scala 2 metadata and TASTY?
There was a problem hiding this comment.
Also, how about the case where a Scala 3 classfile is on the class path but not referenced directly? It could be forced because you're referencing a Scala 2 symbol directly, which then depends on a symbol from a Scala 3 jar. In that case, you should be able to safely consume the Scala 2 classes without adding -Ytasty-reader, I think. (We're running into this error in the wild, but I have not yet figured out how exactly.)
There was a problem hiding this comment.
there cannot be a scenario where there's regular Scala 2 metadata and TASTY?
That's right, Scala 3 doesn't emit ScalaSignatures (Scala 2 pickles), Scala 2 doesn't emit TSATy.
Scala 2 symbol which depends on a symbol from a Scala 3 jar
That's a good point. I haven't tested it, but it seems anything that depends on a Scala 3 jar "pollutes" the entire classpath.
Generally, publishing a Scala 2.13 library that depends on a Scala 3 library is discouraged, see https://docs.scala-lang.org/scala3/guides/migration/compatibility-classpath.html#disclaimer-for-library-maintainers. But in controlled environments this could be OK.
There was a problem hiding this comment.
(The dependency in our case was pulled in by ammonite -- see cs resolve -t com.lihaoyi:ammonite-compiler-interface_2.13.6:2.4.0.)
There was a problem hiding this comment.
cc @lihaoyi
└─ com.lihaoyi:ammonite-compiler-interface_2.13.6:2.4.0
└─ com.lihaoyi:ammonite-cross-23-util_2.13:2.4.0
├─ com.lihaoyi:ammonite-cross-23-ops_2.13:2.4.0
│ ├─ com.lihaoyi:os-lib_2.13:0.7.2
│ │ └─ com.lihaoyi:geny_2.13:0.6.5
│ └─ org.scala-lang.modules:scala-collection-compat_2.13:2.4.1
│ └─ org.scala-lang:scala-library:2.13.4 -> 2.13.5
├─ com.lihaoyi:fansi_3:0.2.14
│ └─ com.lihaoyi:sourcecode_3:0.2.7
├─ com.lihaoyi:pprint_3:0.6.6
│ ├─ com.lihaoyi:fansi_3:0.2.14
│ │ └─ com.lihaoyi:sourcecode_3:0.2.7
│ └─ com.lihaoyi:sourcecode_3:0.2.7
└─ org.scala-lang:scala3-library_3:3.0.0
└─ org.scala-lang:scala-library:2.13.5
There was a problem hiding this comment.
@alexarchambault is probably the expert here. I think we recently resolved an issue around accidental Scala3 dependencies in Ammonite? com-lihaoyi/Ammonite#1215
There was a problem hiding this comment.
Thanks, looks like that should fix it! Would be great to get a release out with this fix. I've seen several places mention this crash while I was trying to figure out what was going on. (Sounds like the canonical issue is com-lihaoyi/Ammonite#1214)
There was a problem hiding this comment.
Yeah we probably should. @alexarchambault would you be able to tag a 2.4.1 release?
cc @bishabosha