call deleteOnExit() after creating temporary scripting compile directory

[philwalk]

The current implementation doesn't clean up after a script compilation run, resulting over time in numerous debris directories.
Examples:

/tmp/scala3-scripting7373413734569065715
/tmp/scala3-scripting6548539148718234542
/tmp/scala3-scripting2225018551136019262
/tmp/scala3-scripting8793089142957194557
/tmp/scala3-scripting9160983434545311523
/tmp/scala3-scripting3659889510603809660
/tmp/scala3-scripting4315852469284034054
/tmp/scala3-scripting2148698146036257887

[anatoliykmetyuk]

There's already a logic to do the clenanup: https://github.com/lampepfl/dotty/pull/13171/files#diff-68611bd0d6544a94685e71ce89a42e5bcf06eef231c141cda5954d5345e05891R47.

In a PR improving the cleanup logic, we also need to address/remove the outdated logic.

Is there a good way to test this behavior?

[philwalk]

There's already a logic to do the clenanup:

I assume you're referring to the call to deleteFile() on line 47.

In a PR improving the cleanup logic, we also need to address/remove the outdated logic.

Manual testing shows that apparently each cleanup logic is needed in different environments.

Summary:

• Windows (including WSL Ubuntu): old logic is needed, although in case of compile errors, neither logic works
• Ubuntu: new logic required

Windows 10, running a script with compile errors, neither cleanup approach deletes temp files (perhaps the compiler still has files open?).

Windows 10, when attempting to run a valid script, with no compile errors:

• the old logic successfully deletes temporary files
• the new logic does not delete temporary files

On Linux quadd 5.4.0-73-generic #82~18.04.1-Ubuntu SMP Fri Apr 16 15:10:02 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux:

• the new logic successfully deletes temporary files
• the old logic does not delete temporary files

Is there a good way to test this behavior?

A problem with automated testing is that, on Windows, there's no guaranteed that temporary files are deleted.
Here's a discussion on stackoverflow