January 2015 - ghc-tickets

[GHC] #9225: Missing syntax error for package qualified import with version number
by GHC 06 Apr '15

06 Apr '15

#9225: Missing syntax error for package qualified import with version number -------------------------+------------------------------------------------- Reporter: | Owner: ezyang ezyang | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler (Parser) | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Consider the following test file: {{{ {-# LANGUAGE PackageImports #-} module Foo where import "containers-0.5.0.0" Data.Map }}} where we have {{{ ezyang@sabre:~$ ghc-pkg list | grep containers containers-0.5.0.0 unordered-containers-0.2.3.0 }}} GHC will fail to compile this, but in an unusual way: {{{ ezyang@sabre:~$ ghc test.hs [1 of 1] Compiling Foo ( test.hs, test.o ) test.hs:3:1: Failed to load interface for `Data.Map' It is not a module in the current program, or in any known package. }}} That's misleading: the real reason the import failed is because this is a package qualified import (not package ID qualified imports). For my purposes, it would be useful to also support package ID imports, but in the meantime, it would be a good idea to run Cabal's syntax check on the package name, which requires every hyphenated component to contain an alphabetic character. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8057: PackageImports with versions for ghci
by GHC 06 Apr '15

06 Apr '15

#8057: PackageImports with versions for ghci ------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: | ------------------------------------+------------------------------------- Imports with explicit package names and versions would be nice to have in GHCi, because you cannot use the -package and -hide-package options from within GHCi. This is what currently happens: {{{ $ ghci-7.6.3 -XPackageImports GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> import Control.Monad.Trans.List <no location info>: Ambiguous module name `Control.Monad.Trans.List': it was found in multiple packages: transformers-0.3.0.0 List-0.5.1 Prelude> import "transformers-0.3.0.0" Control.Monad.Trans.List <no location info>: Could not find module `Control.Monad.Trans.List' It is not a module in the current program, or in any known package. Prelude> :q Leaving GHCi. $ ghci-7.6.3 -hide-package List GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> import Control.Monad.Trans.List Prelude Control.Monad.Trans.List> }}} However, I now see that the import with explicit package name works, if I omit the package version. I think GHCi should at least warn that providing a version does not work. See also #2362 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8057> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8811: Profiling output jumbled together
by GHC 06 Apr '15

06 Apr '15

#8811: Profiling output jumbled together ------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | 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: | ------------------------------------+------------------------------------- In the time profile (-p), if the MODULE column is very wide and the no. column is also very wide they will run together with no space between. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9457: hsc2hs breaks with `--cflag=-Werror` in cross-compilation mode
by GHC 06 Apr '15

06 Apr '15

#9457: hsc2hs breaks with `--cflag=-Werror` in cross-compilation mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I would like to be able to do {{{ config_args='--target=i386-unknown-linux --with-gcc=i386-unknown-linux- gcc' ./validate }}} to validate a 32-bit GHC on a 64-bit Linux system. (I don't know why I have to specify `--with-gcc` in addition to `--target`; an unrelated mystery.) However `validate` sets `-Werror` and the C code that `hsc2hs` generates in cross-compilation mode is not always warning-free, e.g., {{{ Files.hsc: In function ‘_hsc2hs_test’: Files.hsc:81:14: error: variable ‘test_array’ set but not used [-Werror =unused-but-set-variable] cc1: all warnings being treated as errors }}} so `hsc2hs` draws incorrect conclusions from its tests. Either the `hsc2hs`-generated C code should be made (and kept) warning- free, or perhaps `hsc2hs` should append `-Wwarn` to the options that it passes to the C compiler. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9457> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9737: List ANN in pragmas chapter of user manual
by GHC 02 Apr '15

02 Apr '15

#9737: List ANN in pragmas chapter of user manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- That chapter seems to be a comprehensive listing of pragmas. It should fulfill that promise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9737> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9933: Cross-compile failure : Not in scope: ‘gcdInt'’
by GHC 30 Mar '15

30 Mar '15

#9933: Cross-compile failure : Not in scope: ‘gcdInt'’ -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When cross-compiling from x86_64-linux to armhf-linux using the `quick- cross` setting from `mk/build.mk.sample` I get: {{{ libraries/base/GHC/Real.hs:28:25: Not in scope: ‘gcdInt'’ libraries/base/GHC/Real.hs:28:34: Not in scope: ‘gcdWord'’ }}} It turns out these functions are exported un-conditionally but are only defined within an `#ifdef`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception
by GHC 27 Mar '15

27 Mar '15

#8879: System.IO.Error documentation refers to invalid module Control.Exception.Exception -------------------------------------+------------------------------------- Reporter: shadewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- See: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1 /System-IO-Error.html The description for IOError refers to module Control.Exception.Exception: http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1 /Control-Exception-Exception.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8879> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9947: Unicode «other number» characters not consistently accepted in identifiers
by GHC 27 Mar '15

27 Mar '15

#9947: Unicode «other number» characters not consistently accepted in identifiers -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I’ve noticed that some characters classified as numeric by the Unicode standard will currently generate a lexical error. E.g., characters from the «enclosed alphanumerics» block don’t work, such as ① (circled digit one, U+2460), despite having being of the general Unicode category «other number». Usually, «other number» characters are accepted in identifiers. E.g., superscripts like «²» work fine. This is related to https://ghc.haskell.org/trac/ghc/ticket/5108 , where modifier letters (which are also alphanumeric in Unicode) also throw a lexical error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9947> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9780: dep_orphs in Dependencies redundantly records type family orphans
by GHC 27 Mar '15

27 Mar '15

#9780: dep_orphs in Dependencies redundantly records type family orphans -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, there is a comment on `dep_orphs` claiming this: {{{ , dep_orphs :: [Module] -- ^ Orphan modules (whether home or external pkg), -- *not* including family instance orphans as they -- are anyway included in 'dep_finsts' }}} However, it is not difficult to discover that this is not true: {{{ [ezyang@hs01 ghc-quick]$ cat A.hs {-# LANGUAGE TypeFamilies #-} module A where type family F a :: * [ezyang@hs01 ghc-quick]$ cat B.hs {-# LANGUAGE TypeFamilies #-} module B where import A type instance F Int = Bool [ezyang@hs01 ghc-quick]$ cat C.hs module C where import B [ezyang@hs01 ghc-quick]$ inplace/bin/ghc-stage2 --show-iface C.hi | grep orphans orphans: GHC.Base GHC.Float B }}} I'm not sure if the comment or the implementation is wrong. Certainly `TcRnDriver` would not work if we removed type family orphans from the list, because we only currently load `imp_orphans` and not `imp_finsts`. This change occured in this commit: {{{ commit 8f212ab5307434edf92c7d10fe0df88ccb5cd6ca Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu May 26 14:30:15 2011 +0100 Rejig the way in which generic default method signatures are checked - Check GenericSig in tcClassSigs, along with TypeSig - Add the generic default methods to the type envt - Look them up via tcLookupId in TcClassDcl.tcDefMeth Much nicer! diff --git a/compiler/typecheck/TcRnDriver.lhs b/compiler/typecheck/TcRnDriver.lhs index 2542ad3..5aa6959 100644 --- a/compiler/typecheck/TcRnDriver.lhs +++ b/compiler/typecheck/TcRnDriver.lhs @@ -245,7 +245,6 @@ tcRnImports hsc_env this_mod import_decls -- interfaces, so that their rules and instance decls will be -- found. ; loadOrphanModules (imp_orphs imports) False - ; loadOrphanModules (imp_finsts imports) True -- Check type-familily consistency ; traceRn (text "rn1: checking family instance consistency") }}} When did we start adding type family orphans to the list? This commit is to blame (it states that modules with type family orphans are orphans, which means that it will get added to orphan module list in `RnNames` when we import the interface: {{{ commit 98a642cf29781ebd33994a4ecbea6ef07f89bbed Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Tue Jan 3 10:35:08 2012 +0000 Major refactoring of CoAxioms @@ -619,7 +620,9 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls mi_exp_hash = export_hash, mi_orphan_hash = orphan_hash, mi_flag_hash = flag_hash, - mi_orphan = not (null orph_rules && null orph_insts + mi_orphan = not ( null orph_rules + && null orph_insts + && null orph_fis && null (ifaceVectInfoVar (mi_vect_info iface0))), mi_finsts = not . null $ mi_fam_insts iface0, mi_decls = sorted_decls, @@ -631,12 +634,9 @@ addFingerprints hsc_env mb_old_fingerprint iface0 new_decls this_mod = mi_module iface0 dflags = hsc_dflags hsc_env this_pkg = thisPackage dflags - (non_orph_insts, orph_insts) = mkOrphMap ifInstOrph (mi_insts iface0) - (non_orph_rules, orph_rules) = mkOrphMap ifRuleOrph (mi_rules iface0) - -- See Note [Orphans] in IfaceSyn - -- ToDo: shouldn't we be splitting fam_insts into orphans and - -- non-orphans? - fam_insts = mi_fam_insts iface0 + (non_orph_insts, orph_insts) = mkOrphMap ifInstOrph (mi_insts iface0) + (non_orph_rules, orph_rules) = mkOrphMap ifRuleOrph (mi_rules iface0) + (non_orph_fis, orph_fis) = mkOrphMap ifFamInstOrph (mi_fam_insts iface0) fix_fn = mi_fix_fn iface0 }}} I think this is probably a legitimate optimization (keeps interface file smaller), and we try to put it back into effect. The only downside is we'll try to load in the entire `mi_fam_insts` list (mostly harmless sense redundant requests on that front will hit the cache); also, it's more elegant if mi_orph describes orphanness over all orphans. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9780> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8877: "if this code is reached, the program will abort" in sparc
by GHC 25 Mar '15

25 Mar '15

#8877: "if this code is reached, the program will abort" in sparc ----------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: sparc | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8857 | ----------------------------+------------------------------------- Hi, sparc, when built with dynamic libraries, fails with a segmentation fault: https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=sparc&ver=7.8.20140… Possible cause indicated by {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o rts/dist/build/Apply.o /tmp/ghc14927_0/ghc14927_2.hc: In function 'stg_PAP_entry': /tmp/ghc14927_0/ghc14927_2.hc:101:30: warning: function called through a non-compatible type [enabled by default] /tmp/ghc14927_0/ghc14927_2.hc:101:30: note: if this code is reached, the program will abort }}} It works without shared libraries (see #8857) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8877> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2