Handling of ASCII encodings introduced in D898 breaks Unicode terminal detection

D898 was primarily intended to fix hangs in the event that iconv was unavailable (namely #10298 (closed) and #7695 (closed)). In addition to this fix, it also introduced self-contained handling of ANSI terminals to allow compiled executables to run in minimal environments lacking iconv.

However, the behavior that the patch introduced is highly suspicious. Specifically, it gives the user a UTF-8 encoding even if they requested ASCII.

This has the potential to break quite a lot of code. At very least it breaks GHC's Unicode terminal detection logic, which attempts to catch an invalid character when encoding a pair of smart-quotes. Of course, this exception will never be thrown if a UTF-8 encoder is used.

changed weight to 5

added Tbug Trac import labels

changed the description

mentioned in commit d69dfba4

closed

A version of this is also present in the ghc-7.10 branch as 677552f2.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

reopened

changed milestone to %7.10.2

changed weight to 7

I realized that at least hsyl20 and perhaps others actually intend to run their programs in the (what I would consider to be broken) setting of a chroot without a working iconv installation. In that case we really shouldn't use char8 when asked for an ASCII locale. If the programmer wants char8 they can use it explicitly. I implemented an ASCII encoding in D1085.

Trac metadata

Trac field	Value
Priority	normal → high
Resolution	ResolvedFixed → Unresolved
Differential revisions	→ D1059, D1085

mentioned in commit dbe6dac9

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

mentioned in commit 89060374

reopened

The test encoding005 is failing on Windows with an unknown ASCII encoding error.

Trac metadata

Trac field	Value
Resolution	ResolvedFixed → Unresolved
Operating system	Unknown/Multiple → Windows

changed milestone to %7.10.3

Moving out to 7.10.3, as it seems there was a regression (maybe a new ticket is needed?)

It's not a regression, just a new test (I added it in dbe6dac9). The test uses mkTextEncoding "ASCII" which clearly (if you read GHC.IO.Encoding.mkTextEncoding') won't work on Windows. It didn't work in the past either except between e28462de and d69dfba4.

Should we make it work, i.e., handle encodings in our hard-coded list as ASCII on Windows too? Personally I don't see why not.

changed milestone to %8.0.1

The issue mentioned in ticket:10623#comment:106837 is still outstanding. Punting to 8.0.1.

changed weight to 5

Trac metadata

Trac field	Value
Priority	high → normal
Component	Compiler → Test Suite

added testsuite label

changed milestone to %8.0.2

Punting to 8.0.2, since this just affects the testsuite.

I have another patch for this series.

Trac metadata

Trac field	Value
Differential revisions	D1059, D1085 → D1059, D1085, D2262

mentioned in commit 1319363f

closed

changed milestone to %8.2.1

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed
Test case	T8958a → T8958a, libraries/base/tests/IO/encoding005

added Pnormal label