Fixes a surprising bug where a relative output file path would be interpreted relative to the directory of the `.gyb` file being processed rather than the current working directory upon invocation.
The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
In order to deal with encoding conversions for Python 2 and Python 3,
the string had to be passed through CStringIO for Python 2. On Python
3, the strings are unicode.
We would rely on the system encoding, which if unspecified would fall
back to `C` treating the encoding as ASCII. This fails with unicode
data in Python3. Thanks to @tbkka for the brilliant idea of forcing the
encoding when reading the file. This improves the test pass rate on
Linux with Python 3.
The file-like object's `write` method in Python 3 returns the number of
bytes that are written. This was not previously checked and is not
particularly interesting. Simply blackhole the bytes written, repairing
the test on Python 3.
This reverts most of commit 85599f7582b8809be889f589fe4d1d95e09ec945; it turns out the ‘b’ flag changes behavior more drastically in Python 3.
Fixes SR-12328, rdar://problem/60230415.
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.
A number of gyb tests (gyb --test) were failing on Windows. It appears it was
introduced by commit d57b41e which altered the behaviour of line
directives to print paths with forward-slashes even on Windows.
This commit changes two areas of gyb.py:
1. Doctests use normalized paths where applicable.
2. Path normalization is done early in ParseContext initialization
instead of when formatting line directives in ExecutionContext.append_text.
Fixes: SR-9644
Most people don't know what this is for and set it to "", robbing themselves of usability benefits. I'm going to add more help text to line-directive to explain that.
When building on Windows, the filepath contains `\` as the path
separator. Substitute `/` for the path separator prior to replacement.
This allows clang to properly compile the source file. Windows supports
both as a path separator and this matches what clang does by default for
the filepaths when preprocessing. This allows gyb generated files to
build on Windows.
This patch reworks the line-directive command line argument for gyb to
take in a python-style format string with `line` and `file` variables
to be substituted.
Because utils/gyb is just a launcher, `doctest.testmod()` without
explicit module doesn't perform doctest of `gyb` module.
It used to perform doctest of `util/gyb`, the `__main__` module.
From the Python documentation:
* NotImplemented: "Special value which can be returned by the 'rich comparison'
special methods (__eq__(), __lt__(), and friends), to indicate that the
comparison is not implemented with respect to the other type."
* NotImplementedError: "This exception is derived from RuntimeError. In user
defined base classes, abstract methods should raise this exception when they
require derived classes to override the method."
