- ghc-tickets - Haskell.org

[GHC] #15230: unix tests fail under CircleCI's fedora environment
by GHC 15 Jun '18

15 Jun '18

#15230: unix tests fail under CircleCI's fedora environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | 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: -------------------------------------+------------------------------------- It's a bit unclear what is going on here: {{{ =====> getGroupEntryForName(normal) 6377 of 6403 [0, 0, 0] Actual stdout output differs from expected: --- ../../libraries/unix/tests/user001.run/user001.stdout.normalised 2018-06-05 15:18:37.243934191 +0000 +++ ../../libraries/unix/tests/user001.run/user001.run.stdout.normalised 2018-06-05 15:18:37.243934191 +0000 @@ -6,6 +6,6 @@ getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK -getAllGroupEntries: OK +getAllGroupEntries: ERROR: getAllGroupEntries: does not exist (No such file or directory) getUserEntryForID: OK getAllUserEntries: OK *** unexpected failure for user001(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15230> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14600: Work out why Hadrian builds routinely fail
by GHC 15 Jun '18

15 Jun '18

#14600: Work out why Hadrian builds routinely fail -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 Hadrian builds inexplicably and non-deterministically fail on CircleCI. They fail with, {{{ | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_l.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_debug.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_debug.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_l.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_p.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffidebug_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_debug_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffil_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_l_-ghc8.5.20171218.so | Successfully built custom library 'libffi' Too long with no output (exceeded 10m0s) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14600> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15277: Move field name resolution to the type-checker
by GHC 15 Jun '18

15 Jun '18

#15277: Move field name resolution to the type-checker -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: ORF | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15149 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Per discussion on #15149, we plan to make the type-checker responsible for all field name lookup in record construction, pattern-matching and updates. This should be simpler than the current story and let us get rid of `tcg_field_env`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15277> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15215: GHC HEAD internal error when FlexibleContexts isn't enabled
by GHC 15 Jun '18

15 Jun '18

#15215: GHC HEAD internal error when FlexibleContexts isn't enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code produces a GHC internal error on GHC HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data A :: Type -> Type where MkA :: Show (Maybe a) => A a data SA :: forall a. A a -> Type where SMkA :: SA MkA }}} {{{ $ ~/Software/ghc5/inplace/bin/ghc-stage2 Bug.hs[1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:3: error: • Non type-variable argument in the constraint: Show (Maybe a) (Use FlexibleContexts to permit this) • In the definition of data constructor ‘MkA’ In the data type declaration for ‘A’ | 9 | MkA :: Show (Maybe a) => A a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:12:14: error: • GHC internal error: ‘MkA’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [rqU :-> ATcTyCon SA :: forall a. A a -> *, rsV :-> APromotionErr RecDataConPE] • In the first argument of ‘SA’, namely ‘MkA’ In the type ‘SA MkA’ In the definition of data constructor ‘SMkA’ | 12 | SMkA :: SA MkA | ^^^ }}} Enabling `FlexibleContexts` causes the internal error to go away. This is a regression from GHC 8.4, which does not give an internal error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15276: Bogus type in typechecker error recovery
by GHC 15 Jun '18

15 Jun '18

#15276: Bogus type in typechecker error recovery -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- If the typechecker sees {{{ let f = <rhs> in <body> }}} and there's a type error in `<rhs>`, GHC recovers from the error, binds `f` to "a type that should cause no more trouble", and continues with `<both>` in the hope of finding more type errors. What is "a type that should cause no more trouble"? Well `forall a.a` seems like a good candidate. But, in this commit {{{ commit 6746549772c5cc0ac66c0fce562f297f4d4b80a2 Author: Richard Eisenberg <eir(a)cis.upenn.edu> Date: Fri Dec 11 18:19:53 2015 -0500 Add kind equalities to GHC. }}} we made the type look like this: `forall r. forall (a :: TYPE r). a` Alas! That type is ill-formed because the kind `TYPE r` escapes the scope of `f`. I discovered this when beefing up `typeKind` in pursuit of #14939 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15237: New SRT scheme breaks -fvia-C
by GHC 15 Jun '18

15 Jun '18

#15237: New SRT scheme breaks -fvia-C -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- The SRT rework implemented in 2b0918c9834be1873728176e4944bec26271234a introduces a sub-word-size field into `StgSRT`. Unfortunately `-fvia-C` doesn't support such fields. This breaks CircleCI's unregisterised target. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15237> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #4806: Make error message more user friendly when module is not found because package is unusable
by GHC 14 Jun '18

14 Jun '18

#4806: Make error message more user friendly when module is not found because package is unusable -------------------------------------+------------------------------------- Reporter: mitar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4783 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks! The new error messages look good to me! I'll give dfeuer a few days to respond to your review. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4806#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15259: Out-of-scope-variables error still can be deferred in ghci
by GHC 14 Jun '18

14 Jun '18

#15259: Out-of-scope-variables error still can be deferred in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 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: -------------------------------------+------------------------------------- Deferring type errors is unhelpful in ghci, since the expression is evaluated immediately. In #11130, we disabled typed holes in ghci as well. The `-fdefer-out-of-scope-variables` should also be disabled in ghci. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags
by GHC 14 Jun '18

14 Jun '18

#15268: Clarify and test the interaction of -with-rtsopts and -rtsopts flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Looking at the user manual it's not clear how do `-with-rtsopts` and `-rtsopts` flags interact. I'd expect `-with-rtsopts` to work even with `-rtsopts=ignoreAll`, but I don't know if this is really the case, and because we don't have a way to print RTS flags (see #15261 for this) it's hard to make sure this works as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15268> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14601: Remove uses of unsafeGlobalDynFlags for -fopt-coercions
by GHC 14 Jun '18

14 Jun '18

#14601: Remove uses of unsafeGlobalDynFlags for -fopt-coercions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Currently the `-fopt-coercions` flag finds its way to `OptCoercion.optCoercion` by way of the terrible `unsafeGlobalDynFlags`. In general it's nice to minimize the uses of `unsafeGlobalDynFlags`. However, it's not entirely clear that passing a `DynFlags` to `optCoercion` is worthwhile in this case as `-fopt-coercion` is essentially a debug flag. Leaving this here for later consideration. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1