When doing an unified build (Swift being an external project of LLVM),
the Swift build is at `<llvm build dir>/tools/swift`, and that is the
value of `swift_obj_root`. However many products are actually placed in
`<llvm build dir>`, like `bin/`, `include/` and things like
`lib/swift/...` and others.
A couple of macros tests check the error messages printed by the
compiler against `swift_obj_root` (by the replacement done in
`PathSanitizingFileCheck` of `BUILD_DIR`) when it should have been
checking them against the top-level build directory, which will work in
both unified and non-unified builds (like `build-script` builds).
Convert the line endings manually since the parser is sensitive to the
trailing whitespace (the writing of the file will create a `\r\n` rather
than `\n`). This largely fixes the issues for Windows with the issue
that the processing of the file location is currently not properly
processing escape characters and results in issues.
In theory, it should be possible for `getStringLiteralIfNotInterpolated`
to process the literal segments with `getEncodedStringSegment` for each
segment and then return a literal value cooked. However, doing so will
require that the function return a `std::string` rather than `StringRef`
since the cooking means that we cannot simply provide a reference to the
SourceManager view.
GYB opens its inputs and outputs in text mode. This is a problem because the recommendation in Windows is to check everything out in LF mode to avoid breaking tests, so gybbing a file ends up converting LFs to CRLFs. That broke test/SILGen/magic_identifier_file_conflicting.swift.gyb.
Modify GYB to open its files in binary mode instead of text mode. This is a no-op everywhere but Windows.
Note that this change is incomplete: it’s somewhat difficult to switch stdin and stdout to binary mode in Python 2. I’ve added FIXME comments about this.
