#10762: On Windows, out-of-codepage characters can cause GHC build to fail
---------------------------------+-----------------------------------------
Reporter: snoyberg | Owner: snoyberg
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler | Version: 7.10.2
Resolution: fixed | Keywords:
Operating System: Windows | Architecture: x86_64 (amd64)
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: #6037 | Differential Revisions:
---------------------------------+-----------------------------------------
Comment (by Ben Gamari ):
In [changeset:"1b56c40578374a15b4a2593895710c68b0e2a717/ghc"
1b56c405/ghc]:
{{{
#!CommitTicketReference repository="ghc"
revision="1b56c40578374a15b4a2593895710c68b0e2a717"
Respect GHC_CHARENC environment variable #10762
Only supports UTF-8 as a value right now. I expect some discussion to go
on around the naming of this variable and whether it's valid to backport
it to GHC 7.10 (which would be my preference). The motivation here is
that, when capturing the output of GHC to a file, we often want to
ensure that the output is UTF-8, regardless of the actual character
encoding of the terminal/console.
On the other hand, we don't want to necessary change the
terminal/console encoding. The reason being:
* On Windows, this requires a global-esque change to the console
codepage, which adversely affects other processes in the same console
* On all OSes, this can break features like smart quote auto-detection.
Test Plan:
Set LANG to C, GHC_CHARENC to UTF-8, and compile a Haskell source
file with a non-ASCII warning produced. The output who include the UTF-8
sequence instead of replacing it with ?.
Reviewers: austin, rwbarton, bgamari
Reviewed By: bgamari
Subscribers: hsyl20, thomie
Differential Revision: https://phabricator.haskell.org/D1167
GHC Trac Issues: #10762
}}}
--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10762#comment:16
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
