June 2016 - ghc-tickets

[GHC] #12161: Panic when literal is coerced into function
by GHC 13 Jun '16

13 Jun '16

#12161: Panic when literal is coerced into function -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: ⊥ 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: -------------------------------------+------------------------------------- I don't think there is ever a legitimate use-case for any code which triggers this error, but it does seem to indicate some sort of problem with how ANF Core is defined. Consider: {{{ {-# LANGUAGE MagicHash #-} module G where import GHC.Prim f :: a -> a f = unsafeCoerce# 5# g = case f True of True -> () False -> () }}} When I build this I get: {{{ ezyang@sabre:~$ ghc-8.0 -c G.hs -fforce-recomp ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160204 for x86_64-unknown-linux): CoreToStg.myCollectArgs (5# `cast` (UnsafeCo representational Int# (Bool -> Bool) :: Int# ~R# (Bool -> Bool))) True Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} According to the specification of ANF Core in `CorePrep`, this Core is perfectly legitimate: {{{ Trivial expressions triv ::= lit | var | triv ty | /\a. triv | truv co | /\c. triv | triv |> co Applications app ::= lit | var | app triv | app ty | app co | app |> co Expressions body ::= app | let(rec) x = rhs in body -- Boxed only | case body of pat -> body | /\a. body | /\c. body | body |> co Right hand sides (only place where value lambdas can occur) rhs ::= /\a.rhs | \x.rhs | body }}} as the terminal productions for an `app` include both literals and variables. However, `myCollectArgs` assumes that there are only variables in the function position. So it seems that in practice we need a stronger invariant on ANF. An obvious fix is to remove `lit` from `app`, but that is not quite enough because then there is no way to represent expressions of the form `let x = lit in body` (in particular, `MachStr` and `LitInteger` are not considered trivial and may very well be let-bound). So perhaps the right way to do this is to remove `lit` from `app`, and add it to `body`: {{{ Trivial expressions triv ::= lit | var | triv ty | /\a. triv | truv co | /\c. triv | triv |> co Applications (removed lit) app ::= var | app triv | app ty | app co | app |> co Expressions (added lit) body ::= app | lit | let(rec) x = rhs in body -- Boxed only | case body of pat -> body | /\a. body | /\c. body | body |> co Right hand sides (only place where value lambdas can occur) rhs ::= /\a.rhs | \x.rhs | body }}} the point being that we never have an application with a literal in function position. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11638: referring to the existential type from a GADT pattern match with a type application
by GHC 12 Jun '16

12 Jun '16

#11638: referring to the existential type from a GADT pattern match with a type application -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11387 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently I can define a GADT like {{{ data T where MkT :: forall a. (Num a, Show a) => T }}} but it's useless on two counts: * At a use of the constructor `MkT`, I can't specify what type `a` I want to pack dictionaries for. (In fact the declaration is an error unless either the constraints are defaultable (as in the case above) or AllowAmbiguousTypes is enabled.) * At a pattern match against `MkT`, I have no way to refer to the type for which dictionaries were packed. The solution is to add a field of type `Proxy a` (possibly strict/unpacked) or `Proxy# a` to `MkT`. But these options are all a bit verbose and each have minor drawbacks. I had hoped that TypeApplications would address the two points above directly. * At a use of the constructor `MkT`, specify the type with a type application `MkT @a`. This part works as of 90f35612f16ff9cb2466cc936f12e748402abb85. * At a pattern match against `MkT`, I would like to be able to match the type directly like this: {{{ f :: T -> String f t = case t of MkT @a -> show (0 :: a) }}} This is the feature request. Note that, while this may be stressful for the parser due to as-patterns, I don't think there is any actual ambiguity as long as (1) type applications only appear on constructors, not variables, and (2) all type applications appear before any value-level fields of the constructor. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file.
by GHC 12 Jun '16

12 Jun '16

#6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This test always fails for me on OSX. {{{ =====> T6132(normal) 4 of 4 [0, 0, 0] cd "/var/folders/3z/_vqy7kmx4pd90sg_v80zpk340000gn/T/ghctest-UHP1ob/test spaces/1/2/3/./T6132" && "/Users/matt/Documents/haskell/ghc/inplace/test spaces/ghc-stage2" -c T6132.hs -fforce-recomp -dcore-lint -dcmm-lint -dno- debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed- specialisations -fshow-warning-groups -fno-ghci-history > T6132.comp.stderr 2>&1 Compile failed (status 256) errors were: T6132.hs:1:2: error: parse error on input ‘#!/’ }}} Result of `--info` {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","gcc") ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno- unicode -Wno-trigraphs") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","8.1.20160611") ,("Project Git commit id","5895f5c51c36d445360ced3af61a650cfb1ad899") ,("Booter version","8.0.1") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/Users/matt/Documents/haskell/ghc/inplace/lib") ,("Global Package DB","/Users/matt/Documents/haskell/ghc/inplace/lib/package.conf.d") ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6132#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11204: Recompilation checking stochastically broken on Darwin
by GHC 12 Jun '16

12 Jun '16

#11204: Recompilation checking stochastically broken on Darwin ----------------------------------------+---------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- The `retc001` test usually fails on Darwin. Unfortunately, it also sometimes passes. Failures look like this, {{{ =====> retc001(normal) 1 of 1 [0, 0, 0] cd . && $MAKE -s --no-print-directory retc001 </dev/null > retc001.run.stdout 2> retc001.run.stderr Actual stderr output differs from expected: --- ./retc001.stderr.normalised 2015-12-11 23:02:23.000000000 +0200 +++ ./retc001.run.stderr.normalised 2015-12-11 23:02:23.000000000 +0200 @@ -1,2 +0,0 @@ - -C.hs:3:11: Module ‘B’ does not export ‘foo’ \ No newline at end of file Actual stdout output differs from expected: --- ./retc001.stdout.normalised 2015-12-11 23:02:23.000000000 +0200 +++ ./retc001.run.stdout.normalised 2015-12-11 23:02:23.000000000 +0200 @@ -3,5 +3,3 @@ [3 of 3] Compiling Main ( C.hs, nothing ) Middle End -[2 of 3] Compiling B ( B.hs, nothing ) -[3 of 3] Compiling Main ( C.hs, nothing ) [B changed] \ No newline at end of file *** unexpected failure for retc001(normal) }}} I suspect the problem is mtime resolution as if I apply the following patch it almost always passes, {{{ diff --git a/testsuite/tests/driver/retc001/Makefile b/testsuite/tests/driver/retc001/Makefile index a3cf6eb..bb1eca8 100644 --- a/testsuite/tests/driver/retc001/Makefile +++ b/testsuite/tests/driver/retc001/Makefile @@ -20,5 +20,6 @@ retc001: clean echo 'Middle' '$(TEST_HC)' $(TEST_HC_OPTS_NO_RECOMP) -fno-code -fwrite-interface --make C.hs echo 'End' + sleep 1 cp B2.hs B.hs -'$(TEST_HC)' $(TEST_HC_OPTS_NO_RECOMP) -fno-code -fwrite- interface --make C.hs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11204> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12099: ghc --show-options lists invalid flags
by GHC 10 Jun '16

10 Jun '16

#12099: ghc --show-options lists invalid flags -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- While porting ghc-mod to GHC 8 I noticed that all `-fwarn` flags are missing from `flagsForCompletion` instead only `-fwarn-` and `-fno-warn-` appear. This also shows up in the front-end when running `ghc --show- options`. Looking at the code this turned out to be because the old `-fwarn` flags were marked as hidden using `hideFlag` and hidden flags are explicitly filtered out in `flagsForCompletion` but for some reason the `-fwarn-` and `-fno-warn-` prefixes still show up in the list. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12099> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12180: Ctrl-c during build produces *some* outputs for a file, and GHC --make fails handling this
by GHC 10 Jun '16

10 Jun '16

#12180: Ctrl-c during build produces *some* outputs for a file, and GHC --make fails handling this --------------------------------------+--------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Driver | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- This is a minor issue, but after I interrupted and restarted `stack build --ghc-options=-j3` (went from `stack build` to `stack build --ghc- options=-j2` to -j3), I ended up with a build that did not complete. clang: error: no such file or directory: '.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Agda/TypeChecking/SizedTypes.dyn_o' Doing `stack build` again did not fix the issue. I assume this is due to the underlying `ghc --make`. Apparently, only some of the compiled output files were written, not all (see below), but GHC (I guess) assumes they're created atomically. Worse, the `.dyn_hi` variant existed but `.dyn_o` was missing. After removing all of them, restarting the build completed successfully. Fixes could include creating the files atomically or assuming that might not happen; since creating multiple files together atomically is impossible (the rename trick doesn't handle this, even ignoring its limitations), the 2nd option appears more sensible. While this was easy for me, most compilers avoid this, and I'm sure some users would be a bit more confused in this scenario—it's easy to imagine this happening to students. Listing of relevant build products: {{{ $ ls .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Agda/TypeChecking/SizedTypes.* .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Agda/TypeChecking/SizedTypes.dyn_hi .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Agda/TypeChecking/SizedTypes.hi .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Agda/TypeChecking/SizedTypes.o }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12180> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12173: foldl' semantics changed from 4.7 to 4.8
by GHC 10 Jun '16

10 Jun '16

#12173: foldl' semantics changed from 4.7 to 4.8 -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `foldl'` is now defined as {{{#!hs foldl' :: forall a b . (b -> a -> b) -> b -> [a] -> b {-# INLINE foldl' #-} foldl' k z0 xs = foldr (\(v::a) (fn::b->b) -> oneShot (\(z::b) -> z `seq` fn (k z v))) (id :: b -> b) xs z0 }}} As far as I can tell, the Haskell 2010 report does not specify anything about the behavior of `foldl'`. In base 4.7, it was defined {{{#!hs foldl' :: (b -> a -> b) -> b -> [a] -> b foldl' f z0 xs0 = lgo z0 xs0 where lgo z [] = z lgo z (x:xs) = let z' = f z x in z' `seq` lgo z' xs }}} These are ''not'' equivalent. In particular, with the old `foldl'`, {{{#!hs foldl' (\_ _ -> 3) undefined "hello" }}} evaluates to `3`, but with the new one, it throws an exception. If the old semantics are preferred, we can get them with {{{#!hs foldl' :: forall a b . (b -> a -> b) -> b -> [a] -> b {-# INLINE foldl' #-} foldl' k z0 xs = foldr (\(v::a) (fn::b->b) -> oneShot (\(z::b) -> fn $! k z v)) (id :: b -> b) xs z0 }}} The ''old'' semantics match the default `Foldable` instance. The advantage of the ''new'' semantics is that they're more consistent about strictness (unconditionally strict in the accumulator), but that blocks out idioms like {{{#!hs foldl' f (error "Empty list") ... }}} I don't remember this being discussed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12173> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4479: Implement TDNR
by GHC 09 Jun '16

09 Jun '16

#4479: Implement TDNR -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.5 checker) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: => ORF Comment: gidyn, thanks for starting a new proposal. Your effort to push this along is appreciated! I think your idea for doing TDNR without any syntax can indeed be seen as a proper generalization of `DuplicateRecordFields`, which permits syntaxless TDNR in the special case of record field names. Unfortunately I tend to agree with AntC that the proposal needs more precision. We want to avoid the situation that the programs GHC accepts depend on implementation details of the type-checker. This means that we need a (possibly hypothetical) declarative specification of what the typing rules should be for ambiguous names. Moreover, it's probably best if introducing or removing an ambiguity doesn't lead to different valid types for the same program. This implies that disambiguation should use information gleaned from the existing bidirectional typing rules, but not do additional inference. This requirement is why approaches based on deferring name resolution to the constraint solver, like ORF's magic classes, use a syntactic cue to indicate that the identifier should be treated specially. These are tough goals to meet, and explain why the current `DuplicateRecordFields` is quite conservative in what it will accept (see #11343). No doubt it is possible to do something more general, but it's hard to specify, let alone implement. I think that is part of the reason that TDNR has languished over the years. [AntC already mentioned this on the wiki page, but for future reference, this mailing list thread is very relevant: https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-May/026225.html] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4479#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12003: Improve error message about closed variables
by GHC 09 Jun '16

09 Jun '16

#12003: Improve error message about closed variables -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple StaticPointers | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11656 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After allowing local bindings in static definitions the following program {{{ {-# LANGUAGE StaticPointers #-} module M where f x = static g where g = h h = x }}} yields the error {{{ ../tmp/M.hs:4:7: error: • ‘g’ is used in a static form but it is not closed. • In the expression: static g In an equation for ‘f’: f x = static g where g = h h = x }}} Where it would be more helpful to get a message like {{{ ../tmp/M.hs:4:7: error: • ‘g’ is used in a static form but it is not closed because it uses ‘h’ which uses ‘x’ which is not let-bound. • In the expression: static g In an equation for ‘f’: f x = static g where g = h h = x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12003> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 09 Jun '16

09 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"77b8c29b8baf9b84df6c8352d7f785c75522eff4/ghc" 77b8c29/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="77b8c29b8baf9b84df6c8352d7f785c75522eff4" Remove Ord AltCon It uses Ord DataCon which uses Ord Unique which is nondeterministic GHC Trac: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:207> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0