May 2018 - ghc-tickets

[GHC] #15152: Core Lint error in ill-typed GADT code
by GHC 15 May '18

15 May '18

#15152: Core Lint error in ill-typed GADT code -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11066 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} module T3651 where data Z a where U :: Z () B :: Z Bool unsafe2 :: a ~ b => Z b -> Z a -> a unsafe2 B U = () }}} On current GHC HEAD, this fails with an "Inaccessible branch" error. However, if we turn this error into a warning, e.g. using the following patch: {{{ --- a/compiler/typecheck/TcErrors.hs +++ b/compiler/typecheck/TcErrors.hs @@ -708,7 +708,7 @@ mkGivenErrorReporter implic ctxt cts Nothing ty1 ty2 ; traceTc "mkGivenErrorReporter" (ppr ct) - ; maybeReportError ctxt err } + ; reportWarning NoReason err } where (ct : _ ) = cts -- Never empty (ty1, ty2) = getEqPredTys (ctPred ct) }}} ...and then compile with `-dcore-lint -Werror`, the program gets rejected with a core lint error: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) *** Core Lint errors : in result of Desugar (before optimization) *** <no location info>: warning: In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) Unfilled coercion hole: {co_a1rw} <no location info>: warning: In a case alternative: (U co_a1ri :: (a_a1rd :: *) ~# (() :: *)) co_a1rw :: (() :: *) ~# (Bool :: *) [LclId[CoVarId]] is out of scope *** Offending Program *** Rec { $tcZ :: TyCon [LclIdX] $tcZ = TyCon 5287023927886307113## 7998054209879401454## $trModule (TrNameS "Z"#) 0# krep$*Arr* $tc'U :: TyCon [LclIdX] $tc'U = TyCon 5625905484817226555## 8662083060712566586## $trModule (TrNameS "'U"#) 0# $krep_a1sr $tc'B :: TyCon [LclIdX] $tc'B = TyCon 477146386442824276## 11145321492051770584## $trModule (TrNameS "'B"#) 0# $krep_a1st $krep_a1sr [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1sr = KindRepTyConApp $tcZ (: @ KindRep $krep_a1ss ([] @ KindRep)) $krep_a1st [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1st = KindRepTyConApp $tcZ (: @ KindRep $krep_a1su ([] @ KindRep)) $krep_a1ss [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1ss = KindRepTyConApp $tc() ([] @ KindRep) $krep_a1su [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1su = KindRepTyConApp $tcBool ([] @ KindRep) $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "T3651"#) unsafe2 :: forall a b. ((a :: *) ~ (b :: *)) => Z b -> Z a -> a [LclIdX] unsafe2 = \ (@ a_a1rd) (@ b_a1re) ($d~_a1rg :: (a_a1rd :: *) ~ (b_a1re :: *)) -> let { $d~~_a1ro :: (a_a1rd :: *) ~~ (b_a1re :: *) [LclId] $d~~_a1ro = $p1~ @ * @ a_a1rd @ b_a1re $d~_a1rg } in case heq_sel @ * @ * @ a_a1rd @ b_a1re $d~~_a1ro of co_a1rp { __DEFAULT -> \ (ds_d1sv :: Z b_a1re) (ds_d1sw :: Z a_a1rd) -> let { fail_d1tc :: Void# -> a_a1rd [LclId] fail_d1tc = \ (ds_d1td [OS=OneShot] :: Void#) -> patError @ 'LiftedRep @ a_a1rd "minimal.hs:12:1-16|function unsafe2"# } in case ds_d1sv of wild_00 { __DEFAULT -> fail_d1tc void#; B co_a1rh -> let { co_a1ru :: (a_a1rd :: *) ~# (Bool :: *) [LclId[CoVarId]] co_a1ru = CO: co_a1rp ; co_a1rh } in case ds_d1sw of wild_00 { __DEFAULT -> fail_d1tc void#; U co_a1ri -> () `cast` (Sub ({co_a1rw} ; Sym co_a1ru) :: (() :: *) ~R# (a_a1rd[sk:2] :: *)) } } } end Rec } *** End of Offense *** <no location info>: error: Compilation had errors }}} However, without core linting, the correct errors appear: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) minimal.hs:12:1: error: [-Woverlapping-patterns, -Werror=overlapping- patterns] Pattern match has inaccessible right hand side In an equation for ‘unsafe2’: unsafe2 B U = ... | 12 | unsafe2 B U = () | ^^^^^^^^^^^^^^^^ minimal.hs:12:11: error: [-Werror] • Couldn't match type ‘Bool’ with ‘()’ Inaccessible code in a pattern with constructor: U :: Z (), in an equation for ‘unsafe2’ • In the pattern: U In an equation for ‘unsafe2’: unsafe2 B U = () | 12 | unsafe2 B U = () | ^ }}} Without either core linting or `-Werror`, GHC just emits the warnings, and then falls into a hole: {{{ [1 of 1] Compiling T3651 ( minimal.hs, minimal.o ) minimal.hs:12:1: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In an equation for ‘unsafe2’: unsafe2 B U = ... | 12 | unsafe2 B U = () | ^^^^^^^^^^^^^^^^ minimal.hs:12:11: warning: • Couldn't match type ‘Bool’ with ‘()’ Inaccessible code in a pattern with constructor: U :: Z (), in an equation for ‘unsafe2’ • In the pattern: U In an equation for ‘unsafe2’: unsafe2 B U = () | 12 | unsafe2 B U = () | ^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180508 for x86_64-unknown-linux): opt_univ fell into a hole {co_a1rw} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/types/OptCoercion.hs:242:5 in ghc:OptCoercion Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15152> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #913: instance Ord (StableName a)
by GHC 15 May '18

15 May '18

#913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Up until now the fact that you can't care about the arbitrary ordering that the `StableName`s have has been viewed as a feature. Pragmatically, if you need to use them as keys in a container `unordered-containers` should properly treat them as `Hashable`, and rather explicitly considers the container "unordered". That said, one could argue that the same reasoning should apply to `Data.Unique` in that it should be `Hashable`/`Eq` only, and not provide the `Ord` instance it already does, so to your point there is at least an appearance of inconsistency between these two positions. There is some difference between those two scenarios though. It is worth noting that nothing in our current API says a `StableName#` gets any sort of actual _unique_ integer assigned to it during creation. It just lives on the heap. Pretending we can gives me pause. You can't compare pointers to them using an ordering, any more than you can compare `MutVar#`'s for `Ord` because GC can change the relative position of them, and we don't want to inflate them with a superfluous costs to support an operation that isn't fundamental to their existence. Now, we do have a `stableNameToInt#` operation, but it rather carefully doesn't claim to produce a unique name. Mind you it doesn't make this claim largely due to concerns about GC happening in the meantime, but we've had this degree of freedom for a long time, and could abuse it more in the internals without anybody actually being able to care. @simonmar's initial suggestion that we can use the `Ord` on the `stableNameToInt#` used by `hashStableName` to compare `StableName#`s seems a little racy to me: the integer isn't guaranteed to be unique due to the fact that `StableName` IDs can be reused, but due to the fact that I could construct two stable names, converting one to an integer through `stableNameToInt#`, have a gc happen in which the now 'dead' `StableName` gets recollected, have someone else get assigned to the same id, then force another stablename that was constructed in the meantime, which might resolve to the same id. While it seems like a reasonably far fetched scenario that that might go wrong, the chain of reasoning to prove that it always goes right is delicate. e.g. I don't see what prevents you from constructing the second stable name using an `unsafePerformIO` in between the unwrapping of the first and unwrapping the second, it would be constructed by the act of forcing the `StableName` data constructor. Do I think this will really happen in user code? Maybe not, but the fact that I could even see a path towards it, and Jan-Willem's experience report, combined with my previous efforts along these lines building the `intern` library and basically giving up on the cleanup once problems get large enough due to issues of this sort, gives me a great deal of pause. But there isn't really any particular reason other than the current implementation why these Ids are small unique numbers. In a different world, they could just be heap objects with some ID created during initialization, say, based on their initial allocation address. They could then be "moved" like any other heap object. The current API doesn't require uniqueness of keys, so this would pass everything about the `StableName` API, much like how my [https://github.com/ekmett/unique/blob/master/src/Control/Concurrent/Unique.… Control.Concurrent.Unique] matches the shape of the `Data.Unique` API, but can only supply `Hashable`, not `Ord`, as the integer of initial allocation location associated with each `Unique` value could be shared across several such `Unique` values. This has the benefit of avoiding _any_ coordination during allocation of these identifiers across threads and so scales better than our current `Data.Unique` system. I could see a world in which we'd want to refactor the internals of `System.Mem.StableName` at some point to offer a more efficient construction. The current API offers a lot of possible implementation approaches. Adding an `Ord` constraint limits those choices, and reasoning about its soundness takes us into relatively dubious territory as seen above. On a more theoretical basis, to phrase this another way, not everything that can be broken into equivalence classes breaks up into _ordered_ equivalence classes. If these were merely unique objects on the heap, then merely being able to compare these for equality vs. having the power to sort them is analogous to the problem of 'pointer discrimination' mentioned by Fritz Henglein in [https://pdfs.semanticscholar.org/f425/7af9221ca7fe21dc84a049a8545a28a874ae.… Generic Top-down Discrimination for Sorting and Partitioning in Linear Time]. All of these issues taken together leaves me inclined to let the old `wontfix` status of this issue stand. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/913#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #913: instance Ord (StableName a)
by GHC 15 May '18

15 May '18

#913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, right, of course. I don't know why I thought it was in the Report. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/913#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #913: instance Ord (StableName a)
by GHC 15 May '18

15 May '18

#913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): When you say that it "to some extend commits other implementations to also offer this functionality", how do you mean that? StableName isn't part of the Haskell Report. But yes, I agree that checking with the CLC is a good step. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/913#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12012: Socket operations on Windows check errno instead of calling WSAGetLastError()
by GHC 15 May '18

15 May '18

#12012: Socket operations on Windows check errno instead of calling WSAGetLastError() -------------------------------------+------------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: Libraries | Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Winsock doesn't set errno, but it is checked in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` (both are in `GHC.IO.FD`). I the same thing happens in the non threaded RTS too, but that's in terms of primops and I don't understand it very well. The upshot here is that every error message originating from Winsock is wrong. Nobody noticed since any error used to just crash your program (#12010). Here's some MinGW documentation http://oldwiki.mingw.org/index.php/sockets and something from MSDN https://msdn.microsoft.com/en- us/library/windows/desktop/ms740121%28v=vs.85%29.aspx -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #913: instance Ord (StableName a)
by GHC 15 May '18

15 May '18

#913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: | Keywords: 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 bgamari): * cc: core-libraries-committee@… (added) * status: closed => new * resolution: wontfix => Comment: It sounds like we just weren't sure whether this was a desireable feature. Indeed this is a bit of a tricky question as it to some extent commits other implementations to also offer this functionality. Let's see what the Core Libraries Committee says. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/913#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7414: plugins always trigger recompilation
by GHC 15 May '18

15 May '18

#7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12567 | Differential Rev(s): Phab:D4366 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4366 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7414#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14697: Redundant computation in fingerprintDynFlags when compiling many modules
by GHC 15 May '18

15 May '18

#14697: Redundant computation in fingerprintDynFlags when compiling many modules -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I profiled a build of a production code base with thousands of modules and computing `fingerprintDynFlags` is `7%` of time and `14%` of allocations. Here's a synthetic test case inspired by what I observed: {{{ SIZE=1000 for i in $(seq -w 1 $SIZE); do echo "module A$i where" > A$i.hs echo "data A$i = A$i" >> A$i.hs done }}} This generates a 1000 modules each with one datatype. Compiling them with: {{{ inplace/bin/ghc-stage2 A*.hs -optP-D__F{1..10000}__ }}} results in `fingerprintDynFlags` being the top cost centre in the profile. AFAICT there's only one module dependent piece that goes into computing `fingerprintDynFlags` and the rest is the same between those 1000 modules. Now, why would I have so many preprocessor flags? This is how the Buck build system currently works. If a Haskell library depends on a C++ library then the GHC invocation gets the C++ library's directory as include path (`-optP-I -optP-I some/library/path`). This can grow quite big. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7414: plugins always trigger recompilation
by GHC 15 May '18

15 May '18

#7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12567 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Patch: https://phabricator.haskell.org/D4366 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7414#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #913: instance Ord (StableName a)
by GHC 15 May '18

15 May '18

#913: instance Ord (StableName a) -------------------------------------+------------------------------------- Reporter: ekarttun | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.4.2 Resolution: wontfix | Keywords: 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 andrewthad): * failure: => None/Unknown Comment: Is there a reason this is currently marked as wontfix? It seems like adding a `compareStableNames#` primop would be easy and would solve this issue. I might be able to figure out how to do this and would be happy to give it a try if I knew it would be accepted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/913#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0