diff options
| author | KJ Tsanaktsidis <kj@kjtsanaktsidis.id.au> | 2023-12-28 16:08:54 +1100 |
|---|---|---|
| committer | KJ Tsanaktsidis <kj@kjtsanaktsidis.id.au> | 2024-01-10 21:02:23 +1100 |
| commit | 31371b2e24b03ccb0a03b622faf8c65e6cf6a31a (patch) | |
| tree | e419cf38ee171aaf893dd45dcc80ebff5e051cd5 /include | |
| parent | c4051d5f4324536a932e99cbe43f5b7dbe34254a (diff) | |
Fix CRLF -> LF conversion on read for rb_io_fdopen & rb_file_open
When opening a file with `File.open`, and then setting the encoding with
`IO#set_encoding`, it still correctly performs CRLF -> LF conversion on
Windows when reading files with a CRLF line ending in them (in text
mode).
However, the file is opened instead with either the `rb_io_fdopen` or
`rb_file_open` APIs from C, the CRLF conversion is _NOT_ set up
correctly; it works if the encoding is not specified, but if
`IO#set_encoding` is called, the conversion stops happening. This seems
to be because the encflags never get ECONV_DEFAULT_NEWLINE_DECORATOR
set in these codepaths.
Concretely, this means that the conversion doesn't happen in the
following circumstances:
* When loading ruby files with require (that calls rb_io_fdopen)
* When parsing ruuby files with RubyVM::AbstractSyntaxTree (that calls
rb_file_open).
This then causes the ErrorHighlight tests to fail on windows if git has
checked them out with CRLF line endings - the error messages it's
testing wind up with literal \r\n sequences in them because the iseq
text from the parser contains un-newline-converted strings.
This commit fixes the problem by copy-pasting the relevant snippet which
sets this up in `rb_io_extract_modeenc` (for the File.open path) into
the relevant codepaths for `rb_io_fdopen` and `rb_file_open`.
[Bug #20101]
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions
