February 2018 - ghc-tickets

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 19 Feb '18

19 Feb '18

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not sure which comment you are replying to; and I fear I don't understand what "something like this" is. The big trouble with recursive modules is that: either you need a programmer written signature file (i.e. `.hs-boot`) or you have to compile all the modules in the SCC at once. I don't see any other path. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:73> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7259: Eta expansion of products in System FC
by GHC 19 Feb '18

19 Feb '18

#7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.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: | -------------------------------------+------------------------------------- Comment (by simonpj): > This is currently imperilled by #14420. How, exactly? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7259#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14788: `error` in GHC internals can disappear by rerunning ghc again
by GHC 19 Feb '18

19 Feb '18

#14788: `error` in GHC internals can disappear by rerunning ghc again -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #14533 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was messing around with GHC's source code and thus triggered a bug, manifesting in my case as the `pprPanic "applyTypeToArgs" panic_msg` in `applyTypeToArgs` in GHC 8.2.1. Expectedly, ghc died with `the 'impossible' happened` while compiling a package (in my case `vector`). With output like this (it's not important to read the output in detail, only to see the `.o` file involved): {{{ [17 of 21] Compiling Data.Vector.Storable.Mutable ( Data/Vector/Storable/Mutable.hs, .stack- work/dist/x86_64-linux/Cabal-2.0.0.2/build/Data/Vector/Storable/Mutable.o ) Data/Vector/Storable/Mutable.hs:77:1: warning: [-Wunused-imports] The import of ‘Foreign.Ptr’ is redundant except perhaps to import instances from ‘Foreign.Ptr’ To import instances alone, use: import Foreign.Ptr() | 77 | import Foreign.Ptr | ^^^^^^^^^^^^^^^^^^ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): applyTypeToArgs Expression: n#_aKi p_a3X ds5_XM4 ds7_aKj x#_aKa eta_X1H Type: Int# Args: [p_a3X, ds5_XM4, ds7_aKj, x#_aKa, eta_X1H] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreUtils.hs:226:14 in ghc:CoreUtils }}} What I did not expect was that by rerunning my `ghc --make` invocation again, the error would disappear! This is because after the error, the `.o` file is corrupt, just cut off in the middle. The reason is probably that GHC writes the `.o` file contents from an expression that can contain `error` thunks deep in, so the error only surfaces in the middle of the writing. As a result, the `.o` file is touched and `ghc --make` build pipeline, when resumnig the build next time, thinks that the `.o` file was completed all fine. I think `ghc --make` should not write the `.o` file when there's an obvious error. I suggest that ghc either `deepseq` the string to be written to the `.o` file before calling `writeFile` or equivalent, or write the file to an `.o.tmp` file and rename the temp file upon completion. The latter approach would also help against corrupted files due to power loss, see #14533. Fixing this would make developing GHC easier, as right now you can accidentally continue from a completely broken state (corrupt `.o` file) and only notice the error much later and then have to backtrack. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14788> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #602: Warning Suppression
by GHC 19 Feb '18

19 Feb '18

#602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Design/LocalWarningPragmas | -------------------------------------+------------------------------------- Comment (by simonpj): Same request made in #14805. It looks like a very reasonable request to me; but (especially since GHC has to move code around when doing strongly-connected component analysis of type and value bindings) not entirely straightforward to implement. Needs someone to propose a concrete design and implementation path. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/602#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11791: Remove the `isInlinePragma prag` test
by GHC 19 Feb '18

19 Feb '18

#11791: Remove the `isInlinePragma prag` test -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11781, #5928 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a spin off of tickjet:11781#comment:9, where simonpjs writes: > What is more mysterious to me is why the unfolding for `$fApplicativeIO_$c*>` doesn't have `bindIO`, and then `bindIO` inlined into it, which would allow a cascade of further improvements, which would, I think, produce essentially the same code as `thenIO`. > > The offending corner is this > {{{ > active_unfolding_gentle id > = isInlinePragma prag -- WHY?? > && isEarlyActive (inlinePragmaActivation prag) > }}} > So I tried removing the `isInlinePragma prag` test, and indeed the code becomes identical. > > Conclusion: > * I'd love to make the above change to `active_unfolding_gentle` and see if any other performance numbers budge. I doubt that anything will change a lot -- it really only affects whether optimisation happens before or after inlining -- but it should improve compiler performance a bit for that very reason. This could be a separate ticket > > Incidentally, see #5928 which is somewhat related. This ticket tracks that idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11791> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14812: Dot-Notation for Function Application
by GHC 19 Feb '18

19 Feb '18

#14812: Dot-Notation for Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Please allow to put a dot `.` (without spaces) between two things for ''flipped'' function application. This could make for code in pseudo-OOP style: {{{#!hs encrypt(str) = do { str.map(succ); } }}} Currently, as a workaround, this can be achieved by defining `(.) = flip ($)` (making `.` for function composition unavailable, though): {{{#!hs encrypt(str) = do { str.map(succ); } where (.) = flip ($) }}} (For a remotely similar look-and-feel, one could use `Data.Function.((&))` instead of `(.)`.) Please note that `.` without spaces is already an OOP-like notational convenience in order to denote Modules and their elements. {{{#!hs x = do { Prelude.length("Hello World!"); } }}} This means, that a distinction between ` . ` (with spaces) and `.` (without spaces) is already been made, which is why `Just . Just $ 42` compiles, wheras `Just.Just $ 42` doesn't. Analogously, with this Feature Request implemented, `"Hello".map(succ)` would compile whereas `"Hello" . map(succ)"` wouldn't. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 19 Feb '18

19 Feb '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4325 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 583e392a83c17e8baf45bc6ee5b998afae190a44. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14820: MultiFunctionalDependencies
by GHC 19 Feb '18

19 Feb '18

#14820: MultiFunctionalDependencies -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14820> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4102: Bit manipulation built-ins
by GHC 18 Feb '18

18 Feb '18

#4102: Bit manipulation built-ins -------------------------------------+------------------------------------- Reporter: uzytkownik | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Core Libraries | Version: 6.12.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14819 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #14819 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4102#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14818: Provide highestOneBit function in Data.Bits module
by GHC 18 Feb '18

18 Feb '18

#14818: Provide highestOneBit function in Data.Bits module -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | 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 function yields the [https://stackoverflow.com/a/17379704/105137 largest power of 2 less than or equal to the given number]. Relative to the Java standard library, which [https://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#highestOne… provides this function], there is a gap in the Haskell library, even though the Haskell docs [https://hackage.haskell.org/package/base-4.10.1.0/docs/Data- Bits.html#v:countLeadingZeros describe a method to calculate logBase2 via the `countLeadingZeros` function]. From the Java documentation: > The implementations of the "bit twiddling" methods (such as `highestOneBit` and `numberOfTrailingZeros`) are based on material from Henry S. Warren, Jr.'s ''Hacker's Delight'', (Addison Wesley, 2002). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14818> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5