January 2017 - ghc-tickets

[GHC] #13103: The RTS loader/linker relies too heavily on file extensions.
by GHC 10 Jan '17

10 Jan '17

#13103: The RTS loader/linker relies too heavily on file extensions. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13093 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS linker & loader relies way too heavily on file extensions instead of the structure of the file. This means that if we have stuff like object files in archives that don't end with `.o` and `.p_o` we won't load them. Or import libraries etc. This should be changed to use the structure of the file header to determine what the file is. This means that GCC and binutils handle a lot more files than we currently do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13103> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12990: Partially applied constructors with unpacked fields simplified badly
by GHC 10 Jan '17

10 Jan '17

#12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When a constructor is partially applied to at least one unpacked field, the simplifier produces pretty lousy results. {{{#!hs data Foo a = Foo !Int a silly :: ((a -> Foo a) -> r) -> r silly f = f (Foo 3) }}} compiles to {{{ -- RHS size: {terms: 9, types: 7, coercions: 0} $WFoo :: forall a. Int -> a -> Foo a $WFoo = \ (@ a_aqI) (dt_ayl :: Int) (dt_aym :: a_aqI[sk:1]) -> case dt_ayl of { I# dt_ayn -> Foo dt_ayn dt_aym } -- RHS size: {terms: 2, types: 0, coercions: 0} silly2 :: Int silly2 = I# 3# -- RHS size: {terms: 3, types: 3, coercions: 0} silly1 :: forall a. a -> Foo a silly1 = \ (@ a_ayG) -> $WFoo silly2 -- RHS size: {terms: 5, types: 9, coercions: 0} silly :: forall a r. ((a -> Foo a) -> r) -> r silly = \ (@ a_ayG) (@ r_ayH) (f_axY :: (a -> Foo a) -> r) -> f_axY silly1 }}} That is, GHC represents `Foo 3` as a closure containing a ''boxed'' `Int`. Manually eta-expanding would fix it. {{{#!hs silly :: ((a -> Foo a) -> r) -> r silly f = f (\x -> Foo 3 x) }}} compiles to {{{#!hs -- RHS size: {terms: 5, types: 4, coercions: 0} silly1 :: forall a. a -> Foo a silly1 = \ (@ a_ayO) (x_ay9 :: a) -> Foo 3# x_ay9 -- RHS size: {terms: 5, types: 9, coercions: 0} silly :: forall a r. ((a -> Foo a) -> r) -> r silly = \ (@ a_ayO) (@ r_ayP) (f_ay8 :: (a -> Foo a) -> r) -> f_ay8 silly1 }}} in which the `Int` is unpacked into the closure. This transformation is valid whenever the value to be stored unpacked is known not to be bottom, and is certainly a good idea if it's known to have been forced. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12990> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13079: Fixed typo in docs
by GHC 10 Jan '17

10 Jan '17

#13079: Fixed typo in docs -------------------------------------+------------------------------------- Reporter: forki | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13090: Expose all unfoldings of overloaded functions by default
by GHC 10 Jan '17

10 Jan '17

#13090: Expose all unfoldings of overloaded functions by default -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 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): Phab:D2929 | Wiki Page: -------------------------------------+------------------------------------- Users expect their overloaded functions to be specialised at call sites, however, this is only the case if they are either lucky and GHC chooses to include the unfolding or they mark their definition with an INLINABLE pragma. This leads to library authors marking all their functions with INLINABLE (or more accurately INLINE) so they ensure that downstream consumers pay no cost for their abstraction. A more sensible default is to do this job for the library author and give more predictable guarantees about specialisation. Empirically, I compiled a selection of 1150 packages with (a similar) patch applied. The total size of the interface files before the patch was 519mb and after 634mb. On modern machines, I think this increase is justified for the result. This is a ticket to track the progress of D2929. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13090> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13076: GHC panics can cause text-formatting changes from colorized error messages to linger
by GHC 10 Jan '17

10 Jan '17

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: #13076: GHC panics can cause text-formatting changes from colorized error messages to linger + Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8809, #12785 Differential Rev(s): | Wiki Page: + This bug relies on GHC panicking right after emitting a normal error message, so take note that I reproduced this error using a GHC HEAD build at commit 508811004d1806b28a91c3ff4a5c2247e2ad4655, and if #12785 is fixed, then this won't be reproducible anymore. If I compile this program from #12785: [...] Content analysis details: (7.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 1.2 MISSING_HEADERS Missing To: header 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language

1 4

[GHC] #13096: Remove tyConString
by GHC 10 Jan '17

10 Jan '17

#13096: Remove tyConString -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.0.1 Libraries | 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: -------------------------------------+------------------------------------- `Data.Typeable.tyConString` has been deprecated since GHC 7.4. We are long past the three-release rule, so it's time to remove it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13095: Remove deprecated InteractiveEval API
by GHC 10 Jan '17

10 Jan '17

#13095: Remove deprecated InteractiveEval API -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- `RunResult(..)`, `runStmt`, and `runStmtWithLocation` were all deprecated in cf7573b8207bbb17c58612f3345e0b17d74cfb58, replaced by functions able to give more precise allocation statistics. Comments document them as slated for removal in 7.14. As I calculate it, 7.14=8.2, so the time has come. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13095> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13049: Make `-dead_strip` the default on Darwin
by GHC 10 Jan '17

10 Jan '17

#13049: Make `-dead_strip` the default on Darwin -------------------------------------+------------------------------------- Reporter: dobenour | 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: -------------------------------------+------------------------------------- We should make `-dead_strip` the default on Darwin. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11592: Self-kinded type varialbe accepted
by GHC 10 Jan '17

10 Jan '17

#11592: Self-kinded type varialbe accepted -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Found when chasing #11407 {{{ data T (a::a) = Blah -- Accepted data S (b :: a) a = ... -- Rejected with: variable ‘a’ used as a kind variable before being bound -- as a type variable. Perhaps reorder your variables? }}} But `T` should be rejected too, for the same reason as `S` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11592> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #1791: heap overflow should generate an exception
by GHC 10 Jan '17

10 Jan '17

#1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 6.8 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2790 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: ⊥ => 8.2.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1791#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0