Replace the unsafe getmodtime with safe posix calls

[pepeiborra]

We don't need the 2X faster but unsafe getmodtime anymore since GetModificationTime is no longer called O(N) times but only O(FOI) times, where N is the number of known targets and FOI is the number of files of interest.

The main problem with the internal implementation of getModTime is that it's not cross platform. The unix package implements support for more platforms: https://github.com/haskell/unix/blob/master/System/Posix/Files/Common.hsc#L344-L365

This change switches to the safer unix implementation, which provides nanosecond resolution in systems that support it.

[ndmitchell]

Getting rid of custom unsafe code seems good. But given this is no longer a bottleneck, why not go the full way and use https://hackage.haskell.org/package/directory-1.3.6.1/docs/System-Directory.html#v:getModificationTime on both Windows and Linux? For editors which don't support subscriptions, I guess this code path will still be very hot - but are we assuming those editors are going to have a bad time anyway? And I guess it doesn't include Vim/Emacs/VS Code?

[pepeiborra]

Getting rid of custom unsafe code seems good. But given this is no longer a bottleneck, why not go the full way and use https://hackage.haskell.org/package/directory-1.3.6.1/docs/System-Directory.html#v:getModificationTime on both Windows and Linux? For editors which don't support subscriptions, I guess this code path will still be very hot - but are we assuming those editors are going to have a bad time anyway? And I guess it doesn't include Vim/Emacs/VS Code?

I want to fix the unsafe code but I don't want to give up all the performance, specially in large projects with thousands of files, given that we still read timestamps at least once for every file (or multiple times if the client doesn't support file watches) and multiple times for interface files.

But to be fair I haven't benchmarked - I have no idea if the cost of the conversions, one call to divMod, is that expensive.

[ndmitchell]

The code in Shake has been well tested and doesn't use any C - https://github.com/ndmitchell/shake/blob/master/src/Development/Shake/Internal/FileInfo.hs. Any reason we're not using that?

[pepeiborra]

The code in Shake has been well tested and doesn't use any C - https://github.com/ndmitchell/shake/blob/master/src/Development/Shake/Internal/FileInfo.hs. Any reason we're not using that?

It does use foreign import calls on the Windows path, and the Unix path is essentially the same as this PR with additional conversions that we don't need

[pepeiborra]

@ndmitchell do you have any other comments?