Illegal inline errors in code compiled with `-Yexplicit-nulls` depending on artifacts without that option

[jchyb]

Compiler version

3.8.0-RC1-bin-20250818-aaa39c5-NIGHTLY

Minimized code

minim1.scala:

// without Yexplicit-nulls
extension (inline x: AnyRef | Null)
  inline infix def customNe(inline y: AnyRef | Null): Boolean =
    !(x eq y)

minim.test.scala:

//> using options -Yexplicit-nulls

def Test =
  val bucket: Null = ???
  if (bucket customNe null) then
    println("not null")

scala-cli minim1.scala minim2.test.scala -S 3.8.0-RC1-bin-20250818-aaa39c5-NIGHTLY --test

Output

[error] ./minim2.test.scala:5:7
[error] expression does not take parameters
[error]   if (bucket customNe null) then
[error]       ^^^^^^^^^^^^^^^^^^^^

Expectation

No error or error thrown at the typer phase

[hamzaremmal]

No error or error thrown at the typer phase

I don't see how you could catch this at the typer level. This is just the typing breaking when inlining across explicit null vs non-explicit null. This is not a new issue but I haven't thought about it enough to really conclude that there is nothing to do here. Brining @olhotak @noti0na1 and @HarrisL2 to the discussion.

[hamzaremmal]

scala-cli minim1.scala minim2.test.scala -S 3.8.0-RC1-bin-20250818-aaa39c5-NIGHTLY --test

I'm very surprised that we can run configure directives for .test.scala and .scala files independently and compile them both with the same command...

[jchyb]

It's a cool trick to get fake multi-module support out of scala-cli. Although once I am working with a compiler I usually just do:

> scalac minim1.scala -d .
> scalac minim2.test.scala -cp /Users/jchyb/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.16/scala-library-2.13.16.jar:/Users/jchyb/workspace/scala3/library/../out/bootstrap/scala3-library-bootstrapped/scala-3.8.0-RC1-bin-SNAPSHOT-nonbootstrapped/scala3-library_3-3.8.0-RC1-bin-SNAPSHOT.jar:. -Yexplicit-nulls 

and ignore the warnings.

I've investigated a bit and by the time we get to the typedApply in the Inliner the eq part of the tree points to an empty symbol, so there is definitely something wrong there. I suspect it's just some detail we are missing and I don't mind looking for it some more.

In general that custom typing Inliner logic should break like this, unless there is a misconfigured macro involved, because that means that the inline errors are mistyped and yet could have been pickled/compiled successfully.