Specifically to improve diagnostic/error messages - including the
filename in any error of an API that takes a file name (so not APIs that
take raw MemoryBuffers - don't uset the MemoryBuffer's identifier as the
name, because sometimes that's not adequate (such as for MemoryBuffer's
referring to files inside an archive) - and not for APIs taking a raw
file descriptor either).
This was spotted as a defficiency in llvm-jitlink which was complaining
about a missing file but not reporting which file.
Rather than patching that one case of a missing filename up in the
caller as most other callers do to workaround this, I figured I'd try
fixing this at a lower level - which involved plumbing Expected/Error
through those APIs to be able to carry the file name - and then fixing
up lots of callers and lots of test cases for slight differences in
syntax (mostly made diagnostic messages more consistent across tools
about quoting versus not quoting the filename, etc).
One or two cases got a bit worse - like llvm-symbolizer's yaml output,
now the diagnostic itself includes the filename, in addition to the file
yaml field. This could probably be improved/fixed by special-casing
FileError in the diagnostic printing to pull out/separate the file name
in the diagnostic.
Otherwise it's I think just a lot of cleanup.
Oh, it also included changing FileError's convertToErrorCode to look
down through it's nested ErrorInfo for error codes - this makes it
possible to use FileError when a caller is trying to check for a
specific file related error (such as 'file not found') which was being
done in a couple of places (& without this fix would've created a
strange tension where APIs wanting to support such callers would have to
use StringError or ECError instead of FileError, which seemed
counterintuitive/inelegant/difficult to deal with - in terms of then
trying to have consistent syntax/handling for file errors, and to
support the possibility of splitting out filenames as mentioned above
for the symbolizer output).
The Windows/Path.inc is entirely untested - will have to test it out on
buildbots, unless someone wants to give it a go before I submit.