June 2015 - ghc-tickets

[GHC] #10558: Alter type of parseDeclaration and parseTypeSignature entry points
by GHC 21 Aug '15

21 Aug '15

#10558: Alter type of parseDeclaration and parseTypeSignature entry points -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab: | D1007 | -------------------------------------+------------------------------------- Currently the type of the two mentioned entry points is {{{#!hs parseDeclaration :: P (OrdList (LHsDecl RdrName)) }}} and {{{#!hs parseTypeSignature :: P (Located (OrdList (LHsDecl RdrName))) }}} It turns out that in both cases, OrdList is always a singleton so the additional wrapping is redundant. I propose that the parser is modified in order to reflect this so that this is clearer to end users. The end result being that both entry points have type `P (LHsDecl RdrName)` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10567: Redundant parser entry point
by GHC 21 Aug '15

21 Aug '15

#10567: Redundant parser entry point -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- The `stmt` parser is exposed under two different names. (`parseFullStmt` and `parseStatement`) It would be better to remove one of them (I would say `parseFullStmt`) in order to avoid confusion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10567> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8484: Compile-time panic
by GHC 20 Aug '15

20 Aug '15

#8484: Compile-time panic ----------------------------------+--------------------------------------- Reporter: Taymon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile-time crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------------- I attempted to build a program (using make) and got the following output: {{{ ghc -odir binaries -hidir binaries --make Main.hs -optl-w ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): While parsing "/home/taymonbeal/.ghc/x86_64-linux-7.6.3/package.conf.d/package.cache": too few bytes. Failed reading at byte position 8 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make: *** [build] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8484> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9381: Implement rdynamic
by GHC 18 Aug '15

18 Aug '15

#9381: Implement rdynamic -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: feature request | facundo.dominguez Priority: normal | Status: new Component: Compiler | Milestone: Keywords: | Version: 7.8.2 Architecture: Unknown/Multiple | Operating System: Difficulty: Unknown | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: 7015 | None/Unknown | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently ghc ignores the `-rdynamic` flag. With a small effort it can be used as a synonym of `-optl -rdynamic` in linux and `-optl -export-all-symbols` in windows/mingw32. In other platforms, similar translations must be possible to get the symbols of an executable exported. This feature would improve usability of an upcoming implementation of #7015. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #9903: GHCi produces a cryptic message when using HPC
by GHC 13 Aug '15

13 Aug '15

#9903: GHCi produces a cryptic message when using HPC -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.9 Keywords: hpc | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: #9878, #9762 ? | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following test produces an impolite response from GHCi {{{ $ cat t.hs g :: Int g = 1 + 1 $ ghc-stage2 --interactive t.hs -fhpc GHCi, version 7.9.20141217: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( t.hs, interpreted ) Ok, modules loaded: Main. *Main> g ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141217 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc25774_0/ghc25774_5.so: undefined symbol: _hpc_tickboxes_Main_hpc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It has been noted elsewhere (#9878) that these kinds of messages are better avoided. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9903> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9218: Upgrade the version of MinGW shipped with GHC
by GHC 13 Aug '15

13 Aug '15

#9218: Upgrade the version of MinGW shipped with GHC ------------------------------------+--------------------------------- Reporter: komadori | Owner: komadori Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3390 | ------------------------------------+--------------------------------- The Windows binary distribution of GHC incorporates a version of MinGW which has not been updated for several releases and is now out-of-date. It should be upgraded. The previous time this was done appears to correlate with ticket #3390. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9218> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python
by GHC 12 Aug '15

12 Aug '15

#9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python -------------------------------------------+---------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------+---------------------------- The released Windows 64 tarball available at https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-x86_64-unknown- mingw32.tar.xz includes the following under `mingw/bin`: * gfortran * gcj * python27.dll * The whole Python 2.7 standard library (`mingw/bin/lib`) These files have probably been included by mistake. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9014> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9143: feature request: way to set actual program argv
by GHC 12 Aug '15

12 Aug '15

#9143: feature request: way to set actual program argv ----------------------------------------------+---------------------------- Reporter: joeyhess | Owner: Type: feature request | simonmar Priority: normal | Status: new Component: Runtime System | Milestone: Keywords: | Version: 7.8.2 Architecture: Unknown/Multiple | Operating System: Linux Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- It's not currently possible to write a program with ghc that changes its argv, so as to change what the program name/parameters appear to be in ps. An example of a program that does this is sshd, which arranges for the process name to say which user it's serving. For example, "sshd: joey [priv]" I'd like to be able to write such programs using haskell too. Also, I have a haskell program that, due to the way it is executed, has a really horrible display in ps: /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64/ld-linux-x86-64.so.2 --library-path /usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux- gnu:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/lib64:/usr/local/propellor/docker /android-git-annex- builder.orca.kitenet.net.propellor.shim/etc/ld.so.conf.d:/usr/local/propellor/docker /android-git-annex-builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64 -linux-gnu/audit:/usr/local/propellor/docker/android-git-annex- builder.orca.kitenet.net.propellor.shim/usr/lib/x86_64-linux-gnu/gconv /usr/local/propellor/propellor That's enough motivation for me to dig into this. :) In rts/RtsMain.c, progargv is set to point to argv. However, it's static, so this cannot be (ab)used from the FFI to change argv. So, a minimal change would be to make progargv not be static, and perhaps give it a more formal name or minimal FFI binding. A GHC-specific library could then use this to modify argv. The haskell interface I'm considering would be: displayArgv :: [String] -> IO () It would need to truncate strings to fit within the available argv space. (This would not affect the argv used by System.Environment, which is a copy of argv.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages
by GHC 12 Aug '15

12 Aug '15

#9049: Expose srcLoc from the assertion architecture to allow better error messages ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Assertions give great error messages by including file name and line, but they are disabled for optimisation. While there is a compiler flag to turn them on even in presence of optimisation, this is an awkward external way to simply attach a useful error location to something like `error`. It would be great if we could decouple getting the current `srcLoc` from assertions, and making it available for good error messages. It is currently possible to do this using TemplateHaskell (e.g. the `placeholders` package) or `CPP`, but both are inconvenient for technical reasons (such as breaking tooling) and do not enjoy widespread use. It seems a shame that the architecture for annotated error messages is already there, but only available through a mechanism that is disabled for optimisation (or at least "intended" to be disabled for optimisation). Notably, we have the same architecture available for pattern mach failures: {{{ f x | x > 0 = "foo" main = putStrLn (f (-1)) -- gives srcLoc'd pattern match error message }}} {{{ f x | x > 0 = "foo" f _ = error "f needs a positive number" main = putStrLn (f (-1)) -- does not give a srcLoc'd error message }}} It seems non-sensical that your try to write a better error message (here using `error`) yields in fact a less-helpful error message. I completely agree that one can aid bug-fixing by writing globally unique arguments to `error` or using TH, but from an engineering perspective, a little bit of help from the language/compiler side can improve the situation a lot, and in other languages this is acknowledged and used to everybody's benefit. There are some alternatives we might consider, such as * exposing `srcLoc :: String` that gives an `assert`-style location at the lexical position of its occurrence * adding an `error`-like function that behaves like `error` but also prints a source location Arguably `srcLoc :: String` breaks equational reasoning on the ''syntactic'' level, as `let x = srcLoc in (x, x)` and `(srcLoc, srcLoc)` have different values. However, looking at it from a program execution point of view, referential transparency is preserved since once compiled, any function using `srcLoc` will always return the same location. I believe that offering ''some'' kind of improvement over the dreaded `error` or `Prelude: undefined` should be easy to implement, but let's hear what the people who actually know the compiler think about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #10339: PatternSynonyms confuse exhaustiveness check
by GHC 10 Aug '15

10 Aug '15

#10339: PatternSynonyms confuse exhaustiveness check -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 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: | -------------------------------------+------------------------------------- I just noticed some odd behaviour when (ab)using pattern synonyms in the following code (whose style I don't really endorse): {{{#!hs {-# LANGUAGE PatternSynonyms, LambdaCase #-} module PatSyn1 where import System.Directory (doesFileExist) pattern Found = True pattern NotFound = False readConfigFile :: FilePath -> IO () readConfigFile filePath = doesFileExist filePath >>= \case Found -> putStrLn =<< readFile filePath NotFound -> putStrLn "File does not exist." pattern Void = () foo :: () -> () foo Void = () }}} Results in {{{ /home/hvr/Haskell/PatSyn1.hs:(11,54)-(13,47): Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ /home/hvr/Haskell/PatSyn1.hs:19:1-13: Warning: Pattern match(es) are non-exhaustive In an equation for ‘foo’: Patterns not matched: _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10339> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3