separate module context for Compiler.jl tests

[aviatesk]

xref: #56632 (review)

This also allows us to execute each file standalone, which might be useful for debugging.

[KristofferC]

Also need an InteractiveUtils.@activate in every file? And maybe that shouldn't double run on the same worker (in case the tests are executed in parallel in the future).

[aviatesk]

When these files are run from test/runtests.jl, we usually want to test Base.Compiler, and in that case, we shouldn't call @activate Compiler. I think the current situation is just fine, where we only have @activate Compiler in Compiler/test/runtests.jl, which is an entry point to test Compiler.jl as the standard library.

[KristofferC]

where we only have @activate Compiler in Compiler/test/runtests.jl, which is an entry point to test Compiler.jl as the standard library.

Okay but in the future, we will likely run these tests in parallel on different workers and each of these workers needs to run the @activate command (I presume).
So that's why I was thinking something like

julia/test/combinatorics.jl

Line 5 in 0ded536

isdefined(Main, :ImmutableArrays) || @eval Main include("testhelpers/ImmutableArrays.jl")

would be needed in all files because we do not know what files will run on what worker and in what order they will run.

But could be a later thing to add.

[aviatesk]

Yes, it’s probably related to parallel execution, so it might be a good idea to revisit this discussion in a PR that enables parallel execution for Compiler.jl/test/runtests.jl.

[Keno]

I'm ok with the setup_compiler change. For the module wrapping though, the Base test infrastructure does that internally, so I'm not sure it will be required once we switch to that (which we need to for parallel execution).