September 2016 - ghc-tickets

[GHC] #12581: Testsuite segfaults on OS X
by GHC 09 Sep '16

09 Sep '16

#12581: Testsuite segfaults on OS X --------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- {{{ git bisect start # bad: [34010dbe77ac405da6c671c3feb3573d0d025379] Derive the Generic instance in perf/compiler/T5642 git bisect bad 34010dbe77ac405da6c671c3feb3573d0d025379 # good: [b4dfe04aa77bb2d0ce2c7d82cab5e4425e0b738c] Fix kind generalisation for pattern synonyms git bisect good b4dfe04aa77bb2d0ce2c7d82cab5e4425e0b738c # skip: [39103062e50249da857761d0eaca325aa428e446] Add -XStaticPointers to the flag reference. git bisect skip 39103062e50249da857761d0eaca325aa428e446 # good: [0c0129b6a82a87a9bba19f27a4b19fec9ccc5a8d] RtsUtils: Use `size_t` instead of `int` where appropriate git bisect good 0c0129b6a82a87a9bba19f27a4b19fec9ccc5a8d # good: [bdb0d24be9c83b08fd3f4b870a17f6be31a24b1b] Remote GHCi: separate out message types git bisect good bdb0d24be9c83b08fd3f4b870a17f6be31a24b1b # bad: [4036c1f110578f8e2813295116b79a5a06e2bf59] Testsuite: fix T10482a git bisect bad 4036c1f110578f8e2813295116b79a5a06e2bf59 # bad: [6cedef01e00e95517a546a72592ba6ff07bac605] Test Trac #12133 git bisect bad 6cedef01e00e95517a546a72592ba6ff07bac605 # bad: [9854f14ef0a3a6f399a1aa4c141c5e3dddcd77ff] Add a new determinism test git bisect bad 9854f14ef0a3a6f399a1aa4c141c5e3dddcd77ff # good: [206b4a1d0e82e8f0f40f6e36cf657146a8d4b36a] Testsuite: simplify extra_file handling git bisect good 206b4a1d0e82e8f0f40f6e36cf657146a8d4b36a # bad: [dc62a22279846abe7e84ef57896f0a38f6b7b845] Wibble error message for #11471 git bisect bad dc62a22279846abe7e84ef57896f0a38f6b7b845 # bad: [6b3b631e90aa5f6f9322efcb81e9b13d14d087f0] Testsuite: run all indexed-types ways on ./validate --slow git bisect bad 6b3b631e90aa5f6f9322efcb81e9b13d14d087f0 # bad: [58f0086b70f2f409b9f88de1611efcf18756f9e5] Testsuite: open/close stdin/stdout/stderr explicitly git bisect bad 58f0086b70f2f409b9f88de1611efcf18756f9e5 # good: [bafd615e40c2a11af1390e736f6122033eecc4c6] Testsuite: do not print timeout message git bisect good bafd615e40c2a11af1390e736f6122033eecc4c6 # first bad commit: [58f0086b70f2f409b9f88de1611efcf18756f9e5] Testsuite: open/close stdin/stdout/stderr explicitly }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12581> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #393: functions without implementations
by GHC 09 Sep '16

09 Sep '16

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * owner: => Iceland_jack Comment: Code from discussion thread [https://github.com/ramda/ramda- lens/pull/2#issuecomment-181955004 comment] would be valid: > The only way to write such a function is to use methods in the `Profunctor` interface of which there is only 1. Thus, if we have any value `i :: Iso s a` we know it must be of the form > > {{{#!hs > i = dimap fwd bck > where > fwd :: s -> a > bck :: a -> s > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11433: sphinx: Error: source directory and destination directory are same.
by GHC 08 Sep '16

08 Sep '16

#11433: sphinx: Error: source directory and destination directory are same. -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building the Debian package, the build fails with {{{ writing output... [100%] win32-dlls generating indices... genindex writing additional pages... search copying images... [100%] images/prof_scc.svg copying static files... done copying extra files... done dumping search index in English (code: en) ... done dumping object inventory... done build succeeded, 5 warnings. /usr/bin/sphinx-build -b man -d docs/users_guide/.doctrees-man docs/users_guide docs/users_guide Error: source directory and destination directory are same. docs/users_guide/ghc.mk:30: recipe for target 'docs/users_guide/ghc.1' failed make[3]: *** [docs/users_guide/ghc.1] Error 1 Makefile:122: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/<<PKGBUILDDIR>>' }}} Full build log attached. Any idea what might be causing this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11433> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #12580: Eagerly simplify inherently-coherent instances
by GHC 08 Sep '16

08 Sep '16

#12580: Eagerly simplify inherently-coherent instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- [https://downloads.haskell.org/~ghc/8.0.1/docs/html/libraries/ghc-8.0.1/src/…] explains that `~~` and `~` are "inherently coherent", so GHC can reduce them immediately to their constraints. It seems to me that certain user- written classes can also be seen to be inherently coherent in this fashion. Specifically, given {{{#!hs class constraintC => C a1 a2 ... instance constraintI => C a1 a2 ... }}} where `a1`, `a2`, etc., are type variables, `C` is inherently coherent if both of the following hold: 1. `C` has no methods whatsoever. 2. `constraintC` entails `constraintI` (so the constraints are effectively identical). I believe in these cases GHC can and probably should reduce `C a1 a2` immediately to `constraintC`. Condition (2) is more general that we really need; in realistic cases, the constraints will be identical up to alpha renaming because most people don't write obfuscated code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12580> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12579: Allowed to create non-alphanumeric data / newtype constructor that cannot be used
by GHC 08 Sep '16

08 Sep '16

#12579: Allowed to create non-alphanumeric data / newtype constructor that cannot be used -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 can't remember if this had been filed before but this is present in both 7.8.4 and 8.0.1: {{{ Prelude> newtype A = (****) Int }}} There is no way to use the constructor `****`: {{{ Prelude> :i A newtype A = **** Int -- Defined at <interactive>:3:1 Prelude> :i **** Top level: Not in scope: ‘****’ Prelude> :t (****) <interactive>:1:1: Not in scope: ‘****’ Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9880: ghc crashes on th splices in instance context
by GHC 08 Sep '16

08 Sep '16

#9880: ghc crashes on th splices in instance context -------------------------------------+------------------------------------- Reporter: Philonous | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Given Class.hs: {{{#!hs module Class where class Foo a where bar :: a -> Int }}} TH.hs {{{#!hs {-# LANGUAGE TemplateHaskell #-} module TH where import Class import Language.Haskell.TH mkFun :: Q [Dec] mkFun = return [FunD 'bar [Clause [WildP] (NormalB (LitE (IntegerL 0))) []]] }}} and Instance.hs {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Instance where import TH import Class instance Foo Bool where $(mkFun) }}} compiling the project crashes ghc with {{{ #ghc --make Instance.hs [2 of 3] Compiling TH ( TH.hs, TH.o ) [3 of 3] Compiling Instance ( Instance.hs, Instance.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): cvBindsAndSigs $[splice{v}]mkFun{v} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9880> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 08 Sep '16

08 Sep '16

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12576: Large Address space is unenable-able on Windows.
by GHC 08 Sep '16

08 Sep '16

#12576: Large Address space is unenable-able on Windows. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12573 #12495 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Autoconf file changes have made it impossible to enable `USE_LARGE_ADDRESS_SPACE` for Windows, as the `--enable-large-address- space` flag is only respected on Darwin. The general case now depends on the presence of MADV_FREE to enable large address space support. Which means all possibility of enabling this feature on Windows have been removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #5972: option to suppress (Monomorphic) record selector functions
by GHC 07 Sep '16

07 Sep '16

#5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: records Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Thank you Adam for the implementation detail. Remember: * This ticket was raised 4+ years ago (strewth!) when there were huge debates raging about the "Records problem" and a great deal of nothing had been achieved. (It was even before PolyKinds and type-level Strings IIRC.) I wanted to free up some of the design space. * I am not an implementor, so what the ticket requests is in terms of an end-programmer's view. * My remarks just above (and back then) re field labels vs selectors are in terms of the language report [section 3.15] "[Field] Selectors are top level bindings ... This [name] shadowing only affects selector functions; in record construction (Section 3.15.2) and update (Section 3.15.3), field labels cannot be confused with ordinary variables." > When I read this ticket I didn't imagine that enabling this flag would allow duplicate field labels, ... No that wasn't the aim. I was merely aiming to avoid gobbling up the name space. DuplicateRecordFields is a different way to avoid it. > ... just suppress the generation of the field accessors. > > Anyway, this ticket was instructive because it showed how tightly intertwined the implementation is. Yes. Isn't it! I rather wish I hadn't found that out. We still seem a long way from a decent records system. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5972#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5972: option to suppress (Monomorphic) record selector functions
by GHC 07 Sep '16

07 Sep '16

#5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: records Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Replying to [comment:14 AntC]: > Hi Matthew, I guess this whole ticket has been overtaken by the DuplicateRecordFields extension in GHC 8.0. This ticket was written way before SPJ and Adam arrived at that approach. There might still be some lensaholics who hanker after the namespace. For the record ... > > > A field label and record selector are currently the same thing. > > You might think that because they are spelt the same, and one always comes with the other under H98, but actually as at H98 they're not. And that's the point: > > * a record selector is a function, first-class. If the language didn't create one automatically, you could do it yourself. > * a field label can only appear in specific record access contexts {inside curly braces}. It is not first-class; only syntax sugar for positional access to the fields of the constructor. > > I agree there are namespace concerns if a user creates their own function with the same name (which is indeed the purpose). This chiefly affects module export/import. See the link in the OP for more detail. > > > It would seem that a correct solution would place field labels in a separate namespace ... > > I believe the pre-DuplicateRecordFields implementation unsugarred the field labels so they didn't occupy a namespace atall. Perhaps the situation is now different with Overloaded labels. Hi Ant, yes, I am one of those 'lensaholics'. Adam is right that I was referring to the implementation where a field label is identified by the `Name` of the selector (in the non-overloaded case). I don't think this is related to overloaded record fields really. When I read this ticket I didn't imagine that enabling this flag would allow duplicate field labels, just suppress the generation of the field accessors. Anyway, this ticket was instructive because it showed how tightly intertwined the implementation is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5972#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0