Guillaume Martres

It'd be interesting to run async-profiler or jfr on the running compiler to try to see if there's an obvious culprit

The CLA check is failing, would you mind signing the CLA at https://www.lightbend.com/contribute/cla/scala ?

> I'm not sure why we end up creating proxies for the top-level object NamedTuple here Ah I guess it's to deal with the combination of inline and opaque types

So it seems the inliner tries to deal with opaqueness by essentially taking the intersection of the original type and the type you get after replacing all the opaque types...

Actually this isn't specific to lower-bounds, we can minimize this to: ```scala object Foo: opaque type Wrapper[T] = T inline def part[T](w: Wrapper[T]): T = w inline def part2[T](w: Wrapper[T]):...

For the minimized example, we can work around the issue by adding a seemingly useless cast: ```scala inline def part[T](w: Wrapper[T]): T = w inline def part2[T](w: Wrapper[T]): T =...

Tentative fix: https://github.com/scala/scala3/pull/20457

`module-info.class` is a magic JPMS thing generated from the also magic `module-info.java` that doesn't behave like a regular classfile. We should not even try to load it because `-` is...

It has to do with how classpaths are setup but I don't know where the difference comes from. Running with `-Ylog-classpath` might give more information.

> @smarter can you reproduce it on your machine? Yes.