- ghc-tickets - Haskell.org

[GHC] #11646: Make pattern synonym export type mismatch a warning
by GHC 11 Aug '16

11 Aug '16

#11646: Make pattern synonym export type mismatch a warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As I understand it, attempting to associate a pattern synonym with a type constructor that it "obviously" doesn't match is an error. This is strange for two reasons: 1. An "erroneous" association cannot compromise type safety. 2. The test is incomplete. Therefore, I believe such mismatches should lead to warnings instead of errors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10106: GHC doesn't warn on typos in language pragmas
by GHC 11 Aug '16

11 Aug '16

#10106: GHC doesn't warn on typos in language pragmas -------------------------------------+------------------------------------- Reporter: sdemos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In particular, I was struggling with the QuasiQuotes language extension. I had - {{{#!hs {-# LANGAUGE QuasiQuotes #-} site = [shamelet|Hello World!|] }}} Notice the transposed A and U in `LANGUAGE` The error that ghc was emitting was - `Main.hs:23:47: parse error on input ‘]’` It took me a long time and a lot of head-banging to figure out that it was a typo in the language pragma, especially because the language pragma was surrounded by other language pragmas and it was at the top of the file. I would think that this should at least emit a warning when there is a typo in a pragma. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #2867: Make a way to tell GHC that a pragma name should be "recognised"
by GHC 11 Aug '16

11 Aug '16

#2867: Make a way to tell GHC that a pragma name should be "recognised" -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * cc: ghc@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2867#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12377: getExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS also)
by GHC 11 Aug '16

11 Aug '16

#12377: getExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS also) -------------------------------------+------------------------------------- Reporter: oherrala | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: OpenBSD Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- System.Environment.getExecutablePath doesn't return absolute path to executable in OpenBSD. This happens because getExecutablePath uses argv[0] to determine path and argv[0] might not be absolute path. My environment: {{{ $ uname -a OpenBSD fizbuz.pilkki.ciz.fi 6.0 GENERIC.MP#2274 amd64 $ ghc -V The Glorious Glasgow Haskell Compilation System, version 7.10.3 }}} This test program in OpenBSD: {{{#!hs module Main where import System.Environment main = getExecutablePath >>= print }}} returns {{{ $ ./test "./test" }}} For example in OS X the call returns absolute path: {{{ $ ./test "/Users/oherrala/tmp/test" }}} OpenBSD is one of the operating systems which gets fall back to using argv[0] to determine exec's location: https://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/System/Environmen… Maybe the argv[0] result should be wrapped with realpath(3) to get absolute path? This bug is also present in cabal-install and reported here: https://github.com/haskell/cabal/issues/3512#issuecomment-231604356 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12377> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12172: User's Guide patches
by GHC 07 Aug '16

07 Aug '16

#12172: User's Guide patches -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you want your User's Guide patches to be merged to the 8.0 branch, please mention this ticket in the commit message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12172> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12007: Pattern families regression
by GHC 07 Aug '16

07 Aug '16

#12007: Pattern families regression -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- The following code compiles fine for me in GHC 7.10.1, but fails in GHC 8.1.20160502 {{{ {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} data Foo a = Foo a a pattern A a1 a2 = Foo a1 a2 pattern B a1 a2 = A a1 a2 }}} The problem is the nested pattern. Compiling gives: {{{ [1 of 1] Compiling Main ( Bug1.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160502 for x86_64-unknown-linux): kindPrimRep.go rep_a85f Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

Re: [GHC] #7105: Better names for derived SCCs of instances
by GHC 07 Aug '16

07 Aug '16

#7105: Better names for derived SCCs of instances -------------------------------------+------------------------------------- Reporter: ksf | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Profiling | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11543 | Differential Rev(s): Phab:D2282 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged as 7fc7538fffb9ad4ad2132a8a9ef8cb6543d0b2fc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7105#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9517: hp2ps generates invalid postscript file
by GHC 07 Aug '16

07 Aug '16

#9517: hp2ps generates invalid postscript file -----------------------------+---------------------------------- Reporter: JamesM | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------+---------------------------------- Some of the outputs have a name such as foo(...). However, the postscript generation does not add an extra closing parenthesis after the foo(...). Example from attachment on line 410. ((447)modifyEdge.newEdges.(...) show This should presumably be: ((447)modifyEdge.newEdges.$...$) show Output from ps2pdf: Error: /syntaxerror in -file- Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1900 1 3 %oparray_pop 1899 1 3 %oparray_pop 1883 1 3 %oparray_pop 1771 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push Dictionary stack: --dict:1163/1684(ro)(G)-- --dict:0/20(G)-- --dict:79/200(L)-- Current allocation mode is local Last OS error: No such file or directory Current file position is 40721 GPL Ghostscript 9.07: Unrecoverable error, exit code 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12151: GHC 8 allows ambiguous type without AllowAmbiguousTypes
by GHC 07 Aug '16

07 Aug '16

#12151: GHC 8 allows ambiguous type without AllowAmbiguousTypes -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #7437 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This module compiles with GHC 8: {{{ {-# LANGUAGE DefaultSignatures #-} -- {-# LANGUAGE AllowAmbiguousTypes #-} -- Not required with GHC 8.0.1. module T12151 where class Put a where put :: a default put :: t -- This should be `a` instead of `t` put = undefined }}} GHC 7.10 required `AllowAmbiguousTypes`, to defer the ambiguity check to use sites. (Example extracted from the description of #7437) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12151> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code
by GHC 07 Aug '16

07 Aug '16

#9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In an attempt to close #4210 the LLVM code generator's mangler was modified in ed67d290e7389bd87a6feea269a0275e0f0f5e2f to rewrite symbol types from `@function` to `@object`. This was done in order to prevent the linker from sending reference through the PLT which breaks info tables. Unfortunately, this mangling was a simple text replacement of `@function` to `@object` in the assembler produced by LLVM and made no attempt to distinguish `.type` directives (which the mangling targets) from other occurrences of the token. As rwbarton unfortunately found out, this means that any occurrences of `"@function"` in user code (e.g. the LLVM backend itself while compiling GHC) will be rewritten to `"@object"` in the produced object. Hilarity ensues. This can be demonstrated by the simple test `main = putStrLn "@function"`, which prints `@object` in the affected releases (7.8.1 through 7.8.3 thusfar). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9439> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15