March 2015 - ghc-tickets

[GHC] #9122: Make Lint check for bad uses of `unsafeCoerce`
by GHC 10 Mar '15

10 Mar '15

#9122: Make Lint check for bad uses of `unsafeCoerce` ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I think it would be a great idea for Core Lint to check for uses of `unsafeCoerce` that don't obey the rules. It won't catch all cases, of course, but it would have caught #9035. Specficially, look for: * Coercions between lifted and unboxed types * Coercion between unboxed types of different sizes * Coercion between unboxed ints and floats. Would anyone like to make a patch for this? Anything that can be checked by Core Lint, should be checked! I'm afraid I don't know where to look for the reason for the int/float difficulty. I'd write a tiny function that exhibits the unsafe conversion and look the code it generates. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 10 Mar '15

10 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by simonpj): Two thoughts * I'm relaxed about what we choose here. It really matters little; and it's been a long-standing bug in GHC. * You do have a point: that `FlexibleContexts` sounds as if it has to do with type-signature contexts (and it does); and so does `ConstrainedClassMethods`. So perhaps it would be more intuitive to make `FlexibleContexts` imply `ConstrainedClassMethods` than `MultiParamTypeClasses`? But I bet there are packages that use `MultiParamTypeClasses` but not `FlexibleContexts`. So * Perhaps we should try making `FlexibleContexts` imply `ConstrainedClassMethods`, but ''not'' `MultiParamTypeClasses`, just to see what happens. * If it's painful, then maybe the path of least resistance is to make both imply `ConstrainedClassMethods`. Any views from others? Would someone like to try the experiment? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 10 Mar '15

10 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by ekmett): That was me speaking as me, not in any official capacity. =) I had honestly thought FlexibleContexts _was_ the extension for this sort of thing until now. Putting on my CLC hat for a bit, the main reason I can see why it'd be nice to have FlexibleContexts "just work" is it means we don't have to make the hackage trustees go back and retrofit all sorts of old versions of packages with base upper bounds wherever they find themselves encountering this issue. But mostly that rises to the left of "nice to have" not really "have to have". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide
by GHC 10 Mar '15

10 Mar '15

#10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.4 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've been reading the [http://haskell.inf.elte.hu/docs/7.11.20150306.noWin32/html/users_guide /safe-haskell.html documentation] on Safe Haskell. Cool stuff. Here are some suggestions for improvement, I hope some are useful: * 7.29.1.2 This comment is the first introduction to the pragmas `TrustWorthy` and `Safe`: {{{ -- Either of the following Safe Haskell pragmas would do {-# LANGUAGE Trustworthy #-} {-# LANGUAGE Safe #-} module RIO ... }}} Why is either allowed? I suspect because of the details of this module, but this is not explicitly stated. Furthermore, later it is said that `-XTrustworthy` should be used, not `-XSafe`: "This is done by compiling the RIO module with the -XTrustworthy flag and compiling the Danger module with the -XSafe flag." * 7.29.2 "TemplateHaskell — Is particularly dangerous, as it can cause side effects even at compilation time" One could now think that `Safe Haskell` does guarantee compilation safety. Since that is not the case, I would remove that sentence (things are explained properly in the Safe Compilation section). * 7.29.2 "Hand crafted instances of the Typeable type class are not allowed in Safe Haskell". Make a mention of the [https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/deriving.html following]: "... since GHC 7.8.1, handwritten (ie. not derived) instances of Typeable are forbidden, and will result in an error." * 7.29.4 After listing `-XSafe`, `-XTrustWorthy`, `-XUnsafe`: "The procedure to check if a module is trusted or not depends on if the -fpackage-trust flag is present. The check is very similar in both cases" There are three cases. * 7.29.4.1. Trust check (-fpackage-trust disabled) "A module M in a package P is trusted by a client C if and only if: Both of these hold: 1. The module was compiled with -XSafe 2. All of M's direct imports are trusted by C" But isn't the latter implied by the former, or the module wouldn't compile? If that is correct, please mention it. Same in the next section (7.29.4.2). * 7.29.4.2 "Having the -fpackage-trust flag also nicely unifies the semantics of how Safe Haskell works when used explicitly and how modules are inferred as safe." Should explicitly be implicitly? I don't understand this sentence regardless. What does nicely unifies mean? * 7.29.4.1 and 7.29.4.2 There is no mention of Safe Haskell Inference in these rules, only "The module was compiled with -XSafe" and "The module was compiled with -XTrustWorthy". I think the following statement should be true, but I'm not sure: "If a module M in a package P is inferred to be Safe by GHC, then it is trusted by client C". Actually, there is only a short mention of safe inference in the introduction, whereas I suspect it should be mentioned everywhere where `-XSafe` is. * 7.29.5 "That is, the use cases outlined and the purpose for which Safe Haskell is intended: compiling untrusted code." Before, "compiling and executing untrusted code" was listed as one of two cases. Now it's mentioned as the single purpose. Minor issue. * 7.29.5 "Say you are writing a Haskell library. Then you probably just want to use Safe inference." I have more of a general question about this: if this is true, then why are there over 200 mentions of `{-# Language Safe #-}` in a checkout of ghc? Is it because 'Safe Haskell Inference' was not added to GHC until version 7.4 (is that true? I inferred it from the difference between the 7.2 and 7.4 user's guides). So maybe modules that need to be compileable with earlier versions of GHC have to specify -XSafe explicitly? Some guidance on this would be helpful. * There are 2 `ulink`s that don't work. Should be `xref`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10140> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #2991: .tix file generation broken with -fhpc and --make flags with lhs modules
by GHC 09 Mar '15

09 Mar '15

#2991: .tix file generation broken with -fhpc and --make flags with lhs modules -------------------------------------+------------------------------------- Reporter: ppavel | Owner: andy@… Type: bug | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.10.1 Resolution: fixed | Keywords: hpc make Operating System: Unknown/Multiple | lhs Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: hpc/T2991 | Blocking: | Differential Revisions: Phab:D701 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2991#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2991: .tix file generation broken with -fhpc and --make flags with lhs modules
by GHC 09 Mar '15

09 Mar '15

#2991: .tix file generation broken with -fhpc and --make flags with lhs modules -------------------------------------+------------------------------------- Reporter: ppavel | Owner: andy@… Type: bug | Status: patch Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.10.1 Resolution: | Keywords: hpc make Operating System: Unknown/Multiple | lhs Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: hpc/T2991 | Blocking: | Differential Revisions: Phab:D701 -------------------------------------+------------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"f9344f3646156a9efff2dcfb90e1d5d67fd4f5a1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f9344f3646156a9efff2dcfb90e1d5d67fd4f5a1" Fix `ghc --make -fhpc` with imported lhs modules See Note [Don't normalise input filenames] in `compiler/main/DriverPipeline.hs`. Fixes #2991. Reviewers: austin Differential Revision: https://phabricator.haskell.org/D701 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2991#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations
by GHC 09 Mar '15

09 Mar '15

#7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9722 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9722 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7325#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #7651, #4471, #7478, #8095, #8736, #8832, #9198, #9968, #10067, #9821
by GHC 09 Mar '15

09 Mar '15

Batch modification to #7651, #4471, #7478, #8095, #8736, #8832, #9198, #9968, #10067, #9821 by thoughtpolice: milestone to 7.12.1 Comment: Moving to the 7.12.1 milestone, as these tickets won't be fixed in time for the 7.10.1 release (unless you, the reader, help write a patch :) -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=7651%2C4471%2C7478%2C8095%2C8736%2…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10128: Data.List.transpose needs more docs
by GHC 09 Mar '15

09 Mar '15

#10128: Data.List.transpose needs more docs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.4 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- as mentioned by Doug McIlroy on haskell-prime. My preference in the interest of brevity would be to not include the equations that Doug mentioned and simply add his nicely constructed educating example to the docs: > The transpose function transposes the rows and columns of its argument. For example, > > {{{ > transpose [[1,2,3],[4,5,6]] == [[1,4],[2,5],[3,6]] > }}} > > If some of the rows are shorter than the following rows, their elements are skipped: > > {{{ > transpose [[10,11],[20],[],[30,31,32]] == [[10,20,30],[11,31],[32]] > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10128> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10058: Panic: Loading temp shared object failed
by GHC 09 Mar '15

09 Mar '15

#10058: Panic: Loading temp shared object failed -----------------------------------------+--------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- I ran into a panic when updating `singletons` for 7.10. I'm clueless as to what's going on here, so sorry for not minimizing the test case. A little testing has me convinced it's Template Haskell in some way. To reproduce: {{{ > git clone http://github.com/goldfirere/singletons.git > cd singletons > git checkout ghc-loading-panic-test-case > cabal update > cabal install --only-dependencies > cabal configure > cabal build > cat dist/build/autogen/cabal_macros.h # copy the value for CURRENT_PACKAGE_KEY from the end of cabal_macros.h > cd tests/compile-and-dump > ghc -c -this-package-key <package key from cabal_macros.h> -i../../dist/build -XTemplateHaskell Singletons/Maybe.hs }}} You will see something like {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150123 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib, 5): Symbol not found: _mtlzuJNaGzzEkFfL43R3LZZNRlPRm_ControlziMonadziReaderziClass_DZCMonadReader_con_info Referenced from: /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib Expected in: flat namespace in /var/folders/ps/s45r2x1s6r15ws78py_zypl00000gn/T/ghc45837_0/libghc45837_1.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've observed this on a Mac, but Travis has the same problem, so it's not strictly Mac-specific. You can see representative Travis output [https ://travis-ci.org/goldfirere/singletons/jobs/49103793 here]. Why am I doing such a crazy thing? It's part of the `singletons` test suite, where it's important to test the output of a run of ghc with `-ddump-splices`. Getting the test cases to compile against the built-but- not-yet-installed `singletons` object files should work with `-this- package-key`. I'm sure there's a better way to structure a testsuite, but this general technique works (with `-package-name` instead of `-this- package-key`) with 7.8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19