- ghc-tickets - Haskell.org

[GHC] #15238: T13838 fails in ghci way
by GHC 08 Jun '18

08 Jun '18

#15238: T13838 fails in ghci way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- {{{ Wrong exit code for T13838(ghci) (expected 1 , actual 0 ) Stderr ( T13838 ): T13838:6:30: error: • Couldn't match expected type ‘IO a0’ with actual type ‘() -> ()’ • Probable cause: ‘main’ is applied to too few arguments In the first argument of ‘GHC.TopHandler.runIOFastExit’, namely ‘main’ In the first argument of ‘(>>)’, namely ‘GHC.TopHandler.runIOFastExit main’ In the expression: GHC.TopHandler.runIOFastExit main >> return () *** unexpected failure for T13838(ghci) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15238> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ...
by GHC 08 Jun '18

08 Jun '18

#12023: Problems getting information and kind from GHC.Prim ~#, ~R#, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- {{{ >>> import GHC.Prim >>> :bro GHC.Prim [...] type role (~#) nominal nominal data (~#) (t3 :: a) (t4 :: b) type role ~P# phantom phantom data ~P# (t3 :: a) (t4 :: b) type role (~R#) representational representational data (~R#) (t3 :: a) (t4 :: b) }}} getting the kind of `~`, `~#`, `~~` works fine: {{{ >>> import GHC.Prim >>> import GHC.Types >>> :kind (~) (~) :: k -> k -> Constraint >>> :kind (~#) (~#) :: a -> b -> TYPE 'VoidRep >>> :kind (~~) (~~) :: j -> k -> Constraint }}} but `#` gets incorrectly treated as an operator in `~R#` and `~P#`: {{{ >>> :kind (~R#) <interactive>:1:3: error: Illegal operator ‘#’ in type ‘~R #’ Use TypeOperators to allow operators in types <interactive>:1:3: error: Operator applied to too few arguments: ~R # <interactive>:1:4: error: Not in scope: type constructor or class ‘R’ }}} Furthermore while running `:info` on `~~` and `~#` works fine {{{ >>> :info (~~) class a ~# b => (~~) (a :: j) (b :: k) -- Defined in ‘GHC.Types’ >>> :info (~#) type role (~#) nominal nominal data (~#) (t3 :: a) (t4 :: b) -- Defined in ‘GHC.Prim’ }}} the others don't parse {{{ >>> :info (~) <interactive>:1:2: error: parse error on input ‘~’ >>> :info (~R#) <interactive>:1:2: error: parse error on input ‘~’ >>> :info (~P#) <interactive>:1:2: error: parse error on input ‘~’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12023> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15236: GHCi pretty-prints (->)'s fixity poorly
by GHC 08 Jun '18

08 Jun '18

#15236: GHCi pretty-prints (->)'s fixity poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- Consider the following GHCi session: {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :i (->) data (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’ infixr 0 `(->)` <instances elided> }}} Notice that it prints: {{{ `(->)` }}} Which is totally wrong. This should simply be `->`. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15232: TypeError is reported as "redundant constraint" starting with GHC 8.2
by GHC 08 Jun '18

08 Jun '18

#15232: TypeError is reported as "redundant constraint" starting with GHC 8.2 -------------------------------------+------------------------------------- Reporter: fsoikin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple CustomTypeErrors | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program compiles fine on GHC 8.0.2, but GHC 8.2.2 issues a warning, complaining that `TypeError` is a redundant constraint. This makes it very inconvenient to use `TypeError` with type classes. {{{#!hs {-# OPTIONS_GHC -Wredundant-constraints -Wall -Werror #-} import GHC.TypeLits (TypeError, ErrorMessage(..)) class C a where f :: a -> a instance {-# OVERLAPPING #-} C Int where f _ = 42 instance {-# OVERLAPPABLE #-} TypeError ( 'Text "Only Int is supported" ) => C a where f = undefined main :: IO () main = print $ f (42::Int) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc
by GHC 08 Jun '18

08 Jun '18

#15229: Run typeCheckResultAction and renamedResultAction in TcM rather than Hsc -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: plugins | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4792 | Wiki Page: -------------------------------------+------------------------------------- The primary motivation for this is that this allows users to access the warnings and error machinery present in TcM. However, it also allows users to use TcM actions which means they can typecheck GhcPs which could be significantly easier than constructing GhcTc. See https://phabricator.haskell.org/D4792 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15212: powerpc64le-unknown-linux is missing from llvm-targets
by GHC 07 Jun '18

07 Jun '18

#15212: powerpc64le-unknown-linux is missing from llvm-targets ---------------------------------+--------------------------------- Reporter: admock | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+--------------------------------- T5681 fails with: Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180531 for powerpc64le-unknown-linux): Failed to lookup the datalayout for powerpc64le-unknown-linux; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unkno wn-linux-gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux- gnueabihf","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux- gnueabihf","aarch64-unknown-linux-gnu","aarch64-unknown-linux","i3 86-unknown-linux-gnu","i386-unknown-linux","x86_64-unknown-linux- gnu","x86_64-unknown-linux","armv7-unknown-linux-androideabi","aarch64 -unknown-linux-android","arm-unknown-nto-qnx-eabi","i386-apple-darwin ","x86_64-apple-darwin","armv7-apple-ios","aarch64-apple-ios","i386-apple- ios","x86_64-apple-ios"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15212> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends
by GHC 07 Jun '18

07 Jun '18

#14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: ghc-pkg | Version: 8.2.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: -------------------------------------+------------------------------------- In GHC 8.2, we introduced `abi-depends` to solve #12485. Following the same pattern as all ghc-pkg fields, this field is to be fllled by whoever is performing the registration. I now suspect designing it this way was a mistake. In https://github.com/haskell/cabal/issues/4728 we have a bug where Cabal is writing nonsense data for `abi-depends`, `ghc-pkg` isn't noticing it, and GHC is rejecting the package (with a "shadow" warning) when it gets to the end. The problem is the Cabal aggressively caches the contents of the package database (ostensibly because it is expensive to query `ghc-pkg`); this means that it is easy to get into a situation where its understanding of the ABIs of its dependencies is out-of-date (because it is not re- reading the database in order to get newer information). The insult to the injury is, in most cases, ghc-pkg already knows what the ABIs are supposed to be: they're whatever the ABIs of the packages pointed at by 'depends' already in the database are. So ghc-pkg could have computed the abi dependency itself, and prevented this stale data situation from ever happening. This sounds quite attractive to me. What do people think? Here is one possible proposal (but it is just one in the space): * `ghc-pkg` will be modified to ignore the `abi-depends` field (perhaps with a warning), to prevent itself from being poisoned by buggy versions of Cabal which are giving bad ABI information * Instead, `ghc-pkg` generates the `abi-depends` field by looking up dependency IDs from the database. If an ID is not found, it omits the dep from `abi-depends` (this is equivalent to suspending ABI checking in GHC, so this won't break anything; it will just make ABI checking less robust) * Possibly, introduce a new "virtual" field, which can be used to override `ghc-pkg` default -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13438: ghci :browse does not work with DuplicateRecordFields
by GHC 07 Jun '18

07 Jun '18

#13438: ghci :browse does not work with DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple duplicaterecordfields ghci | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using `:browse` on module which has enabled DuplicateRecordFields and datatypes are exported, does not return the field accessor functions. So for example: {{{#!hs data Login = Login { code :: Text , password :: Text } )}}} `browse` for module does not return `code` and `password` accessor functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13438> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13471: segmentation fault by compiling GHC
by GHC 06 Jun '18

06 Jun '18

#13471: segmentation fault by compiling GHC -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi,\\ I tried to compile GHC on my computer.\\ by compiling GHC under Linux I got this error message.\\ {{{ compiler/ghc.mk:588: recipe for target 'compiler/stage2/build/DynFlags.o' failed make[1]: *** [compiler/stage2/build/DynFlags.o] segmentation fault Makefile:122: recipe for target 'install' failed make: *** [install] Error 2 }}} on my computer Linux runs on VirtualBox.\\ the problem is probably with my hardware but as I know nothing I tell you this issue.\\ {{{ ~/ghc/inplace/bin$ /ghc-stage1 --version The Glorious Glasgow Haskell Compilation System, version 8.3.20170322 }}} Hope this help\\ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13471> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14713: GHCi doesn't load project.
by GHC 06 Jun '18

06 Jun '18

#14713: GHCi doesn't load project. -------------------------------------+------------------------------------- Reporter: recursion- | Owner: (none) ninja | Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: GHCi crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got the following output when trying to load my Haskell project into GHCi using stack: {{{ GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc3372_0/libghc_13.so: undefined symbol: numStates_g Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} No other informative output was displayed. Output says report the defect, so you get a "bug report." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6