- ghc-tickets - Haskell.org

[GHC] #16041: Address warnings reported by -Wincomplete-uni-patterns and -Wincomplete-record-updates
by GHC 12 Dec '18

12 Dec '18

#16041: Address warnings reported by -Wincomplete-uni-patterns and -Wincomplete- record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15656 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While implementing the GHC proposal which adds these flags to {{{-Wall}}}, we suppressed a lot of warnings generated due to code that is considered ''unsafe'' per these flags. However, the proper way to fix this is to refine things so that these warnings go away. See https://ghc.haskell.org/trac/ghc/ticket/15656#comment:6 for more details. w -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16041> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16027: Cannot use DefaultSignatures for TypeFamiles
by GHC 12 Dec '18

12 Dec '18

#16027: Cannot use DefaultSignatures for TypeFamiles -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- I'm surprised there wasn't a ticket for this. Maybe I just couldn't find it. In short, I want to do something like: {{{ class Monad m => MyMonad m where type AssociatedMonad m :: Type -> Type default type AssociatedMonad m :: (m ~ t m', MonadTrans t, MyMonad m') => Type -> Type type AssociatedMonad (t m') = t (AssociatedMonad m') fun :: Foo -> m () default fun :: (m ~ t m', MonadTrans t, MyMonad m') => Foo -> m () fun = lift . fun }}} The syntax is a bit weird, but I hope in the process of implementing constrained type families the syntax properly analogous to the term-level would shake itself out. The use-case, like the normal method original, is to assist with monad transformer boilerplate. {{{MonadTrans}}} wouldn't be enough, but {{{MFunctor}}} from mmorph might be depending on the method using the associated type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16027> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs
by GHC 11 Dec '18

11 Dec '18

#11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10458 #5289 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In particular when compiling on NixOS, but also in many other situations, it is often needed to pass --extra-lib-dirs / --extra-include-dirs to cabal/stack, to help GHC find required system libraries. This works fine for GHC, but not GHCi, and therefore also not Template Haskell code. Minimal example attached. Try it in an environment where libz is not in a standard location, e.g. inside a nix-shell. Note that if you remove the template Haskell splice in Main.hs, the code compiles just fine. This affects GHC 7.10.2, but also HEAD from 2015-08-28, even one including Tamar Christina's 5d841108acef950fed6a5e608ac9b18e7431aa87 commit cherry- picked. I haven't been able to test more recent HEAD, because of unrelated compilation issues. I surmise that a fix to #10458, which currently blocks using HaskellR in GHCi, would also fix this, but I'm not sure. The error message I get is different: {{{ $ stack build --skip-ghc-check --extra-lib- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/lib --extra- include- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/include b-0.1.0.0: build Preprocessing executable 'b' for b-0.1.0.0... [2 of 2] Compiling Main ( src/Main.hs, .stack- work/dist/x86_64-linux/Cabal-1.23.0.0/build/b/b-tmp/Main.o ) <command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory) -- While building package b-0.1.0.0 using: /home/mboes/.stack/setup-exe-cache/setup-Simple- Cabal-1.23.0.0-x86_64-linux-ghc-7.11.20150828 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.23.0.0/ build exe:b --ghc-options " -ddump- hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings
by GHC 11 Dec '18

11 Dec '18

#15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings -------------------------------------+------------------------------------- Reporter: NeilMitchell | 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: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using GHC 8.4.3, I'd expect the following to work: {{{#!hs {-# LANGUAGE RebindableSyntax, OverloadedStrings #-} module Fail where import Prelude hiding (fail) foo x = do Just y <- x return y newtype Text = Text String fail :: Text -> a fail (Text x) = error x fromString :: String -> Text fromString = Text }}} But it fails with: {{{ Fail.hs:8:5-15: error: * Couldn't match expected type `[Char]' with actual type `Text' * In a stmt of a 'do' block: Just y <- x In the expression: do Just y <- x return y In an equation for `foo': foo x = do Just y <- x return y | 8 | Just y <- x | ^^^^^^^^^^^ }}} Given the enabled extensions, I'd expect {{{foo}}} to desugar as: {{{#!hs foo x = x >>= \v -> case v of Just y -> return y _ -> fail (fromString "pattern match error") }}} But looking at TcMatches.tcMonadFailOp it checks the fail operation (which is literally {{{fail}}}) takes an argument of type tyString (e.g. {{{[Char]}}}). One way around that would be to make the "fail-op" being passed around be {{{fail . fromString}}} if the appropriate extensions are enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15645> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux
by GHC 11 Dec '18

11 Dec '18

#15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux ----------------------------------------+--------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.7 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #15847 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- ghc assumes that on linux, C compiler (e.g. gcc) will build non-PIC object code when no `-fPIC` is passed. But this is no longer true for recent gcc version on some distributions. e.g. {{{ $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ gcc --version gcc (GCC) 7.3.1 20180312 $ touch dummy.c $ gcc -Q -v dummy.c 2>&1 | grep PIC options enabled: -fPIC -fPIE -faggressive-loop-optimizations }}} We need pass `-fno-PIC` explicitly just like `-no-pie`. In particular, this results in 300+ ext-interp related tests to fail on i386 when built with a gcc that has `-fPIC` on by default, as we don't support loading non-PIC .o built from .c on i386. (See #15847, fix this bug will mitigate #15847) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15848> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15826: Allow using (Source)Plugins through the GHC API
by GHC 11 Dec '18

11 Dec '18

#15826: Allow using (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- One might expect to be able to load plugins through the GHC API by doing something like: {{{ runGHC $ do dflags <- getSessionDynFlags setSessionDynFlags dflags { plugins = [LoadedPlugin some_plugin _conjure_up_modiface []] } }}} but this doesn't actually work because the `plugins` field in `DynFlags` is used as a cache and overwritten by `initializePlugins` whenever plugins loaded through the command-line need reloading. Not to mention that there isn't a meaningful way to fill the `_conjure_up_modiface` hole AFAIK. While in principle it might be possible to use source plugins via the API right now by messing with the exposed cmdline flags the right way it feels much cleaner to just have a new type of plugin that can be added to GHC right through the API. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15826> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15854: PPC: Panic in native code generator
by GHC 11 Dec '18

11 Dec '18

#15854: PPC: Panic in native code generator ---------------------------------+---------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+---------------------------------------- Head fails on powerpc64le: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181103 for powerpc64le-unknown-linux): PPC.CodeGen.getRegister: no match Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.o' failed }}} I think I know what is going on and will work on a fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14225: "No module named ... is imported" message is a bit misleading with qualified imports
by GHC 11 Dec '18

11 Dec '18

#14225: "No module named ... is imported" message is a bit misleading with qualified imports -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: low | 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: -------------------------------------+------------------------------------- It seems that the `No module named ... is imported` message produced in response to out-of-scope identifiers doesn't account for qualified imports. For instance, {{{ $ ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci λ> import qualified Data.Maybe as M λ> M.fromJusr <interactive>:2:1: error: Not in scope: ‘M.fromJusr’ Perhaps you meant ‘M.fromJust’ (imported from Data.Maybe) No module named ‘M’ is imported. λ> }}} I suppose there is the question of whether we consider `M` to be a "module" here; I would argue that I imported it and therefore the message is at very least a bit misleading. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15924: Do not save performance test results if work tree is dirty
by GHC 11 Dec '18

11 Dec '18

#15924: Do not save performance test results if work tree is dirty -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Keywords: performance | Operating System: Unknown/Multiple tests git notes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12758 Differential Rev(s): | Wiki Page: | Performance/Tests -------------------------------------+------------------------------------- The test driver will automatically save performance results to git notes. Notes are attached to commits, but if the working tree is dirty, performance characteristics my be affected and the saved results will not be valid. * Only save performance test results if work tree is dirty. * Bonus: don't save to a git note if we have 0 results. * Update wiki page. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15924> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16026: No way to run a subset of the testsuite
by GHC 11 Dec '18

11 Dec '18

#16026: No way to run a subset of the testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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 lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16026> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12