Fix TastyPrinter's JAR-walking logic to include subdirectories

[SolalPirelli]

Previously it only looked at tasty files at the root of the JAR. I'm not sure if anyone uses this code.

How much have you relied on LLM-based tools in this contribution?

not

How was the solution tested?

it wasn't

[mbovel]

Seems to make sense at first sight.

JarArchive extends PlainDirectory:

scala3/compiler/src/dotty/tools/io/JarArchive.scala

Line 13 in bf846df

class JarArchive private (val jarPath: Path, root: Directory) extends PlainDirectory(root) {

Which define iterator:

scala3/compiler/src/dotty/tools/io/PlainFile.scala

Line 17 in bf846df

override def iterator: Iterator[PlainFile] = givenPath.list.filter(_.exists).map(new PlainFile(_))

Which uses Directory.list:

scala3/compiler/src/dotty/tools/io/Directory.scala

Lines 49 to 58 in bf846df

	/** An iterator over the contents of this directory.
	*/
	def list: Iterator[Path] =
	if (isDirectory) {
	val fileStream = Files.list(jpath)
	val files = fileStream.toArray(size => new Array[JPath](size))
	fileStream.close()
	files.iterator.map(Path.apply)
	}
	else Iterator.empty

While allFileNames uses nio.file.Files.walk:

scala3/compiler/src/dotty/tools/io/JarArchive.scala

Lines 16 to 18 in bf846df

	def allFileNames(): Iterator[String] =
	java.nio.file.Files.walk(jpath).iterator().asScala.map(_.toString)

---

it wasn't

Could it?

[tgodzik]

I am having issue when backporting and I don't understand how can this work 🤔

Path(f) shouldn't correspond to the host filesystem instead of the jar file system?

Getting an exception on lts-3.3 because of this change:
Exception in thread "main" java.nio.file.NoSuchFileException: /App.tasty
at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:218)
at java.base/java.nio.file.Files.newByteChannel(Files.java:380)
at java.base/java.nio.file.Files.newByteChannel(Files.java:432)
at java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:422)
at java.base/java.nio.file.Files.newInputStream(Files.java:160)
at dotty.tools.io.File.inputStream(File.scala:53)
at dotty.tools.io.PlainFile.input(PlainFile.scala:70)
at dotty.tools.io.AbstractFile.toByteArray(AbstractFile.scala:172)
at dotty.tools.dotc.core.tasty.TastyPrinter$.main$$anonfun$1$$anonfun$3(TastyPrinter.scala:60)
at scala.runtime.function.JProcedure1.apply(JProcedure1.java:15)
at scala.runtime.function.JProcedure1.apply(JProcedure1.java:10)
at scala.collection.IterableOnceOps.foreach(IterableOnce.scala:630)
at scala.collection.IterableOnceOps.foreach$(IterableOnce.scala:628)

[SolalPirelli]

tbh this was one of the ostif bugs and when applying their recommended fix I wasn't sure if this code was even used anywhere.

But yeah you're right creating the file outside the jar doesn't make all that much sense.

What test/command are you running to trigger this?

[tgodzik]

Not sure, it's failing on CI https://github.com/scala/scala3-lts/actions/runs/25926858931/job/76210327085?pr=905

I think it's some of the scripted tests

[tgodzik]

it might be removed in main, which would explain why it's not triggered.

[tgodzik]

project/scripts/bootstrappedOnlyCmdTests is probably what fails

[tgodzik]

Checking an alternative fix in scala@0835a90

[SolalPirelli]

yeah that alternative seems more reasonable. I'll look into why this didn't cause trouble in main.

[tgodzik]

I can make that fix in the main as well, what do you think? OR do you want to handle it?

[SolalPirelli]

I'll handle it in #26082 along with whatever else might be needed to make those tests pass. Sorry for the bother.

[tgodzik]

no worries, thanks for the help!