October 2018 - ghc-tickets

[GHC] #15660: source file modify race leads to inconsistent error message
by GHC 20 Nov '18

20 Nov '18

#15660: source file modify race leads to inconsistent error message -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got this odd error message from ghc: {{{ Command/AddUrl.hs:120:32: error: lexical error in string/character literal at character '-' | 120 | BatchNull -> '\0' | ^ }}} Part of the error message says that '-' is the problem character, but the quoted line of code does not contain that. What happened is I started the build, noticed I had typoed '\-' and quickly corrected it in my editor and saved. It seems ghc must have read the source file twice, so I raced it and so experienced this inconsistency. I wonder if it could display the wrong line entirely if a larger change was made to the file? Thanks for your time with such a minor thing as this bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15660> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10445: Wrong stack space size when using -Ksize
by GHC 19 Nov '18

19 Nov '18

#10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After compiling the first example in https://wiki.haskell.org/Performance/Accumulating_parameter: {{{ $ cat Test.hs len :: [a] -> Int len [] = 0 len (x:xs) = len xs + 1 main :: IO () main = print $ len [1..1000000] }}} {{{ $ ghc Test.hs -rtsopts }}} and running {{{ ./Test +RTS -K10K }}} GHC 7.6.3 reports {{{ Stack space overflow: current size 10240 bytes. }}} GHC 7.8.4 reports {{{ Stack space overflow: current size 33632 bytes. }}} and GHC 7.10.1 reports {{{ Stack space overflow: current size 99136 bytes. }}} GHC 7.8.3 and 7.10.1 report an incorrect stack space size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10347: Spurious "unused constructor" warning with Coercible
by GHC 19 Nov '18

19 Nov '18

#10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE RoleAnnotations #-} module Bug (N, twiddle) where import Data.Coerce newtype N a = MkN Int type role N representational twiddle :: N a -> N b twiddle = coerce }}} I get {{{ Bug.hs:7:15: warning: Defined but not used: data constructor ‘MkN’ }}} But the constructor ''is'' used, in order to do the coercion. The role annotation is to force GHC to use the constructor to do the coercion -- otherwise, it might not have. This bug exists in 7.10 and in HEAD. I will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10347> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15126: Opportunity to compress common info table representation.
by GHC 18 Nov '18

18 Nov '18

#15126: Opportunity to compress common info table representation. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: CodeGen | 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've looked at a lot of GHC produced assembly recently and noticed that most info tables describing stacks have the form: {{{ .align 8 .long SDjR_srt-(block_cHmk_info)+296 .long 0 .quad 6151 .quad 4294967326 }}} I haven't managed to dig fully into the description however some observations: * I noticed that the second .long directive almost always ends up being zero. * When figuring out what is what I realized the first quad (describing the pointers) is almost never fully used. * The last entrie (closure type + ?), here `4294967326` also seems quite repetitive given the size reserved. So I looked in detail at spectral/simple: * There are 2012 info tables of this sort with all of them having a zero in the second long. * We also reserve 8 byte for the stack layout. However only a single of these tables requires more than 4 byte. The compiled module has a size of 276384 Bytes, with 16092 being redundant: * 4 bytes for 0 * 4 bytes unused stack description * times 2012 info tables. That is an overhead of 5,8% which seems like quite a lot to me. The questions where to put that information is a different one. But only looking at the data and not how it is used tagging the pointer to the SRT table seems like a possibility. The info table description `4294967326` also appeared over 1k times. Maybe it's possible to come up with a more efficient encoding there as well. I didn't give it much thought yet since I don't have the time to do anything about it in the near future. But putting it here in case anyone is interested or looks into this in the future. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9207: Detect obvious cases of infinite recursion.
by GHC 18 Nov '18

18 Nov '18

#9207: Detect obvious cases of infinite recursion. --------------------------------------+------------------------------------ Reporter: mrugiero | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: infinite recursion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: --------------------------------------+------------------------------------ Pure functions are guaranteed to return the same value if the same arguments are used. Because of that, a compiler could be able to detect infinite recursion in the form of a function calling itself with the same arguments (case, some distracted programmer forgot to apply the function tail to a list). The way I see it, one of Haskell's main selling points is that it helps the programmer to avoid sources of bugs as much as it can, and infinite recursion is one of the few that stand unchecked. I specifically point to this example because both, I'm a newbie and made that newbie mistake, and think it shouldn't be hard to implement to the parsing stage of the compiler/interpreter. It probably should throw an error when this happens in pure functions, and maybe an opt-in warning if it happens in monads. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12906: GHC fails to typecheck Main module without main
by GHC 17 Nov '18

17 Nov '18

#12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given a `Main` module without a `main` value, GHC 8 reports the missing `main` and then exits, without bothering to typecheck the rest of the module. Previous versions, I believe, had the more useful behavior of reporting type errors regardless. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12906> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12525: Internal identifiers creeping into :show bindings
by GHC 17 Nov '18

17 Nov '18

#12525: Internal identifiers creeping into :show bindings -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When binding variables the "new" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list. {{{#!html <pre class="wiki"> GHCi, version 8.1.20160725: http://www.haskell.org/ghc/ :? for help > :show bindings > x = () > :show bindings <b>$trModule :: GHC.Types.Module = _</b> x :: () = _ > class Foo a > :show bindings x :: () = _ class Foo a <b>$tcFoo :: GHC.Types.TyCon = _ $tc'C:Foo :: GHC.Types.TyCon = _ $trModule :: GHC.Types.Module = _</b> </pre> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12525> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15702: "-main-is" flag is broken for recent ghc-head
by GHC 17 Nov '18

17 Nov '18

#15702: "-main-is" flag is broken for recent ghc-head -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect (amd64) | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a minimal reproduction: Main.hs: {{{ main :: IO () main = putStrLn "Main" }}} Main2.hs: {{{ module Main2 where import Main main2 :: IO () main2 = do putStrLn "Main2" main }}} Run ghc with something like `/home/terrorjack/.stack/programs/x86_64-linux/ghc-8.7.20181003/bin/ghc -main-is Main2.main2 Main.hs Main2.hs`, and it reports the following error: {{{ [1 of 2] Compiling Main ( Main.hs, Main.o ) Main.hs:1:1: error: Not in scope: ‘main2’ Perhaps you meant ‘main’ (line 2) | 1 | main :: IO () | ^ }}} Meanwhile, the exact same flags work for ghc-8.6.1, and also a previous ghc-head build on d90946cea1357d3e99805c27dab1e811785a4088, so some accidental breakage might be in a recent commit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13704: -main-is flag should change exports in default module header
by GHC 17 Nov '18

17 Nov '18

#13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- The -main-is option to GHC should probably change the export list for the default module header. It doesn't. {{{ $ cat Main.hs program = return () $ ghc -main-is Main.program Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:1:1: error: Not in scope: ‘main’ Perhaps you meant ‘min’ (imported from Prelude) Main.hs:1:1: error: The main IO action ‘program’ is not exported by module ‘Main’ }}} I cannot imagine any possible use case for a feature that changes the entry point name to something else, and then deliberately fails to export the symbol by that name. This seems like an obvious thing to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11477: Remove -Wamp
by GHC 17 Nov '18

17 Nov '18

#11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This warning is intended as a temporary measure to aid the Applicative- Monad Proposal transition. It should be eventually removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11477> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11