Avoid error in windows due to temp file being locked

[jneira]

• In the process to use hie-bios on ghc i hit a problem when the hie-bios script tried to write in %HIE_BIOS_OUTPUT$: the file was locked by the executable and the script could not write in it
  • As usual in posis systems the lock works in a way the process started by hie-bios can write
• Now the file es created but it is not opened until the process has used it. It is not deleted auto when it finishes but i thin kit is no a big problem, being a temporal file (but i could add a deleting)
• I've changed the handling of %HIE_BIOS_OUTPUT$` to honour the possible previous value set by the user: maybe it can be used if users pnly have permissions over concrete directories or they want to keep the compiler args in a file controled by them

[mpickering]

This will leak bios-output files into TMP. You need to clean up the temporary file after the cradle has finished running.

[jneira]

@mpickering done! it is clearner now

[mpickering]

This should be an error rather than returning empty string?

[jneira]

well, it seems there are test cases that actually dont write anything in the HIE_BIOS_OUTPUT (they failed before ad2a675 cause they dont even create the file to write in) so i assumed that it is a known-allowed case (see https://travis-ci.org/github/mpickering/hie-bios/jobs/683972142#L764 f.e.)
maybe is it the other way around and tests were wrong?

[jneira]

well it turns out that readProcessWithOutputFile is used to make calls (well only one of them actually does it) that are not related with the args and consume the stdout/stderr:

https://github.com/mpickering/hie-bios/blob/f0abff9c855ea7e6624617df669825f3f62f723b/src/HIE/Bios/Cradle.hs#L489-L490

so it seems it is fine in some cases (one?) to ignore the fact that the call has not written anything to HIE_BIOS_OUTPUT

[mpickering]

I would really rather not return empty string here as imagine this situation.

• User consults the cradle, the file doesn't exist for some unknown reason
• The cradle reports "" as the output
• ghcide starts a session with no options
• User sees error about import of module failing

Now to get from the first step to the last step is not trivial to realise unless you are familar with how all the parts work.

[jneira]

ok, i've removed the file existence check as you suggested so it will crash early

[jneira]

@mpickering @fendor i think it is done, thanks for the review and suggestions.
I tested the last version in my win 10 with the ghc config and it works: it uses the file pointed by HIE_BIOS_OUTPUT and a temp file (like before) if it is not

[mpickering]

Thanks LGTM. Over to you @fendor

[fendor]

Great thank you! Sorry it took me so long to review :/

[jneira]

Thanks!, only a correction to my previous comments for the shake of being precise: with the change from withSystemTempDirectory to withSystemTempFile the behaviour is the same as before the pr and the file is always created.
So the check for the existence of the file had no sense anymore (again like before the pr) and it is well removed.
However, the file can be empty and it would no trigger any error. I've checked it sending the output of hadrian/hie-bios.bat to nul and running hie-bios check ghc\Main.hs to see the temp file was created but compiler options are empty.
That is the reason that stack path call is succesful although it does not write anything to $HIE_BIOS_OUTPUT.