- ghc-tickets - Haskell.org

Re: [GHC] #7942: aarch64 support in ghc
by GHC 20 Nov '14

20 Nov '14

#7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks Luke! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:53> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7942: aarch64 support in ghc
by GHC 20 Nov '14

20 Nov '14

#7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: GHC | Difficulty: Unknown doesn't work at all | Blocked By: Test Case: | Related Tickets: 7623, 8664 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"d87fa343cd5d298c9fea96d65d05a20929ff97d0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d87fa343cd5d298c9fea96d65d05a20929ff97d0" arm64: 64bit iOS and SMP support (#7942) Signed-off-by: Austin Seipp <austin(a)well-typed.com> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7942#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9698: GHC_PACKAGE_PATH should be more lenient for empty paths
by GHC 20 Nov '14

20 Nov '14

#9698: GHC_PACKAGE_PATH should be more lenient for empty paths -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Consider a working {{{GHC_PACKAGE_PATH=foo:bar:baz:}}}. It is not uncommon that we would want to append som extra vars later which might possibly be empty, perhaps resulting in {{{GHC_PACKAGE_PATH=foo:bar:baz::qux:}}}. Unfortunately, due to the {{{::}}} GHC tries to looking for a package at the empty path and shows the usual error about not being able to find the package. This forces the user to set up various safeguards (such as {{{${GHC_PACKAGE_PATH:+:} }}} bashism) at the inital binding location. It'd be great if GHC would simply skip over empty paths. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9698> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9807: Clarify warning if LLVM is not found by configure
by GHC 20 Nov '14

20 Nov '14

#9807: Clarify warning if LLVM is not found by configure -------------------------------------+------------------------------------- Reporter: ihmccreery | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | Documentation bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When running `./configure` to build GHC, and `opt` is not found, the current output is: > <no location info>: > Warning: Couldn't figure out LLVM version! > Make sure you have installed LLVM > ghc: could not execute: opt > failed to compile When I first saw this, I thought that this was causing the entire compiler build to fail. To clarify that this isn't a critical error, should it be something more like: > checking for llvm... no -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9807> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9776: -frule-check flag not recognized without parameter
by GHC 20 Nov '14

20 Nov '14

#9776: -frule-check flag not recognized without parameter -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Incorrect than a day) | warning at compile-time Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ $ ghc Foo.hs -frule-check ghc: on the commandline: unrecognised flag: -frule-check Usage: For basic information, try the `--help' option. }}} That error message is confusing. `-frule-check` is a valid flag, it's just being used incorrectly. It should be followed by a parameter: {{{ $ ghc Foo.hs -frule-check ruleFoo }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9396: Code cleanup: warning: use of GNU old-style field designator extension
by GHC 20 Nov '14

20 Nov '14

#9396: Code cleanup: warning: use of GNU old-style field designator extension -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- The attached patch updates replaces GNU old-style designator syntax with C98 syntax for initializing structs. This gets rid of warnings such as {{{ rts/Profiling.c:90:1: warning: use of GNU old-style field designator extension [-Wgnu- designator] CC_DECLARE(CC_MAIN, "MAIN", "MAIN", "<built-in>", CC_NOT_CAF, ); ^ includes/rts/prof/CCS.h:215:13: note: expanded from macro 'CC_DECLARE' = {{ ccID : 0, \ }}} ^ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9396> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg.
by GHC 20 Nov '14

20 Nov '14

#2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg. -------------------------------------+--------------------------------- Reporter: cjs | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: -------------------------------------+--------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"6fc78fdfa1482a31ed7b586f20c9d7cb592ea944/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6fc78fdfa1482a31ed7b586f20c9d7cb592ea944" Refactor: use System.FilePath.splitSearchPath Summary: To address #2521 ("Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg"), we were using a custom version of splitSearchPath (e4f46f5de). This solution however caused issue #9698 ("GHC_PACKAGE_PATH should be more lenient for empty paths"). This patch reverts back to System.FilePath.splitSearchPath (fixes #9698) and adresses (#2521) by testing for a trailing search path separators explicitly (instead of implicitly using empty search path elements). Empty paths are now allowed (ignored on Windows, interpreted as current directory on Posix systems), and trailing path separator still tack on the user and system package databases. Also update submodule filepath, which has a version of splitSearchPath which handles quotes in the same way as our custom version did. Test Plan: $ GHC_PACKAGE_PATH=/::/home: ./ghc-pkg list ... db stack: ["/",".","/home","<userdb>","<systemdb>"] ... Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D414 GHC Trac Issues: #2521, #9698 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2521#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8310: Can we change the semantics of `Trustworthy`?
by GHC 20 Nov '14

20 Nov '14

#8310: Can we change the semantics of `Trustworthy`? ------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I would like to propose that if I put `{-# LANGUAGE Trustworthy #-}` on a module and it infers as Safe, then the module should get marked `Safe` instead of `Trustworthy`. Putting `Trustworthy` in right now has the semantics "it is at most `Trustworthy`". It would be far more useful to have the semantics "it is at least `Trustworthy`". The current situation is actually a maintenance nightmare. Currently, if I incur a dependency on a package has some `Safe` versions and some non-Safe versions, but I know I'm not using any unsafe componentry of it, I have to either a.) Mark my package Trustworthy unnecessarily enlarging the trusted code base a lot. b.) Track ALL of the dependencies of my dependencies to know when it will be Safe rather than Trustworthy, then insert brittle CPP pragmas that often fail. Consider that `hashable` 1.2.1.0 recently became flagged `Trustworthy`, but was previously not. Now, if I want to properly infer as `Safe`, I have to track the exact version of `hashable` I depend on _and_ whether or not my `Typeable` instance is being rolled manually and make an enormous composite `#ifdef` at the top of the module. Worse, we got the patch in about a month ago, so to future proof my code I'd have had to be psychic. Now consider that I have 50 other packages to maintain in this same manner. I wind up shotgunning `Trustworthy`, do deal with the fact that I deigned to provide instances for `vector`. If `vector` ever refactored to support Safe Haskell, I'd have to go fix up 50 very arcane CPP pragmas to match the internal details of an external package. Then I wind up checking them by round tripping through cabal installs and checking my haddocks. This is further complicated by the fact that some things are just becoming Safe "for free" as they go, due to the fact that they no longer need or can supply hand-rolled `Typeable` instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8310> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances
by GHC 20 Nov '14

20 Nov '14

#2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: D488 => Phab:D488 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2182#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8354: Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim
by GHC 20 Nov '14

20 Nov '14

#8354: Add INLINE (or at least INLINABLE) pragmas for methods of Ord in ghc-prim -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Self-explanatory. Eq already has INLINE on (==) and (/=), and it'd be nice to have it on Ord so that SPECIALIZE pragmas on its methods in user code can fire. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8354> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5