- ghc-tickets - Haskell.org

[GHC] #15320: Save the types in the typechecked syntax tree
by GHC 30 Jan '19

30 Jan '19

#15320: Save the types in the typechecked syntax tree -------------------------------------+------------------------------------- Reporter: nboldi | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- When working on development tools that use the GHC API as a backend, it is useful to have information on the types (or kinds) of the elements of the syntax tree (expressions, patterns, types). I found that the lack of this semantic information is limiting in some cases of refactoring transformations (for example to generate the type signature or extract a subexpression to a binding with type signature), and is necessary for tools that try to fix common programmer errors. But there should be other kind of tools that this little change may help. The type is currently saved for some expressions and most patterns but it would be useful if it would be available uniformly. It could be implemented nicely by adding type information to the `X* GhcTc` type families. I plan to implement these changes, I'm just asking the opinion of the developers about a change in this direction. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15320> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16144: GHC with valid license on windows
by GHC 30 Jan '19

30 Jan '19

#16144: GHC with valid license on windows -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: incorrect | Operating System: Unknown/Multiple license on windows | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, I am unable to upgrade on windows to either 8.4.* or 8.6.* since for these version with the right licenses (in particular using integer-simple) are available. Could you please make the windows version of GHC with BSD3 / MIT license available on the next release? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #3372: Allow for multiple linker instances
by GHC 29 Jan '19

29 Jan '19

#3372: Allow for multiple linker instances -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: | JulianLeviston Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): This is my plan so far: - add `DynLinker` `newtype` and use feed it into all the functions where we used to use the `v_PersistentLinkerState` global `IORef` state - rewrite `modifyPLS` and `modifyPLS_` to work with the passed-in `DynLinker` `IORef` value rather than the global - survey all the places where we've added `DynLinker` as an argument (in 1st *or* 2nd pos) extendLoadedPkgs - extendLinkEnv - deleteFromLinkEnv - getHValue - withExtendedLinkEnv - initDynLinker - reallyInitDynLinker - linkCmdLineLibs - linkExpr - linkDecls - linkModule - unload - linkPackages - - refactor all the surveyed call sites such that they're also passing now the DynLinker argument - rewrite initDynLinker as per wiki - rewrite withLinkerState as per wiki (this is just old modifyPLS, basically...) - rewrite readPLS to be passed DynLinker and refactor its sole call-site - rewrite modifyMbPLS_ so it works with DynLinker - try compiling and fix any errors - write a test -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3372#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk`
by GHC 29 Jan '19

29 Jan '19

#16253: Offer a shorthand for `--skip=_build/stage$n/compiler/.dependencies.mk` -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (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: -------------------------------------+------------------------------------- When working on a stage1 compiler, the slightest change in any of the files leads to rebuilding the dependency matrix, which takes 20-30s time. That makes for a very disruptive edit-compile cycle. Alp helped me on #ghc and found `--skip=_build/stage0/compiler/.dependencies.mk` as the right flag to skip dependency rebuilding. I wonder if could hide that behind a nicer flag? I think this should do similar things as `--freeze1`, only that we 'freeze' stage 0 and dependency building. The analogy is that we need a hadrian equivalent of `make -C ghc 1` as we have `--freeze1` for `make -C ghc 2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16253> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #15970: Recompilation bug with default class methods
by GHC 28 Jan '19

28 Jan '19

#15970: Recompilation bug with default class methods -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: -------------------------------------+------------------------------------- Repro as follows. A.hs: {{{ {-# OPTIONS_GHC -fno-full-laziness #-} module A (toTypedData, toTypedDataNoDef) where toTypedData :: String -> IO Int toTypedData s = wrapPrint "yoyo" $ toTypedDataNoDef s wrapPrint :: String -> IO Int -> IO Int wrapPrint s act = do putStrLn s act toTypedDataNoDef :: String -> IO Int toTypedDataNoDef s = return $ length s }}} B.hs: {{{ module B ( TypeClass(..) ) where import A class Show a => TypeClass a where getSize :: a -> IO Int getSize a = toTypedData (show a) printA :: a -> IO () }}} C.hs: {{{ module Main where import B data MyDataType = MyDataType String Int deriving Show instance TypeClass MyDataType where printA = putStrLn . show main :: IO () main = do let myValue = MyDataType "haha" 99 sz <- getSize myValue putStrLn $ show sz printA myValue }}} 1. Comment out the `-fno-full-laziness` option in A.hs 2. `rm *.o *.hi; ghc -O2 C.hs` 3. Re-enable the `-fno-full-laziness` option in A.hs 4. `ghc -O2 C.hs` Produces a linker error: {{{ C.o:Main_main1_info: error: undefined reference to 'A_toTypedData2_closure' C.o(.data.rel.ro+0x48): error: undefined reference to 'A_toTypedData2_closure' collect2: error: ld returned 1 exit status }}} Reproduced in 8.0, 8.4 and master. Probably happens in all released versions of GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16250: Make it easy to invoke Hadrian
by GHC 28 Jan '19

28 Jan '19

#16250: Make it easy to invoke Hadrian -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (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: -------------------------------------+------------------------------------- Right now, invoking Hadrian requires running `hadrian/build.sh`. That's a small mouthful (when using it regularly), and it crucially depends on being in the root directory of GHC. It would be very convenient to have some command (say, `build`) which would work ''anywhere'' within the GHC tree, e.g. by searching for the root and then running the local Hadrian build script. Doing this would require devs to install something locally (so that it's in the PATH always), but that something can be small and light. Shall we fix? Thanks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16250> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16232: Add setField to HasField
by GHC 28 Jan '19

28 Jan '19

#16232: Add setField to HasField -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 (Type checker) | Keywords: ORF | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This ticket is to track the implementation of https://github.com/ghc- proposals/ghc-proposals/blob/master/proposals/0042-record-set-field.rst I've made a start on the implementation but have a question on which I'd appreciate some input: how should the dictionary for `HasField` be generated? To recap, recall that at present, `HasField x r a` is coercible to `r -> a` so the dictionary can be constructed merely by taking the selector function for the field and wrapping it in an appropriate coercion. With the proposal, `HasField x r a` will instead be represented as `r -> (a -> r, a)` where the first component of the tuple is an update function. The problem is how to define this update function in Core. This function should perform case analysis on the record data type, where each case replaces the value of the field being updated and preserves all the other fields. For example, given a data type `data T = MkT { foo :: Int, bar :: Bool }` we need to generate {{{#!hs \ r x -> case r of MkT {foo = _, bar = bar} -> MkT { foo = x, bar = bar } }}} The most obvious approach is to generate well-typed Core for the update function directly, but this seems to be rather complex, in particular because of the worker/wrapper distinction, as one ends up reconstructing much of the typechecking/desugaring for record pattern matching and construction. This also seems like a lot of work to do every time a `HasField` constraint is solved. Would it be reasonable to generate update functions for fields at definition sites, as we do for selector functions? I've implemented this in the past, and it is relatively simple to generate renamed syntax to feed in to the type-checker. However, this would add some overhead for every field, even if `HasField` was not subsequently used, and would require some naming scheme for update functions. Or are there other options? Is there some way to solve a `HasField` constraint and construct its dictionary by emitting renamed syntax for subsequent type-checking, such that subsequently solving similar constraints will use the same dictionary? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16241: Avoid orphan instances with OVERLAPPABLE (sometimes)
by GHC 28 Jan '19

28 Jan '19

#16241: Avoid orphan instances with OVERLAPPABLE (sometimes) -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #15135 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not sure whether to count this as a bug or a feature. If it's 'intended behaviour', what is the intent, exactly? GHC is on the verge of doing something useful, but it's inconsistent and "fragile" (as the warning does tell me). Consider the standard example of what goes wrong with orphan instances, from the [https://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/glasgow_exts… #overlapping-instances big red **warning** in the Users Guide]. (Version 1 lightly adapted to use `OVERLAPPING` rather than the now-deprecated `Overlapping Instances`.) {{{#!hs {-# LANGUAGE FlexibleInstances, FlexibleContexts #-} module Help where class MyShow a where myshow :: a -> String instance MyShow a => MyShow [a] where -- version 1 -- instance {-# OVERLAPPABLE #-} -- version 2 -- MyShow a => MyShow [a] where myshow xs = concatMap myshow xs showHelp :: MyShow a => [a] -> String -- version 1 -- showHelp :: MyShow [a] => [a] -> String -- version 2 showHelp xs = myshow xs {-# LANGUAGE FlexibleInstances #-} module Main where import Help data T = MkT instance MyShow T where myshow x = "Used generic instance" instance {# OVERLAPPING #} MyShow [T] where myshow xs = "Used more specific instance" main = do { print (myshow [MkT]); print (showHelp [MkT]) } }}} Version 1 gives the as-warned incoherent behaviour ("different instance choices are made in different parts of the program" -- that is, in different modules for the (apparently) same code `myshow xs`.) If and only if both changes marked `version 2` are in place, `myshow xs` returns the same result from both calls consistently. Why? Because the `MyShow [a] =>` constraint on `showHelp`'s sig sees that exactly matches an instance head, and that the head is marked `OVERLAPPABLE`. But GHC is not happy {{{ ... warning: [-Wsimplifiable-class-constraints] * The constraint `MyShow [a]' matches an instance declaration instance [overlappable] MyShow a => MyShow [a] This makes type inference for inner bindings fragile; either use MonoLocalBinds, or simplify it using the instance }}} Hmm: wrong advice: simplifying the constraint using the instance gives us the version 1 signature, which exactly makes `showHelp` use the orphan instance. ''Does'' version 2 make inference for inner bindings fragile? I think only if the instance is not marked `OVERLAPPABLE`. IOW a tentative rule would be 'OVERLAPPABLE constraints should not be simplified!' Inconsistencies I see: * Marking overlappable instances as `OVERLAPPABLE` is not merely the mirror-image of marking the overlapping instance as `OVERLAPPING`: you get different behaviour. * The `OVERLAPPABLE` pragma, when you already have `OVERLAPPING` to accept the instances, is not merely a comment. * This makes an observable difference under separate compilation, contra SPJ's ticket:15135#comment:9 . * ticket:15135#comment:1 is also relevant "I think it's arguable that an instance should only be overlappable if it says `{-# OVERLAPPABLE #-}`. But that's not our current spec." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16241> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12758: Bring sanity to our performance testsuite
by GHC 28 Jan '19

28 Jan '19

#12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | 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: -------------------------------------+------------------------------------- The GHC testsuite's performance tests tends to be a constant source of busy-work as it requires that contributors manually bump performance numbers and propagate these changes across platforms. Moreover, the testsuite is poor at noticing performance regressions due to false positive failures (due to spurious environmental differences) and false negatives (due to the rather generous acceptance windows that many tests have). Joachim and I briefly discussed this at Hac Phi and came up with the following proposal: * We rip expected performance numbers out of the `.T` files * -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #16160: TH_NestedSplices fails on Windows
by GHC 27 Jan '19

27 Jan '19

#16160: TH_NestedSplices fails on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ Compile failed (exit code 11) errors were: Access violation in generated code when executing data at 0x0 Attempting to reconstruct a stack trace... Frame Code address Null address *** unexpected failure for TH_NestedSplices(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16160> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6