Fix appending a specified newline type to a multi-byte-encoded diff.

Review Request #11764 — Created July 31, 2021 and submitted

Information

DiffX
master

Reviewers

When writing a diff to a file section, we always ensure it ends in a
newline. There's some work that's done to ensure content and newlines
are in the right encoding and the BOM stripped, and this didn't work
quite right when working with a specified newline type, as opposed to
guessing a type.

The result was that, for multi-byte-encoded diffs, we could append a
newline with a BOM, breaking the content.

This logic has been cleaned up to ensure we always encode and strip BOMs
at the right time.

For additional reliability and performance, we also no longer split
content into lines unnecessarily. If we're not indenting, we just return
the content as-is instead of splitting into lines and writing them to a
stream first.

Unit tests pass on Python 2 and 3.

Summary ID
Fix appending a specified newline type to a multi-byte-encoded diff.
When writing a diff to a file section, we always ensure it ends in a newline. There's some work that's done to ensure content and newlines are in the right encoding and the BOM stripped, and this didn't work quite right when working with a specified newline type, as opposed to guessing a type. The result was that, for multi-byte-encoded diffs, we could append a newline with a BOM, breaking the content. This logic has been cleaned up to ensure we always encode and strip BOMs at the right time. For additional reliability and performance, we also no longer split content into lines unnecessarily. If we're not indenting, we just return the content as-is instead of splitting into lines and writing them to a stream first.
f4462b3b23783d4cac9abfb914d626825172761d
david
  1. Ship It!
  2. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to master (6246b15)
Loading...