You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was a bit surprised to learn that running through both launch configurations and code lens may be running code that was compiled after the run was kicked off.
run with the code lens on Main. Terminal should open with waiting until enter..., but don't hit enter yet!
modify def four = 4 to def four = 5
now hit enter in the terminal
see Helper.four = 5 in the terminal output
Same occurs with a launch config, though passing "jvmOptions": ["-verbose:class"], there makes the problem apparent. Here's the terminal output (repeating above steps but with step 2 being "Run > Run Without Debugging"):
...
[0.158s][info][class,load] java.nio.CharBuffer source: shared objects file
[0.158s][info][class,load] java.nio.HeapCharBuffer source: shared objects file
[0.158s][info][class,load] java.nio.charset.CoderResult source: shared objects file
waiting until enter...
[6.227s][info][class,load] example.Helper$ source: file:/Users/alec/Scratch/metals-testing/base-package/.bloop/root/bloop-bsp-clients-classes/classes-Metals-S8GNEqpeT32D6dPwHfD0QQ==/
Helper.four = 5
[6.228s][info][class,load] scala.runtime.BoxedUnit source: file:/Users/alec/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.12.17/scala-library-2.12.17.jar
[6.228s][info][class,load] java.util.IdentityHashMap$IdentityHashMapIterator source: shared objects file
[6.228s][info][class,load] java.util.IdentityHashMap$KeyIterator source: shared objects file
[6.228s][info][class,load] java.lang.Shutdown source: shared objects file
[6.228s][info][class,load] java.lang.Shutdown$Lock source: shared objects file
* Terminal will be reused by tasks, press any key to close it.
Helper doesn't get loaded in until after we hit enter, and it is loaded straight from where bloop compiled it.
Expected behavior
I'd expect that running takes a defensive copy or the classfiles being run (or at least there's a setting to recover that behavior) at the time that I click the code lens or launch the run config.
Operating system
macOS
Editor/Extension
VS Code
Version of Metals
v1.4.2
Extra context or search terms
No response
The text was updated successfully, but these errors were encountered:
tgodzik
changed the title
Running code doesn't take defensive copy of the compiled output
Running code should take defensive copy of the compiled output
Jan 20, 2025
Describe the bug
I was a bit surprised to learn that running through both launch configurations and code lens may be running code that was compiled after the run was kicked off.
Repro
Take this code:
Main
. Terminal should open withwaiting until enter...
, but don't hit enter yet!def four = 4
todef four = 5
Helper.four = 5
in the terminal outputSame occurs with a launch config, though passing
"jvmOptions": ["-verbose:class"],
there makes the problem apparent. Here's the terminal output (repeating above steps but with step 2 being "Run > Run Without Debugging"):Helper
doesn't get loaded in until after we hit enter, and it is loaded straight from where bloop compiled it.Expected behavior
I'd expect that running takes a defensive copy or the classfiles being run (or at least there's a setting to recover that behavior) at the time that I click the code lens or launch the run config.
Operating system
macOS
Editor/Extension
VS Code
Version of Metals
v1.4.2
Extra context or search terms
No response
The text was updated successfully, but these errors were encountered: