January 2016 - ghc-tickets

[GHC] #11502: Scrutinize use of 'long' in rts/
by GHC 19 Dec '16

19 Dec '16

#11502: Scrutinize use of 'long' in rts/ -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | 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: -------------------------------------+------------------------------------- In commit 53055bb5023e8cc145ad8a9cd36ac56cee4695b0 (#5656), several uses of `int` in the rts were replaced by `long`, to avoid potential overflows for some calculations. On Windows though, `int` and `long` have the same size (4 bytes). Carefully go through all uses of `long` in `rts/`, and replace by one of the types from `includes/stg/Types.h`: * `long` -> `StgInt` or `StgInt64` * `unsigned long` -> `StgWord` or `StgWord64` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots
by GHC 19 Dec '16

19 Dec '16

#10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: | Owner: scpmw thoughtpolice | Status: new Type: bug | Milestone: 7.10.1 Priority: high | Version: 7.10.1-rc1 Component: Profiling | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #9961 Blocking: | Differential Revisions: Phab:D616 | -------------------------------------+------------------------------------- Split off from #9961 - the profiling results while debugging erroneously reported that most cost centre profiles were a result of `lintAnnots`, as opposed to `CSE`. This is a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10723: Make declarations in signatures "weakly bound" until they are used
by GHC 17 Dec '16

17 Dec '16

#10723: Make declarations in signatures "weakly bound" until they are used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 7.11 system | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Suppose you are the author of a library in a Backpack world, and you publish a signature package which defines the entire public facing interface of your library. The library `foo` which uses of your library decides to `include` the signature package for convenience, but actually only uses a small portion of the API. Later, you make a BC-breaking change in one part of the library and release a new signature package. The library `bar` which uses your library includes this NEW signature package, using a different portion of the API which was unaffected by the by the BC change. Now, a hapless user tries to use `foo` and `bar`, but Backpack complains that the requirements are not compatible. What's the problem here? The practice of writing reusable signature packages for people to use caused the requirements of `foo` and `bar` to become too large, since they included a lot of junk that these libraries didn't actually use. It would be far better if you could `include` a signature package, but only "require" the bits of it that you actually used! How can we achieve this? 1. We augment the `ModIface` of signature merges (#10690) to record whether or not a declaration was (transitively) used or not by some module. Used declarations must be filled, but unused ones are treated more flexibly: if they are merged with a different, incompatible but used requirement, they disappear, and we don't check if an implementing module actually implemented the declaration. (If two unused incompatible requirements are merged, we just erase the name.) 2. How do we compute the usage info? I think it will have to be done during shaping (which runs the renamer). We only need to annotate each declaration a signature with the transitive set of names from other signatures that it has used--this can be incrementally computed. (It's not necessary to annotate declarations in modules, since they are always assumed to use holes). Then whenever a declaration from a signature is used in a module, we mark its transitive set as used. This information can then be used later when constructing the merged `ModIface` which represents the "public requirement" of the package. So, for example, a package containing only signatures would contain all unused declarations (however, they may start being used by a package which includes them). Any unused declaration which isn't mixed with another incompatible declaration can be imported (causing it to be used), but we will complain if you try to use a name and we can't tell which declaration to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9601: Make the rewrite rule system more powerful
by GHC 16 Dec '16

16 Dec '16

#9601: Make the rewrite rule system more powerful -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more | Type of failure: than a week) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be amazing if the current RULES system could be upgraded to include various predicates, or even into a full-on strategic programming system. This would allow far far more optimisations to be possible, rather than the current conservative system where you have to make sure that the optimisations ALWAYS apply. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11221: Remove -fwarn-context-quantification
by GHC 16 Dec '16

16 Dec '16

#11221: Remove -fwarn-context-quantification -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- This option was deprecated and does nothing as of GHC 8.0. Remove `Opt_WarnContextQuantification` and its uses from `DynFlags`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size)
by GHC 15 Dec '16

15 Dec '16

#8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: 8287 ----------------------------------------------+---------------------------- currently GHC's internals and code gen don't provide a strong distinction between Ints as data, and Ints for pointer / address arithmetic. This also comes up as being problematical in a number of ways. 1. We wind up having many portability issues around Int and pointer / address sizes. 2. adds some inessential complexity / problems to adding new architectures to ghc. eg x32 ABI which has 32bit pointers and 64bit ints somewhat breaks current assumptions in the GHC primops (because arrays are indexed by a byte offset, and the valid range for those is determined by the ABI pointer size!) 3. this Ints and Ptrs confusion we currently have, also means we can't leverage the Integer support in SIMD registers that is in most modern CPUs! If we could have those two separated better, theres a lot of low leve optimizations we could do for Int/Word data that we currently cant do! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8299> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators
by GHC 15 Dec '16

15 Dec '16

#11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Throughout GHC's source there are related pretty-printing operators with subtly different `infixr/infixl`-declarations. It would be desirable to unify those and possibly use `Semigroup((<>))` instead (where `<>` represents a semigroup/monoid operation anyway) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11243: Use Type Synonyms to Compress Errors
by GHC 15 Dec '16

15 Dec '16

#11243: Use Type Synonyms to Compress Errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Error messages can be ugly, especially when working with promoted types. I've been dealing with this for a long time with [one library in particular](https://hackage.haskell.org/package/lol). But I just encountered something truly heinous. Due to a minor mistake, GHC spit out 8 errors in total, the shortest of which was 60 lines, and the longest of which was 20,046 lines long. That's no typo: the last error is over 20,000 lines long. Props to GHC for handling such a mess. As the library author, I've learned to look paste these massive errors. But I'm afraid that some user is going to have a heart attack (or worse: give up and go home). You can see in the error message that most of it is recurring blocks of {{{ PrimePower ('PP '(type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type- natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type- natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type- natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0)))))), type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type-natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0)) }}} and {{{ (NextListElt * zq ((':) * (ZqBasic * Types.Q18869761 Types.Z) ((':) * (Types.Zq * Types.Q19393921, ZQ1) ((':) * (Types.Zq * Types.Q19918081, ZQ2) ((':) * (Types.Zq * Types.Q2149056001, ZQ3) ((':) * (Types.Zq * Types.Q3144961, ZQ4) ((':) * (Types.Zq * Types.Q7338241, ZQ5) ('[] *))))))))), }}} I believe that GHC attempts to expand type synonyms as much as possible, which is great in many cases. But for this error, the repetition of fully expanded blocks completely hides the true nature of the error, especially since the user (obviously) makes heavy use of type synonyms anyway. The feature I'm requesting is the ability to somehow reduce the mess in the attached error. Here are a few ideas: 1. A flag to tell GHC to *not* expand type synonyms, i.e. if the user uses `N2` from Data.Type.Natural, GHC should print 'N2' instead of {{{ type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 (type-natural-0.3.0.0:Data.Type.Natural.Definitions.SSym1 type-natural-0.3.0.0:Data.Type.Natural.Definitions.ZSym0) }}} 2. Allow library developers a way to tell the compiler how to print a certain entity, i.e., with a custom name. This is somewhat similar to the Custom Type Errors proposal, but I don't think that proposal includes a way to tell GHC how to print specific types/type synonyms. Has anyone else run into this issue before? Are there any existing solutions or other ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #10301: Plugins/dynamic loading subtly broken (it seems)
by GHC 15 Dec '16

15 Dec '16

#10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.8.2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: | crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #8276 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Imported from #8276, which was originally about a Haddock bug (that was different in nature but appeared similarly): > I still experience this panic on GHC 7.8.2 with Windows x86_64: > > {{{ > $ ghci > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > λ> import StaticFlags > λ> import Data.IORef > λ> readIORef v_opt_C_ready > Loading package array-0.5.0.0 ... linking ... done. > Loading package deepseq-1.3.0.2 ... linking ... done. > Loading package bytestring-0.10.4.0 ... linking ... done. > Loading package containers-0.5.5.1 ... linking ... done. > Loading package Win32-2.3.0.2 ... linking ... done. > Loading package filepath-1.3.0.2 ... linking ... done. > Loading package old-locale-1.0.0.6 ... linking ... done. > Loading package time-1.4.2 ... linking ... done. > Loading package directory-1.2.1.0 ... linking ... done. > Loading package pretty-1.1.1.1 ... linking ... done. > Loading package process-1.2.0.0 ... linking ... done. > Loading package Cabal-1.18.1.3 ... linking ... done. > Loading package binary-0.7.1.0 ... linking ... done. > Loading package bin-package-db-0.0.0.0 ... linking ... done. > Loading package hoopl-3.10.0.1 ... linking ... done. > Loading package hpc-0.6.0.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package transformers-0.3.0.0 ... linking ... done. > Loading package ghc-7.8.2 ... linking ... done. > False > λ> staticFlags > ghc.exe: panic! (the 'impossible' happened) > (GHC version 7.8.2 for x86_64-unknown-mingw32): > Static flags have not been initialised! > Please call GHC.parseStaticFlags early enough. > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > But not with GHC 7.8.2 on Linux x86_64: > > {{{ > $ ghci > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > λ> import StaticFlags > λ> import Data.IORef > λ> readIORef v_opt_C_ready > Loading package array-0.5.0.0 ... linking ... done. > Loading package deepseq-1.3.0.2 ... linking ... done. > Loading package bytestring-0.10.4.0 ... linking ... done. > Loading package containers-0.5.5.1 ... linking ... done. > Loading package filepath-1.3.0.2 ... linking ... done. > Loading package old-locale-1.0.0.6 ... linking ... done. > Loading package time-1.4.2 ... linking ... done. > Loading package directory-1.2.1.0 ... linking ... done. > Loading package pretty-1.1.1.1 ... linking ... done. > Loading package process-1.2.0.0 ... linking ... done. > Loading package Cabal-1.18.1.3 ... linking ... done. > Loading package binary-0.7.1.0 ... linking ... done. > Loading package bin-package-db-0.0.0.0 ... linking ... done. > Loading package hoopl-3.10.0.1 ... linking ... done. > Loading package hpc-0.6.0.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package transformers-0.3.0.0 ... linking ... done. > Loading package ghc-7.8.2 ... linking ... done. > True > λ> staticFlags > [] > }}} > > This has caused problems for me when running programs such as [https://github.com/ku-fpg/hermit/ HERMIT] on Windows, since at some point, {{{parseStaticFlagsFull}}} seems to be called during program execution. A workaround is to call {{{initStaticOpts}}} manually somewhere in the program, but I feel like that shouldn't be necessary. The one above was on Windows. Also reported: > Hello, > > A similar panic also happens when running Liquid Haskell [http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/] on a file that uses the Units of Measure plugin [https://github.com/adamgundry/uom- plugin] > > > {{{ > liquid: liquid: panic! (the 'impossible' happened) > (GHC version 7.10.1 for x86_64-unknown-linux): > Static flags have not been initialised! > Please call GHC.parseStaticFlags early enough. > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #10294: Missing instances if compiling with -fplugin
by GHC 15 Dec '16

15 Dec '16

#10294: Missing instances if compiling with -fplugin -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Linux Keywords: | Type of failure: GHC rejects Architecture: x86_64 | valid program (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using the example from "9.3.3.2. Using Annotations" of the GHC user manual does not work correctly with GHC 7.10. The following fails: $ ghc -c Bug1.hs -fplugin=SayAnnNames.Plugin {{{ Bug1.hs:5:1: No instance for (Data SomeAnn) arising from an annotation In the annotation: {-# ANN foo SomeAnn #-} }}} It does not seem to matter why the type class is required: $ ghc -c Bug2.hs -fplugin=SayAnnNames.Plugin {{{ Bug2.hs:10:7: No instance for (Data SomeAnn) arising from a use of ‘bar’ In the expression: bar SomeAnn In an equation for ‘baz’: baz = bar SomeAnn }}} Compiling without -fplugin works fine, though. If SomeAnn is defined in a different module than SayAnnNames.Plugin and reexported from it, the instances are in scope, too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10294> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7