diff options
author | Ryan Scott <ryan.gl.scott@gmail.com> | 2018-08-27 14:02:49 +0200 |
---|---|---|
committer | Krzysztof Gogolewski <krz.gogolewski@gmail.com> | 2018-08-27 14:03:34 +0200 |
commit | 7a3cda534d1447c813aa37cdd86e20b8d782cb02 (patch) | |
tree | 7f266adf199eb3c26a387bdd20357699c49dbe13 /compiler/basicTypes/BasicTypes.hs | |
parent | 5e6cf2a9301a5473ff9c5319b96de941b1ad72dd (diff) | |
download | haskell-7a3cda534d1447c813aa37cdd86e20b8d782cb02.tar.gz |
Fix #15502 by not casting to Int during TH conversion
Summary:
When turning an `IntegerL` to an `IntegralLit` during TH
conversion, we were stupidly casting an `Integer` to an `Int` in
order to determine how it should be pretty-printed. Unsurprisingly,
this causes problems when the `Integer` doesn't lie within the bounds
of an `Int`, as demonstrated in #15502.
The fix is simple: don't cast to an `Int`.
Test Plan: make test TEST=T15502
Reviewers: bgamari, simonpj
Reviewed By: simonpj
Subscribers: simonpj, rwbarton, carter
GHC Trac Issues: #15502
Differential Revision: https://phabricator.haskell.org/D5089
Diffstat (limited to 'compiler/basicTypes/BasicTypes.hs')
-rw-r--r-- | compiler/basicTypes/BasicTypes.hs | 14 |
1 files changed, 12 insertions, 2 deletions
diff --git a/compiler/basicTypes/BasicTypes.hs b/compiler/basicTypes/BasicTypes.hs index 93010b75f9..ce4696293c 100644 --- a/compiler/basicTypes/BasicTypes.hs +++ b/compiler/basicTypes/BasicTypes.hs @@ -1436,9 +1436,12 @@ data IntegralLit deriving (Data, Show) mkIntegralLit :: Integral a => a -> IntegralLit -mkIntegralLit i = IL { il_text = SourceText (show (fromIntegral i :: Int)) +mkIntegralLit i = IL { il_text = SourceText (show i_integer) , il_neg = i < 0 - , il_value = toInteger i } + , il_value = i_integer } + where + i_integer :: Integer + i_integer = toInteger i negateIntegralLit :: IntegralLit -> IntegralLit negateIntegralLit (IL text neg value) @@ -1463,6 +1466,13 @@ data FractionalLit mkFractionalLit :: Real a => a -> FractionalLit mkFractionalLit r = FL { fl_text = SourceText (show (realToFrac r::Double)) + -- Converting to a Double here may technically lose + -- precision (see #15502). We could alternatively + -- convert to a Rational for the most accuracy, but + -- it would cause Floats and Doubles to be displayed + -- strangely, so we opt not to do this. (In contrast + -- to mkIntegralLit, where we always convert to an + -- Integer for the highest accuracy.) , fl_neg = r < 0 , fl_value = toRational r } |