- ghc-devs - Haskell.org

Fwd: GHC | Hadrian: ld crashes linking HStime on macos (#16685)
by Shayne Fletcher 23 May '19

23 May '19

Hi Andrey, On Thu, May 23, 2019 at 10:04 AM Andrey Mokhov <gitlab(a)gitlab.haskell.org> wrote: > I've travelling all week, so can't look into this issue properly, but > can't we simply revert the commit that introduced the breakage? Looks like > it was committed just a week ago. > I'll have to defer to the approvers on this one - I'm just a reporter :) -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher(a)daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> New York, NY 10007, USA <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> digitalasset.com <http://www.digitalasset.com/> -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher(a)daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> New York, NY 10007, USA <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> digitalasset.com <http://www.digitalasset.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.

1 0

Processing MRs very slow?
by Iavor Diatchki 22 May '19

22 May '19

Hello, I made a gitlab MR that adds two NOINLINE pragmas and some comments. It's been about a week since my last push to the MR, and nothing has happened since. Is there a way to check on what is its status: - Is it stuck because I need to do something? - Is it stuck because someone else needs to do something? - Or is it just in the queue to be merged, in which case it would be nice to know where in line it is, so I can see that there is progress, and it is not just stuck. Given that this is such a simple MR, I am not too worried about conflicts but a week long lag seems less than ideal for anything even mildly complex. -Iavor PS: I just clicked on all the little check boxes from the template---perhaps that's why things weren't progressing?

3 3

[hadrian/macos] build broken
by Shayne Fletcher 22 May '19

22 May '19

I'm trying to isolate the commit that's causing this, but the deal is on MacOS I'm seeing stage1 `ld` crashes linking `HStime`: ``` 0 0x1052e2748 __assert_rtn + 129 1 0x1052be30f ld::Fixup::Fixup(unsigned int, ld::Fixup::Cluster, ld::Fixup::Kind, bool, char const*) + 95 2 0x1052e8736 mach_o::relocatable::Parser<x86_64>::addFixup(mach_o::relocatable::Parser<x86_64>::SourceLocation const&, ld::Fixup::Cluster, ld::Fixup::Kind, bool, char const*) + 34 3 0x1052eaa9c mach_o::relocatable::Section<x86_64>::addRelocFixup(mach_o::relocatable::Parser<x86_64>&, macho_relocation_info<Pointer64<LittleEndian> > const*) + 1722 4 0x1052ff61b mach_o::relocatable::Section<x86_64>::makeFixups(mach_o::relocatable::Parser<x86_64>&, mach_o::relocatable::Parser<x86_64>::CFI_CU_InfoArrays const&) + 105 5 0x1052faa66 mach_o::relocatable::Parser<x86_64>::parse(mach_o::relocatable::ParserOptions const&) + 2120 6 0x1052f1250 mach_o::relocatable::Parser<x86_64>::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 282 7 0x10534352a ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 808 8 0x105345f22 ld::tool::InputFiles::parseWorkerThread() + 530 9 0x7fff70a6b2eb _pthread_body + 126 10 0x7fff70a6e249 _pthread_start + 66 A linker snapshot was created at: /tmp/HStime-1.9.2.o-2019-04-22-132113.ld-snapshot ld: Assertion failed: (name != NULL), function Fixup, file /Library/Caches/com.apple.xbs/Sources/ld64/ld64-450.3/src/ld/ld.hpp, line 724. ``` I can replicate this on multiple machines and different versions of xcode command line tools. Any ideas? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher(a)daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> New York, NY 10007, USA <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> digitalasset.com <http://www.digitalasset.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 4

RE: Bug or feature?
by Simon Peyton Jones 22 May '19

22 May '19

We have to be careful in how we define "equality" in the above sentence, including class constraints that (may) have superclass equality constraints. Indeed. That’s what happens now. I do think this would work. Cool. Nick or Iavor: would you like to turn this conversation into a ticket? (Although it is technically user-facing, it is a very small corner and I’m not sure it would need a GHC proposal – others may want to comment.) Simon From: Richard Eisenberg <rae(a)cs.brynmawr.edu> Sent: 21 May 2019 09:43 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: Nicolas Frisby <nicolas.frisby(a)gmail.com>; Iavor Diatchki <iavor.diatchki(a)gmail.com>; ghc-devs(a)haskell.org; Ryan Scott <ryan.gl.scott(a)gmail.com> Subject: Re: Bug or feature? On May 21, 2019, at 10:23 AM, Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> wrote: But (A) looks sound to me. I like (A). (B) makes me nervous, too. > A. An implication is considered to “bind local equalities” iff it has at least one given equality whose free variables are not all bound by the same implication. We have to be careful in how we define "equality" in the above sentence, including class constraints that (may) have superclass equality constraints. I do think this would work. Richard

3 2

make fails with "No entry for "integer library" in .../inplace/lib/settings"
by Roland Senn 21 May '19

21 May '19

Hi, Suddenly I'm unable to build ghc with make. I get the error: "inplace/bin/ghc-cabal" check libraries/ghc-prim "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install -- with-ghc="/home/roland/Projekte/ghc/inplace/bin/ghc-stage1" --with-ghc- pkg="/home/roland/Projekte/ghc/inplace/bin/ghc-pkg" --disable-library- for-ghci --enable-library-vanilla --enable-library-for-ghci --disable- library-profiling --enable-shared --configure-option=CFLAGS="- Wall -Werror=unused-but-set-variable -Wno-error=inline" -- configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc- options="-Wall -Werror=unused-but-set-variable -Wno- error=inline " --with-gcc="gcc" --with-ld="ld.gold" --with-ar="ar" -- with-alex="/home/roland/Software/ghc/bin/alex" --with- happy="/home/roland/Software/ghc/bin/happy" Configuring ghc-prim-0.6.1... ghc-cabal: '/home/roland/Projekte/ghc/inplace/bin/ghc-stage1' exited with an error: No entry for "integer library" in "/home/roland/Projekte/ghc/inplace/lib/settings" libraries/ghc-prim/ghc.mk:4: die Regel für Ziel „libraries/ghc- prim/dist-install/package-data.mk“ scheiterte make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Fehler 1 Makefile:123: die Regel für Ziel „all“ scheiterte make: *** [all] Fehler 2 Any ideas what's wrong? Any ideas how to fix? Many thanks and best wishes Roland PS: I still need the old make based build system to run validations...

2 1

Re: Bug or feature?
by Ryan Scott 21 May '19

21 May '19

Hi Iavor, This is a feature in the sense that it is an expected outcome of the OutsideIn(X) type inference algorithm (in particular, Section 5 of the corresponding paper [1]). I'll try to explain the issue to the best of my understanding. The tricky thing about the Q3 data type: data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) Is that there is a rank-n type with a /local/ equality constraint. In order to ensure that the type of the Q3 data constructor is never ambiguous, GHC tries to infer that Q3's type is always a subtype of itself. As a part of this, GHC attempts to solve the following implication constraint: forall a. forall b. (F b ~ Int) => (a ~ alpha) Where `alpha` is a unification variable. GHC tries to find a unique, most-general substitution that solves this constraint but ultimately gives up and reports the "untouchable" error message you observed. This is a bit strange, however. Upon first glance, this constraint would appear to have a unique solution: namely, [alpha |-> a]. Why doesn't GHC just use this? Ultimately, it's because OutsideIn(X) is conservative: there may exist constraints that admit a unique solution which it may fail to solve. This is explained in greater depth in Section 5.2 of the paper, but the essence of this restriction is because of the open-world assumption for type families. Namely, it's possible that your Q3 data type might later be linked against code which defines the following type family: type family G i a type instance G Int a = a If that were the case, then the implication constraint above would no longer have a unique solution, since there would exist another substitution [alpha |-> G (F b) a] that is incomparable with [alpha |-> a]. OutsideIn(X) was designed to only pick unique solutions that remain unique solutions even if more axioms (i.e., type family equations) are added, so for these reasons it fails to solve the implication constraint above. See also GHC issues #10651 [2], #14921 [3], and #15649 [4], which all involve similar issues. ----- I'm far from an expert on type inference, so I can't really offer a better inference algorithm that would avoid this problem. The best you can do, as far as I can tell, is to enable AllowAmbiguousTypes and hope for the best. Even then, you'll still run into situations where untouchability rears its ugly head, as in your `q3` definition. When that happens, your only available option (again, as far as I can tell) is to make use of TypeApplications. For example, the following /does/ typecheck: q3 :: Q3 q3 = Q3 @Bool t Hope that helps, Ryan S. ----- [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp-out… [2] https://gitlab.haskell.org/ghc/ghc/issues/10651 [3] https://gitlab.haskell.org/ghc/ghc/issues/14921 [4] https://gitlab.haskell.org/ghc/ghc/issues/15649

4 4

Re: gitlab upgrade - change in approval system
by Ryan Scott 18 May '19

18 May '19

To be clear, your workaround is precisely what I used to do, but that is no longer working after the GitLab upgrade. I can add myself as a reviewer, but only to a group besides the default approvers list. Because Marge only counts approvals from those who belong to the default approvers list, my approvals don't count anymore. Ryan S.

1 0

Re: gitlab upgrade - change in approval system
by Ryan Scott 18 May '19

18 May '19

I would definitely appreciate changing Marge's behavior back to the old one. As things stand currently, I am unable to approve anything that I'm not explicitly listed as a reviewer for. See here [1] for an example of where this has happened. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/559#note_198714

2 1

Bug or feature?
by Iavor Diatchki 17 May '19

17 May '19

Hello, I've encountered some odd behavior related to quantification and type families, but I am not sure if it is a bug or by design. Here is an example which works fine: > {-# Language ExistentialQuantification, RankNTypes, TypeFamilies #-} > > data T a b = T a > > t :: T Bool a > t = T True > > data Q1 = forall a. Q1 (forall b. T a b) > > q1 :: Q1 > q1 = Q1 t Now, suppose we wanted to constraint the universally quantified type of the field. This also works fine: > data Q2 = forall a. Q2 (forall b. (b ~ Int) => T a b) > > q2 :: Q2 > q2 = Q2 t However, things break down if the restriction involves a type family: > type family F a > > data Q3 = forall a. Q3 (forall b. (F b ~ Int) => T a b) > > q3 :: Q3 > q3 = Q3 t This causes some complaints about *a*, resulting from checking ambiguity. If we `AllowAmbiguousTypes`, then the definition of `Q3` is accepted, but `q3` fails with a similar error, complaining that GHC cannot match `a` with `Bool` because it is "untouchable". This seems confusing---I would have thought that when we use the `Q3` constructor we are providing the value for `a` (e.g., it is `Bool`), so I am not sure why GHC is trying to match anything. Any ideas? -Iavor

1 0

gitlab upgrade - change in approval system
by Matthew Pickering 17 May '19

17 May '19

Hi, I just noticed that the gitlab upgrade has caused the approval system to change. Before all that was required was 1 approval from anyone. Now, at least one approval from the default group is required (me, Ben, Omer, Tobias, David) I couldn't see a way to turn back to the old behaviour from a brief look at the UI. Do you know if there is a way Ben? Cheers, Matt

1 0