- ghc-devs - Haskell.org

Proposed changes to typechecker plugins API
by Adam Gundry 27 May '15

27 May '15

Hi devs, I thought I should flag up some proposed changes relating to typechecker plugins, which Christiaan, Iavor and I have been discussing. The quick summary: * make it possible for plugins to create constraints (Phab:D909); * make it easier for plugins to define special type families; * embed CoreExpr in EvTerm. For more details, see the wiki page: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker#Post-7.10changest… Questions/review/comments very welcome. Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

Re: [commit: ghc] master: Refactor tuple constraints (ffc2150)
by Christiaan Baaij 27 May '15

27 May '15

Hi, This patch causes a regression from GHC 7.10 with regards to constraint kinds. Where previously, constraint tuples could go up to 62, the same as normal tuples, they have now been reduced to 8. I filed a bug report at: https://ghc.haskell.org/trac/ghc/ticket/10451 <https://ghc.haskell.org/trac/ghc/ticket/10451> Regards, Christiaan > On 18 May 2015, at 14:45, git(a)git.haskell.org wrote: > > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/ffc21506894c7887d3620423aaf86bc61… > >> --------------------------------------------------------------- > > commit ffc21506894c7887d3620423aaf86bc6113a1071 > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Mon May 11 23:19:14 2015 +0100 > > Refactor tuple constraints > > Make tuple constraints be handled by a perfectly ordinary > type class, with the component constraints being the > superclasses: > class (c1, c2) => (c2, c2) > > This change was provoked by > > #10359 inability to re-use a given tuple > constraint as a whole > > #9858 confusion between term tuples > and constraint tuples > > but it's generally a very nice simplification. We get rid of > - In Type, the TuplePred constructor of PredTree, > and all the code that dealt with TuplePreds > - In TcEvidence, the constructors EvTupleMk, EvTupleSel > > See Note [How tuples work] in TysWiredIn. > > Of course, nothing is ever entirely simple. This one > proved quite fiddly. > > - I did quite a bit of renaming, which makes this patch > touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. > > - I made constraint tuples known-key rather than wired-in. > This is different to boxed/unboxed tuples, but it proved > awkward to have all the superclass selectors wired-in. > Easier just to use the standard mechanims. > > - While I was fiddling with known-key names, I split the TH Name > definitions out of DsMeta into a new module THNames. That meant > that the known-key names can all be gathered in PrelInfo, without > causing module loops. > > - I found that the parser was parsing an import item like > T( .. ) > as a *data constructor* T, and then using setRdrNameSpace to > fix it. Stupid! So I changed the parser to parse a *type > constructor* T, which means less use of setRdrNameSpace. > > I also improved setRdrNameSpace to behave better on Exact Names. > Largely on priciple; I don't think it matters a lot. > > - When compiling a data type declaration for a wired-in thing like > tuples (,), or lists, we don't really need to look at the > declaration. We have the wired-in thing! And not doing so avoids > having to line up the uniques for data constructor workers etc. > See Note [Declarations for wired-in things] > > - I found that FunDeps.oclose wasn't taking superclasses into > account; easily fixed. > > - Some error message refactoring for invalid constraints in TcValidity > > - Haddock needs to absorb the change too; so there is a submodule update > > >> --------------------------------------------------------------- > > ffc21506894c7887d3620423aaf86bc6113a1071 > compiler/basicTypes/BasicTypes.hs | 21 +- > compiler/basicTypes/DataCon.hs | 1 - > compiler/basicTypes/RdrName.hs | 28 +- > compiler/basicTypes/Unique.hs | 28 +- > compiler/basicTypes/VarSet.hs | 23 +- > compiler/coreSyn/CoreLint.hs | 2 +- > compiler/coreSyn/MkCore.hs | 7 +- > compiler/coreSyn/PprCore.hs | 4 +- > compiler/deSugar/Check.hs | 2 +- > compiler/deSugar/DsArrows.hs | 2 +- > compiler/deSugar/DsBinds.hs | 25 +- > compiler/deSugar/DsCCall.hs | 6 +- > compiler/deSugar/DsExpr.hs | 5 +- > compiler/deSugar/DsMeta.hs | 840 +-------------------- > compiler/deSugar/Match.hs | 4 +- > compiler/ghc.cabal.in | 3 +- > compiler/ghci/RtClosureInspect.hs | 7 +- > compiler/hsSyn/Convert.hs | 4 +- > compiler/hsSyn/HsExpr.hs | 3 +- > compiler/hsSyn/HsPat.hs | 35 +- > compiler/hsSyn/HsTypes.hs | 2 +- > compiler/iface/BinIface.hs | 14 +- > compiler/iface/BuildTyCl.hs | 4 + > compiler/iface/IfaceSyn.hs | 9 +- > compiler/iface/IfaceType.hs | 154 ++-- > compiler/iface/TcIface.hs | 84 ++- > compiler/main/Constants.hs | 3 + > compiler/main/HscMain.hs | 11 +- > compiler/parser/Parser.y | 20 +- > compiler/parser/RdrHsSyn.hs | 164 +++- > compiler/prelude/PrelInfo.hs | 28 +- > compiler/prelude/PrelNames.hs | 17 - > compiler/prelude/PrelRules.hs | 6 +- > compiler/prelude/PrimOp.hs | 2 +- > compiler/prelude/THNames.hs | 836 ++++++++++++++++++++ > compiler/prelude/TysWiredIn.hs | 269 ++++--- > compiler/rename/RnEnv.hs | 1 + > compiler/rename/RnNames.hs | 42 +- > compiler/rename/RnSplice.hs | 6 +- > compiler/simplStg/UnariseStg.hs | 10 +- > compiler/specialise/Specialise.hs | 3 +- > compiler/stranal/WwLib.hs | 6 +- > compiler/typecheck/FunDeps.hs | 32 +- > compiler/typecheck/TcBinds.hs | 52 +- > compiler/typecheck/TcCanonical.hs | 32 - > compiler/typecheck/TcErrors.hs | 2 - > compiler/typecheck/TcEvidence.hs | 15 +- > compiler/typecheck/TcExpr.hs | 10 +- > compiler/typecheck/TcGenDeriv.hs | 15 +- > compiler/typecheck/TcHsSyn.hs | 5 +- > compiler/typecheck/TcHsType.hs | 15 +- > compiler/typecheck/TcInstDcls.hs | 4 +- > compiler/typecheck/TcInteract.hs | 11 +- > compiler/typecheck/TcMType.hs | 1 - > compiler/typecheck/TcPat.hs | 2 +- > compiler/typecheck/TcRnMonad.hs | 4 + > compiler/typecheck/TcSimplify.hs | 1 - > compiler/typecheck/TcSplice.hs | 2 +- > compiler/typecheck/TcTyClsDecls.hs | 20 +- > compiler/typecheck/TcType.hs | 3 - > compiler/typecheck/TcValidity.hs | 186 +++-- > compiler/types/TyCon.hs | 34 +- > compiler/types/Type.hs | 7 +- > compiler/types/TypeRep.hs | 11 +- > compiler/vectorise/Vectorise/Builtins/Base.hs | 2 +- > .../vectorise/Vectorise/Builtins/Initialise.hs | 2 +- > compiler/vectorise/Vectorise/Utils/Closure.hs | 4 +- > libraries/ghc-prim/GHC/Classes.hs | 44 +- > libraries/ghc-prim/GHC/Tuple.hs | 242 +++--- > libraries/ghc-prim/GHC/Types.hs | 2 +- > .../should_fail/NotRelaxedExamples.stderr | 17 +- > .../indexed-types/should_fail/TyFamUndec.stderr | 17 +- > testsuite/tests/module/all.T | 2 +- > testsuite/tests/module/mod89.hs | 2 + > testsuite/tests/module/mod89.stderr | 10 +- > .../tests/typecheck/should_fail/T9858a.stderr | 2 +- > .../tests/typecheck/should_fail/fd-loop.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail108.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail154.stderr | 6 +- > .../tests/typecheck/should_fail/tcfail157.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail213.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail214.stderr | 8 +- > .../tests/typecheck/should_fail/tcfail220.hsig | 1 - > .../tests/typecheck/should_fail/tcfail220.stderr | 8 - > utils/genprimopcode/Main.hs | 49 +- > utils/haddock | 2 +- > 86 files changed, 1985 insertions(+), 1672 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc ffc21506894c7887d3620423aaf86bc6113a1071 > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

1 0

StaticPointers to local definitions
by Facundo Domínguez 25 May '15

25 May '15

Hello, It is happening in practice that one wants to create a static pointer in a function and use some local definitions. > f :: Static (Int -> Int) > f x = sf > where > body = (+1) > sf = Static body 'body' defines a closed expression, but this is currently rejected because desugaring the static form would produce a top-level binding of the form: > sf_top_level :: Int -> Int > sf_top_level = body where the local binding 'body' is not in scope. Barring inlining, which wouldn't work in more complex examples, one approach around this is to have the compiler move local definitions to the top level during desugaring when they are referenced by a static pointer. Two questions arise: 1) Would this interfere with other aspects of compilation? 2) Would anyone argue there is a better approach to accomplish this? Thanks, Facundo

1 0

RE: [GHC] #10370: Compile time regression in OpenGLRaw
by Simon Peyton Jones 22 May '15

22 May '15

Austin: I have validated, but I am now going on holiday for a week. Can you monitor and revert if there's a major problem? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf | Of GHC | Sent: 22 May 2015 15:21 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #10370: Compile time regression in OpenGLRaw | | #10370: Compile time regression in OpenGLRaw | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: michalt | Owner: | Type: bug | Status: new | Priority: normal | Milestone: | Component: Compiler | Version: | 7.10.1 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: Compile-time | Unknown/Multiple | performance bug | Test Case: | Blocked By: | Blocking: | Related Tickets: | Differential Revisions: | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by simonpj): | | The commit messages tell the story. Reid's example in comment:3 | showed up TWO separate, substantial non-linear performance holes in | GHC, both of which I have now fixed. Reid, your example was | amazingly helpful. | | '''Austin''' I have not added a `perf/compiler` test case. Could you | do so please? I wasn't sure that a 20-second compile time was | acceptable. | I'm leaving the ticket open for that reason. | | Simon | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10370#comment:13> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

2 1

Re: Interactions between type-checker plugins
by Christiaan Baaij 20 May '15

20 May '15

I have yet to test this properly, but I don't think your suggestions (which you happen to give with 1 minute of eachother...) play nicely with error reporting. Here is an output of my testsuite: ``` [1 of 2] Compiling ErrorTests ( tests/ErrorTests.hs, dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/ErrorTests.o ) [GHC.TypeLits.Normalise changed] tests/ErrorTests.hs:1:1: Warning: Couldn't match type ‘GCD 6 9’ with ‘GCD 6 8’ NB: ‘GCD’ is a type function, and may not be injective Expected type: Proxy (GCD 6 8 + x) -> Proxy (x + GCD 6 9) Actual type: Proxy (x + GCD 6 9) -> Proxy (x + GCD 6 9) tests/ErrorTests.hs:14:13: Warning: Couldn't match type ‘GCD 6 8’ with ‘4’ Expected type: Proxy (GCD 6 8) -> Proxy 4 Actual type: Proxy 4 -> Proxy 4 In the expression: id In an equation for ‘testFail1’: testFail1 = id [2 of 2] Compiling Main ( tests/Main.hs, dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise-tmp/Main.o ) [GHC.TypeLits.Normalise changed] Linking dist/build/test-ghc-tynat-normalise/test-ghc-tynat-normalise ... Running 1 test suites... Test suite test-ghc-tynat-normalise: RUNNING... ghc-typelits-natnormalise Basic functionality GCD 6 8 ~ 2: OK GCD 6 8 + x ~ x + GCD 10 8: OK errors GCD 6 8 ~ 4: OK GCD 6 8 + x ~ x + GCD 9 6: FAIL No exception! 1 out of 4 tests failed (0.00s) ``` Note that 'ErrorTest.hs' is compiled with '-fdefer-type-errors'. There's a two things you may notice * The first error message's location is '1:1' * Evaluation the function with the type-error does not raise an exception. So by solving the constraint "GCD 6 8 + x ~ x + GCD 9 6" The boxed/run-time coercion no longer errors. Also, I'm using newSimpleWanted ( https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/Tc…) to create the new wanted constraint. But for some reason the errror message doesn't get the source-error location of the original constraint. Perhaps I shouldn't be using 'newSimpleWanted' to create new wanted constraints? The sources for the plugins are over here: https://github.com/christiaanb/ghc-typelits-natnormalise https://github.com/christiaanb/ghc-typelits-extra Cheers, Christiaan On 19 May 2015 at 18:01, Iavor Diatchki <iavor.diatchki(a)gmail.com> wrote: > Hi Christiaan, > > > Plugins should return the solved constraints in the first field of > `TcPLuginOk`, and additional sub-goals in the second. > The constraints in the first list are marked as solved, and do not need to > be processed further, while the constraints > in the second list will be added to the work queue, for further > processing. Also, the solutions of wanted goals may be in terms of other > as yet unsolved things. > > I think that there are two situations when a plugin might return an empty > first list, but new work in the second list. > Both are about computing new facts, and thus "communicating" with other > plugins: > 1. Discover new given facts: the plugin was presented with some > givens, and it computed some additional givens that it thinks might be of > use to someone else (typically these are equality constraints) > 2. Discover new derived facts: the plugin was presented with a mixture > of wanted and givens, and it thinks that the new derived facts might be > useful by specializing the problem----derived facts help with type > inference by instantiating unification variables. > > Generally, I don't think a plugin should ever need to emit new wanted > constraints without solving anything. It'd be interesting if that could > happen though... > > Another thing that might be relevant: at present, GHC's constraint solver > does not do back tracking. So there is no way for a plugin (or other parts > of the constraint solver) to say: "I'll emit this new wanted constraint, > and depending on if it was proved or disproved do something". Another way > to think of his is that constraints are either solved or unsolved, but > being unsolved does not mean that they are disproved. Now, there is a > mechanism to mark a constraint as "never solvable", but currently this is > mostly used for error reporting. > > For your concrete example though, the plugin can actually commit to the > given path because the only way to solve "GCD 6 8 + x ~ x + GCD 9 6" is if > "GCD 6 8 ~ GCD 9 6". So I'd imagine you want these steps: > > Plugin A: Solve "GCD 6 8 + x ~ x + GCD 9 6", new wanted "GCD 6 8 ~ GCD 9 6" > Plugin B: "GCD 6 8 ~ GCD 9 6" --> impossible > Done. > > > -Iavor > > > > On Tue, May 19, 2015 at 3:35 AM, Christiaan Baaij < > christiaan.baaij(a)gmail.com> wrote: > >> I have a question about how type-checker plugins should interact. >> My situation is the following: >> I have two type-checker plugins, one that can solve equalities involving >> the standard type-level operations on kind Nat (+,*,-,^), and another >> type-checker plugin that can prove equalities involving a new type-level >> operation GCD. >> In the following, the type-checker plugin involving the stand type-level >> operations is called ‘A’, and the type checker involving the new GCD >> operations is called ‘B’. >> >> When type-checker plugin A encounters: >> [W] GCD 6 8 + x ~ x + GCD 9 6 >> >> It knows that (+) is commutative, so it can prove the above equality >> _given_ that "GCD 6 8 ~ GCD 9 6” holds. >> So what type-checker plugin A does now is emits a new wanted constraints: >> [W] GCD 6 8 ~ GCD 9 6 >> And remembers that it emitted this wanted constraint. >> In type-checker plugin lingo, it returns: >> TcPluginOk [] ["[W] GCD 6 8 ~ GCD 9 6”] >> >> > > Now whenever type-checker plugin encounters >> [W] GCD 6 8 + x ~ x + GCD 9 6 >> again, it checks to see if the discharged constraint >> [W] GCD 6 8 ~ GCD 9 6 >> Is already solved, is disproven, or unsolved. >> If the discharged constraint is solved, it will return: >> TcPluginOk ["[W] GCD 6 8 + x ~ x + GCD 9 6”] [] >> If the discharged constraint is dis proven, it returns: >> TcPluginContradiction ["[W] GCD 6 8 + x ~ x + GCD 9 6”] >> And otherwise, it doesn’t do anything: >> TcPluginOk [] [] >> >> > > >> Now, type-checker plugin B, the one that knows about GCD, comes along. >> It sees: >> [W] GCD 6 8 + x ~ x + GCD 9 6 >> [W] GCD 6 8 ~ GCD 9 6 >> I doesn’t know anything about (+); but it does know about GCD, and >> clearly sees that GCD 6 8 is not equal to GCD 9 6. >> So it tells that GCD 6 8 ~ GCD 9 6 is insoluble. >> In type-checker plugin lingo it says: >> TcPluginContradiction ["[W] GCD 6 8 ~ GCD 9 6”] >> >> According to >> https://github.com/ghc/ghc/blob/228ddb95ee137e7cef02dcfe2521233892dd61e0/co… >> What happens next is that the insoluble constraint >> [W] GCD 6 8 ~ GCD 9 6 >> is taken of the work list for all plugins. >> However! the same thing happens when a plugin is able to prove a >> constraint. >> That is, if B would have (erroneously) returned: >> TcPluginOk ["[W] GCD 6 8 ~ GCD 9 6”] [] >> >> Then there is _no_ way for type-checker plugin A to know what happened. >> Were its discharged constraints taken from the work-list because it was >> insoluble? or because it was solved? >> This is a problem because to me it seems that the work list is the only >> way that two type-checker plugins can communicate. >> >> I guess my question is: if not through the work list, how are >> type-checker plugins supposed to communicate? >> Am I going about it all wrong in terms how I should be writing >> type-checker plugins? >> Or, should the type of ‘TcPluginSolver’ ( >> https://downloads.haskell.org/~ghc/7.10.1/docs/html/libraries/ghc-7.10.1/Tc…) >> be updated to?: >> >> ``` >> type TcPluginSolver = [Ct] -- ^ Given constraints >> -> [Ct] -- ^ Derived constraints >> -> [Ct] -- ^ Wanted constraints >> -> [Ct] -- ^ Insoluble constraints >> -> TcPluginM TcPluginResult >> ``` >> >> Best regards, >> >> Christiaan >> >> >> >> >> >

2 2

Re: Non-deterministic package IDs are really bad in 7.10
by Mateusz Kowalczyk 20 May '15

20 May '15

On 05/14/2015 05:43 PM, Joachim Breitner wrote: > Hi, > > Am Sonntag, den 10.05.2015, 19:39 +0100 schrieb Mateusz Kowalczyk: >> I'd like to bring some attention to ticket #4012 about non-determinism. >> As many of you may know, the nix package manager distributes binaries >> throughout its binary caches. The binaries are shared as long as the >> hash of some of their inputs matches: this means that we can end up with >> two of the same hashes of inputs but thanks to #4012 means that the >> actual contents can differ. You end up with machines with some packages >> built locally and some elsewhere and due to non-determinism, the GHC >> package IDs don't line up and everything is broken. > > is NixOS sensitive to changes in the build directory. Debian is, and > since 7.8 the build path creeps into the interface files and affects the > hash: https://bugs.debian.org/785282 > > But you probably are not, otherwise you’d have complained when 7.8 was > out, and not now :-) > > Greetings, > Joachim > Not a problem for nix, the paths are are calculated based on the derivation inputs. I don't want to go into details but if same expression goes in, same path comes out. If the path that comes out is different, you simply don't get to use it. More or less nix does ‘calculate the store path from this expression, check if it exists in binary caches and fetch it if it does, build if it does not’. So for us the store paths in the interface files would always be the same for the same inputs hence no problem there. -- Mateusz K.

3 4

Re: [commit: ghc] master: Refactor tuple constraints (ffc2150)
by Christiaan Baaij 20 May '15

20 May '15

Hi, This patch broke the ‘Binary’ instance for ‘IfaceType’ in ‘iface/IfaceType.hs’ Specifically, it changed: ``` put_ bh (IfaceLitTy n) = do { putByte bh 30; put_ bh n } ``` to: ``` put_ bh (IfaceLitTy n) = do { putByte bh 7; put_ bh n } ``` However, the ‘get’ definition was left as: ``` 30 -> do n <- get bh return (IfaceLitTy n) ``` I don’t know what’s preferable: - revert the definition of `put_`, - or update the `get` definition to `7` Regards, Christiaan > On 18 May 2015, at 14:45, git(a)git.haskell.org wrote: > > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/ffc21506894c7887d3620423aaf86bc61… > >> --------------------------------------------------------------- > > commit ffc21506894c7887d3620423aaf86bc6113a1071 > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Mon May 11 23:19:14 2015 +0100 > > Refactor tuple constraints > > Make tuple constraints be handled by a perfectly ordinary > type class, with the component constraints being the > superclasses: > class (c1, c2) => (c2, c2) > > This change was provoked by > > #10359 inability to re-use a given tuple > constraint as a whole > > #9858 confusion between term tuples > and constraint tuples > > but it's generally a very nice simplification. We get rid of > - In Type, the TuplePred constructor of PredTree, > and all the code that dealt with TuplePreds > - In TcEvidence, the constructors EvTupleMk, EvTupleSel > > See Note [How tuples work] in TysWiredIn. > > Of course, nothing is ever entirely simple. This one > proved quite fiddly. > > - I did quite a bit of renaming, which makes this patch > touch a lot of modules. In partiuclar tupleCon -> tupleDataCon. > > - I made constraint tuples known-key rather than wired-in. > This is different to boxed/unboxed tuples, but it proved > awkward to have all the superclass selectors wired-in. > Easier just to use the standard mechanims. > > - While I was fiddling with known-key names, I split the TH Name > definitions out of DsMeta into a new module THNames. That meant > that the known-key names can all be gathered in PrelInfo, without > causing module loops. > > - I found that the parser was parsing an import item like > T( .. ) > as a *data constructor* T, and then using setRdrNameSpace to > fix it. Stupid! So I changed the parser to parse a *type > constructor* T, which means less use of setRdrNameSpace. > > I also improved setRdrNameSpace to behave better on Exact Names. > Largely on priciple; I don't think it matters a lot. > > - When compiling a data type declaration for a wired-in thing like > tuples (,), or lists, we don't really need to look at the > declaration. We have the wired-in thing! And not doing so avoids > having to line up the uniques for data constructor workers etc. > See Note [Declarations for wired-in things] > > - I found that FunDeps.oclose wasn't taking superclasses into > account; easily fixed. > > - Some error message refactoring for invalid constraints in TcValidity > > - Haddock needs to absorb the change too; so there is a submodule update > > >> --------------------------------------------------------------- > > ffc21506894c7887d3620423aaf86bc6113a1071 > compiler/basicTypes/BasicTypes.hs | 21 +- > compiler/basicTypes/DataCon.hs | 1 - > compiler/basicTypes/RdrName.hs | 28 +- > compiler/basicTypes/Unique.hs | 28 +- > compiler/basicTypes/VarSet.hs | 23 +- > compiler/coreSyn/CoreLint.hs | 2 +- > compiler/coreSyn/MkCore.hs | 7 +- > compiler/coreSyn/PprCore.hs | 4 +- > compiler/deSugar/Check.hs | 2 +- > compiler/deSugar/DsArrows.hs | 2 +- > compiler/deSugar/DsBinds.hs | 25 +- > compiler/deSugar/DsCCall.hs | 6 +- > compiler/deSugar/DsExpr.hs | 5 +- > compiler/deSugar/DsMeta.hs | 840 +-------------------- > compiler/deSugar/Match.hs | 4 +- > compiler/ghc.cabal.in | 3 +- > compiler/ghci/RtClosureInspect.hs | 7 +- > compiler/hsSyn/Convert.hs | 4 +- > compiler/hsSyn/HsExpr.hs | 3 +- > compiler/hsSyn/HsPat.hs | 35 +- > compiler/hsSyn/HsTypes.hs | 2 +- > compiler/iface/BinIface.hs | 14 +- > compiler/iface/BuildTyCl.hs | 4 + > compiler/iface/IfaceSyn.hs | 9 +- > compiler/iface/IfaceType.hs | 154 ++-- > compiler/iface/TcIface.hs | 84 ++- > compiler/main/Constants.hs | 3 + > compiler/main/HscMain.hs | 11 +- > compiler/parser/Parser.y | 20 +- > compiler/parser/RdrHsSyn.hs | 164 +++- > compiler/prelude/PrelInfo.hs | 28 +- > compiler/prelude/PrelNames.hs | 17 - > compiler/prelude/PrelRules.hs | 6 +- > compiler/prelude/PrimOp.hs | 2 +- > compiler/prelude/THNames.hs | 836 ++++++++++++++++++++ > compiler/prelude/TysWiredIn.hs | 269 ++++--- > compiler/rename/RnEnv.hs | 1 + > compiler/rename/RnNames.hs | 42 +- > compiler/rename/RnSplice.hs | 6 +- > compiler/simplStg/UnariseStg.hs | 10 +- > compiler/specialise/Specialise.hs | 3 +- > compiler/stranal/WwLib.hs | 6 +- > compiler/typecheck/FunDeps.hs | 32 +- > compiler/typecheck/TcBinds.hs | 52 +- > compiler/typecheck/TcCanonical.hs | 32 - > compiler/typecheck/TcErrors.hs | 2 - > compiler/typecheck/TcEvidence.hs | 15 +- > compiler/typecheck/TcExpr.hs | 10 +- > compiler/typecheck/TcGenDeriv.hs | 15 +- > compiler/typecheck/TcHsSyn.hs | 5 +- > compiler/typecheck/TcHsType.hs | 15 +- > compiler/typecheck/TcInstDcls.hs | 4 +- > compiler/typecheck/TcInteract.hs | 11 +- > compiler/typecheck/TcMType.hs | 1 - > compiler/typecheck/TcPat.hs | 2 +- > compiler/typecheck/TcRnMonad.hs | 4 + > compiler/typecheck/TcSimplify.hs | 1 - > compiler/typecheck/TcSplice.hs | 2 +- > compiler/typecheck/TcTyClsDecls.hs | 20 +- > compiler/typecheck/TcType.hs | 3 - > compiler/typecheck/TcValidity.hs | 186 +++-- > compiler/types/TyCon.hs | 34 +- > compiler/types/Type.hs | 7 +- > compiler/types/TypeRep.hs | 11 +- > compiler/vectorise/Vectorise/Builtins/Base.hs | 2 +- > .../vectorise/Vectorise/Builtins/Initialise.hs | 2 +- > compiler/vectorise/Vectorise/Utils/Closure.hs | 4 +- > libraries/ghc-prim/GHC/Classes.hs | 44 +- > libraries/ghc-prim/GHC/Tuple.hs | 242 +++--- > libraries/ghc-prim/GHC/Types.hs | 2 +- > .../should_fail/NotRelaxedExamples.stderr | 17 +- > .../indexed-types/should_fail/TyFamUndec.stderr | 17 +- > testsuite/tests/module/all.T | 2 +- > testsuite/tests/module/mod89.hs | 2 + > testsuite/tests/module/mod89.stderr | 10 +- > .../tests/typecheck/should_fail/T9858a.stderr | 2 +- > .../tests/typecheck/should_fail/fd-loop.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail108.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail154.stderr | 6 +- > .../tests/typecheck/should_fail/tcfail157.stderr | 12 +- > .../tests/typecheck/should_fail/tcfail213.stderr | 4 +- > .../tests/typecheck/should_fail/tcfail214.stderr | 8 +- > .../tests/typecheck/should_fail/tcfail220.hsig | 1 - > .../tests/typecheck/should_fail/tcfail220.stderr | 8 - > utils/genprimopcode/Main.hs | 49 +- > utils/haddock | 2 +- > 86 files changed, 1985 insertions(+), 1672 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc ffc21506894c7887d3620423aaf86bc6113a1071 > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

2 1

RE: Some test data
by Tamar Christina 20 May '15

20 May '15

Hi Ben, I haven't noticed a target for ARM in the split script which is why it wasn't in my list. I'll check later but my guess if the ARM version of the compiler does not support obj-split. Cheers, TamarFrom: Ben Gamari Sent: ‎5/‎20/‎2015 14:38 To: Tamar Christina; GHC Subject: Re: Some test data Tamar Christina <lonetiger(a)gmail.com> writes: > Hi All, > > > I’m currently busy rewriting the GHC-split perl script into Haskell and require some for the platforms I don’t have at the moment. > > > I require an example file(s) for: > > - Apple Darwin > > - Sparc > > - PowerPC Linux > > - X86 Linux > > - X86_64 Linux > Is this to say that you have an ARM? If not I would be willing to do some testing once my hardware arrives (which may be a month or so sadly; it's currently drifting across the Atlantic). Cheers, - Ben

1 0

Some test data
by Tamar Christina 20 May '15

20 May '15

Hi All, I’m currently busy rewriting the GHC-split perl script into Haskell and require some for the platforms I don’t have at the moment. I require an example file(s) for: - Apple Darwin - Sparc - PowerPC Linux - X86 Linux - X86_64 Linux The test file I require can be generated using ghc -split-objs -keep-tmp-files -v <hs_file> and I’m looking for the file ending with .split_s (e.g. "R:\Temp\ghc1764_0\ghc1764_2.split_s") Any file of a non-trivial nature would be helpful. Thanks, Tamar

3 3

FFI problems on 64-bit Windows
by Yitzchak Gale 20 May '15

20 May '15

As I am sure many people have noticed, there is currently a serious problem with FFI on 64-bit Windows. It often happens that when you link in FFI against a standard DLL, the resulting application segfaults as soon as any function from the DLL is called. I experienced this problem with Bryan's text-icu library when I linked it against the standard Windows 64-bit DLLs provided by the ICU project. In this case, the workaround I found is to link instead against DLLs built using mingw-w64 and provided as part of MSYS2: https://mail.haskell.org/pipermail/haskell-cafe/2015-May/119737.html On reddit, /u/awson (is that Kyra?) pointed out that this issue is probably caused by a serious bug in GNU binutils that was fixed about two months ago: https://sourceware.org/bugzilla/show_bug.cgi?id=16598 Is it possible to update the MSYS2/mingw-w64 toolchain used by GHC to a recent version that includes this fix? Thanks, Yitz

1 0