Testsuite: do not depend on sys.stdout.encoding

Authored by thomie on Jun 29 2016, 3:56 PM.

Description

Testsuite: do not depend on sys.stdout.encoding

The cause of Trac #12213 is in dump_stdout and dump_stderr:

print(read_no_crs(<filename>))

Commit 6f6f515401a29d26eaa5daae308b8e700abd4c04 changed read_no_crs to
return a unicode string. Printing a unicode strings works fine as long
as sys.stdout.encoding is 'UTF-8'.

There are two reasons why sys.stdout.encoding might not be 'UTF-8'.

  • When output is going to a file, sys.stdout and sys.stdout do not respect the locale:

    $ LC_ALL=en_US.utf8 python -c 'import sys; print(sys.stderr.encoding)' UTF-8 $ LC_ALL=en_US.utf8 python -c 'import sys; print(sys.stderr.encoding)' 2>/dev/null None
  • When output is going to the terminal, explicitly reopening sys.stdout has the side-effect of changing sys.stdout.encoding from 'UTF-8' to 'None'.

    sys.stdout = os.fdopen(sys.__stdout__.fileno(), "w", 0)

    We currently do this to set a buffersize of 0 (the actual buffersize used is irrelevant for the sys.stdout.encoding problem).

Solution: fix dump_stdout and dump_stderr to not use read_no_crs.

Details

Committed
thomieJun 30 2016, 3:43 AM
Parents
rGHC24194a6aed95: Fix pretty-printer for IfaceCo
Branches
Unknown
Tags
Unknown
Build Status
Buildable 10299
Build 12345: [GHC] Linux/amd64: Continuous Integration