fix #29059, unnecessary warning in precompile for eval in __init__

[JeffBezanson]

Load-time eval into a different module is not allowed, since its results can't be tracked and saved. Init-time and run-time eval are allowed. __init__ methods are the only code expected to run during precompilation that are not "load time" code. So technically, the eval warning could be disabled at init-time. We don't have a good way to do that though, so instead I chose to set current_module to X while running X.__init__. That at least allows X to eval into itself, which is the most sensible case.

Incidentally, I believe this warning is the only remaining use for the current_module stuff. I'll make a separate PR to remove unnecessary setting/resetting of it.

I also made a slight change to the logic controlling when to run __init__ methods. Previously we did it (1) after loading a precompiled module, or (2) once we are back outside of any module. E.g. these modules:

module PackageA
using PackageB
println(PackageB.inited)
end

module PackageB
inited = false
__init__() = (global inited = true)
end

used to print true in precompiled mode, but false in --compiled-modules=no mode. The change makes it always print true, by considering any full package to be sufficiently "top level".

fixes #29059

[vtjnash]

No, this will allow code to run that is exactly the bad pattern it's designed to detect.

The current_module handling everywhere is supposed to go away with eventual deprecation cleanup (to be replaced with a scan through jl_module_init_order to implement this warning, and I think it will also drop some of the other try/catch functions that wrap eval)

[JeffBezanson]

this will allow code to run that is exactly the bad pattern it's designed to detect

Example?

to be replaced with a scan through jl_module_init_order

Is the idea to disallow eval into a module after it has had __init__ called?

[vtjnash]

The idea is to detect calls to eval for which we won't be able to handle the result. The jl_module_init_order does essentially contain that information (of which modules have had __init__ called), but I think that's more driven by common intent than definition.

[JeffBezanson]

The idea is to detect calls to eval for which we won't be able to handle the result.

Certainly, but we need a more practical definition than that --- for example there's nothing wrong with eval(mod, 2) but it's too complicated to try to specify why that's ok but other evals aren't.

Just to make sure we're on the same page, is the code in the original issue intended to be valid?

[vtjnash]

No, that’s specifically the example this is here to catch

Yes, there’s nothing wrong with that. We just make the observation that you don’t need eval for doing permitted actions, so while we could attempt to write a classifier (like we have for pure), it’s unnecessary.

[JeffBezanson]

Well clearly eval(:(b() = 1)) doesn't really need eval, but if it depended on, say, a random number or environment variable then it would be invalid?

[JeffBezanson]

Superseded by #29483