December 2017 - ghc-tickets

[GHC] #12498: Support unconventionally named import libraries
by GHC 20 Mar '18

20 Mar '18

#12498: Support unconventionally named import libraries -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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: #11072 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use. Instead we should look at the presence of certain patterns. e.g. .o files contain only `.idata` sections etc. This would allow us to be able to support import libraries such as `gcc_s` and no longer need to hardcode the GCC library full name in cabal file. This should add more compatibility with packages on hackage. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12437: 20% regression in max_bytes_used for T1969
by GHC 20 Mar '18

20 Mar '18

#12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | 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: -------------------------------------+------------------------------------- This is 20% worse: {{{ =====> T1969(normal) 1 of 1 [0, 0, 0] cd "./T1969.run" && "/data/users/smarlow/ghc/inplace/test spaces/ghc- stage2" -c T1969.hs -dno-debug-output -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups +RTS -G1 -RTS +RTS -V0 -tT1969.comp.stats --machine-readable -RTS max_bytes_used value is too high: Expected T1969(normal) max_bytes_used: 15017528 +/-15% Lower bound T1969(normal) max_bytes_used: 12764898 Upper bound T1969(normal) max_bytes_used: 17270158 Actual T1969(normal) max_bytes_used: 18071064 Deviation T1969(normal) max_bytes_used: 20.3 % *** unexpected stat test failure for T1969(normal) }}} One of these patches is the culprit, but I can't tell from the build logs because the build was broken between these two points: {{{ commit 6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91 Author: Ömer Sinan Ağacan <omeragacan(a)gmail.com> Bump Haddock submodule commit 8d4760fb7b20682cb5e470b24801301cfbbdce3b Author: Simon Peyton Jones <simonpj(a)microsoft.com> Comments re ApThunks + small refactor in mkRhsClosure commit 9c54185b26922d88e516942aad946f05f707d7ce Author: Simon Peyton Jones <simonpj(a)microsoft.com> Comments + tiny refactor of isNullarySrcDataCon commit a09c0e3e68c96882a1fb392c9dbeea84056bf32f Author: Simon Peyton Jones <simonpj(a)microsoft.com> Comments only commit 714bebff44076061d0a719c4eda2cfd213b7ac3d Author: Ömer Sinan Ağacan <omeragacan(a)gmail.com> Implement unboxed sum primitive type }}} The patch immediately preceding this sequence does not have the failure: https://phabricator.haskell.org/rGHC83e4f49577665278fe08fbaafe2239553f3c448e (follow the link to the build) and the final patch in this sequence *does* have the failure: https://phabricator.haskell.org/rGHC6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91 (along with an improvement in T9675) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12437> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10933: REMOVED pragma
by GHC 20 Mar '18

20 Mar '18

#10933: REMOVED pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 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): | -------------------------------------+------------------------------------- Say I have a function that's been deprecated for some time. Then I remove it. Some clients will still use the now-missing function. It would be nice to give a helpful error message, instead of a "symbol not found" error. I thus propose a `REMOVED` pragma. The syntax is identical to `DEPRECATED`, except for the name of the pragma. Whenever a `REMOVED` function is mentioned, the error message includes the string from the pragma. (This includes trying to define a `REMOVED` class method in an instance.) See Design/DeprecationMechanisms for more info and related efforts. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11092: ApiAnnotations : make annotation for shebang
by GHC 20 Mar '18

20 Mar '18

#11092: ApiAnnotations : make annotation for shebang -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently a valid haskell file can have a first line of the form {{{#!lhs #!/usr/bin/env runhaskell }}} This does not end up as anything that can have an API Annotation, and so gets lost on round tripping. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10640: Document prim-ops
by GHC 20 Mar '18

20 Mar '18

#10640: Document prim-ops -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently documentation is quite scarce for many primops (particularly the BCO operations). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10640> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally
by GHC 20 Mar '18

20 Mar '18

#10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When used as an infix operator, a data constructor is explicitly promoted simply with `'` prefixed, but when used as a prefix operator enclosed between `(` and `)`, it is explicitly promoted only with `'` put before `(`, not before the constructor. On the other hand, messages of GHC and GHCi indicate that a data constructor operator in a prefix form is promoted by putting `'` before the constructor! (as in `forall (k :: BOX) (k :: BOX). (':*)` below.) I believe that this is a matter of parsing. The parser should admit `(':*)` as well as `'(:*)` for the naturalness of the syntax. In a GHCi: {{{#!hs > :set -XDataKinds -XTypeOperators > data a :* b = a :* b > :kind! Int :* Int Int :* Int :: * = Int :* Int > :kind! Int ':* Int Int ':* Int :: * :* * = Int ':* Int > :kind! (:*) (:*) :: * -> * -> * = (:*) > :kind! '(:*) '(:*) :: k -> k1 -> k :* k1 = forall (k :: BOX) (k :: BOX). (':*) > :kind! (':*) <interactive>:1:3: parse error on input ‘:*’ }}} (By the way I assume that Template Haskell quotes (`'function` and `''Type`) are parsed by the same mechanism as the one for the explicit promotion syntax. I hope both styles of quotes for prefix operators will be admitted because currently only the `'(` `''(` style is admitted.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10506: SourceNotes are not applied to all identifiers
by GHC 20 Mar '18

20 Mar '18

#10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling {{{ module Foo where foo x = x + 1 bar y = foo y }}} with `-g` produces {{{ $ ghc -g -ddump-ticked test.hs [1 of 1] Compiling Foo ( test.hs, test.o ) AbsBinds [a_avC] [$dNum_avD] {Exports: [foo <= foo_amB <>] Exported types: foo :: forall a_avC. Num a_avC => a_avC -> a_avC [LclId, Str=DmdType] Binds: -- ticks = [src<test.hs:3:1-13>] foo_amB x_alA = src<test.hs:3:9-13> (+) src<test.hs:3:9> x_alA src<test.hs:3:13> 1} AbsBinds [a_avV] [$dNum_avW] {Exports: [bar <= bar_avN <>] Exported types: bar :: forall a_avV. Num a_avV => a_avV -> a_avV [LclId, Str=DmdType] Binds: -- ticks = [src<test.hs:5:1-13>] bar_avN y_amz = src<test.hs:5:9-13> foo (src<test.hs:5:13> y_amz)} }}} Note that neither the occurrence of `(+)` in `foo`, nor the occurrence of `foo` in `bar` have their own Ticks. Instead they are only covered by the Tick for the entire application `x + 1` (resp. `foo y`). I'm trying to use the new SourceNote infrastructure to map CoreExprs back to their original source location, but unfortunately I need these locations for each identifier in the source. Would it be reasonable to add a SourceNote to each occurrence of an identifier? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic
by GHC 20 Mar '18

20 Mar '18

#10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently in `base` we have * `GHC.SrcLoc`: the data type `SrcLoc` contains `srcLocPackage` and `srcLocModule` * `Data.Typeable.Internals`: the data type `TyCon` contains `tyConPackage`, `tyConModule` and `tyConName. * `GHC.Generics`: the data type `Datatype` contains `dataTypePackage`, `dataTypeModule` and `dataTypeName` * `Data.Data`: the data type `DataType` (yes the capitalisation differs!) contains a field `tycon :: String`, and there are functions `tyconModule :: String -> String`, and `tyconUQname :: String -> String`, for parsing that string and extracting the module name and tycon name. * `GHC.StaticPtr`: the data type `StaticPtrInfo` contains `spInfoPackageKey`, `spInfoModuleName`, `spInfoName` (all `String`s). Oh, and `spInfoSrcLoc :: (Int,Int)` too! This is madness! Five different representations for the same information in one package! Let's fix this by defining some shared data types, for * `Module` = `ModuleName` + package * `Entity` = `Module` + unqualified name There would be a tiresome changeover period; but `Typeable` and `StaticPtr` are in flux anyway. Would anyone be willing to lead on this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10068> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #14468: Why does alanz's branch blow up GHC's heap?
by GHC 20 Mar '18

20 Mar '18

#14468: Why does alanz's branch blow up GHC's heap? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- alanz mentioned that moving all of GHC's `Data` instances [[https://git.haskell.org/ghc.git/blob/12028239b597e17fb3f3734c6b494e127be58e…]] to a new module causes the stage1 compile to run out of memory during compilation (he has 8 GB of memory). This is rather suspicious as this module isn't terribly large. IIRC typechecking time may be non-linear in program size, but I don't see why it would be non-linear in space. Investigate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14468> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11382: Optimize Data.Char
by GHC 20 Mar '18

20 Mar '18

#11382: Optimize Data.Char -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Core | Version: 7.10.3 Libraries | 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: -------------------------------------+------------------------------------- Many of the predicates in `Data.Char` do full Unicode category lookups which turns out to be quite expensive. Ideally we would handle some of the more common ASCII characters with cheaper tests before falling back to the full Unicode treatment. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8