October 2014 - ghc-tickets

Re: [GHC] #6018: Injective type families
by GHC 31 Oct '14

31 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.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 | -------------------------------------+------------------------------------- Comment (by jstolarek): Finding pairs would be done once. Only the traversal would be done twice - see my inline comment on Phab. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:101> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2968: Avoid generating C trigraphs (was: add test for C trigraphs)
by GHC 31 Oct '14

31 Oct '14

#2968: Avoid generating C trigraphs -------------------------------------+------------------------------------- Reporter: duncan | Owner: kchugalinskiy Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: unregisterised Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => unregisterised Old description: > {{{ > main = print "??)" > }}} > > If we compile the above `-fvia-C` then some gcc versions report: > > {{{ > /tmp/ghc6084_0/ghc6084_0.hc:99:30: > warning: trigraph ??) ignored, use -trigraphs to enable > }}} > > This should make us nervous. > > According to the GCC manual if we were ever to use `-std=c89` or any of > the official C standard compliance modes (ie non-GNU) then we would get > standard C (cpp) trigraph behavior. > > We should therefore add a codeGen/should_run test to make sure that the > above program does always print `"??)"` and never `"]"`. This test only > needs to be run for the `-fvia-C` 'ways', optc etc. > > It's not an immediate priority but it may trip someone up in future when > porting or if we make unregisterised C code more standards compliant and > start using one of the official `-std=` modes. It is unlikely to hit us > but if it ever did it'd be a real pain to debug. New description: {{{ main = print "??)" }}} If we compile the above with an `unregisterised` ghc then some gcc versions report: {{{ /tmp/ghc6084_0/ghc6084_0.hc:99:30: warning: trigraph ??) ignored, use -trigraphs to enable }}} This should make us nervous. According to the GCC manual if we were ever to use `-std=c89` or any of the official C standard compliance modes (ie non-GNU) then we would get standard C (cpp) trigraph behavior. We should therefore add a codeGen/should_run test to make sure that the above program does always print `"??)"` and never `"]"`. This test only needs to be run in `unregisterised` mode. It's not an immediate priority but it may trip someone up in future when porting or if we make unregisterised C code more standards compliant and start using one of the official `-std=` modes. It is unlikely to hit us but if it ever did it'd be a real pain to debug. Edit: replaced `-fvia-c` by [wiki:Building/Unregisterised unregisterised] (see 392b7e2a34d26b01ca65648eb5b4a078b0a64e69). -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2968#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas
by GHC 31 Oct '14

31 Oct '14

#4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.10.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * difficulty: => Unknown Comment: There are 2 possible solutions: * in hsc2hs, ignore `#define NAME VALUE` when `VALUE` contains a space. This could be done in the function `outHeaderHs` in `utils/hsc2hs/C.hs` as mentioned by @awson. I'm not sure this is good idea (wouldn't an error be better?), but note that #defines where `NAME` contains a `'('` are currently also ignored. * when using the OPTIONS pragma `-Dsymbol=value`, accept spaces inside `value` when `value` is quoted. This would need to be done in the function `getOptions'` in `compiler/main/HeaderInfo.hs`, by changing `(words str)` to something more complicated. Note that GHC already accepts spaces in `value` when the option is passed as a command line argument: `-D'"FOO BAR"'` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4931#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 31 Oct '14

31 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.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 | -------------------------------------+------------------------------------- Comment (by simonpj): My instinct is (a) because finding all pairs is potentially quite expensive, and repeating all that code seems a shame -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 31 Oct '14

31 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.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 | -------------------------------------+------------------------------------- Comment (by jstolarek): Oh, and while we're talking about open type families, there's a design decision to make. Verifying user-supplied injectivity condition requires comparing the same equations that are compared by compatibility check. Should we: a) verify injectivity at the same time we verify compatibility? b) verify injectivity in a separate pass? a) might seem like an obvious answer because it allows us to avoid traversing the equation pairs twice. However, that makes compatibility checking code in `FamInstEnv.lookup_fam_inst_env'` a bit more complicated. b) on the other hand can allow us to skip the injectivity checking altogether if the user did not supply any injectivity declarations. This would be a big win since compilation performance would not be degraded for already existing code (since there are no injectivity declarations). I am in favour of option b). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:99> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 31 Oct '14

31 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.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 | -------------------------------------+------------------------------------- Comment (by jstolarek): I'm implementing injectivity checking for open type families and got stuck on some nonsense problem (described on Phab) so I diverted to #8326 this week. Will resume work on this next week. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:98> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6018: Injective type families
by GHC 31 Oct '14

31 Oct '14

#6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature | Status: new request | Milestone: 7.10.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 | -------------------------------------+------------------------------------- Comment (by simonpj): What's the status on injective type families? Stalled? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6018#comment:97> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7944: GHC goes into an apparently infinite loop at -O2
by GHC 31 Oct '14

31 Oct '14

#7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: 5550 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new Comment: I don't think this is fixed yet. Steps to reproduce (with a quick build of today's ghc master in directory ~/ghc-build, on Linux): {{{ cabal install --with-ghc=ghc-build/inplace/bin/ghc-stage2 vector git clone https://github.com/thomie/inttable cd inttable ~/ghc-build/inplace/bin/ghc-stage2 -O2 -v3 --make Repro }}} This last step freezes after about 1 second, with final output: {{{ *** SpecConstr: Result size of SpecConstr }}} CPU is at 100%, until I kill it after a few minutes. Contrary to Brian's observation, I do see an increase in memory usage over time. I get the same results when using ghc-7.8.3 instead of current ghc master. I had to make a small change to Bryan's `inttable` repository (hide some imports from base). See the mentioned github url. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7944#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9236: hGetContents leads to late/silent failures
by GHC 31 Oct '14

31 Oct '14

#9236: hGetContents leads to late/silent failures ------------------------------------+------------------------------------- Reporter: dfeuer | 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: | ------------------------------------+------------------------------------- A common newbie error: {{{ #!haskell withFile "file" ReadMode hGetContents >>= putStr }}} The problem, of course, is that the result of `withFile "file" ReadMode hGetContents` isn't forced until `putStr` is executed, at which point the file has already been closed. The Haskell report doesn't specify what it will find, and, at least in 7.6.3, it finds the string empty. The behavior that seems most correct to me would be to guarantee that if a file has not been completely read (or read up to an I/O error) when it is closed, then its contents should be reported as something like `"Four score and seven years ag"++error "Forcing a suspended computation led to an attempted read from a handle that was already closed."` Since the current system apparently puts an `[]` as a temporary marker while waiting to see what the rest of the list will be, I imagine that the fix is as simple as putting the error thunk there instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas
by GHC 31 Oct '14

31 Oct '14

#9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas ------------------------------------+------------------------------------- Reporter: simonpj | 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: | ------------------------------------+------------------------------------- The language extensions `-XIncoherentInstances` and `-XOverlappingInstances` (described in [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap the user manual]) apply to every instance declaration in the module. Internally, however, GHC records this information on a per-instance-declaration basis. It would be much better for the programmer to be able to control these matters on a per-instance-declaration basis. Thus: {{{ instance Show a => Show [a] where {-# OVERLAPPABLE #-} ... instance Show [Char] where ... }}} We came across the need for this when discussing the `Typeable` instances. We have a generic instance like this: {{{ instance (Typeable f, Typeable a) => Typeable (f a) where .... }}} but also want {{{ instance KnownNat n => Typeable (n :: Nat) where ... }}} If we seek `(Typeable (x::Nat))`, we should pick the second instance even though in principle you might imagine that `x` might be instantiated to `(f a)`, for some `f` and `a`. But we know that there are no type constructors `f` of kind `blah -> Nat`, so this can never happen and it's safe to pick the second instance. So a local `{-# INCOHERENT #-}` pragma for this particular instance declaration would be very useful to express this fact. {{{ instance KnownNat n => Typeable (n :: Nat) where {-# INCOHERENT #-} ... }}} Quite apart from this special case, it's plain better to have per-instance control * Rather than a remote per-module flag, the pragma draws attention that ''this particular instance'' is incoherent, overlappable or whatever. * The current situation almost certainly means that more instances are marked overlapping than are really necessary. I have some design questions. * Where should the pragma appear, syntactically? {{{ instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... or instance Show a => Show [a] {-# OVERLAPPABLE #-} where ... or instance Show a => Show [a] where {-# OVERLAPPABLE #-} }}} Remember that `SPECIALISE INSTANCE` pragmas appear in the third of the above positions, so I mildly favour that. * The user manual (link above) allows overlap if ''either'' instance is compiled with `-XOverlappingInstances` (see the rules towards the end of [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#instance-overlap 7.6.3.5). It would be more explicit to have two pragmas, one to say "I can be overlapped" and one to say "I can overlap something else". The rule would then be that "either IX is marked `{-# OVERLAPPABLE #-}` or IY is marked `{-# OVERLAPPING #-}`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9242> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38