- ghc-tickets - Haskell.org

[GHC] #15505: Assertion failure in test T7224
by GHC 21 Aug '18

21 Aug '18

#15505: Assertion failure in test T7224 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To reproduce, build GHC HEAD with slow validate settings, then run test `T7224`. Output: {{{ =====> T7224(normal) 9 of 15 [0, 2, 0] cd "polykinds/T7224.run" && "/home/omer/haskell/ghc/inplace/test spaces /ghc-stage2" -c T7224.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output Actual stderr output differs from expected: diff -uw "polykinds/T7224.run/T7224.stderr.normalised" "polykinds/T7224.run/T7224.comp.stderr.normalised" --- polykinds/T7224.run/T7224.stderr.normalised 2018-08-11 13:33:16.874459507 +0300 +++ polykinds/T7224.run/T7224.comp.stderr.normalised 2018-08-11 13:33:16.874459507 +0300 @@ -1,13 +1,11 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20180809 for x86_64-unknown-linux): + ASSERT failed! + Type-correct unfilled coercion hole {co_asw} + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + pprPanic, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable + assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:<line>:<column> in <package-id>:TcHsSyn -T7224.hs:6:19: - Expected kind ‘i’, but ‘i’ has kind ‘*’ - In the first argument of ‘m’, namely ‘i’ - In the type signature: ret' :: a -> m i i a - In the class declaration for ‘PMonad'’ - -T7224.hs:7:14: - Expected kind ‘i’, but ‘i’ has kind ‘*’ - In the first argument of ‘m’, namely ‘i’ - In the type signature: - bind' :: m i j a -> (a -> m j k b) -> m i k b - In the class declaration for ‘PMonad'’ +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T7224(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15553: GHC.IO.Encoding not flushing partially converted input
by GHC 21 Aug '18

21 Aug '18

#15553: GHC.IO.Encoding not flushing partially converted input -------------------------------------+------------------------------------- Reporter: msakai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Conversion by `GHC.IO.Encoding` produces incomplete output for some encodings because it does not flush ''partially converted input'' at the end of the string. [https://manpages.debian.org/stretch/manpages-dev/iconv.3 iconv(3)] provides API for the flushing. > In each series of calls to iconv(), the last should be one with inbuf or *inbuf equal to NULL, in order to flush out any partially converted input. But `GHC.IO.Encoding` does not perform the flushing properly and it can cause incomplete conversion result. I found two cases that it actually produces incomplete output, but there might be more cases. = Case 1: EUC-JISX0213 For example, the following code is expected to output two bytes 0xa4 0xb1, but it outputs none. {{{#!hs enc <- mkTextEncoding "EUC-JISX0213" withFile "test.txt" WriteMode $ \h -> hSetEncoding h enc >> hPutStr h "\x3051" }}} The problem happens because of the following mapping between Unicode and EUC-JISX0213. ||Unicode||EUC-JISX0213|| ||U+3051 U+309A||0xa4 0xfa|| ||U+3051||0xa4 0xb1|| After seeing the codepoint U+3051, the converter is unable to determine which of the two byte sequence to output until it sees the next character or ''the end of the string''. But `GHC.IO.Encoding` does not call the above mentioned ''flushing'' API, therefore the converter is unable to recognize the end of the string. = Case 2: ISO-2022-JP Similarly, following code is expected to output byte sequence `0x1b 0x24 0x42` `0x24 0x22` `0x1b 0x28 0x42` but the last three bytes `0x1b 0x28 0x42` is not produced. {{{#!hs enc <- mkTextEncoding "ISO-2022-JP" withFile "test.txt" WriteMode $ \h -> hSetEncoding h enc >> hPutStr h "\x3042" }}} ISO-2022-JP is a stateful encoding and [https://www.ietf.org/rfc/rfc1468.txt RFC 1468] requires the state is reset to initial state at the end of the string. The missing three bytes `0x1b 0x28 0x42` are the escape sequence for that purpose. But again `GHC.IO.Encoding` does not call the above mentioned`flushing` API, therefore the converter cannot recognize the end of the string and cannot reset the state. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15553> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15504: -XStrict doesn't prevent warnings from -Wunbanged-strict-patterns
by GHC 21 Aug '18

21 Aug '18

#15504: -XStrict doesn't prevent warnings from -Wunbanged-strict-patterns -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm using: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.3 }}} I was under the impression that [https://ghc.haskell.org/trac/ghc/wiki/StrictPragma#Strict -XStrict] automatically included outermost bang patterns, but either that isn't always the case or [https://downloads.haskell.org/~ghc/master/users-guide /using-warnings.html#ghc-flag--Wunbanged-strict-patterns -Wunbanged- strict-patterns] doesn't know that `-XStrict` did its job correctly: {{{#!hs {-# OPTIONS_GHC -Wunbanged-strict-patterns #-} {-# LANGUAGE BangPatterns, MagicHash, Strict, UnboxedTuples #-} module Example where import GHC.Exts (Int(I#), quotRemInt#) lastDigit :: Int -> Int lastDigit (I# x) = let (# q, r #) = quotRemInt# x 10# in I# r }}} compiles with a warning: {{{ [1 of 1] Compiling Example ( Example.hs, Example.o ) Example.hs:9:24: warning: [-Wunbanged-strict-patterns] Pattern bindings containing unlifted types should use an outermost bang pattern: (# q, r #) = quotRemInt# x 10# | 9 | lastDigit (I# x) = let (# q, r #) = quotRemInt# x 10# | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15504> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9854: Literal overflow check is too aggressive
by GHC 21 Aug '18

21 Aug '18

#9854: Literal overflow check is too aggressive -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The literal overflow check is too aggressive. Sometimes you want to give a literal as a hexadecimal value that does fit inside e.g. an `Int`, like so: {{{ Prelude> 0xdc36d1615b7400a4 :: Int <interactive>:2:1: Warning: Literal 15868100553162883236 is out of the Int range -9223372036854775808..9223372036854775807 -2578643520546668380 }}} However the compiler complains because of the wrap-around. I feel this is common enough and practice (and perfectly well-defined) that the compiler shouldn't warn. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12467: distclean does not clean 'compact' library
by GHC 21 Aug '18

21 Aug '18

#12467: distclean does not clean 'compact' library -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ > ghc_2 git:(master) make distclean 2>&1 | grep compact > ghc_2 git:(master) }}} I think we should see something like {{{ "rm" -rf libraries/compact/dist-install }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12467> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15547: A function `nat2Word# :: KnownNat n => Proxy# n -> Word#`
by GHC 21 Aug '18

21 Aug '18

#15547: A function `nat2Word# :: KnownNat n => Proxy# n -> Word#` -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It would be nice if there were the function (perhaps in `GHC.Prim`) `nat2Word# :: KnownNat n => Proxy# n -> Word#` that was essentially `(\ W# w# -> w#) . fromInteger . natVal`, except that it produces the `Word#` at compile-time rather than runtime and that it works with `Proxy#` (for [https://hackage.haskell.org/package/base-4.11.1.0/docs/GHC- Exts.html#t:Proxy-35- its no-runtime-representation, totally-free nature]) instead of `Proxy`. This would enable compile-time computations on `Nat`s to produce a literal `Word#` without any runtime expense at all, which seems nice if you're dealing with primitives ''because'' you want to avoid runtime expense. == Motivating example I'm learning primitive types and type-level arithmetic by making a simple set of fixed-width integer types where the type contains a `Nat` for the number of bits in the fixed-width integer. Going from the following `Nat`s to their corresponding `Word#`s at compile time even when optimizations are turned off during development would be very nice: ||= `Div (n + 63) 64` \\=||the highest index we should try to access via `indexWordArray#` || ||= `Mod (n - 1) 64 + 1` \\=||except when `n == 0`, the number of bits actually used in the \\ most-significant word || ||= `2^(Mod (n + 63) 64 + 1) - 1` \\=||the unsigned integer narrowing bitmask to use on the \\ most-significant word || -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15513: How to pass "-hide-all-packages" to the GHC API?
by GHC 21 Aug '18

21 Aug '18

#15513: How to pass "-hide-all-packages" to the GHC API? -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Keywords: environment | Operating System: Unknown/Multiple file API | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In brittany, we have make use of the GHC API e.g. in the following fashion: {{{#!hs parseModuleFromString :: [String] -> System.IO.FilePath -> (GHC.DynFlags -> IO (Either String a)) -> String -> IO (Either String (ExactPrint.Anns, GHC.ParsedSource, a)) parseModuleFromString args fp dynCheck str = mask_ $ ExactPrint.ghcWrapper $ ExceptT.runExceptT $ do dflags0 <- lift $ ExactPrint.initDynFlagsPure fp str (dflags1, leftover, warnings) <- lift $ GHC.parseDynamicFlagsCmdLine dflags0 (GHC.noLoc <$> args) when (not $ null leftover) $ ExceptT.throwE $ "when parsing ghc flags: leftover flags: " ++ show (leftover <&> \(L _ s) -> s) when (not $ null warnings) $ ExceptT.throwE $ "when parsing ghc flags: encountered warnings: " ++ show (warnings <&> warnExtractorCompat) dynCheckRes <- ExceptT.ExceptT $ liftIO $ dynCheck dflags1 let res = ExactPrint.parseModuleFromStringInternal dflags1 fp str case res of Left (span, err) -> ExceptT.throwE $ show span ++ ": " ++ err Right (a , m ) -> pure (a, m, dynCheckRes) }}} This code unfortunately picks up "package environment files", which I take it is not at all necessary for this use-case: Brittany only requires parsing functionality, so external packages should be irrelevant. "Unfortunately", because the package environment files can easily become stale, which in turn breaks the API. The users' guide mentions the "-hide-all-packages" flag, but my attempts to pass this to the API so far have failed. What I have tried is calling `parseDynamicFlagsCmdLine` with "-hide-all-packages" as an argument, and using the resulting dynflags afterwards. This appears to be without effect, I think even when it is the first thing executed inside of `runGhc`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15513> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings
by GHC 21 Aug '18

21 Aug '18

#5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ulysses4ever): * milestone: => 8.8.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5518#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15295: Haddock options should be concatened
by GHC 21 Aug '18

21 Aug '18

#15295: Haddock options should be concatened -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Keywords: haddock | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently we have the following situation: 1. If we have an `OPTIONS_HADDOCK` pragma, any CLI options from `-haddock- opts` are ignored 2. If there are multiple `OPTIONS_HADDOCK` pragmas, only the last one is remembered. Instead all options should be concatenated (with `, `), with the CLI options at the end. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15295> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors.
by GHC 20 Aug '18

20 Aug '18

#15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors. -------------------------------------+------------------------------------- Reporter: Wizek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Me and Neil Mitchell have ran into this quite a few times while using GHCid, here is our discussion: https://github.com/ndmitchell/ghcid/issues/159 Here is a small reproducible example: {{{#!hs module Main where foo :: String foo = show a where a = baz bar :: Int bar = 1 main = putStrLn foo }}} GHC 8.0.x and above will say {{{ src/Main.hs:4:7: error: • Ambiguous type variable ‘a0’ arising from a use of ‘show’ prevents the constraint ‘(Show a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance (Show a, Show b) => Show (Either a b) -- Defined in ‘Data.Either’ instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ ...plus 23 others ...plus 212 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: show a In an equation for ‘foo’: foo = show a where a = baz | 4 | foo = show a | ^^^^^^ src/Main.hs:5:13: error: • Variable not in scope: baz • Perhaps you meant ‘bar’ (line 8) | 5 | where a = baz | ^^^ }}} It's much more useful and much less noisy what 7.10.3 reports: {{{ src/Main.hs:5:13: Not in scope: ‘baz’ Perhaps you meant ‘bar’ (line 8) }}} So a desired output would be something like this for a later GHC release: {{{ src/Main.hs:5:13: error: • Variable not in scope: baz • Perhaps you meant ‘bar’ (line 8) | 5 | where a = baz | ^^^ }}} Or if someone is adamant about keeping the other errors even when there are out of scope variables present, then at least can we please reorder them such that the much more relevant out-of-scope errors are at the top? {{{ src/Main.hs:5:13: error: • Variable not in scope: baz • Perhaps you meant ‘bar’ (line 8) | 5 | where a = baz | ^^^ src/Main.hs:4:7: error: • Ambiguous type variable ‘a0’ arising from a use of ‘show’ prevents the constraint ‘(Show a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance (Show a, Show b) => Show (Either a b) -- Defined in ‘Data.Either’ instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ ...plus 23 others ...plus 212 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: show a In an equation for ‘foo’: foo = show a where a = baz | 4 | foo = show a | ^^^^^^ }}} I might even be up for fixing this if there is agreement on the next steps to be taken. (Though I've never contributed to GHC before, on the surface this doesn't seem hard to fix.) What do you think? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3