November 2016 - ghc-tickets

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 16 Nov '16

16 Nov '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Test Suite | Version: 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: | -------------------------------------+------------------------------------- Comment (by alanz): The current AST does not allow faithful reproduction of a context with extra parens around it. So {{{#!hs foo :: (Show a) => a -> String }}} and {{{#!hs foo :: ((Show a)) => a -> String }}} produce the same AST fragment. `ghc-exactprint` works around this by using the API Annotations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12842: DatatypeContexts in data types and data families
by GHC 16 Nov '16

16 Nov '16

#12842: DatatypeContexts in data types and data families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: lowest | 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: -------------------------------------+------------------------------------- Does datatype contexts only apply for non-phantom variables? Figured I'd ask {{{#!hs {-# Language DatatypeContexts, TypeFamilies #-} -- F :: Foo a b data (a ~ b) => Foo a b = F }}} and {{{#!hs {-# Language DatatypeContexts, KindSignatures, DatatypeContexts, DataKinds, TypeFamilies #-} data N = O | S N -- FO :: Fin (S n) n' O data family Fin (n::N) (a::N) (b::N) data instance (n ~ n') => Fin (S n) n' O = FO }}} It surprised me to see the first two of these (yes I know, datatype contexts): {{{#!hs -- F :: x -> Foo x x data (a ~ b) => Foo a b = F a -- F :: x -> Foo x x data (a ~ b) => Foo a b = F b -- F :: x -> x -> Foo x x data (a ~ b) => Foo a b = F a b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12842> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 16 Nov '16

16 Nov '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Test Suite | Version: 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: | -------------------------------------+------------------------------------- Comment (by alanz): Email response from Richard Eisenberg I'm afraid I've lost track of where this discussion took place (does someone else remember seeing it?), but I've advocated for faithful reproduction in the past. In particular, the pretty-printers for HsSyn should, in my opinion, never add or remove parentheses. There is a problem here, though: sometimes HsSyn is produced within GHC (for example, in the implementation of `deriving`, or in splicing TH, among a few other spots). This HsSyn can get away with missing parentheses, because it's built as an unambiguous AST. But if the pretty- printer is always faithful, then pretty-printing such an AST will produce an unparsable string. Perhaps the answer is that the generated code should be generous with parentheses -- essentially moving the paren-adding code from today's pretty-printer to the generation sites. Bottom line here: I fully support this direction of travel, but it's not without bumps in the road. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 16 Nov '16

16 Nov '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Test Suite | Version: 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: | -------------------------------------+------------------------------------- Comment (by alanz): Capturing some email on ghc-devs: From @alanz I am currently working on #3384, with the intent of ensuring that parse (ppr (parse source)) == parse source I have hit the issue where `foo :: (Int)` has the parens reflected in the original parsed AST, but the types pretty printer goes to a lot of trouble to remove any parens not required to interpret the meaning of the type. So the question is, should the default ppr faithfully reproduce the source that was parsed to generate the given AST, or simplify it? From a round-tripping perspective I prefer the former, but there are other use cases where the current behaviour is preferred. If the original is preferred, it can perhaps be enabled via a flag to the pretty printer, but before doing that I want to see if it actually matters. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11832: Allow reify to yield types in the current declaration group
by GHC 16 Nov '16

16 Nov '16

#11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: template- | Operating System: Unknown/Multiple haskell reify | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: | TemplateHaskell/Reify -------------------------------------+------------------------------------- Here is the motivation TemplateHaskell/Reify. It would be useful to have a way to obtain types of identifiers in the current declaration group in splices. However, {{{reify}}} is defined to provide information about identifiers in previous declaration groups only. It would be fine to allow {{{reify}}} to work in a scheme combined with {{{addModFinalizer}}} or similar so it is executed when the types are known. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11832> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #12839: mmap functions not properly guarded by RTS_LINKER_USE_MMAP in Linker.c
by GHC 16 Nov '16

16 Nov '16

#12839: mmap functions not properly guarded by RTS_LINKER_USE_MMAP in Linker.c -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System (Linker) | Keywords: | Operating System: Other Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A few uses of munmap etc. are inside of C conditional statements (e.g. `if (RTS_LINKER_USE_MMAP && oc->imageMapped)`) instead of CPP conditional statements, causing compilation failure on systems that don't use MMAP -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12838: On iOS, sys_icache_invalidate called with an end pointer instead of a size
by GHC 16 Nov '16

16 Nov '16

#12838: On iOS, sys_icache_invalidate called with an end pointer instead of a size ----------------------------------------+--------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Keywords: | Operating System: Other Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The second argument of sys_icache_invalidate takes a size, but Storage.c passes an end pointer instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12838> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12744: Register Allocator Unit Tests
by GHC 15 Nov '16

15 Nov '16

#12744: Register Allocator Unit Tests -------------------------------------+------------------------------------- Reporter: tjakway | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (NCG) | 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: -------------------------------------+------------------------------------- Currently the backend only has end-to-end tests and I think it would benefit from some unit tests starting with (for no special reason) the register allocator. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12744> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12841: Remove or explain target triple normalization
by GHC 15 Nov '16

15 Nov '16

#12841: Remove or explain target triple normalization -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- Currently during configure, GHC normalizes the triple passed e.g. with --target. It's not clear why this happens, and it has caused problems in the past (See #12840, #12487), so we should probably either just remove the GHC triples altogether or add some explanations for why they're around. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12830: ARM crosscompile panic
by GHC 15 Nov '16

15 Nov '16

#12830: ARM crosscompile panic -------------------------------------+------------------------------------- Reporter: skovalev | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: arm, | Operating System: Unknown/Multiple crosscompile, panic | Type of failure: Compile-time Architecture: arm | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While building yesod-based project for ARM architecture I have faced with error: {{{ ghc: panic! (the 'impossibel' happened) (GHC version 8.0.1 for arm-unknown-linux): fint_tycon Block [] }}} My yesod packages (inside cabal-sandbox on path `.cabal-sandbox/lib/arm- linux-ghc-8.0.1`): * yesod-1.4.3 * yesod-auth-1.4.13.5 * yesod-core-1.4.25 * yesod-form-1.4.8 * yesod-newsfeed-1.6.4 * yesod-persistent-1.4.0.6 * yesod-static-1.5.0.5 My building machine is `Debian 4.7.8-1`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3