August 2017 - ghc-tickets

[GHC] #12110: Windows exception handler change causes segfault with API Monitor
by GHC 26 Sep '17

26 Sep '17

#12110: Windows exception handler change causes segfault with API Monitor ----------------------------------------+---------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------------- [http://www.rohitab.com/apimonitor API Monitor] is a debugging tool that intercepts and logs calls to DLLs. It was extremely helpful with debugging #12010 and is broken in recent GHCs. Attaching it to a GHC compiled executable causes the message `Segmentation fault/access violation in generated code` to be printed. Launching one from inside API Monitor doesn't work either, though I can't read the console output before the window closes. Bisect shows the offending commit is 5200bdeb26 - "Replaced SEH handles with VEH handlers which should work uniformly across x86 and x64". I know this is somewhat outside of "standard usage", but there are very few useful debugging tools for stuff like this and I'd really like to not lose this one. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11198: TypeInType error message regressions
by GHC 26 Sep '17

26 Sep '17

#11198: TypeInType error message regressions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- `TypeInType` causes error messages around certain kind errors to degrade. Here is the case: {{{ [W] (alpha :: k) ~ (Int :: *) }}} where `alpha` is a unification variable, `k` is a skolem, and there is no witness that `k ~ *`. The solver will simplify to {{{ [W] kco :: k ~ * [W] (alpha :: k) ~ (Int |> sym kco) }}} and then the latter, now homogeneous equality is solved by unification {{{ alpha := Int |> sym kco }}} This is all sound. But when reporting a kind error around `k` not equalling `*`, GHC likes to report the type error that the kind error came from. But, after zonking, the type error looks like `Int ~ Int`, when we drop coercions (as we tend to do in error messages). That's unfortunate. It affects test cases * T9196 * T8262 * T8603 * tcfail122 Simon has proposed a rule that should avoid this: never, ever use a wanted as a kind cast. That might work, but an attempt at implementing caused a loop when kind families were involved. I will keep pushing on this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11198> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression
by GHC 26 Sep '17

26 Sep '17

#13873: Adding a SPECIALIZE at a callsite in Main.hs is causing a regression -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 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: -------------------------------------+------------------------------------- Github user jmoy documents an issue with lack of specialization happening for INLINABLE functions in GHC 8.0 here: https://github.com/jmoy/testing- specialize . Testing on 8.2.1 it seems that specialization happened (although I didn't verify this in the core) as the result was 10x faster. But the odd thing to me was uncommenting the `SPECIALIZE` pragma at the callsite actually resulted in a significant regression: https://github.com/jmoy/testing-specialize/issues/1#issuecomment-310868360 Maybe GHC is choosing the worse manual partial specialization for some reason. I'm sorry I can't produce a better ticket for this at the moment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12717: Permit data types in signatures to be implemented with equivalent pattern synonyms (and vice versa)
by GHC 26 Sep '17

26 Sep '17

#12717: Permit data types in signatures to be implemented with equivalent pattern synonyms (and vice versa) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose I write in a signature: {{{ data Type = TArrow t1 t2 | TApp String [Type] }}} But it turns out that the real data type only has TApp (and uses "->" as the TyCon for TArrow). It would be nice if a pattern synonym could be used to implement this "concrete abstract data type" instead. Signature matching would have to typecheck the pattern synonyms against each other, and also check for totality. Note that in this example, App would need a guard against the Arrow case; otherwise the patterns overlap, whereas in the data type above it shouldn't matter what order the patterns go in. The converse might be useful too: {{{ data Type pattern TArrow :: Type -> Type -> Type pattern TInt :: Type }}} These patterns would be available for matching, with the assumption that they weren't total. If they were implemented directly using constructors, that should not be a problem. (In fact, do we even support abstract pattern synonyms?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12717> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14162: Core Lint error
by GHC 26 Sep '17

26 Sep '17

#14162: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Options_GHC -dcore-lint #-} {-# Language TypeOperators, KindSignatures, DataKinds, PolyKinds, TypeFamilies, GADTs, TypeInType #-} import Data.Kind data family Sing (a :: k) data SubList :: [a] -> [a] -> Type where SubNil :: SubList '[] '[] Keep :: SubList xs ys -> SubList (x ': xs) (x ': ys) Drop :: SubList xs ys -> SubList xs (x ': ys) data instance Sing (x :: SubList ys xs) where SSubNil :: Sing SubNil SKeep :: Sing x -> Sing (Keep x) SDrop :: Sing x -> Sing (Drop x) }}} running it gives a massive core lint error, attached as a `lint.log`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14162> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14144: Standardize binary distribution doc files
by GHC 26 Sep '17

26 Sep '17

#14144: Standardize binary distribution doc files -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- I'm making a pass at the documentation in general, and next up on my list is simplifying the building process a bit. I hope to create something like `docs/dist-install` that would collect and hold all of the generated documentation. This would help in writing the docs, as you could verify links, say, from the user's guide to the library documentation. This would also allow installation and distribution to mainly be a `cp`. While looking into this, I ran into some discrepancies between releases. The contents of !https://downloads.haskell.org/~ghc/VERSION/docs for [https://downloads.haskell.org/~ghc/7.10-latest/docs 7.10], [https://downloads.haskell.org/~ghc/8.0-latest/docs 8.0], and [https://downloads.haskell.org/~ghc/latest/docs 8.2] are all different. 8.0 dropped `*.ps` files and `haddock.pdf`. 8.2 now additionally holds a `windows` folder that has a wide array of binaries and documentation. Going back further, the `Cabal` user's guide used to be included. I searched around for a reason that it was dropped and only found a git commit citing the change from `docbook`. But now most sources use `Sphinx`, so we could generate and include them if we so wished. The `Cabal` guide can be found at: * https://www.haskell.org/cabal/users-guide/ (Version 1.24.2) * https://cabal.readthedocs.io/en/latest/ (Versions 2.0 and HEAD) The `Haddock` guide can be found at: * https://www.haskell.org/haddock/doc/html (Version 2.15.0) * https://haskell-haddock.readthedocs.io/en/latest/ (Versions 2.18.0 and HEAD) * https://downloads.haskell.org/~ghc/latest/docs/haddock.html.tar.xz (GHC release version) Unfortunately, the www.haskell.org links are the most prominent when Googled. To bring this back to a point, I would like to clean up the `docs` folder of the distribution. The `windows` folder inside seems like it might be a mistake. Additionally, `Cabal` and `Haddock` have ended up in strange positions, and I think they probably could both use the same solution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14153: Change worker thread name to something mentioning original process name
by GHC 25 Sep '17

25 Sep '17

#14153: Change worker thread name to something mentioning original process name ----------------------------------------+--------------------------------- Reporter: enolan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Worker OS thread are renamed to `ghc_worker` when spawned. This is annoying when reading debugging messages that print the process name. For example, at work I'm debugging a segfault in a Haskell program and the kernel message just says `ghc_worker[21992]: segfault at 0 ip...` which doesn't tell me which of our Haskell programs is having the problem. I'd like to change this so it mentions the original name. On Linux, we can get that from the `program_invocation_name` global. `pthread_setname_np` has a maximum length of 15 characters, so we'll have to truncate it. I propose the first 13 characters of the original name followed by ":w". I'd just as soon not change the name in the first place but apparently this change was made to make it easier to distinguish worker threads from the main thread when debugging processes in gdb (commit 674c631ea111233daa929ef63500d75ba0db8858). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13608: Expose the type of quasiquotes
by GHC 22 Sep '17

22 Sep '17

#13608: Expose the type of quasiquotes -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: QuasiQuotes | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12778 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It happens with inline-java that {{{ [java| 0.0 |] }}} produces a static method in java {{{ Object fresh_name() { return 0.0; } }}} where {{{ double fresh_name() { return 0.0; } }}} would be preferred. This is better because the user would get an error if the expression does not match the expected result type. Examining the context in which the quasiquote is used would allow to build the later variant. However, GHC provides no way to grab the type that it expects of the quasiquote. The quasiquote desugars as follows: {{{ [java| 0.0 |] ====> $(parseExp java " 0.0 ") }}} We have experimented with a patch that desugars instead like {{{ [java| 0.0 |] ====> let __ghc_qq_<loc_hash> = $(parseExp java " 0.0 ") in __ghc_qq_<loc_hash> }}} The quasiquoter can learn then of the expected type by doing: {{{ do qqName <- getCurrentQuasiQuoteName addModFinalizer $ reify qqName >>= ... where getCurrentQuasiQuoteName :: Q Name getCurrentQuasiQuoteName = do loc <- TH.location return $ mkName $ "__ghc_qq_" ++ hash loc }}} Where `getCurrentQuasiQuoteName` can be provided in `Language.Haskell.TH.Quote`. This addresses the same concern that I initially intended to solve with the more complex proposal in #12778. I hope to submit a patch this week, but it would be useful if people want to provide some feedback about the proposal meanwhile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13608> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #13847: record construction accepts local unqualified name instead of qualified imported name
by GHC 21 Sep '17

21 Sep '17

#13847: record construction accepts local unqualified name instead of qualified imported name -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given {{{ module A where data A = A { foo :: () } deriving Show }}} the following code is accepted {{{ module Main where import qualified A foo = "foo" main = print $ A.A { foo = () } }}} albeit with a warning {{{ B.hs:4:16: warning: [-Wmissing-fields] • Fields of ‘A.A’ not initialised: foo }}} Indeed the `foo = ()` is type-checked as if it were `A.foo = ()` but the `foo` field is actually not assigned. Evaluation gives {{{ *Main> main A {foo = *** Exception: B.hs:4:16-31: Missing field in record construction foo }}} The code should be rejected outright? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc
by GHC 21 Sep '17

21 Sep '17

#13644: overloaded name used in record pattern matching leads to panic! (the 'impossible' happened) in ghc -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In Haskell, 1. The scope of definitions can be controled. 2. The same name can be used to define both a function and a field of record. 3. The user can use that name in record pattern matching when only the function is within scope. For example {{{ FuncId{ name = nm } }}} resulting in the following bug {{{ [38 of 39] Compiling TxsUtils ( src\TxsUtils.hs, .stack- work\dist\1f7101f2\build\Txs Utils.o ) ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-mingw32): translateConPatVec: lookup Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13644> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23