Move all macro tests to macro test folders

[nicolasstucki]

We should only execute macro tests on the bootstrap compiler.

Also, removescala.quoted imports in tests that do not use it, such as inline tests.

[dwijnand]

We should only execute macro tests on the bootstrap compiler.

Why is that? Having to bootstrap the compiler just to understand and fix a macro bug seems like needless overhead.

[nicolasstucki]

Tests with macros can be problematic when re-bootstraping on a new minor version. In those situations, the TASTy generated in the Expr and Type of the standard library has a different TASTy version and will cause failures when unpickling.

Now, the tests that I moved happen not to be problematic, but they incite contributors to add macro tests in tests/run, tests/pos and tests/neg. These end up failing when we try to publish the new minor release and need to be moved to the proper folder. This has happened a few times in the past and the person that is doing the release usually does not know about those obscure details of macro tests.

[dwijnand]

This has happened a few times in the past and the person that is doing the release usually does not know about those obscure details of macro tests.

It doesn't sound like something that is outside the realm of things a "Scala release manager" should be ready to handle. Now, everything we can do to help that situation is great.

But let's try something that makes both things work. Can we not have these tests in a place, maybe even neg-macro/etc works, with a one-liner that you can comment out / comment in to affect if it's only run in bootstrapped or not. With the hope/ideal that the commented code would be discoverable when the bootstrap issue occurs.

[dwijnand]

.

[nicolasstucki]

A secondary reason to move these tests is to be able to tests all macro related tests using scala3-bootstrapped/testCompilation macros. I have lost some development time and CI time due to these tests only running when we run all tests. That does happen with more frequency, but mostly to me.

[nicolasstucki]

But let's try something that makes both things work. Can we not have these tests in a place, maybe even neg-macro/etc works, with a one-liner that you can comment out / comment in to affect if it's only run in bootstrapped or not. With the hope/ideal that the commented code would be discoverable when the bootstrap issue occurs.

I did not understand the idea. Could you elaborate?

[som-snytt]

Vulpix understands pragmas, e.g., // test: -bootstrapped. (hypothetical)

It would be nice for the framework to enforce macro tests reside in the desired dirs, too.

[dwijnand]

I did not understand the idea. Could you elaborate?

For example: move all the macro tests from BootstrappedOnlyCompilationTests to a MacroCompilationTests, have a commented out annotation of // @Category(Array(classOf[BootstrappedOnlyTests])), with details in a comment explaining how to comment it in if needed for rebootstrapping.

[nicolasstucki]

The point is that we should never tests macros on non bootstrapped compiler. Commenting out // @Category(Array(classOf[BootstrappedOnlyTests])) would be a step backwards.

I also remembered that there are other situations where the non-bootstrapped version of the compiler can lead into issues with macros. One of them is as simple as fixing or changing the behavior of a method in the stdlib. This one is much trickier for contributors to pinpoint.

[dwijnand]

The point is that we should never tests macros on non bootstrapped compiler. Commenting out // @Category(Array(classOf[BootstrappedOnlyTests])) would be a step backwards.

Why?

I also remembered that there are other situations where the non-bootstrapped version of the compiler can lead into issues with macros. One of them is as simple as fixing or changing the behavior of a method in the stdlib. This one is much trickier for contributors to pinpoint.

If my understanding is correct, the change is in how the scala3-compiler code is compiled that's different: with non-bootstrapped the file Tuple.scala, for example, is compiled with the reference compiler and that bytecode+tasty is present during non-boostrap test compilation.

It's annoying to deal and think about these subtleties, but it's also annoying to have a test feedback loop be ~twice as long. But you're at the frontier of that battle, so your preference should rule.