- ghc-tickets - Haskell.org

[GHC] #13303: Bad pretty printer for let bindings in a do-notation with braces
by GHC 20 Feb '17

20 Feb '17

#13303: Bad pretty printer for let bindings in a do-notation with braces -------------------------------------+------------------------------------- Reporter: rem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: do-notation, | Operating System: Unknown/Multiple let, parse | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Let bindings in do-notations with braces like this: {{{#!hs module Thing where thing = do {let {x = 1}; print x} }}} get pretty printed with the braces around the bindings stripped, like this: {{{#!hs module Thing where thing = do {let x = 1; print x} }}} Steps to reproduce: copy the module into Try.hs then call: ghc -ddump-rn Try.hs I traced the code to: https://github.com/ghc/ghc/blob/e28fbbb7c3d5904a88b4743d0d10f212d61d8293/co… which points to the pretty printer for list of declarations: https://github.com/ghc/ghc/blob/95dc6dc070deac733d4a4a63a93e606a2e772a67/co… Indeed there is a comment on the two ways to pretty print binders - without braces in multiple lines and with braces in one line. However the comment does not explain the choice, and as discussed in #13302 the former won't parse in a do-notation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13303> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13302: Let in do-notation with braces does not parse
by GHC 20 Feb '17

20 Feb '17

#13302: Let in do-notation with braces does not parse -------------------------------------+------------------------------------- Reporter: rem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: do-notation, | Operating System: MacOS X let, parse | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to the the syntax at https://www.haskell.org/onlinereport/haskell2010/haskellch10.html the following do-notation should parse: {{{#!hs do {let x = 4; print x} }}} But it doesn't. {{{#!hs do {let x = 4 in print x} }}} parses OK. Doesn't look like a new bug, I tried with GHC 7.8 and same result. Googling "haskell do {let ds; es} = let ds in do {es}" also shows quite a lot of people taught Haskell that way, so maybe it once worked? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13251: Must perform family consistency check on non-imported identifiers
by GHC 20 Feb '17

20 Feb '17

#13251: Must perform family consistency check on non-imported identifiers -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the family consistency check checks pairs of *imported* modules (and the modules they transitively import) for consistency. However, there are a number of mechanisms by which we can refer to an identifier from a module without explicitly importing it. Here is one example from Template Haskell: {{{ -- A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a -- B.hs {-# LANGUAGE TypeFamilies #-} module B where import A type instance F Bool = String g :: F Bool g = "af" -- C.hs {-# LANGUAGE TypeFamilies #-} module C where import A type instance F Bool = Int h :: F Bool -> IO () h = print -- D.hs {-# LANGUAGE TemplateHaskell #-} import C import Language.Haskell.TH.Syntax main = h $( return (VarE (Name (OccName "g") (NameG VarName (PkgName "main") (ModName "B")))) ) }}} This does an unsafe coerce: {{{ ezyang@sabre:~/Dev/labs/T13102$ ghc-head --make B.hs D.hs -fforce-recomp [1 of 4] Compiling A ( A.hs, A.o ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling C ( C.hs, C.o ) [4 of 4] Compiling Main ( D.hs, D.o ) Linking D ... ezyang@sabre:~/Dev/labs/T13102$ ./D 8070450533355229282 }}} Clearly, checking consistency on imports is not enough: we must also check up on original names that come by other mechanisms. (Other ways we can end up with identifiers without imports include overloading, see #13102. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13251> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] Trac email verification for user: sukhmel
by GHC 20 Feb '17

20 Feb '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=UdTLQgli> Username: sukhmel Verification Token: UdTLQgli -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Trac email verification for user: blaze
by GHC 19 Feb '17

19 Feb '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=sU7Movb5> Username: blaze Verification Token: sU7Movb5 -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #149: missed CSE opportunity
by GHC 18 Feb '17

18 Feb '17

#149: missed CSE opportunity --------------------------------------------+------------------------------ Reporter: nobody | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 5.04.2 Resolution: None | Keywords: optimisations Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime performance bug | Test Case: T149 Blocked By: | Blocking: Related Tickets: | --------------------------------------------+------------------------------ Changes (by AndreasK): * Attachment "CriterionBenchFixed2.hs" added. Updated test -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #797: nofib tests fail on Windows due to different EOL convention in output files
by GHC 18 Feb '17

18 Feb '17

#797: nofib tests fail on Windows due to different EOL convention in output files -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 6.4.1 suite | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3030 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Fixed in 307ae61121a99f6ffd3d5fa56e5d37b1b91a492b {{{ This allows nofib to run on Windows using `msys`. Also deprecates the old `cygwin` stuff. Test Plan: make clean && make Reviewers: bgamari Reviewed By: bgamari Subscribers: RyanGlScott, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3030 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/797#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #797: nofib tests fail on Windows due to different EOL convention in output files
by GHC 18 Feb '17

18 Feb '17

#797: nofib tests fail on Windows due to different EOL convention in output files -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 6.4.1 suite | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3030 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * differential: => Phab:D3030 * resolution: => fixed * milestone: 6.6 => 8.4.1 Old description: New description: Fixed in 307ae61121a99f6ffd3d5fa56e5d37b1b91a492b {{{ This allows nofib to run on Windows using `msys`. Also deprecates the old `cygwin` stuff. Test Plan: make clean && make Reviewers: bgamari Reviewed By: bgamari Subscribers: RyanGlScott, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3030 }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/797#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12409: Unboxed tuples have no type representations
by GHC 18 Feb '17

18 Feb '17

#12409: Unboxed tuples have no type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket continues with the long tradition of types missing type representations (see #12082, #12132, #11120). This time the culprit is unboxed tuples, {{{ $ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci λ> import Data.Typeable λ> :set -XUnboxedTuples λ> typeRep (Proxy :: Proxy (#Int, Int#)) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): tyConRep (#,#) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The problem, as usual, is that the tycons are missing from `knownKeyNames`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] Trac email verification for user: praduca
by GHC 18 Feb '17

18 Feb '17

Please visit the following URL to confirm your email address. Verification URL: <http://ghc.haskell.org/trac/ghc/verify_email?verify=1&token=4D_eeaAv> Username: praduca Verification Token: 4D_eeaAv -- GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0