September 2015 - ghc-tickets

Re: [GHC] #6018: Injective type families
by GHC 03 Sep '15

03 Sep '15

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: | TypeFamilies, Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T6018, | T6018fail, T6018rnfail, T6018th, | T6018failclosed1, T6018failclosed2, | T6018failclosed3, T6018failclosed4, | T6018failclosed5, T6018failclosed6, | T6018failclosed7, T6018failclosed8, | T6018failclosed9, | T6018failclosed10, | T6018failclosed11, | T6018failclosed12, T6018ghci, | T6018ghcifail, T6018ghcirnfail Blocked By: | Blocking: Related Tickets: #4259 | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Changes (by jstolarek): * testcase: => T6018, T6018fail, T6018rnfail, T6018th, T6018failclosed1, T6018failclosed2, T6018failclosed3, T6018failclosed4, T6018failclosed5, T6018failclosed6, T6018failclosed7, T6018failclosed8, T6018failclosed9, T6018failclosed10, T6018failclosed11, T6018failclosed12, T6018ghci, T6018ghcifail, T6018ghcirnfail * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 03 Sep '15

03 Sep '15

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: | TypeFamilies, Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4259 | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by Jan Stolarek <jan.stolarek@…>): In [changeset:"374457809de343f409fbeea0a885877947a133a2/ghc" 37445780/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="374457809de343f409fbeea0a885877947a133a2" Injective type families For details see #6018, Phab:D202 and the wiki page: https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies This patch also wires-in Maybe data type and updates haddock submodule. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Subscribers: mpickering, bgamari, alanz, thomie, goldfire, simonmar, carter Differential Revision: https://phabricator.haskell.org/D202 GHC Trac Issues: #6018 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:111> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5273: error and undefined should print a location
by GHC 02 Sep '15

02 Sep '15

#5273: error and undefined should print a location -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9049 | Differential Revisions: Phab:D861 -------------------------------------+------------------------------------- Comment (by bgamari): One remaining question here is how this should interact with DWARF-based stacktraces (see Phab:D1198). The two mechanisms exhibit different strengths, * IP-based stacktraces: * Always accurate * Cheap to gather stack but have small effect on code generation * Can only provide limited stack depth * DWARF-based stacktraces: * May not point you at exactly the right place * More expensive to gather stack but no effect on code generation * Can provide full stack (but perhaps it's best if we capped the depth to avoid costly unwinding of deep stacks) * Requires that code be built with `-g` Given they are to some extent complementary, perhaps we should produce both if available? Note: technically there are two costs to DWARF stack collection: 1. Unwinding the stack: the task of actually walking the stack and collection the relevant addresses 2. Looking up the addresses: the task of looking up symbol names and source location information for the addresses we collected in step 1. In my experience (2) tend to be much more expensive than (1). In Phab:D1198 step (2) should occur lazily, so it will only be paid if the necessary. Step (1) however necessarily happens unconditionally. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5273#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5273: error and undefined should print a location
by GHC 02 Sep '15

02 Sep '15

#5273: error and undefined should print a location -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9049 | Differential Revisions: Phab:D861 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5273#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5273: error and undefined should print a location
by GHC 02 Sep '15

02 Sep '15

#5273: error and undefined should print a location -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9049 | Differential Revisions: Phab:D861 -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"6740d70d95cb81cea3859ff847afc61ec439db4f/ghc" 6740d70d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6740d70d95cb81cea3859ff847afc61ec439db4f" Use IP based CallStack in error and undefined This patch modifies `error`, `undefined`, and `assertError` to use implicit call-stacks to provide better error messages to users. There are a few knock-on effects: - `GHC.Classes.IP` is now wired-in so it can be used in the wired-in types for `error` and `undefined`. - `TysPrim.tyVarList` has been replaced with a new function `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce subtle bugs when you need tyvars of different kinds. The naive ``` tv1 = head $ tyVarList kind1 tv2 = head $ tyVarList kind2 ``` would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions would be applied incorrectly, treating `tv1` and `tv2` as the same tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds and producing a single tyvar of each kind. - The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in ghc-prim. - The type `GHC.Exception.ErrorCall` has a new constructor `ErrorCallWithLocation` that takes two `String`s instead of one, the 2nd one being arbitrary metadata about the error (but usually the call-stack). A bi-directional pattern synonym `ErrorCall` continues to provide the old API. Updates Cabal, array, and haddock submodules. Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter, liyang, bgamari, thomie Differential Revision: https://phabricator.haskell.org/D861 GHC Trac Issues: #5273 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5273#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10541: Expose kind information for type variables with reify
by GHC 01 Sep '15

01 Sep '15

#10541: Expose kind information for type variables with reify -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The comment on [https://hackage.haskell.org/package/template- haskell-2.10.0.0/docs/Language-Haskell-TH-Syntax.html#v:TyVarI TyVarI] notes that the attached Type is always {{{VarT theName}}}, and that this could potentially be extended. Currently, there isn't a way to access kind information for a type variable through the Template Haskell API. It would be useful (at least for me) to have this ability here. The limitation on the returned Type comes from the [https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcSplice.hs#L1060 ATyVar clause of reifyThing], which zonks the TyVar to a GHC type and then uses reifyType to convert it to a TH type. For a TyVarTy, [https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcSplice.hs#L1281 reifyType] always returns {{{VarT theName}}}. I can see a few possible ways of exposing kind information here: (a) Fill the Type argument to TyVarI with {{{SigT (VarT theName) theKind}}}. This could be done either as a special case in place of the call to reifyType in reifyThing, or as a modification to reifyType's behavior. The question of when SigT should be included is open: all the time? when the kind isn't {{{*}}}? when the kind is something that involves more than {{{*}}} and {{{->}}}? (b) Change TyVarI from {{{TyVarI Name Type}}} to {{{TyVarI Name TyVarBndr}}}. This seems like the most straightforward, stable way of exposing kind information, but it requires a breaking API change. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10541> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6