Skip to content

Tests with explicit nulls are broken on main branch #22988

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
noti0na1 opened this issue Apr 12, 2025 · 5 comments · Fixed by #22992
Closed

Tests with explicit nulls are broken on main branch #22988

noti0na1 opened this issue Apr 12, 2025 · 5 comments · Fixed by #22992
Labels
itype:bug itype:crash stat:needs triage Every issue needs to have an "area" and "itype" label

Comments

@noti0na1
Copy link
Member

It seems the CI is failing on main branch because of the PR #22473.

The errors only happen in "Test Suite with the CC Standard Library". Maybe related to cc library compiled in explicit nulls?

One of the failed tests is a debug test introduced by #22597, but the error message does not give much information...

Error:  Debug step failed: tests/debug-custom-args/eval-explicit-nulls.check:3
Evaluation failed:
-- [E170] Type Error: <expression class>:12:28 -------------------------------------------------------------------------
12 |    if idx == -1 then throw new NoSuchElementException(name)
   |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |                            NoSuchElementException is not a class type
   |
   | longer explanation available when compiling with `-explain`-- [E170] Type Error: <expression class>:18:28 -------------------------------------------------------------------------
18 |    if idx == -1 then throw new NoSuchElementException(name)
   |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |                            NoSuchElementException is not a class type
   |
   | longer explanation available when compiling with `-explain`
Error:  Test dotty.tools.debug.DebugTests.debug failed: java.lang.AssertionError: Debug test failed, but should not, reasons:
Error:  encountered 1 test failure(s):
Error:    - generic failure (see test output), took 74.963 sec
Error:      at dotty.tools.vulpix.ParallelTesting$CompilationTest.checkPass(ParallelTesting.scala:1269)
Error:      at dotty.tools.debug.DebugTests$.dotty$tools$debug$DebugTests$$$checkDebug(DebugTests.scala:45)
Error:      at dotty.tools.debug.DebugTests.debug(DebugTests.scala:23)
Error:      at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Error:      at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
Error:      at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Error:      at java.lang.reflect.Method.invoke(Method.java:569)
Error:      ...

cc @HarrisL2 @olhotak

@noti0na1 noti0na1 added itype:bug itype:crash stat:needs triage Every issue needs to have an "area" and "itype" label labels Apr 12, 2025
@olhotak
Copy link
Contributor

olhotak commented Apr 12, 2025

Have you found a way to reproduce it in sbt? I haven't yet.

I would guess it's probably some interaction between CC, which wraps types in Tasty inside AnnotatedType, and #22473, which wraps types coming from Tasty in a FlexibleType. Maybe the two wrappers are interfering and the check for a class type can't see through both of them.

But first I need to be able to reproduce it outside of the CI.

@olhotak
Copy link
Contributor

olhotak commented Apr 12, 2025

But I see that this is only one of many errors.

We should revert #22473, figure out how to run these tests outside of CI, and then debug it offline before merging it again.

@olhotak
Copy link
Contributor

olhotak commented Apr 12, 2025

The following sbt commands reproduce this:

set ThisBuild/Build.scala2Library := Build.Scala2LibraryCCTasty
scala3-bootstrapped/testCompilation

@olhotak
Copy link
Contributor

olhotak commented Apr 12, 2025

For the specific test mentioned above, it's:

set ThisBuild/Build.scala2Library := Build.Scala2LibraryCCTasty
scala3-bootstrapped/testOnly * -- *debug

@olhotak
Copy link
Contributor

olhotak commented Apr 14, 2025

It seems the problems are unrelated to CC. The same errors come up with

set ThisBuild/Build.scala2Library := Build.Scala2LibraryTasty

So just having the standard library coming from Tasty is enough to cause the errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
itype:bug itype:crash stat:needs triage Every issue needs to have an "area" and "itype" label
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants