16495-Wrong-source-for-CompiledBlocks-due-to-incorrect-bytecode-to-AST-nodes-mapping

[tesonep]

Fix #16495
When removing an undeclared variable we recompile the methods that are accessing through a message send.
It is a WIP. We need to refactor the code as it is quite ugly to have everything in #at:put:

[MarcusDenker]

Ah, nice.

One problem that it does not solve is that of methods on the stack: it will still read/write by message send, but when creating the mapping, it recompiles with the Undeclared now really there and create a wrong mapping.

I was thinking to solve this the following way:

• when compiling a method with undeclared vars, record the names in a method property
• add a compiler API to force compiling with reflective read/write for certain names
• when asking for the AST of a method that has fixed Undeclared reads that was not recompiled, ask the compiler to compile for these variables with a message to access

(this would require some more cleanup before)

I think this would be in addition to this fix and just fixe the case of methods that are not installed.

[tesonep]

Fixing the method in the stack is not trivial at all. We usually not do that, for example when we have a deprecation we are doing the same, just changing the method and leaving the old in the stack. The problem with the method in the stack is that will produce bad BC->ast mappings, but that is another story

[MarcusDenker]

Yes, exactly. I want to improve how we compile the AST by forcing Undeclared compilation for methods that are not repaired. This way the mapping will be in sync

[MarcusDenker]

For the Undeclared recompile there is another case that I completly overlooked before: How do we deal with removing a global (e.g. deleting a class)?

If the variable is still referenced, it will use the pushLiteral bytecode, no message send. But the Variable should now be an UndeclaredVariable, with access done by message send so we can raise the Exception.

We could recompile, but that might be slow.

At some point in the past we checked if a Class was still used after removing it (to cleanup the Undeclared)
And already that destoyed performance to a point that we stopped doing it.

Finding all using methods and recompiling might slow down class removal (e.g. unloading packages) quite a lot

[demarey]

This PR fixes a loading problem I had on Pharo12.

[MarcusDenker]

Great! Pablo mentioned that a good idea is to merge this PR as the next step. And we should backport it, too

[MarcusDenker]

I remove the WIP Staus from this