December 2014 - ghc-tickets

[GHC] #9881: GHCi gives misleading error message when looking up info of ambiguous type
by GHC 22 Dec '14

22 Dec '14

#9881: GHCi gives misleading error message when looking up info of ambiguous type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When GHCi imports multiple functions with the same name, using {{{:i}}} results in an ambiguous occurrence error: {{{ > import Data.Text > import Data.Text.Lazy > :i length Top level: Ambiguous occurrence ‘length’ It could refer to either ‘Data.Text.Lazy.length’, imported from ‘Data.Text.Lazy’ or ‘Prelude.length’, imported from ‘Prelude’ (and originally defined in ‘GHC.List’) or ‘Data.Text.length’, imported from ‘Data.Text’ }}} However, if you use {{{:i}}} on a type name that has imported multiple times in GHCi, a misleading error is given: {{{ > import Data.Text > import Data.Text.Lazy > :i Text Top level: Not in scope: data constructor ‘Text’ }}} The real problem is that the type name {{{Text}}} was imported twice with two different definitions, so the error should probably look something like this: {{{ Top level: Ambiguous occurrence ‘Text’ It could refer to either ‘Data.Text.Lazy.Text’, imported from ‘Data.Text.Lazy’ (and originally defined in ‘Data.Text.Internal.Lazy’) or ‘Data.Text.Text’, imported from ‘Data.Text’ (and originally defined in ‘Data.Text.Internal‘) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9881> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #6018: Injective type families
by GHC 22 Dec '14

22 Dec '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: TypeFamilies, Resolution: | Injective Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4259 Test Case: | Blocking: | Differential Revisions: Phab:D202 | -------------------------------------+------------------------------------- Changes (by jstolarek): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:102> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8650: Unexpected behaviour of import ccall "header.h function"
by GHC 22 Dec '14

22 Dec '14

#8650: Unexpected behaviour of import ccall "header.h function" ------------------------------------+-------------------------------------- Reporter: nh2 | 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: Documentation bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+-------------------------------------- When I write {{{ foreign import ccall "myheader.h myfunction" function :: IO ... }}} Is GHC supposed to check the existence of the header file, or do anything with it? Because I can still write {{{"myheaderBLA.h myfunction"}}} and it doesn't care about the first word (no error, ever, not even in linking, executable builds all fine). ---- Relatedly, I can write {{{ foreign import ccall "some.rubbish" f :: IO ... }}} and as long as {{{"some.rubbish"}}} contains a dot, nothin in the system will ever complain. carter suggested that maybe names with a dot inside are ignored by a linker. This leads me to the question: In my example above, is {{{myheaderBLA.h}}} actually understood as some kind of file and ignored by e.g. GHC, or is it a garbled symbol name? In that case, why does http://www.haskell.org/onlinereport/haskell2010/haskellch8.html suggest {{{ccall "string.h strlen"}}}? In the other case, why would it suggest this if the {{{"string.h"}}} part is ignored? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9916: ghc -e ":foo bar" exit status is inconsistent
by GHC 22 Dec '14

22 Dec '14

#9916: ghc -e ":foo bar" exit status is inconsistent -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #7962, #9905 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Since #7962 `ghc -e EXPR` exits with status code 1 if `EXPR` fails to compile. While it's undocumented, `ghc -e` does also accept anything that's valid input to GHCi, including GHCi commands like `:t`. In this case, the exit code of `ghc -e` is not always 1 when the command apparently failed. For example, all of: {{{ ghc -e ':t' ghc -e ':t +' ghc -e ':t =' ghc -e ':t x' ghc -e ':l nonexistentfile.hs' }}} exit with status code 0. But `ghc -e ':l a'` exits with status code 1, because `a` is not a (possible) module name or a source file. (At the code level, `ghc -e ":foo bar"` currently exits with status code 1 when the function for `:foo` raises an exception, and with status code 0 in all other cases.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9916> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3814: Compile to more than one (sub)-architecture
by GHC 22 Dec '14

22 Dec '14

#3814: Compile to more than one (sub)-architecture -------------------------------------+------------------------------------- Reporter: filcab | Owner: Type: feature | Status: closed request | Milestone: ⊥ Priority: normal | Version: 6.12.1 Component: Compiler | Keywords: architecture, Resolution: duplicate | compiler, x86_64 Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4163 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): The description touches on two issues: (1) being able to cross-compile at all and (2) being able to generate code for several different targets with the same compiler by using command-line switches. We have (1) currently (though it's a bit DIY), but not (2). But I'll let someone else file a feature request for (2) if they want it, since I'm not convinced it's sufficiently more valuable than just having one ghc installed for each target. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3814#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9909: Linker error (TemplateHaskell + HPC?)
by GHC 21 Dec '14

21 Dec '14

#9909: Linker error (TemplateHaskell + HPC?) -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: bug | 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: -------------------------------------+------------------------------------- I'm getting the following error message when compiling a Yesod application (which uses Template Haskell rather a lot) with -fhpc: {{{ /usr/bin/ld: ./Foundation.dyn_o: relocation R_X86_64_PC32 against undefined symbol `_hpc_tickboxes_Settings_hpc' can not be used when making a shared object; recompile with -fPIC }}} Steps to reproduce: 1. Run `yesod init` to make a new scaffold. Call it `testsite` and select `simple` for no database. 2. Run: {{{ cd testsite ghc --make app/main.hs -XTemplateHaskell -XCPP -XOverloadedStrings -XMultiParamTypeClasses -XTypeFamilies -XQuasiQuotes -fhpc -O1 }}} Running the `ghc` line again completes successfully. It seems that there is a missing `./Settings.dyn_o` in the `gcc` command line that `ghc` calls, the first time through. It's there the second time so the link succeeds. No idea what that might mean. It's not a problem at `-O0`. I'm using 7.8.3 so this might be fixed now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9909> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9913: Discrepancy in type synonym definition and usage
by GHC 21 Dec '14

21 Dec '14

#9913: Discrepancy in type synonym definition and usage -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: | Operating System: Architecture: x86 | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Minor consistency issue, the following compiles fine (note parentheses): {{{#!hs type Alg f a = f a -> a initial :: Alg(f) a initial = undefined }}} But changing the definition to mirror its use: {{{#!hs type Alg(f) a = f a -> a initial :: Alg(f) a initial = undefined }}} and it fails with: {{{#!hs Unexpected type ‘f’ In the type declaration for ‘Alg’ A type declaration should have form type Alg a b c = ... Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9913> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #5001: makeCorePair: arity missing
by GHC 21 Dec '14

21 Dec '14

#5001: makeCorePair: arity missing -------------------------------------+------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | deSugar/should_compile/T5001 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: simonpj => * status: closed => new * resolution: fixed => Comment: Not fully fixed yet. I just observed this when compiling `mono- traversable-0.6.2` using GHC-7.8.4-rc1: {{{ [2 of 7] Compiling Data.MonoTraversable ( src/Data/MonoTraversable.hs, dist-ghc/build/Da ta/MonoTraversable.o ) src/Data/MonoTraversable.hs:39:1: Warning: The import of `$, replicate' from module `Prelude' is redundant makeCorePair: arity missing $cofoldMap{v aaQ1} [lid] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5001#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9912: Where injured soldiers
by GHC 20 Dec '14

20 Dec '14

#9912: Where injured soldiers -------------------------------------+------------------------------------- Reporter: ZafinaPrincess | Owner: Type: bug | 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: -------------------------------------+------------------------------------- Where injured soldiers would occasionally go into shock and I within minutes are being given blood from plastic I V bottles before that time blood was stored in glass bottles but in 1948 with the invention a plastic blood storage bags the military abandon the story to blooding glass bottles since they were too easily broken in a wartime environment unfortunately but ballads leaked from the plastic bags into the stored blood. http://xtremenitrotruth.com/blackline-elite/ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9908: Improve enumFromX support for OverloadedLists
by GHC 19 Dec '14

19 Dec '14

#9908: Improve enumFromX support for OverloadedLists -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | 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: -------------------------------------+------------------------------------- At present, `OverloadedLists` desugars `[m..n]` as `fromList (enumFromTo m n)`. This is sometimes okay, but terrible for `Data.Sequence`. In particular, I want, for example, {{{#!hs [m..n] :: Seq Int }}} to end up as `fromFunction (n-m+1) (+m)`, which performs much better. There are a few approaches that look reasonable: 1. Try to catch `fromList (enumFromTo m n)` before `enumFromTo` becomes `eftInt`. This does not, unfortunately, seem to work. 2. Grab `eftInt` after it gets written back from `eftIntFB`. This would probably work, but it's currently impossible because `eftInt` is not exported from `GHC.Exts` or even `GHC.Enum`. 3. Add `enumFromTo`, etc., to the `IsList` class. Default to the current behavior, but if possible use `fromListN` for well-known `Enum` types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9908> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0