- ghc-devs - Haskell.org

ByteArray# as a foreign import argument?
by Shao, Cheng 11 Oct '19

11 Oct '19

Hello devs, I've been trying to figure out how to pass lifted types as foreign types, then encountered the following code in the `DsCCall` module (https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/deSugar/DsCCall.hs#…) ``` -- Byte-arrays, both mutable and otherwise; hack warning -- We're looking for values of type ByteArray, MutableByteArray -- data ByteArray ix = ByteArray ix ix ByteArray# -- data MutableByteArray s ix = MutableByteArray ix ix (MutableByteArray# s) | is_product_type && data_con_arity == 3 && isJust maybe_arg3_tycon && (arg3_tycon == byteArrayPrimTyCon || arg3_tycon == mutableByteArrayPrimTyCon) = do case_bndr <- newSysLocalDs arg_ty vars@[_l_var, _r_var, arr_cts_var] <- newSysLocalsDs data_con_arg_tys return (Var arr_cts_var, \ body -> Case arg case_bndr (exprType body) [(DataAlt data_con,vars,body)] ) ``` It seems we allow a "ByteArray" type as a foreign import argument, if the third field of the datacon is a ByteArray# or MutableByteArray#. But I can't find such a ByteArray type definition in today's common packages. What's the rationale for this piece of code? Cheers, Cheng

4 8

GHC_STAGE
by Shayne Fletcher 10 Oct '19

10 Oct '19

Hi Ben, I observed warnings of this kind in a couple of places building head yesterday: ``` compiler/utils/FastString.hs:336:5: error: warning: 'GHC_STAGE' is not defined, evaluates to 0 [-Wundef] | 336 | #if GHC_STAGE < 2 | ^ #if GHC_STAGE < 2 ^ ``` ``` compiler/main/DynFlags.hs:323:5: error: warning: 'GHC_STAGE' is not defined, evaluates to 0 [-Wundef] | 323 | #if GHC_STAGE >= 2 | ^ #if GHC_STAGE >= 2 ^ ``` I was using the `hadrian/build.stack.sh` approach. Figured you'd want to know! -- *Shayne Fletcher* Language Engineer */* +1 917 699 7663 *Digital Asset* <https://digitalasset.com/>, creators of *DAML <https://daml.com/>* -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

2 2

Unsquashed merge requests
by Andreas Klebinger 10 Oct '19

10 Oct '19

Hello devs, I've recently seen a few MR's make it into master with commits which rather obviously were meant to be squashed. Please look out for this when assigning MRs to marge. Cheers Andreas

1 0

T13615 fragile?
by Richard Eisenberg 09 Oct '19

09 Oct '19

Hi devs, https://gitlab.haskell.org/rae/ghc/-/jobs/173504 <https://gitlab.haskell.org/rae/ghc/-/jobs/173504> tells me that T13615 failed -- but only in DEBUG mode. My patch is nowhere near this code. Is this a new fragile test? The number of fragile tests seems to be growing quickly. And once a test is labeled fragile, we're essentially no longer tracking the test, if I understand correctly. So that's a bit unfortunate. Thanks, Richard

3 2

slow load and typecheck
by Sam Halliday 09 Oct '19

09 Oct '19

Hello all, I am writing an interactive tool using the ghc api. It is able to load and typecheck a source file in a user's package. I obtain the flags that cabal uses to compile the user's package via the hie-bios trick, and I `parseDynamicFlagsCmdLine' them inside my tool, then I `setTargets' all the home modules (with targetAllowObjCode=True). I use HscNothing and NoLink because I only want access to the trees, I don't want to produce any output files. For the file that I wish to inspect, I `removeTarget' the module and `addTarget` it again but this time providing the full path to the file and don't allow object code. Then I LoadUpTo and typecheck. For the sake of simplicity, let's assume that the file under inspection only has a module definiton and no imports or top levels. Functionally, my code is working great and I am able to do what I want with the typechecked tree. However, load is very slow (~10 seconds user time) on large projects. Here is a cpu time trace of my program (milliseconds): main 1 parse flags 93 load 20436 typecheck 20437 I can enable a bit more ghc timing info via -Rghc-timings and I see !!! Chasing dependencies: finished in 157.20 milliseconds, allocated 528.112 megabytes This seems fine, anything sub-second is ok. But then I see a bunch of home modules in CodeGen that I was not expecting: !!! CodeGen [My.Module.Dependency]: finished in 3335.62 milliseconds, allocated 270.615 megabytes So it looks like the targetAllowObjCode is being ignored... is there any way to force it? Actually I'd prefer to fail fast than to ever compile or codegen a dependency module. I know that it should be possible to load the module a lot faster because if I make a small change in the file under inspection and ask cabal to recompile the module it is super fast (less than a second). Could somebody who understands how incremental/partial compiles work please help me out? PS: If this textual description is confusing, I could put together a minimal reproduction and example project but it will take me some time to do that. -- Best regards, Sam

4 14

[ANNOUNCE] GHC 8.8.1 is now available
by Ben Gamari 08 Oct '19

08 Oct '19

Hello everyone, The GHC team is pleased to announce the release candidate for GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/ghc/8.8.1 This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Visible kind applications are now supported (GHC Proposal #15) * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator significantly improving the runtime performance of some kernels * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * Users can write `forall` in more contexts (GHC Proposal #7) * The pattern-match checker is now more precise in the presence of strict fields with uninhabited types. * A comprehensive audit of GHC's memory ordering barriers has been performed, resulting in a number of fixes that should significantly improve the reliability of programs on architectures with weakly-ordered memory models (e.g. PowerPC, many ARM and AArch64 implementations). * A long-standing linker limitation rendering GHCi unusable with projects with cyclic symbol dependencies has been fixed (#13786) * Further work on the Hadrian build system * Countless miscellaneous bug-fixes Unfortunately, due to a build issue (#17108) found late in the release process i386 Windows builds are currently unavailable. These will be provided in the coming weeks. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1/docs/html/users_guide/8.8.1-notes.h…

4 5

Re: Coercible questions
by Michal Terepeta 07 Oct '19

07 Oct '19

Adding +ghc-devs <ghc-devs(a)haskell.org> to continue the thread Hi Sandy, Thanks for the answer! Do you think there is some fundamental reason for this? Or just a matter of implementing this in GHC? It seems to me that this should work just fine as long as the runtime representation is the same. And a related question--is it safe to `unsafeCoerce` an `Int` to a `Word`? The only reason for why this could be problematic that comes to my mind is that there could be an assumption that different `data`s do not alias each other (although `newtype`s can due to `Coercible` functionality). But I'm not sure this is ever used by GHC? Are there any other reasons why this could be problematic? Thanks! - Michal On Sat, Oct 5, 2019 at 5:27 PM Sandy Maguire <sandy(a)sandymaguire.me> wrote: > Hi Michal, > > Datas aren't coercible, only newtypes. This is why you can't coerce Ints > and Words, and why Foo and Bar don't work. > > Sandy > > On Sat, Oct 5, 2019 at 4:17 PM Michal Terepeta <michal.terepeta(a)gmail.com> > wrote: > >> Hi, >> >> I've started looking into using `Data.Coerce` (and the `Coercible` >> type-class) for a personal project and was wondering why coercing between >> `Int` and `Word` is not allowed? I don't see any fundamental reason why >> this shouldn't work... >> >> Perhaps, it's just a matter of GHC's implementation details leaking out? >> IIRC internally GHC has separate `RuntimeRep`/`PrimRep` for a `Word#` and >> for an `Int#`. If that's the case, would it make sense to unify these? >> Their actual runtime representation should be the same and I'd expect most >> (all?) of their differences should be attached to `PrimOp`s. >> >> And that leads me to another question--what exactly goes wrong here: >> ``` >> data Foo = Foo Int# >> data Bar = Bar Int# >> >> test :: Bar >> test = coerce (Foo 42#) >> ``` >> Which fails with: "Couldn't match representation of type ‘Foo’ with that >> of ‘Bar’ arising from a use of ‘coerce’" >> >> Perhaps I'm just misunderstanding exactly how `Coercible` works? >> >> Thanks in advance! >> >> - Michal >> >> PS. The ability to coerce through things like lists is amazing :) >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > -- > I'm currently travelling the world, sleeping on people's couches and doing > full-time collaboration on Haskell projects. If this seems interesting to > you, please consider signing up as a host! > https://isovector.github.io/erdos/ >

3 2

Should coercion binders (arguments or binders in patterns) be TyVars?
by Ömer Sinan Ağacan 07 Oct '19

07 Oct '19

Hi, I just realized that coercion binders are currently Ids and not TyVars (unlike other type arguments). This means that we don't drop coercion binders in CoreToStg. Example: {-# LANGUAGE ScopedTypeVariables, TypeOperators, PolyKinds, GADTs, TypeApplications, MagicHash #-} module UnsafeCoerce where import Data.Type.Equality ((:~:)(..)) import GHC.Prim import GHC.Types unsafeEqualityProof :: forall k (a :: k) (b :: k) . a :~: b unsafeEqualityProof = error "unsafeEqualityProof evaluated" unsafeCoerce :: forall a b . a -> b unsafeCoerce x = case unsafeEqualityProof @_ @a @b of Refl -> x If I build this with -ddump-stg this is what I get for `unsafeCoerce`: UnsafeCoerce.unsafeCoerce :: forall a b. a -> b [GblId, Arity=1, Unf=OtherCon []] = [] \r [x_s2jn] case UnsafeCoerce.unsafeEqualityProof of { Data.Type.Equality.Refl co_a2fd -> x_s2jn; }; See the binder in `Refl` pattern. Unarise drops this binder because it's a "void" argument (doesn't have a runtime representation), but still it's a bit weird that we drop types but not coercions in CoreToStg. Is this intentional? Ömer

4 5

Hadrian failure after worktree update
by Bryan Richter 05 Oct '19

05 Oct '19

Below is an error message I have seen a number of times after rebasing my git worktree, i.e. this is how to "reproduce": git fetch origin git rebase origin/master git submodule update ./hadrian/build.sh (Obviously some details are elided, and this is not a complete reproduction.) I don't have many copies of the error, but I do remember seeing the complaint about "No generator for .../PmOracle.hs" on other occasions. Any idea what this comes from? -Bryan --- 8< --- Error when running Shake build system: at action, called at src/Rules.hs:71:19 in main:Rules at need, called at src/Rules.hs:93:5 in main:Rules * Depends on: _build/stage0/lib/package.conf.d/ghc-8.9.0.20190929.conf at need, called at src/Rules/Register.hs:113:5 in main:Rules.Register * Depends on: _build/stage0/compiler/build/libHSghc-8.9.0.20190929.a * Depends on: _build/stage0/compiler/build/GHCi.o * Depends on: _build/stage0/compiler/build/GHCi.o _build/stage0/compiler/build/GHCi.hi * Depends on: OracleQ (KeyValues ("_build/stage0/compiler/.dependencies","_build/stage0/compiler/build/GHCi.o")) * Depends on: _build/stage0/compiler/.dependencies * Depends on: _build/stage0/compiler/.dependencies.mk at need, called at src/Rules/Dependencies.hs:26:9 in main:Rules.Dependencies * Depends on: _build/stage0/compiler/build/PmOracle.hs at error, called at src/Rules/Generate.hs:105:34 in main:Rules.Generate * Raised the exception: No generator for _build/stage0/compiler/build/PmOracle.hs.

2 1

Coercible questions
by Michal Terepeta 05 Oct '19

05 Oct '19

Hi, I've started looking into using `Data.Coerce` (and the `Coercible` type-class) for a personal project and was wondering why coercing between `Int` and `Word` is not allowed? I don't see any fundamental reason why this shouldn't work... Perhaps, it's just a matter of GHC's implementation details leaking out? IIRC internally GHC has separate `RuntimeRep`/`PrimRep` for a `Word#` and for an `Int#`. If that's the case, would it make sense to unify these? Their actual runtime representation should be the same and I'd expect most (all?) of their differences should be attached to `PrimOp`s. And that leads me to another question--what exactly goes wrong here: ``` data Foo = Foo Int# data Bar = Bar Int# test :: Bar test = coerce (Foo 42#) ``` Which fails with: "Couldn't match representation of type ‘Foo’ with that of ‘Bar’ arising from a use of ‘coerce’" Perhaps I'm just misunderstanding exactly how `Coercible` works? Thanks in advance! - Michal PS. The ability to coerce through things like lists is amazing :)

1 0