- ghc-tickets - Haskell.org

[GHC] #9192: Add sameByteArray#
by GHC 15 Nov '14

15 Nov '14

#9192: Add sameByteArray# ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- We have `sameMutableByteArray#` so we ought to have `sameByteArray#` as well, allowing for cheap equality checks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9197: FFI types should be usable in foreign import decls without revealing representations
by GHC 15 Nov '14

15 Nov '14

#9197: FFI types should be usable in foreign import decls without revealing representations ------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (FFI) | 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: | ------------------------------------+------------------------------------- This is another go at #5529 but with, we hope, clearer and better arguments. The original FFI spec defined a whole bunch of FFI types that are acceptable in foreign import/export declarations, including lots of things defined in Foreign.C.*. The original spec defined these as abstract types. The original FFI spec also allowed for automatic newtype unwrapping in foreign declarations. In 2009 Simon PJ [pointed out http://www.haskell.org/pipermail/haskell-prime/2009-February/002726.html] that automatic newtype unwrapping breaks abstraction for user-defined types. In that same thread [I suggested http://www.haskell.org/pipermail /haskell-prime/2009-February/002727.html] that the breaking of abstraction for user types should be fixed, but that the intent of the FFI spec to have the FFI types as abstract should be kept. Manuel [argued http://www.haskell.org/pipermail/haskell-prime/2009-February/002729.html] that the C FFI types should actually not be abstract, and thus no special case for them was needed. On the basis of that thread the decision in #5529 was to only allow FFI decls to look through newtypes when the constructor is available, plus for a few types GHC uses to represent the C FFI types, like Int32 etc. Johan and I want to argue that it still makes sense as a user to not be forced into knowing the representation of the C FFI types to be able to use them. This is similar to but slightly weaker than the rationale of the FFI spec originally making those types abstract. Manuels argument is essentially that sometimes you need to know concrete types when those can change, e.g. CInt might be Int32 or Int64 and you should be free to depend on that difference. Manuel's argument is fine when the "concrete" representation exists as yet another portable type, as is the case for Int32. Of course we don't insist that the representation for Int or Int32 be exposed, in large part because they cannot have a Haskell implementation independent representation. The important point is Johan and I are defining/writing a portable low level ByteArray library that could be considered alongside the FFI's definition of some of the Foreign.* libraries: it defines and API for some low level types and functions but different Haskell implementations will implement them differently. For GHC we implement `data ByteArray = BA ByteArray#`. We want to make this an FFI type, in the same sense as the FFI spec defines the C types to be FFI types. (You could consider our library as a Haskell extension and implementations following this extension will support this type for FFI in a similar way to the FFI spec). Of course for this implementation of `ByteArray` the representation crosses the boundary into implementation dependent, unlike the case for `newtype CInt = CInt Int32` where both are still portable types. So, we think the right thing to do is to again be able to declare certain types (those defined in the FFI spec and its extensions) as being valid types to use in FFI decls, without their constructors being available. Thus users could choose to import `CInt` only (i.e. without its constructor) and use it. We are not arguing against Manuel's point that it's sometimes useful to not hide representations where that is possible (like for CInt being an Int32 or 64). So we are not asking that the C FFI types be made abstract again, just that it be possible to use them (and our new type) as FFI types without user access to the constrctor. For GHC, my suggestion for a reasonable way to do this is with a pragma. The pragma would say that this single-constrcutor single-field newtype or data is an FFI type, and that GHC may perform the usual newtype unwrapping even when the constructor is not in scope at the FFI decl site. We would then use this pragma on Int, Int32 and other core GHC (and FFI) types, and also on the various C FFI types. And finally, we would also do this on our ByteArray type. Note that it would have to cover data as well as newtype to be able to work for Int and other boxed wrappers of unboxed types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9197> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9802: A ghci bug
by GHC 15 Nov '14

15 Nov '14

#9802: A ghci bug -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: :force :type | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Prelude> let a = [1,2,3] (0.00 secs, 0 bytes) Prelude> :t a a :: Num t => [t] Prelude> :force a a = _ Prelude> a [1,2,3] (0.02 secs, 3580816 bytes) Prelude> :print a a = (_t1::Num t => [t]) Prelude> :t _t1 ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): tcTyVarDetails t{tv auB} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9802> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5462: Deriving clause for arbitrary classes
by GHC 15 Nov '14

15 Nov '14

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5462#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5462: Deriving clause for arbitrary classes
by GHC 15 Nov '14

15 Nov '14

#5462: Deriving clause for arbitrary classes -------------------------------------+------------------------------------- Reporter: simonpj | Owner: dreixel Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.2.1 Component: Compiler | Keywords: Generics Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #7346 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D476 | -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:D476 Comment: It's up for review at Phab:D476! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5462#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 15 Nov '14

15 Nov '14

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac | Owner: Dupree | Status: new Type: feature | Milestone: ⊥ request | Version: 6.10.2 Priority: normal | Keywords: backpack Component: Compiler | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9256 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9256 Comment: See #9256 for a recent proposal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2258: ghc --cleanup
by GHC 15 Nov '14

15 Nov '14

#2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: VictorDenisov Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4114 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by VictorDenisov): Replying to [comment:17 bheklilr]: > I'd be willing to try to take this on as my first contribution to GHC (along with [https://ghc.haskell.org/trac/ghc/ticket/4114 4114] since it's rather related) if someone would be willing to help me along. I insist this is my ticket) I assigned it to me when nobody was. Please find another unassigned ticket assign it to you and work on it. (4114 I also assigned to me since they are related) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2258#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2258: ghc --cleanup
by GHC 15 Nov '14

15 Nov '14

#2258: ghc --cleanup -------------------------------------+------------------------------------- Reporter: claus | Owner: VictorDenisov Type: feature | Status: new request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: newcomer Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #4114 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Just do it :-) If you run into problems or have any questions ask here, on ghc-devs, or in #ghc IRC channel. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2258#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9286: ghc-7.9.20140707 fails testsuite on OS X (
by GHC 15 Nov '14

15 Nov '14

#9286: ghc-7.9.20140707 fails testsuite on OS X ( ----------------------------+---------------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: MacOS X testsuite | Type of failure: Building GHC failed Architecture: x86_64 | Test Case: T5435_dyn_asm T4801 T6048 (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Using ghc straight from the git repository, I just ran sh validate. The ghc that I used to build this new one was from https://github.com/ghcformacosx/ghc-dot-app (a neat packaging of GHC as it does not mess with system system files). This is on Yosemite DP3, XCode 6 Beta 3. {{{ OVERALL SUMMARY for test run started at Tue Jul 8 21:51:22 2014 BST 0:45:11 spent to go through 4039 total tests, which gave rise to 15863 test cases, of which 12161 were skipped 28 had missing libraries 3606 expected passes 65 expected failures 0 caused framework failures 0 unexpected passes 3 unexpected failures Unexpected failures: perf/compiler T4801 [stat too good] (normal) perf/compiler T6048 [stat not good enough] (optasm) rts T5435_dyn_asm [bad stdout] (normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8701: Update libffi-tarballs to latest libffi
by GHC 15 Nov '14

15 Nov '14

#8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (FFI) | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- libffi 3.0.14 contains fixes necessary for successful iOS (and probably ARM in general) cross-compilation. I've created a new archive that can be dropped in to replace the current libffi-tarballs archive here: https://github.com/ghc-ios/libffi- tarballs/blob/master/libffi-3.0.14.tar.gz?raw=true -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6