October 2018 - ghc-tickets

[GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications?
by GHC 13 Dec '18

13 Dec '18

#15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- As a part of the work on moving some fragile analyses from Core to final phase before code gen (#9718) I found an unused analysis in CoreToStg which basically assigns each binder this: {{{ data StgBinderInfo = NoStgBinderInfo | SatCallsOnly -- All occurrences are *saturated* *function* calls -- This means we don't need to build an info table and -- slow entry code for the thing -- Thunks never get this value }}} The idea is , as mentioned in the comment, for `SatCallsOnly` binder we can avoid generating code for slow entry. However this is currently not used (see Phab:D5232), and this ticket is to decide whether to use or remove this. I found these comments in `StgCmmClosure` that explains how this became unused and how it was used before: {{{ ----------------------------------------------------------------------------- -- staticClosureRequired ----------------------------------------------------------------------------- {- staticClosureRequired is never called (hence commented out) SimonMar writes (Sept 07) It's an optimisation we used to apply at one time, I believe, but it got lost probably in the rewrite of the RTS/code generator. I left that code there to remind me to look into whether it was worth doing sometime {- Avoiding generating entries and info tables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ At present, for every function we generate all of the following, just in case. But they aren't always all needed, as noted below: [NB1: all of this applies only to *functions*. Thunks always have closure, info table, and entry code.] [NB2: All are needed if the function is *exported*, just to play safe.] * Fast-entry code ALWAYS NEEDED * Slow-entry code Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) we're in the parallel world and the function has free vars [Reason: in parallel world, we always enter functions with free vars via the closure.] * The function closure Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) if the function has free vars (ie not top level) Why case (a) here? Because if the arg-satis check fails, UpdatePAP stuffs a pointer to the function closure in the PAP. [Could be changed; UpdatePAP could stuff in a code ptr instead, but doesn't seem worth it.] [NB: these conditions imply that we might need the closure without the slow-entry code. Here's how. f x y = let g w = ...x..y..w... in ...(g t)... Here we need a closure for g which contains x and y, but since the calls are all saturated we just jump to the fast entry point for g, with R1 pointing to the closure for g.] * Standard info table Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) the function has free vars (ie not top level) NB. In the sequential world, (c) is only required so that the function closure has an info table to point to, to keep the storage manager happy. If (c) alone is true we could fake up an info table by choosing one of a standard family of info tables, whose entry code just bombs out. [NB In the parallel world (c) is needed regardless because we enter functions with free vars via the closure.] If (c) is retained, then we'll sometimes generate an info table (for storage mgr purposes) without slow-entry code. Then we need to use an error label in the info table to substitute for the absent slow entry code. -} staticClosureRequired :: Name -> StgBinderInfo -> LambdaFormInfo -> Bool staticClosureRequired binder bndr_info (LFReEntrant top_level _ _ _ _) -- It's a function = ASSERT( isTopLevel top_level ) -- Assumption: it's a top-level, no-free-var binding not (satCallsOnly bndr_info) staticClosureRequired binder other_binder_info other_lf_info = True -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules
by GHC 12 Dec '18

12 Dec '18

#14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Because of the way the GHCi defaults are applied, specifying `-XMonomorphismRestriction` or `-XNoExtendedDefaultRules` on the GHCi command line doesn't actually make those take effect at the interactive prompt. They get reset to their interactive defaults afterwards. This is rather surprising, and I think it should be fixed. One option is to dig through the parsed flags after setting the defaults to try to find these, but that sounds unpleasant. We're slowly accumulating hacks in this area, and it would be nice to find a better approach. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates
by GHC 12 Dec '18

12 Dec '18

#15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: GHCProposal | 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 [https://github.com/ghc-proposals/ghc-proposals/pull/71 proposal] has been accepted, and could be implemented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[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] #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] #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] #15270: TH doesn't verify name types during conversion
by GHC 11 Dec '18

11 Dec '18

#15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | 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: -------------------------------------+------------------------------------- Angerman reported that a use of the [[http://hackage.haskell.org/package /deriving-compat-0.4.2/docs/src/Data.Eq.Deriving.Internal.html#deriveEq1 `deriveEq`]] splice is causing GHC to abort with an assertion failure: {{{#!hs zonkExpr env (HsVar x (L l id)) = ASSERT2( isNothing (isDataConId_maybe id), ppr id ) return (HsVar x (L l (zonkIdOcc env id))) }}} I suspect the `deriveEq1` is calling `varE` with a DataCon name. We should catch this case and throw a better error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13897: Ship check-ppr in bindist and compile during testsuite run
by GHC 11 Dec '18

11 Dec '18

#13897: Ship check-ppr in bindist and compile during testsuite run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 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: -------------------------------------+------------------------------------- Currently `check-ppr` is built during the compiler build and used by the testsuite in the pretty-printer tests. In a source checkout this is fine, however this arrangement blows up in the case of a binary distribution as we don't (and probably shouldn't) ship the `check-ppr` binary in the bindist. I think the most reasonable way to deal with this is to instead ship the `check-ppr` source (perhaps in the testsuite tarball) and build it as a dependency of the testsuite. Ideally we would build the executable once and use it for each of the ppr tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13897> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15608: Segfault in retainer profiling
by GHC 11 Dec '18

11 Dec '18

#15608: Segfault in retainer profiling -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | 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: -------------------------------------+------------------------------------- To reproduce, build ghc using "prof" flavor, then {{{ $ ghc-stage2 --interactive +RTS -hr GHCi, version 8.7.20180905: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/omer/rcbackup/.ghci λ:1> sequence_ (replicate 100000000 (return ())) zsh: segmentation fault (core dumped) ghc-stage2 --interactive +RTS -hr }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9