Compiler outputs

[chsienki]

Closes https://github.com/dotnet/roslyn/issues/48649

This repurposes the touched file logger so that we can correctly record which files were emitted to disk by the compiler. An msbuild task then reads the file back and adds them to file wites so that they are correctly tracked.

[chsienki]

@dotnet/roslyn-compiler and specifically @jaredpar for an initial look over of this approach.

I updated the touched file logger to not print everything uppercase, so it works on non-windows platforms, and also allow a relative path.

It works already, but not sure a) how to go about writing tests for it, and b) if we're ok changing the touched file logger. We could alternatively add a new compiler switch just for this purpose, and build on top the of the logger with a second 'write written files call' that puts them to the new location in disk case. I looked around and couldn't find any usages of the touched file logger, so fairly confident we're ok to re-purpose it, but happy to err on the side of caution too.

[chsienki]

Ping @jaredpar

[jaredpar]

The one thing that bothers me a bit about this approach is it's a thing we need to remember. Essentially any future I/O we need to make sure we go through TouchedFileLogger to ensure it's correct. That will work but it will also leave gaps (as I'm sure gaps exist today because it's something we never really productized).

I wonder if we should lean into #57941 here. Essentially unify all of our file system abstractions around one interface. One implementation would be backed by the real System.IO.File APIs. Outside that we use the banned API analyzer to remove System.IO.File from the code base. Then we could be very confident in the implementation of TouchedFileLogger because it could just plug into our file system abstraction. Every call would go through it, the call could be logged, and then it would forward on to the real implementation