Crystal: Running multiple macro runs doesn't work

[asterite]

# foo.cr
{% run "./bar" %}
{% run "./baz" %}
{% run "./bar" %}

# bar.cr
puts %(puts "hello")

# baz.cr
puts %(puts "bye")

Running crystal foo.cr results in:

--: /Users/asterite-manas/.cache/crystal/crystal-run-macro-run-_Users_asterite-manas_Projects_crystal_bar.cr.tmp: No such file or directory
Error in ./foo.cr:3: expanding macro

{% run "./bar" %}
^

in ./foo.cr:3: Error executing run: ./bar 

Got:

{% run "./bar" %}
   ^~~

The problem is that in 0.16.0 we changed the way .crystal works, and as part of its cleanup I decided to remove temporary files inside that directory. Temporary files are ones that result from old crystal file.cr. When a macro run is executed, it compiles that file and then executes it. It relies on the temporary executable to be there for next invocations, so that the file pointed by the macro run doesn't need to be compiled over and over. The problem is that a second macro run with a different file erases the previous temporary executable.

I'll fix this and release 0.17.3, as I think it affects a bunch of projects. At least slang and frost. I'll also include a bunch of fixes I put in that branch, together with this, so in 0.18.0 we can have correct Tuple.new and NamedTuple.new :-)

I still don't know what should the fix be. We could leave temporary files there forever, but that's not good. Maybe a better one is to delete all temporary files that a main compilation uses: the temporary file that results from the main compilation, if any, and temporary files from macro runs.

[ozra]

Storage is cheap, better to let the standard cache-cleaning mechanism do work and be configurable (only so and so much allowed in "~/.cache/crystal/" before wiping oldest).
Re-compiling could be further sped up if macros are unchanged and the compilation process is further optimized to reduce work by identifying as early as possible when there are no changes to a prog/unit/etc...
Perhaps even at the stage of evaluating run...

[jhass]

Can we perhaps somehow scope the target filename into the cache subdirectory for the current compilation?