From ghc-devs at haskell.org Wed Oct 1 00:06:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 00:06:41 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.6b6e327240a549bbee729bb7ebb8cb60@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255 | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:18 thoughtpolice]: > In essence it just adds `Opt_WarnTabs` (AKA `-fwarn-tabs`) to `standardWarnings` in `DynFlags`, which is the correct move. Next, it disables `-fno-warn-tabs` when building the libraries by modifying `mk /validate-settings.mk` to include `-fno-warn-tabs`, so that everything can validate correctly. This may very well be the best thing for right now, but here's another idea that would take more work but might pay off in the long run, especially if other warnings are added to the defaults in the future. Instead of ''actually'' running ghc with `-Werror`, make the validation script watch for warnings. That is, replace an `Error` monad with a `Writer` monad. Given appropriate options, validation could ''collect'' warnings instead of halting immediately. This would allow us to automatically create lists of files for which specific warnings should be tolerated. Obviously, these lists would need to be maintained in order to prevent regressions, but this is easy: Phabricator (or whatever) would collect a "warning diff" from each build that passes validation, which could be used to update the lists. Ideally, we'd also find a way to trim down the warning list generated by a differential to just those files it changed, so as to get notice that something else might need to be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 03:00:42 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 03:00:42 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.a4b0a2760fab91edc785f2f42896077e@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: | Version: 7.9 libraries/haskell2010 | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): It is a bit more complex than just pasting the report. GHC internals actually know where `Monad` comes from for instance, so you'd have knock- on consequences. If we `do` adopt a `haskell2010` fully standards compliant package: 1.) We'd need to make some modifications to GHC itself to tell it where to desugar to for the `Monad` syntax and internal hackery. We'd need to figure out how to tell tools like cabal to do the right thing. 2.) Code that previously worked with the `haskell2010` or `haskell98` packages would cease to work with `base` and vice versa where those instances are concerned. You'd be giving up, say, `containers`, not just the rest of `base`. This actually comes at a price to a dozen or two packages that are built right now with the `haskell98` package and with these other dependencies as well, possibly breaking in non-obvious ways. It may be that to fully support both of these two very different usecases for `haskell2010` that you'd get two `haskell2010`-like packages to support both user pools. This makes for a very complex story to explain to end users, and a lot of engineering. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 05:05:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 05:05:58 -0000 Subject: [GHC] #9654: Clean up stringify in util/hsc2hs/CrossCodegen Message-ID: <045.657a77fc78f7a0332afb629d9a8c0a4b@haskell.org> #9654: Clean up stringify in util/hsc2hs/CrossCodegen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Code Coverage | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, it's defined {{{#!hs stringify :: String -> String stringify s = reverse . dropWhile isSpace . reverse -- drop trailing space . dropWhile isSpace -- drop leading space . compressSpaces -- replace each span of -- whitespace with a single space $ s where compressSpaces [] = [] compressSpaces (a:as) | isSpace a = ' ' : compressSpaces (dropWhile isSpace as) compressSpaces (a:as) = a : compressSpaces as }}} If we're going to go to the trouble of doing this by hand, we might as well take the efficiency advantage doing so can give us: {{{#!hs stringify :: String -> String -- Spec: stringify = unwords . words stringify xs = go False (dropWhile isSpace xs) where go _haveSpace [] = [] go haveSpace (x:xs) | isSpace x = go True xs | otherwise = if haveSpace then ' ' : x : go False xs else x : go False xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 05:07:22 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 05:07:22 -0000 Subject: [GHC] #9654: Clean up stringify in util/hsc2hs/CrossCodegen In-Reply-To: <045.657a77fc78f7a0332afb629d9a8c0a4b@haskell.org> References: <045.657a77fc78f7a0332afb629d9a8c0a4b@haskell.org> Message-ID: <060.30a670db0baa170aecb2184de5a912b9@haskell.org> #9654: Clean up stringify in util/hsc2hs/CrossCodegen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Code | Version: 7.9 Coverage | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 05:08:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 05:08:30 -0000 Subject: [GHC] #9654: Clean up stringify in util/hsc2hs/CrossCodegen In-Reply-To: <045.657a77fc78f7a0332afb629d9a8c0a4b@haskell.org> References: <045.657a77fc78f7a0332afb629d9a8c0a4b@haskell.org> Message-ID: <060.543850cb154a8c332e870bc5e0359a25@haskell.org> #9654: Clean up stringify in util/hsc2hs/CrossCodegen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: hsc2hs | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * component: Code Coverage => hsc2hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 08:39:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 08:39:18 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.9cb722f667bc434d4adf198c7ad38ad8@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => ekmett * component: libraries/haskell2010 => Core Libraries Comment: I'm open to whatever the Core Libraries committee thinks is best here, including discussing magical GHC support for whatever you need. I confess that I am reluctant to invest much GHC-development effort in this, but I respect the need to avoid killing off lots of useful libraries by mistake. Hence making "Core Libraries" the "Component". (We are removing libraries/* components... too much noise.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 08:55:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 08:55:18 -0000 Subject: [GHC] #9655: Do not UNPACK strict fields that are very wide Message-ID: <046.c5043c06a960b4e37dc0e2bc0fcfba64@haskell.org> #9655: Do not UNPACK strict fields that are very wide -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- John Lato [http://www.haskell.org/pipermail/ghc- devs/2014-September/006473.html writes} (a propos of another discussion): This is possibly unrelated, but the setup seems almost identical to a very similar problem we had in some code, i.e. very long compile times (6+ minutes for 1 module) and excessive memory usage when compiling generic serialization instances for some data structures. In our case, I also thought that INLINE functions were the cause of the problem, but it turns out they were not. We had a nested data structure, e.g. {{{ > data Foo { fooBar :: !Bar, ... } }}} with `Bar` a very wide product type (~150 fields). Even when we explicitly NOINLINE'd the function that serialized Bar, GHC still created a very large helper function of the form: {{{ > serialize_foo :: Int# -> Int# -> ... }}} where the arguments were the unboxed fields of the Bar structure, along with the other fields within Foo. It appears that even though the serialization function was NOINLINE'd, it simply created a Builder, and while combining the Builder's ghc saw the full structure. Our serializer uses blaze, but perhaps Binary's builder is similar enough the same thing could happen. Anyway, in our case the fix was to simply remove the bang pattern from the 'fooBar' record field. So the question is: '''should GHC auto-unpack a strict argument of a data constructor, if the argument type is a very wide product type?'''. I think "no". The unpacking can save allocation (by allocating one object instead of two) but it can also increase it (at a pattern matching site). So it should probably only happen automatically for sufficiently narrow types. How narrow? We need some testing, but my guess is three or four words. Maybe a flag to set the size? (Maybe not worth the pain.) Incidentally, the choice can already be manually controlled with `{-# UNPACK #-}` and `{-# NOUNPACK #-}` pragmas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 08:55:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 08:55:44 -0000 Subject: [GHC] #9655: Do not UNPACK strict fields that are very wide In-Reply-To: <046.c5043c06a960b4e37dc0e2bc0fcfba64@haskell.org> References: <046.c5043c06a960b4e37dc0e2bc0fcfba64@haskell.org> Message-ID: <061.c3c0e7af80a8545712e2e0bcc82edf27@haskell.org> #9655: Do not UNPACK strict fields that are very wide -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > John Lato [http://www.haskell.org/pipermail/ghc- > devs/2014-September/006473.html writes} (a propos of another discussion): > This is possibly unrelated, but the setup seems almost identical to a > very similar problem we had in some code, i.e. very long compile times > (6+ minutes for 1 module) and excessive memory usage when compiling > generic serialization instances for some data structures. > > In our case, I also thought that INLINE functions were the cause of the > problem, but it turns out they were not. We had a nested data structure, > e.g. > {{{ > > data Foo { fooBar :: !Bar, ... } > }}} > with `Bar` a very wide product type (~150 fields). > > Even when we explicitly NOINLINE'd the function that serialized Bar, GHC > still created a very large helper function of the form: > {{{ > > serialize_foo :: Int# -> Int# -> ... > }}} > where the arguments were the unboxed fields of the Bar structure, along > with the other fields within Foo. It appears that even though the > serialization function was NOINLINE'd, it simply created a Builder, and > while combining the Builder's ghc saw the full structure. Our serializer > uses blaze, but perhaps Binary's builder is similar enough the same thing > could happen. > > Anyway, in our case the fix was to simply remove the bang pattern from > the 'fooBar' record field. > > So the question is: '''should GHC auto-unpack a strict argument of a data > constructor, if the argument type is a very wide product type?'''. I > think "no". The unpacking can save allocation (by allocating one object > instead of two) but it can also increase it (at a pattern matching site). > So it should probably only happen automatically for sufficiently narrow > types. > > How narrow? We need some testing, but my guess is three or four words. > Maybe a flag to set the size? (Maybe not worth the pain.) > > Incidentally, the choice can already be manually controlled with `{-# > UNPACK #-}` and `{-# NOUNPACK #-}` pragmas. New description: John Lato [http://www.haskell.org/pipermail/ghc- devs/2014-September/006473.html writes] (a propos of another discussion): "This is possibly unrelated, but the setup seems almost identical to a very similar problem we had in some code, i.e. very long compile times (6+ minutes for 1 module) and excessive memory usage when compiling generic serialization instances for some data structures. In our case, I also thought that INLINE functions were the cause of the problem, but it turns out they were not. We had a nested data structure, e.g. {{{ > data Foo { fooBar :: !Bar, ... } }}} with `Bar` a very wide product type (~150 fields). Even when we explicitly NOINLINE'd the function that serialized Bar, GHC still created a very large helper function of the form: {{{ > serialize_foo :: Int# -> Int# -> ... }}} where the arguments were the unboxed fields of the Bar structure, along with the other fields within Foo. It appears that even though the serialization function was NOINLINE'd, it simply created a Builder, and while combining the Builder's ghc saw the full structure. Our serializer uses blaze, but perhaps Binary's builder is similar enough the same thing could happen. Anyway, in our case the fix was to simply remove the bang pattern from the 'fooBar' record field." So the question is: '''should GHC auto-unpack a strict argument of a data constructor, if the argument type is a very wide product type?'''. I think "no". The unpacking can save allocation (by allocating one object instead of two) but it can also increase it (at a pattern matching site). So it should probably only happen automatically for sufficiently narrow types. How narrow? We need some testing, but my guess is three or four words. Maybe a flag to set the size? (Maybe not worth the pain.) Incidentally, the choice can already be manually controlled with `{-# UNPACK #-}` and `{-# NOUNPACK #-}` pragmas. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 09:03:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 09:03:29 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.609e037326f690b51b5b48d2541f7254@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): So, to be concrete, if I write: {{{ foo :: Either (T a) a -> a foo (Right x) = x }}} then you would like `(foo (Right True))` to signal a type error. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 09:45:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 09:45:04 -0000 Subject: [GHC] #1473: isSpace is too slow In-Reply-To: <044.3c2c0fec916372178c4bf5ce7945c8fa@haskell.org> References: <044.3c2c0fec916372178c4bf5ce7945c8fa@haskell.org> Message-ID: <059.81ec8b95a94eada1ecd645a2ed6a6477@haskell.org> #1473: isSpace is too slow -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: | Version: 6.6.1 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: hvr, ekmett (added) Comment: I wrote up a whole long comment here, but then TRAC timed me out and I lost it. The gist of it is that I don't think we should be using `iswspace` here at all, because Haskell 2010's [https://www.haskell.org/onlinereport/haskell2010/haskellch16.html specification of `isSpace`] appears to be intended to match [http://www.unicode.org/Public/6.3.0/ucd/PropList.txt the Unicode concept of whitespace], which does not seem to match the locale-specific [http://pubs.opengroup.org/onlinepubs/009695399/functions/iswspace.html definition of `iswspace`]. As I discussed with Carter, we can probably improve the performance of `isSpace` by using something like Yitzchak Gale's implementation modified to cut down the number of branches (since many of them will be mispredicted). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 09:56:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 09:56:51 -0000 Subject: [GHC] #9637: Type level programming needs an error function In-Reply-To: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> References: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> Message-ID: <062.1c4f1c58ba374ea4bbd77c8c1fb70b71@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you give some examples of its use in a program? I still don't get it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 10:06:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 10:06:45 -0000 Subject: [GHC] #9654: Clean up stringify in util/hsc2hs/CrossCodegen In-Reply-To: <045.657a77fc78f7a0332afb629d9a8c0a4b@haskell.org> References: <045.657a77fc78f7a0332afb629d9a8c0a4b@haskell.org> Message-ID: <060.8dfea1db98a6d16a42a5227743efc70f@haskell.org> #9654: Clean up stringify in util/hsc2hs/CrossCodegen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: hsc2hs | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Applied, pending validation. The code was not `-Werror`-safe; it would be nice if submitted patches were validated (or, if not, that fact were mentioned when submitting). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 10:16:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 10:16:27 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.11e57610e7645cc8dbe4456ef79ce7e6@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): You should never have more capabilities than cores. It's hard to know where to set the default on the memory-vs-time tradeoff curve. GHC has typically been quite conservative here. Personally I'd like to know why -j is hardly providing any benefit beyond 2-3 cores, regardless of heap size settings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 10:29:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 10:29:12 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance (was: Strange performance bug) In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.60d7bbfe0ab71b35a293c6668c302f70@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 10:29:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 10:29:49 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.7ddc887f162ea709040ed118c9b40fe1@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by erikd: Old description: > I've been chasing a weird performance bug for about a week now. I've > reduced the testcase to the following git repo: > > https://github.com/erikd/ghc-perfbug-test > > The Readme.md file in that repo contains an explanation of how to > reproduce the issue. > > The benchmark program in the repo uses Criterion to test the performance > of one particular function. Running the program in a particular way > results into two significanlty different results. > > The commands are: > > {{{ > make clean bench-integer.html > cp -f bench-integer.html bench-integer-slow.html > touch New3/GHC/Integer/Natural.hs && make bench-integer.html > }}} > > The results for one function in the file `New3/GHC/Integer/Natural.hs` is > 8 times slower in the first test that the second while the other test > function always executes at about the speed. > > I haven't been able to test this with ghc-7.6.3 because the code uses > `isTrue#` which isn't available in 7.6.3. New description: I've been chasing a weird performance bug for about a week now. I've reduced the testcase to the following git repo: https://github.com/erikd/ghc-perfbug-test The Readme.md file in that repo contains an explanation of how to reproduce the issue. The benchmark program in the repo uses Criterion to test the performance of one particular function. Running the program in a particular way results into two significanlty different results. The commands are: {{{ make clean bench-integer.html cp -f bench-integer.html bench-integer-slow.html touch New3/GHC/Integer/Natural.hs && make bench-integer.html }}} The results for one function in the file `New3/GHC/Integer/Natural.hs` is 8 times slower in the first test that the second while the other test function always executes at about the speed. I haven't been able to test this with ghc-7.6.3 because the code uses `isTrue#` which isn't available in 7.6.3. Updated explanation: Compiling the whole project results in the function under test running 4 times slower than the comparison. Touching the file containing the function under test and rebuilding the benchmark program results in the function under test runing 2 times faster than the comparison function. Dumping intermediate files showed that the output of the simplifier was different enough to create this 8 fold difference in performance. The simplifier should be deterministic. Same input file should result in the same simplifier output, preferably the output that results in 8 fold better performance. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 10:47:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 10:47:32 -0000 Subject: [GHC] #9654: Clean up stringify in util/hsc2hs/CrossCodegen In-Reply-To: <045.657a77fc78f7a0332afb629d9a8c0a4b@haskell.org> References: <045.657a77fc78f7a0332afb629d9a8c0a4b@haskell.org> Message-ID: <060.67390c4a83ffbe47ed9fb32c3668cdd3@haskell.org> #9654: Clean up stringify in util/hsc2hs/CrossCodegen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: hsc2hs | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"5d16c4d92a483ee07323689447c16189dfaa7f63/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5d16c4d92a483ee07323689447c16189dfaa7f63" Update hsc2hs submodule to get David?s code improvements (#9654). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 10:48:29 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 10:48:29 -0000 Subject: [GHC] #9654: Clean up stringify in util/hsc2hs/CrossCodegen In-Reply-To: <045.657a77fc78f7a0332afb629d9a8c0a4b@haskell.org> References: <045.657a77fc78f7a0332afb629d9a8c0a4b@haskell.org> Message-ID: <060.80cafb4d551a4bdf5ef7018301d1a35b@haskell.org> #9654: Clean up stringify in util/hsc2hs/CrossCodegen -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: hsc2hs | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Thanks for your contribution! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 11:02:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 11:02:17 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.8fd4a190bcd13915f9540cf58728726c@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erikd): Amos Robinson has helped make some progress on this. The problem is with the `StrictPrim` monad (defined in the file `Common/GHC/Ineteger/StrictPrim.hs` of the ghc-perfbug-test project) which basically an ST monad with a bunch of explicit bang patterns to force strict evaluation. The big difference between the slow and the fast version is that in the slow version of the .dump-simpl output of these inner loops have an extra lambda eg on line 39 of `slow-Natural.dump-simpl`: {{{ (\ eta -> (# eta, vx #)) `cast` ...; }}} The `eta` variable in this case is the state token for the `StrictPrim` monad. Furthermore, Amos Robinson was able to re-write the inner loop from: {{{#!hs innerLoop2 !xi !yi !carryhi !carrylo !sum | yi < n2 = do x <- indexWordArrayM arr1 xi y <- indexWordArrayM arr2 yi let (# !cry0, !prod #) = timesWord2 x y (# !cry1, !sum1 #) = plusWord2 prod sum (# !tcryhi, !crylo #) = plusWord2C carrylo cry0 cry1 !cryhi = plusWord carryhi tcryhi innerLoop2 (xi - 1) (yi + 1) cryhi crylo sum1 | otherwise = do return $! (carryhi, carrylo, sum) }}} to {{{#!hs innerLoop2 !xi !yi !carryhi !carrylo !sum = StrictPrim $ \s -> if yi < n2 then let StrictPrim go = do x <- indexWordArrayM arr1 xi y <- indexWordArrayM arr2 yi let (# !cry0, !prod #) = timesWord2 x y (# !cry1, !sum1 #) = plusWord2 prod sum (# !tcryhi, !crylo #) = plusWord2C carrylo cry0 cry1 !cryhi = plusWord carryhi tcryhi innerLoop2 (xi - 1) (yi + 1) cryhi crylo sum1 in go s else (# s, (carryhi, carrylo, sum) #) }}} and this new formulation *always* compiles to run fast. After some discussion with Amos, we came to the following conclusions: 1. The simplifier should be deterministic. The same input file, with the same compiler flags should result in the same output (preferably the output that performs better). 2. It is not un-reasonable to expect the compiler to apply the transformation that Amos appied manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 11:51:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 11:51:35 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.949508291dc91e2697d40b821e5790b3@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I spent a few minutes earlier today, and indeed I'm sure that difference in eta expansion is the cause of the trouble. What I do not understand is why it happens. Would you be prepared to cut down the example still more? Dump the Criterion wrapping. Just leave enough to reproduce the strange difference in Core generated in the wot different ways. Strip away everything else; eg we don't actually need to run the program any more. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 12:02:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 12:02:21 -0000 Subject: [GHC] #9655: Do not UNPACK strict fields that are very wide In-Reply-To: <046.c5043c06a960b4e37dc0e2bc0fcfba64@haskell.org> References: <046.c5043c06a960b4e37dc0e2bc0fcfba64@haskell.org> Message-ID: <061.960b071058d2a1f6afd3fc44a52138db@haskell.org> #9655: Do not UNPACK strict fields that are very wide -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by tibbe): > should GHC auto-unpack a strict argument of a data constructor, if the argument type is a very wide product type? I'm confused. I don't think GHC does unpack strict fields unless either 1) it's of pointer size or 2) you use `-funbox-strict-fields` or 3) you use `UNPACK`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 12:39:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 12:39:28 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.aa6613f8eae587e0437d354dd0032bb9@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 12:59:04 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 12:59:04 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.89398e9502b9161679c38c7178bbb938@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Fuuzetsu, which patch are you talking about, Phab:D175? I don't think it should affect the ABI hash at all, so it only pertains to (2), not (1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 13:03:17 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 13:03:17 -0000 Subject: [GHC] #9655: Do not UNPACK strict fields that are very wide In-Reply-To: <046.c5043c06a960b4e37dc0e2bc0fcfba64@haskell.org> References: <046.c5043c06a960b4e37dc0e2bc0fcfba64@haskell.org> Message-ID: <061.8cd5b0d0ee2effb49d2b31d7d84b3eb0@haskell.org> #9655: Do not UNPACK strict fields that are very wide -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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 simonpj): * cc: jwlato@? (added) Comment: I'm guessing that John was using `-funbox-strict-fields`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 13:20:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 13:20:24 -0000 Subject: [GHC] #9637: Type level programming needs an error function In-Reply-To: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> References: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> Message-ID: <062.87b61be78abc623131a4384407680b79@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by augustss): Here's a real example: {{{#!hs type F_NoDups (t :: FieldSet) :: FieldSet = Assert "Type has duplicate labels:\n " (Not (F_HasDups t)) t type family Assert (msg :: Symbol) (a :: Bool) (b :: k) :: k where Assert msg True x = x Assert msg False x = Error (msg `ErrorAnd` x) }}} And here's a sample error message: {{{ RunMu.exe: Cortex: Cortex.Stem.Relation.Test.Typed:21:1: Type error: Type has duplicate labels: Cortex.Stem.Relation.Types.FS ("A" ::: String : "B" ::: Bool : "B" ::: Bool : "C" ::: () : Data.TypeLevel.Nil) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 13:27:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 13:27:12 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.a37dedb8b106c05930be23cba4080f2d@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by augustss): Yes, I'd like that to be an error. And no, I don't know how to write the typing rules. I've not even thought about it. What I'd like is for the typing rules to capture the intuitively right semantics. If my intuition is wrong, or if that's impossible then I'll have to accept a compromise, of course. Do we agree that `T Bool` is a weird beast that has no meaning? Or do you think it is a real type? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 13:32:33 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 13:32:33 -0000 Subject: [GHC] #9356: scanl does not participate in list fusion In-Reply-To: <045.ab578058deeca9329303e3b009a823aa@haskell.org> References: <045.ab578058deeca9329303e3b009a823aa@haskell.org> Message-ID: <060.77ad25fcdfcf85b2e8f3cffd8c14762a@haskell.org> #9356: scanl does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => infoneeded Comment: Can you extend the patch with a bit more comments? In particular, why do you need this `tailScanl`, when with other functions, the `fooList` rule writes it back to the direct code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 13:39:09 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 13:39:09 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.3ceeeb86cc629253dac0640515f53da5@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => infoneeded Comment: Is this understanding correct: `reverse` is made a good consumer, and additionally, it is a good producer when immediately consumed by `map`. You might make the rules simpler by using `mapReverseFB revId` instead of `revFB`: No need to have both `mapMapReverse` and `mapReverse` then. There is quite a bit of logic in this patch. Would you mind adding test cases for this, so that this behaviour is not accidentally broken in the future? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 13:52:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 13:52:56 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.ed3990692c89f8a7850ead2d603eacce@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): It is a weird beast. But I have learned, painfully, that not being able to write down typing judgements is a Bad Sign. It suggests that we don't know exactly which programs should be erroneous and which should be OK. And if we don't know, it's hard to explain to the user which programs are ok and which are not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 13:53:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 13:53:50 -0000 Subject: [GHC] #9616: Incorrect numbers from HpcMarkup.markup_plugin In-Reply-To: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> References: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> Message-ID: <060.8e0c07fc13a8b5c0876e0a3e63119240@haskell.org> #9616: Incorrect numbers from HpcMarkup.markup_plugin -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Code | Version: 7.9 Coverage | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D259 | -------------------------------------+------------------------------------- Changes (by nomeata): * differential: => Phab:D259 Comment: You can use the Phab:D259 syntax to automatically link it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 14:19:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 14:19:01 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.786ad196b47ccd7da13927abb810e618@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't feel strongly how we come down on this one, but I want to note that making `T Bool` an error is a breaking change. It's easy enough to write a typing rule in Core that handles this: {{{ F is a closed type family t is not apart from all equations in F F : [a:k1]. k2 G |- t : k1 ------------- G |- F[t] : k2[a |-> t] }}} BUT, that rule doesn't obey the substitution lemma! Specifically, `T a` could be well-typed, but `T Bool` wouldn't be. This is No Good. I see this is as somewhat like the error for inaccessible code. Writing inaccessible code isn't actually erroneous -- we're just sure that users don't want to. Furthermore, with enough type-level trickery, users ''can'' write provably inaccessible code that GHC isn't smart enough to flag. So, we could similarly try to flag and error on "weird beasts" on a best- effort basis, but this would probably have to be restricted to user- written types, missing Simon's case in comment:8. However, having just written that, I recall that, separately, I would love a way to disable the "inaccessible code" check. When I'm producing Haskell code programmatically (say, from Template Haskell), I sometimes produce inaccessible branches and have had to go to some lengths to avoid this. It would be nicer just to be able to ask GHC to accept these harmless chunks of code. In a similar vein, I can imagine some programatically-written Haskell that would contain weird beasts and wouldn't want failure. As I said above, though, I don't feel too strongly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 15:58:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 15:58:02 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.326dd1e96069b99355fd26a22f6f6588@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:14 nomeata]: > Is this understanding correct: `reverse` is made a good consumer, and additionally, it is a good producer when immediately consumed by `map`. It's made a good consumer, yes. It never becomes a good producer, per se; rather, it fuses with map to form something else that's not a good producer but fuses with map. The purpose of this is to shift the break we introduce in the fusion "pipeline" to the left in the hope that it will coalesce with another such break further on. > You might make the rules simpler by using `mapReverseFB revId` instead of `revFB`: No need to have both `mapMapReverse` and `mapReverse` then. That's a good idea. > There is quite a bit of logic in this patch. Would you mind adding test cases for this, so that this behaviour is not accidentally broken in the future? I can add some correctness tests for sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:00:28 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:00:28 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.21a771f2b085b5045279aa3f6da56d94@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I also just realized it may be better to ditch `mapreverse` altogether and actually interchange the `map` with the `reverse` so as to be sure not to interfere with the `map/map` rule. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:19:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:19:44 -0000 Subject: [GHC] #9434: GHC.List.reverse does not fuse In-Reply-To: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> References: <045.307e264233b9ba83858f4f16f33fa96f@haskell.org> Message-ID: <060.c1747fb4d2f86f4ac62cedaaa9dd75f0@haskell.org> #9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: | Version: 7.9 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > I can add some correctness tests for sure. Not just functional correctness, but also that things fuse as they should, in the spirit of `T9339`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:21:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:21:18 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.744af11803217766c2a895d4a22067a7@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"488e95b433d4f7568aa89622c729e64aa3b6520d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="488e95b433d4f7568aa89622c729e64aa3b6520d" Make foldr2 a bit more strict in order to make its RULES semantics preserving. This fixes #9495. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:21:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:21:18 -0000 Subject: [GHC] #9355: scanr does not participate in stream fusion In-Reply-To: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> References: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> Message-ID: <060.e67a2ba5516989a0448c56e224611980@haskell.org> #9355: scanr does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"4e1dfc3767167dddd0e151a2df8305b12aa0f49c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4e1dfc3767167dddd0e151a2df8305b12aa0f49c" Make scanr a good producer and consumer This fixes #9355. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:21:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:21:18 -0000 Subject: [GHC] #9502: mapAccumL does not participate in foldr/build fusion In-Reply-To: <045.004d5a2aa80154a27f3198a7a0d1aca1@haskell.org> References: <045.004d5a2aa80154a27f3198a7a0d1aca1@haskell.org> Message-ID: <060.519129719fc4bc01c9f1464fb0e3e543@haskell.org> #9502: mapAccumL does not participate in foldr/build fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"d41dd03fdf0ef723ca31f5a11f07a54a15d2cbc0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d41dd03fdf0ef723ca31f5a11f07a54a15d2cbc0" Make mapAccumL a good consumer This fixes #9502. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:21:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:21:18 -0000 Subject: [GHC] #9536: Implement foldr/cons/build In-Reply-To: <045.6ebfec57f4d10be70298126e95b3e1e6@haskell.org> References: <045.6ebfec57f4d10be70298126e95b3e1e6@haskell.org> Message-ID: <060.fd2352f164bc4d2d3760ab9cd992d631@haskell.org> #9536: Implement foldr/cons/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.4 Component: | Version: 7.9 libraries/base | Keywords: fusion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"789321098f86fd3c4483b24372f8938f89b12312/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="789321098f86fd3c4483b24372f8938f89b12312" Fusion rule for "foldr k z (x:build g)" There seem to be various issues with general fold/cons and even cons/build rules, but it seems pretty clear to me that the simple fold/cons/build rule is a good idea. It doesn't do much for nofib allocation, but it seems to improve some other analyses and speed several benchmarks up. Implements #9536. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:21:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:21:18 -0000 Subject: [GHC] #9546: filterM is not a good consumer for list fusion In-Reply-To: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> References: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> Message-ID: <060.dce0fcf6266ed1d9927ecfecd7f2a956@haskell.org> #9546: filterM is not a good consumer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"96a4062a7e7587592829c045b3b12c755cc8e329/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="96a4062a7e7587592829c045b3b12c755cc8e329" Make filterM a good consumer analogously to mapM. Fixes #9546. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:21:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:21:18 -0000 Subject: [GHC] #9561: Clean up mergeSATInfo In-Reply-To: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> References: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> Message-ID: <060.20ca59f0e34c06b063b7881c3ae03eb0@haskell.org> #9561: Clean up mergeSATInfo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"93b8d0fd63cf8e00ca37c1ce76b93d4ee1fc56f8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="93b8d0fd63cf8e00ca37c1ce76b93d4ee1fc56f8" Simplify mergeSATInfo by using zipWith Closes #9561. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:22:57 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:22:57 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.f6c56281009ffc67c39d91b2e82e035c@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:23:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:23:02 -0000 Subject: [GHC] #9355: scanr does not participate in stream fusion In-Reply-To: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> References: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> Message-ID: <060.8d5d090e7f07adf251ebe32c81708616@haskell.org> #9355: scanr does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:23:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:23:06 -0000 Subject: [GHC] #9536: Implement foldr/cons/build In-Reply-To: <045.6ebfec57f4d10be70298126e95b3e1e6@haskell.org> References: <045.6ebfec57f4d10be70298126e95b3e1e6@haskell.org> Message-ID: <060.c6de4e8f1793f6d66649f9546314265d@haskell.org> #9536: Implement foldr/cons/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.8.4 Component: | Version: 7.9 libraries/base | Keywords: fusion Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:23:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:23:14 -0000 Subject: [GHC] #9502: mapAccumL does not participate in foldr/build fusion In-Reply-To: <045.004d5a2aa80154a27f3198a7a0d1aca1@haskell.org> References: <045.004d5a2aa80154a27f3198a7a0d1aca1@haskell.org> Message-ID: <060.7ea93e6091292b9390d76736e4f34e09@haskell.org> #9502: mapAccumL does not participate in foldr/build fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:23:18 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:23:18 -0000 Subject: [GHC] #9546: filterM is not a good consumer for list fusion In-Reply-To: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> References: <045.f71c9e311b6149a022962aa8ca275590@haskell.org> Message-ID: <060.1cc283e8bbab7fa1ad365921345d32f4@haskell.org> #9546: filterM is not a good consumer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:23:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:23:50 -0000 Subject: [GHC] #9561: Clean up mergeSATInfo In-Reply-To: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> References: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> Message-ID: <060.af36fd07033d3a44cd8a0ded8992544a@haskell.org> #9561: Clean up mergeSATInfo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: I agree with dfeuer, this is an unproblematic refactoring; merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 16:29:15 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 16:29:15 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.f054f8195edc1218330994122a9718ee@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by augustss): To me saying that `T Bool` is OK because it's inaccessible is akin to saying that type incorrect expressions are OK as long as they are inaccessible. After all, if you don't use them, they can't cause any harm. But for expressions we have decided that this isn't acceptable. I guess making `T a` behave would require something like kind classes. We don't say that the expression `show x` is unconditionally type correct. It depends on the type of `x` belonging to the `Show` class. In the same way, `T a` is not unconditionally type correct, it's only type correct if `a` is one of the types where `T` is well defined. Until we have something like that I think you'll have to accept that the substitution lemma doesn't work. You can pretend it works by saying `T Bool` is a type, if that makes you happier. I just wonder which type it is. :) But I'm not asking for the moon. :) I'd just like the compiler to tell me when it finds something that is clearly not going to work, like `T Bool`. Exactly under what conditions and how it tells me, I don't care. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 17:05:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 17:05:40 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.c0fb9cad6b1885345c4b796875f2b99a@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:12 augustss]: > To me saying that `T Bool` is OK because it's inaccessible is akin to saying that type incorrect expressions are OK as long as they are inaccessible. After all, if you don't use them, they can't cause any harm. But for expressions we have decided that this isn't acceptable. Isn't it analogous to saying that incomplete pattern matches are OK as long as they are inaccessible? (Which they are.) After all, like you said, a closed type family is like a function on types. The type expression `T Bool` has no normal form, for sure, but who says we have to evaluate it? Anyways, failure of what I have learned is called "the substitution lemma" is far more unintuitive to me than GHC allowing `T Bool` even though it is "floating" (my made-up word for type family applications that cannot be reduced (yet)) and GHC knows that it can never be reduced. But a warning, sure. > I guess making `T a` behave would require something like kind classes. We don't say that the expression `show x` is unconditionally type correct. It depends on the type of `x` belonging to the `Show` class. In the same way, `T a` is not unconditionally type correct, it's only type correct if `a` is one of the types where `T` is well defined. Something like this would be great for other uses, too (imagine restricting the kind of the argument to `Set` to only allow types which are instances of `Ord`). But it sounds more like a research project than a bug report! > Until we have something like that I think you'll have to accept that the substitution lemma doesn't work. You can pretend it works by saying `T Bool` is a type, if that makes you happier. I just wonder which type it is. :) In the System FC translation it's an indeterminate type, sort of like the variable "x" in a ring of polynomials. I can do algebra on polynomials without ever asking which number "x" is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 17:08:47 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 17:08:47 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.83ccb0908985eef1975cd592c801f06d@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:12 augustss]: > To me saying that `T Bool` is OK because it's inaccessible is akin to saying that type incorrect expressions are OK as long as they are inaccessible. After all, if you don't use them, they can't cause any harm. But for expressions we have decided that this isn't acceptable. I actually would say that an inaccessible expression is ''always'' type- correct, because inaccessibility means that there is a proof of ''false'' in the context, and thus anything is possible. But that's perhaps a story for another day. > > I guess making `T a` behave would require something like kind classes. It's a little worse than that, I think. Say `x :: Z`. In `show x`, we know `Z` must be in the `Show` class, and we also know that ''anything'' of type `Z` is a valid parameter to `show`. Thus, we have substitution, because substitution preserves types. But, in closed type families, we have a stranger situation: `T a` where `a :: *` is acceptable, but `T Bool` is not. I think kind classes (which can be kludged today) don't solve this problem. > But I'm not asking for the moon. :) I'd just like the compiler to tell me when it finds something that is clearly not going to work, like `T Bool`. Exactly under what conditions and how it tells me, I don't care. This is certainly possible. It's just that the behavior around this feature won't be complete and might not be predictable in corner cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 17:11:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 17:11:43 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.61f611ddfc92eda49324f195a48423e5@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:13 rwbarton]: > Anyways, failure of what I have learned is called "the substitution lemma" is far more unintuitive to me If the substitution lemma doesn't hold, then (perhaps) FC, and by extension Haskell, is no longer type-safe. In other words, I don't believe that the type system is capable of ruling out `T Bool`, without major surgery. So, maybe we can report errors to the user if we see `T Bool` in source code, but if `T Bool` ends up sloshing around internally, GHC will respect it as a valid type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 20:53:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 20:53:34 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.238c49c11e103d2ab12b575d4199c80f@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by singpolyma): > We'd need to make some modifications to GHC itself to tell it where to desugar to for the Monad syntax and internal hackery. We'd need to figure out how to tell tools like cabal to do the right thing. Isn't this already needed for RebindableSyntax? Is this not a special case of that, or it more different than I think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 20:54:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 20:54:44 -0000 Subject: [GHC] #7998: Stage1Only does not work In-Reply-To: <049.a2735032c7c38fb5dac9fe49eaae690b@haskell.org> References: <049.a2735032c7c38fb5dac9fe49eaae690b@haskell.org> Message-ID: <064.bda053abd5d36091efb053951339fabe@haskell.org> #7998: Stage1Only does not work -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | 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 singpolyma): * status: new => closed * difficulty: => Unknown * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 20:55:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 20:55:51 -0000 Subject: [GHC] #7490: ghc-stage1 panic when building a cross-compiler or cross-building a compiler In-Reply-To: <049.8184bf9377eb14f5459700a01fd62871@haskell.org> References: <049.8184bf9377eb14f5459700a01fd62871@haskell.org> Message-ID: <064.ad482421f6f5de1642dd56c7b887686c@haskell.org> #7490: ghc-stage1 panic when building a cross-compiler or cross-building a compiler -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: cross-compilation Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by singpolyma): This is not longer happening for me. I think it might be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 21:38:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 21:38:49 -0000 Subject: [GHC] #9616: Incorrect numbers from HpcMarkup.markup_plugin In-Reply-To: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> References: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> Message-ID: <060.c01e3c2a6f0090979c8ed1f0619c49b3@haskell.org> #9616: Incorrect numbers from HpcMarkup.markup_plugin -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Code | Version: 7.9 Coverage | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D259 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"2a8856884de7d476e26b4ffa829ccb3a14d6f63e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a8856884de7d476e26b4ffa829ccb3a14d6f63e" Use dropWhileEndLE p instead of reverse . dropWhile p . reverse Summary: Using `dropWhileEndLE` tends to be faster and easier to read than the `reverse . dropWhile p . reverse` idiom. This also cleans up some other, nearby, messes. Fix #9616 (incorrect number formatting potentially leading to incorrect numbers in output). Test Plan: Run validate Reviewers: thomie, rwbarton, nomeata, austin Reviewed By: nomeata, austin Subscribers: simonmar, ezyang, carter, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D259 GHC Trac Issues: #9623, #9616 Conflicts: compiler/basicTypes/OccName.lhs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 21:38:49 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 21:38:49 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.3603cf3bcdf96a700b81a9405ad26e04@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"2a8856884de7d476e26b4ffa829ccb3a14d6f63e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a8856884de7d476e26b4ffa829ccb3a14d6f63e" Use dropWhileEndLE p instead of reverse . dropWhile p . reverse Summary: Using `dropWhileEndLE` tends to be faster and easier to read than the `reverse . dropWhile p . reverse` idiom. This also cleans up some other, nearby, messes. Fix #9616 (incorrect number formatting potentially leading to incorrect numbers in output). Test Plan: Run validate Reviewers: thomie, rwbarton, nomeata, austin Reviewed By: nomeata, austin Subscribers: simonmar, ezyang, carter, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D259 GHC Trac Issues: #9623, #9616 Conflicts: compiler/basicTypes/OccName.lhs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 21:39:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 21:39:05 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.2d965e0bcf5f7d1bea4e57a48d84b1ce@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 21:39:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 21:39:19 -0000 Subject: [GHC] #9616: Incorrect numbers from HpcMarkup.markup_plugin In-Reply-To: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> References: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> Message-ID: <060.a0b65fe2b9f6bbffa378dad02b6041b4@haskell.org> #9616: Incorrect numbers from HpcMarkup.markup_plugin -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Code | Version: 7.9 Coverage | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D259 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 21:41:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 21:41:34 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.a13b793ca2758d3c7b34047c578a4c05@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: monoidal Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D233 | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"084d241b316bfa12e41fc34cae993ca276bf0730/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="084d241b316bfa12e41fc34cae993ca276bf0730" Basic Python 3 support for testsuite driver (Trac #9184) Summary: Most of the changes is adaptation of old Python 2 only code. My priority was not breaking Python 2, and so I avoided bigger changes to the driver. In particular, under Python 3 the output is a str and buffering cannot be disabled. To test, define PYTHON=python3 in testsuite/mk/boilerplate.mk. Thanks to aspidites who provided the initial patch. Test Plan: validate under 2 and 3 Reviewers: hvr, simonmar, thomie, austin Reviewed By: thomie, austin Subscribers: aspidites, thomie, simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D233 GHC Trac Issues: #9184 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 21:52:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 21:52:21 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.5853d355e5d07d8fab394f9b2728dce5@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: monoidal Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D233 | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed Comment: I consider this done; I marked the support as "experimental" since I'm not absolutely sure if all code is properly covered and the code will be less used then the P2 version, but once it gets traction and no issues arise, I will remove the mark. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 1 22:29:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Oct 2014 22:29:51 -0000 Subject: [GHC] #9656: Process and thread init/deinit hooks for C libraries Message-ID: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> #9656: Process and thread init/deinit hooks for C libraries -------------------------------------+------------------------------------- Reporter: 3noch | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: FFI | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Haskell's FFI for C seems geared toward C as an optimization. But in many cases, we use the C FFI merely hook into a 3rd-party library. In this case, the FFI seems a bit lacking. In my specific case, I want to link against libmysqlclient_r to perform MySQL queries. However, the library requires global init and deinit. Worse, it requires init/deinit for *each* thread that wishes to interact with its API. This type of thing is not entirely uncommon among C libraries. Of course, we can bend over backward to inter-operate with such libraries (e.g. wrap the C API with our own versions that ensure proper initialization), but the process is painstaking and often requires decent performance overhead. I would like to request some sort of hook registration where the FFI can be used to accomplish these common tasks. Perhaps it's too difficult, but it doesn't hurt to ask! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 00:53:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 00:53:13 -0000 Subject: [GHC] #9655: Do not UNPACK strict fields that are very wide In-Reply-To: <046.c5043c06a960b4e37dc0e2bc0fcfba64@haskell.org> References: <046.c5043c06a960b4e37dc0e2bc0fcfba64@haskell.org> Message-ID: <061.f5eb14e56a0534d88d22b1c9a75d2423@haskell.org> #9655: Do not UNPACK strict fields that are very wide -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by jwlato): Ah, thanks for this ticket, I think it's a good idea. Unfortunately my code isn't using `-funbox-strict-fields`. To double-check I tried adding a `{-# NOUNPACK #-}` on the wide strict field and the behavior didn't change, so I think something else is going on with my code. But I do think the suggested behavior is more sensible, I usually avoid `-funbox- strict-fields` because I don't want types like this auto-unboxed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 02:45:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 02:45:04 -0000 Subject: [GHC] #9142: LLVM 3.5.0 rejects aliases used by LLVM codegen (was: LLVM HEAD rejects aliases used by LLVM codegen) In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.4f97d2978f976fb18beabb6faf616269@haskell.org> #9142: LLVM 3.5.0 rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4213 | Differential Revisions: Phab:D155 | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 03:59:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 03:59:59 -0000 Subject: [GHC] #9656: Process and thread init/deinit hooks for C libraries In-Reply-To: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> References: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> Message-ID: <059.282527b26368959fc964ed5d7b755181@haskell.org> #9656: Process and thread init/deinit hooks for C libraries -------------------------------------+------------------------------------- Reporter: 3noch | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: FFI Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * status: new => closed * resolution: => invalid Comment: have you looked at https://hackage.haskell.org/package/mysql and its higher level cousin mysql-simple ? that sort of thread local storage machinery is totally manageable in userland, use the forkOS primitive to start a thread in a dedicated distinct OS thread. point being, this sort of thing is manageable in userland (see also how folks hand ffi bindings to libs that need thread local storage). So unless i'm misunderstanding this ticket, im going to close it for now. Haskell- cafe or haskell reddit are good places to ask for pointers on C ffi engineering, though theres also numerous resources on the wiki and many many c ffi bindings on hackage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 04:41:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 04:41:13 -0000 Subject: [GHC] #9656: Process and thread init/deinit hooks for C libraries In-Reply-To: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> References: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> Message-ID: <059.d12102fb156b2315f5a9de49850792c7@haskell.org> #9656: Process and thread init/deinit hooks for C libraries -------------------------------------+------------------------------------- Reporter: 3noch | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: FFI Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by 3noch): The mysql package punts on this issue because it uses the single-threaded lib, so it can get away without calling most of the init/deinit functions manually. One issue is that the main library init function is not thread safe so must be called before any threads are created (or mutex protected). In a C program, this is easily done by adding a few calls in main. The trouble when connecting Haskell apps to these libraries is that we don't have that kind of access to "main" and thus have to come up with awkward APIs and monads, etc. to make sure everything happens properly. Of course, as I said, it's possible to do this in user-land, its just painful and makes Haskell less friendly in real-world scenarios where you want to interop with stuff like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 05:17:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 05:17:34 -0000 Subject: [GHC] #9656: Process and thread init/deinit hooks for C libraries In-Reply-To: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> References: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> Message-ID: <059.11eac5222f0b34c37ec1d716611811dc@haskell.org> #9656: Process and thread init/deinit hooks for C libraries -------------------------------------+------------------------------------- Reporter: 3noch | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: FFI Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I"ll repeat, you can get the behavior you want with forkOS and finalizers http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.7.0.1 /Foreign-ForeignPtr.html and http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.7.0.1 /Control-Concurrent.html if you wish to have some help getting the design you want, please ask on #haskell on irc freenode, haskell-cafe mailing list, or the haskell reddit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 05:20:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 05:20:08 -0000 Subject: [GHC] #9656: Process and thread init/deinit hooks for C libraries In-Reply-To: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> References: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> Message-ID: <059.62f5da80acf5dd00d61ab0ebcc71c135@haskell.org> #9656: Process and thread init/deinit hooks for C libraries -------------------------------------+------------------------------------- Reporter: 3noch | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: FFI Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by 3noch): Excellent. If it really is cleanly possible without changes to the compiler, then that is most definitely better! Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 05:24:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 05:24:50 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.d257a59bef9257038ee33f06be57b0d9@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by juhpetersen): (another +1 for NCG for arm and arm64! :-) Likely I should open a new ticket, but I am having trouble with installing ghc-7.8.3 plus above patch on Fedora 21 ARM64 (aarch64). {{{ "inplace/bin/ghc-cabal" copy libraries/haskell2010 dist-install "strip" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' 'v dyn ' Installing library in /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/haskell2010-1.1.2.0 "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" --force --global-package-db "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. rts-1.0: Warning: library-dirs: /usr/lib64/ghc-7.8.3/rts-1.0 doesn't exist or isn't a directory rts-1.0: Warning: include-dirs: /usr/lib64/ghc-7.8.3/include doesn't exist or isn't a directory rts-1.0: cannot find any of ["libHSrts.a","libHSrts.p_a","libHSrts- ghc7.8.3.so","libHSrts-ghc7.8.3.dylib","HSrts-ghc7.8.3.dll"] on library path (ignoring) "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg : "" Registering ghc-prim-0.3.1.0... "inplace/bin/ghc-cabal" register libraries/integer-gmp dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg : "" ghc-cabal: Installed package ID not registered: "ghc-prim-0.3.1.0-inplace" ghc.mk:901: recipe for target 'install_packages' failed Makefile:64: recipe for target 'install' failed make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 }}} The problem seems to be that the installed (dynlinked) ghc-pkg does no output anything! (eg "ghc-pkg --version" returns "", same for --help.) When I try the built binaries I find that ghc-7.8.3/utils/ghc-pkg/dist/build/tmp/ghc-pkg (which is statically linked) works normally (ie it outputs --help and --version) whereas $DESTDIR/$libdir/ghc-7.8.3/bin/ghc-pkg gives no output on stdout! Maybe I should try installing statically linked ghc and see if that makes difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 05:29:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 05:29:48 -0000 Subject: [GHC] #9656: Process and thread init/deinit hooks for C libraries In-Reply-To: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> References: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> Message-ID: <059.64bfc61257d9b945e9a2a3b7a787830a@haskell.org> #9656: Process and thread init/deinit hooks for C libraries -------------------------------------+------------------------------------- Reporter: 3noch | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: FFI Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): Note that because ghc threads (aside from forkOS threads) aren't bound to specific OS threads, you'll have to do some intermediating the calls via the bound thread. But these are thing which folks on haskell-cafe and those other fora will be more than able to help you with -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 06:10:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 06:10:47 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.e2c06f293b71e8fa1bc8e0b5c81789da@haskell.org> #8199: Get rid of HEAP_ALLOCED -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 5435 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D207 | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"644c76a3574a623fa5d2a9a28d8e6fc971aca901/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="644c76a3574a623fa5d2a9a28d8e6fc971aca901" Use LinkerInternals.h for exitLinker. Part of remove HEAP_ALLOCED patch set (#8199) Summary: Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonmar, austin Subscribers: simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D262 GHC Trac Issues: #8199 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 06:10:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 06:10:47 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.ac4791ead16a7f781bad9723af828ecb@haskell.org> #8199: Get rid of HEAP_ALLOCED -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 5435 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D207 | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"b23ba2a7d612c6b466521399b33fe9aacf5c4f75/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b23ba2a7d612c6b466521399b33fe9aacf5c4f75" Place static closures in their own section. Summary: The primary reason for doing this is assisting debuggability: if static closures are all in the same section, they are guaranteed to be adjacent to one another. This will help later when we add some code that takes section start/end and uses this to sanity-check the sections. Part of remove HEAP_ALLOCED patch set (#8199) Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonmar, austin Subscribers: simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D263 GHC Trac Issues: #8199 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 06:10:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 06:10:47 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.98f904536e1a3096e5a20666a83aacf5@haskell.org> #8199: Get rid of HEAP_ALLOCED -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 5435 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D207 | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"178eb9060f369b216f3f401196e28eab4af5624d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="178eb9060f369b216f3f401196e28eab4af5624d" Properly generate info tables for static closures in C--. Summary: Previously, we assumed all objects declared in C-- were not-static, even ones which were CONSTR_NOCAF_STATIC. This used to be harmless, but now we need this information to be correct. Part of remove HEAP_ALLOCED patch set (#8199) Depends on D264 Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonmar, austin Subscribers: simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D265 GHC Trac Issues: #8199 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 06:10:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 06:10:47 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.e19bb4ff0f0806b65c6f625a2f7cc664@haskell.org> #8199: Get rid of HEAP_ALLOCED -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 5435 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D207 | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"3b5a840bba375c4c4c11ccfeb283f84c3a1ef22c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3b5a840bba375c4c4c11ccfeb283f84c3a1ef22c" BC-breaking changes to C-- CLOSURE syntax. Summary: Previously, there were two variants of CLOSURE in C--: - Top-level CLOSURE(foo_closure, foo, lits...), which defines a new static closure and gives it a name, and - Array CLOSURE(foo, lits...), which was used for the static char and integer arrays. They used the same name, were confusing, and didn't even generate the correct internal label representation! So now, we have two new forms: - Top-level CLOSURE(foo, lits...) which automatically generates foo_closure (along with foo_info, which we were doing already) - Array ANONYMOUS_CLOSURE(foo, lits...) which doesn't generate a foo_closure identifier. Part of remove HEAP_ALLOCED patch set (#8199) Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonmar, austin Subscribers: simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D264 GHC Trac Issues: #8199 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 06:10:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 06:10:47 -0000 Subject: [GHC] #8199: Get rid of HEAP_ALLOCED In-Reply-To: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> References: <045.61ceff1405fed9aab9c8f0fda5e9d453@haskell.org> Message-ID: <060.cd7ccdd59e5dbf574f6722ba326fc020@haskell.org> #8199: Get rid of HEAP_ALLOCED -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Project (more Unknown/Multiple | than a week) Type of failure: | Blocked By: 5435 None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D207 | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"35672072b4091d6f0031417bc160c568f22d0469/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="35672072b4091d6f0031417bc160c568f22d0469" Rename _closure to _static_closure, apply naming consistently. Summary: In preparation for indirecting all references to closures, we rename _closure to _static_closure to ensure any old code will get an undefined symbol error. In order to reference a closure foobar_closure (which is now undefined), you should instead use STATIC_CLOSURE(foobar). For convenience, a number of these old identifiers are macro'd. Across C-- and C (Windows and otherwise), there were differing conventions on whether or not foobar_closure or &foobar_closure was the address of the closure. Now, all foobar_closure references are addresses, and no & is necessary. CHARLIKE/INTLIKE were not changed, simply alpha-renamed. Part of remove HEAP_ALLOCED patch set (#8199) Depends on D265 Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonmar, austin Subscribers: simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D267 GHC Trac Issues: #8199 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 07:27:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 07:27:56 -0000 Subject: [GHC] #9655: Do not UNPACK strict fields that are very wide In-Reply-To: <046.c5043c06a960b4e37dc0e2bc0fcfba64@haskell.org> References: <046.c5043c06a960b4e37dc0e2bc0fcfba64@haskell.org> Message-ID: <061.18abc78e3e97b8e20efa2ea3afbdaf7e@haskell.org> #9655: Do not UNPACK strict fields that are very wide -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah. In that case I'm puzzled. The strictness analyser does worker/wrapper split that does not take account of the width of the argument product, which is more defensible than in unpacking wide data type declarations. But in that case * I don't think that removing the "!" would make a difference. * We might get a worker with lots of arguments but I don't see why that would increase compile times. John: if you feel motivated, could you boil out a reproducible test case? If you use `-dshow-passes` on your current set-up, I think you'll see that the size of one of the intermediate stages blows up when you have the "!" vs not having it. So you can use that unexpected size blow-up instead of looking for very long compile times (which can get a bit painful). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 08:10:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 08:10:41 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.3f440aea8a1f4b8417a2d4e0aa17751b@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * cc: juhp@? (removed) * cc: petersen@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 08:52:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 08:52:34 -0000 Subject: [GHC] #9180: New magic function `staticError` In-Reply-To: <046.f02a1097d6c172420c24668297fdcea7@haskell.org> References: <046.f02a1097d6c172420c24668297fdcea7@haskell.org> Message-ID: <061.d946ba16c2c13dfbb90863ad62bf7b06@haskell.org> #9180: New magic function `staticError` -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Lint is not run by default, is it? In that case I don?t think it would quite cut it. I imagine that `staticError` could be quite a general tool that library authors can use to warn unaware users when they use the library wrongly; a user that deliberately runs the linter is, by definition, not unaware. Another use case would be to have rules that detect certain patterns that the library author knows that do not make sense, by having a rule `foo doNotPassMeToFoo = staticError "Bad user!"` he could prevent that. (Of course we?d like library authors to use the type system for that, but that might not be possible in all cases...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 09:12:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 09:12:34 -0000 Subject: [GHC] #9117: Coercible constraint solver misses one In-Reply-To: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> References: <047.778638aa48ea68f632ec9b5a978a795b@haskell.org> Message-ID: <062.fc26c75db83315b538f69439d671881f@haskell.org> #9117: Coercible constraint solver misses one -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 nomeata): * owner: nomeata => Comment: This ticket started with `eta :: Coercible f g => Coercion (f a) (g a)` and then discussed the order of our existing solving steps (which was then changed). But nothing happened about `eta :: Coercible f g => Coercion (f a) (g a)`. Is there a real use case for this? Do we have an idea how to integrate that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 09:16:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 09:16:56 -0000 Subject: [GHC] #9180: New magic function `staticError` In-Reply-To: <046.f02a1097d6c172420c24668297fdcea7@haskell.org> References: <046.f02a1097d6c172420c24668297fdcea7@haskell.org> Message-ID: <061.e86235f8fc64376508041337b1e245c5@haskell.org> #9180: New magic function `staticError` -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): My guess is that you'll be plagued with false positives, but you can try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 09:27:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 09:27:18 -0000 Subject: [GHC] #9121: Presence of dyn_o files not checked upon recompilation (was: Presence of dyn_o files not checked? upon recompilation) In-Reply-To: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> References: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> Message-ID: <066.dbf43696d84aa0292f559097acd6b3ab@haskell.org> #9121: Presence of dyn_o files not checked upon recompilation -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.3 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Other | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by andreas.abel): * priority: normal => high * failure: None/Unknown => Other * version: 7.8.2 => 7.8.3 Old description: > When I interrupt a compilation (initiated with cabal), and then recompile > (with cabal), it can happen that gcc fails with missing .dyn_o file. > > I have "shared:True" in my .cabal/config file. > > [I can of course do cabal clean to work around, but since a full > recompilation is about 10 min, I try to avoid this.] > > time cabal install --disable-library-profiling --disable-documentation > Resolving dependencies... > In order, the following will be installed: > Agda-2.3.3 (latest: 2.3.2.2) (reinstall) > Warning: Note that reinstalls are always dangerous. Continuing anyway... > Configuring Agda-2.3.3... > Building Agda-2.3.3... > Preprocessing library Agda-2.3.3... > [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( > src/full/Agda/TypeChecking/Monad/Base.hs-boot, > dist/build/Agda/TypeChecking/Monad/Base.o-boot ) > > ... > [239 of 273] Compiling Agda.TypeChecking.Conversion ( > src/full/Agda/TypeChecking/Conversion.hs, > dist/build/Agda/TypeChecking/Conversion.o ) > [Agda.Syntax.Translation.InternalToAbstract changed] > ^Cmake: *** [install-bin] Interrupt > > time cabal install --disable-library-profiling --disable-documentation > > Resolving dependencies... > In order, the following will be installed: > Agda-2.3.3 (latest: 2.3.2.2) (reinstall) > Warning: Note that reinstalls are always dangerous. Continuing anyway... > Configuring Agda-2.3.3... > Building Agda-2.3.3... > Preprocessing library Agda-2.3.3... > [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( > src/full/Agda/TypeChecking/Monad/Base.hs-boot, > dist/build/Agda/TypeChecking/Monad/Base.o-boot ) > ... > [273 of 273] Compiling Agda.Main ( src/full/Agda/Main.hs, > dist/build/Agda/Main.o ) [Agda.Compiler.Epic.Compiler changed] > gcc: error: dist/build/Agda/TypeChecking/Conversion.dyn_o: No such file > or directory > Failed to install Agda-2.3.3 > cabal: Error: some packages failed to install: > Agda-2.3.3 failed during the building phase. The exception was: > ExitFailure 1 New description: This bug persists in 7.8.3. (originally reported for 7.8.2). When I interrupt a compilation (initiated with cabal), and then recompile (with cabal), it can happen that gcc fails with missing .dyn_o file. I have "shared:True" in my .cabal/config file. [I can of course do cabal clean to work around, but since a full recompilation is about 10 min, I try to avoid this.] {{{ time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [239 of 273] Compiling Agda.TypeChecking.Conversion ( src/full/Agda/TypeChecking/Conversion.hs, dist/build/Agda/TypeChecking/Conversion.o ) [Agda.Syntax.Translation.InternalToAbstract changed] ^Cmake: *** [install-bin] Interrupt }}} {{{ time cabal install --disable-library-profiling --disable-documentation Resolving dependencies... In order, the following will be installed: Agda-2.3.3 (latest: 2.3.2.2) (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring Agda-2.3.3... Building Agda-2.3.3... Preprocessing library Agda-2.3.3... [116 of 273] Compiling Agda.TypeChecking.Monad.Base[boot] ( src/full/Agda/TypeChecking/Monad/Base.hs-boot, dist/build/Agda/TypeChecking/Monad/Base.o-boot ) ... [273 of 273] Compiling Agda.Main ( src/full/Agda/Main.hs, dist/build/Agda/Main.o ) [Agda.Compiler.Epic.Compiler changed] gcc: error: dist/build/Agda/TypeChecking/Conversion.dyn_o: No such file or directory Failed to install Agda-2.3.3 cabal: Error: some packages failed to install: Agda-2.3.3 failed during the building phase. The exception was: ExitFailure 1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 09:32:42 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 09:32:42 -0000 Subject: [GHC] #9590: AMP breaks `haskell2010` package In-Reply-To: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> References: <042.9b806dd604b81c3eeadf68302337e634@haskell.org> Message-ID: <057.f5450fed1f50335c7209d68d65fa3daa@haskell.org> #9590: AMP breaks `haskell2010` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: AMP Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:9 singpolyma]: > Isn't this already needed for RebindableSyntax? Is this not a special case of that, or it more different than I think? Here's some sketchy idea I also wrote in a reddit comment about an hypothetical `RebindableSyntax`-variant called `ExportedRebindedSyntax` (modulo bikeshed): - Code using a non-default Prelude (like e.g. `haskell2010` or `haskell98`) shall just need to hide the `base` package and bring `haskell2010` into scope - Particularly, code importing that non-default Prelude shall not need to enable any language extensions - The non-default Prelude module would rebind all syntax elements like with `RebindableSyntax`, but it would only export the desugaring rules, but does not need to export the symbols such as `IfThenElse` the desugaring rules are bound to for client code to work - If a module `X` directly or indirectly imports a Prelude module using the `ExportedRebindedSyntax` extension, it inherits the desugaring rules, and exports them to other modules that import that module `X`. It would be illegal to have conflicting desugaring rules brought into scope (c.f. conflicting typeclass instances being an error) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 10:05:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 10:05:47 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.d5c8740385b31e55e64533516cdaa84b@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:18 Herbert Valerio Riedel ]: > In [changeset:"b8f583928fa6cb5371a872fc73080d2002dd87d9/ghc"]: > {{{ > #!CommitTicketReference repository="ghc" revision="b8f583928fa6cb5371a872fc73080d2002dd87d9" > Export `Monoid(..)`/`Foldable(..)`/`Traversable(..)` from Prelude > > This finally exposes also the methods of these 3 classes in the Prelude > in order to allow to define basic class instances w/o needing imports. > > This almost completes the primary goal of #9586 > > NOTE: `fold`, `foldl'`, `foldr'`, and `toList` are not exposed yet, > as they require upstream fixes for at least `containers` and > `bytestring`, and are not required for defining basic instances. > > Reviewed By: ekmett, austin > > Differential Revision: https://phabricator.haskell.org/D236 > }}} This patch seems to be unrelated to the scope of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 10:21:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 10:21:03 -0000 Subject: [GHC] #9646: Simplifer non-determinism leading to 8 fold difference in run time performance In-Reply-To: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> References: <044.91d1be288ff53f5ea138a0b071967333@haskell.org> Message-ID: <059.79e3c48c5fe6c86854bf73693ecf8573@haskell.org> #9646: Simplifer non-determinism leading to 8 fold difference in run time performance -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by erikd): ?The repo at https://github.com/erikd/ghc-perfbug-test has been stripped back as far as possible and no longer needs either criterion or hspec. The code has been tested with ghc-7.8.3 and ghc-7.9.20140929 and both display the same problem. Cloning the repo, cd-ing into it and running `make` will build the code and then print out: {{{ Fast version etas : 0 Slow version etas : 18 }}} which is simply the count of the occurence of the identifier `eta` in the twp -ddump-simpl outputs generated from the same file. When this bug is fixed, both values should be zero. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 10:43:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 10:43:24 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.b4f0f38ebc37290e9ef816b32c88414e@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by augustss): Replying to [comment:13 rwbarton]: > Isn't it analogous to saying that incomplete pattern matches are OK as long as they are inaccessible? (Which they are.) After all, like you said, a closed type family is like a function on types. The type expression `T Bool` has no normal form, for sure, but who says we have to evaluate it? Yes, it's a lot like a pattern match failure. So let us go with that analogy for a moment. Assume we have these definitions: {{{#!hs foo :: Int -> Int foo 0 = 42 bar = foo 5 - foo 5 }}} Since we know that `x - x = 0` it is tempting to optimize the definition of `bar` to `bar = 0`. This is, of course, wrong since computing `foo 5` will result in bottom. Now compare this to what the type checker does in my original example. It happily assumes that `T Bool` is equal to `T Bool`, but that's wrong. `T Bool` is bottom at type checking time and should be reported as such. I've decided I'm OK with having `T Bool` just floating around in the same way that I'm OK with having `foo 5` floating around in a lazy language. Type families introduce partial functions on the type level, and I think this has to be dealt with. Type expressions can now blow up during type checking. So at the points when a (closed) type family expression has to be evaluated, e.g., for equality comparison, and it cannot be reduced then this should be an error. IMHO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 10:59:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 10:59:28 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.0461368eb11dfcc3f16145af8d694ba3@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | 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 nomeata): * status: new => closed * resolution: => wontfix Comment: Since nested cpr was not merged, this ticket makes little sense any more. Or, put differently, it was investigated and deemed not worthwhile pursuing on its own. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 11:46:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 11:46:16 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.da6d158de4ebf635d94f8d2aa376b146@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:16 augustss]: > So at the points when a (closed) type family expression has to be evaluated, e.g., for equality comparison, and it cannot be reduced then this should be an error. IMHO. Unfortunately, this, too, violates the substitution lemma. We probably want to be able to solve `(a ~ a)` with reflexivity, for ''any'' `a`. But, you're suggesting that a particular value for `a`, namely `T Bool`, will ''not'' equal itself. The difference between types and terms here is that we need to be able to reason about unevaluated types, such as `a`. We never need this ability on terms, so the existing term-level semantics works out just fine. To be clear, I'm saying that issuing an error/warning in the case of a user-written strange beast seems quite easy to implement. Any suggestion beyond that made here seems like a stretch, though. Do keep suggesting, though -- perhaps we'll find something that works in here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 12:27:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 12:27:59 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.f8361116e4e629e45b51f7264ad78f45@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:24 Herbert Valerio Riedel ]: > In [changeset:"a07ce1654ac5b8033f2daf9270c6e182415b69ca/ghc"]: > {{{ > #!CommitTicketReference repository="ghc" revision="a07ce1654ac5b8033f2daf9270c6e182415b69ca" > Generalise `Control.Monad.{when,unless,guard}` > > Generalise `when`/`unless`from `Monad` to `Applicative` and `guard` from > `MonadPlus` to `Alternative` respectively. > > This was made possible by the AMP and is somewhat related to #9586 > (but generalising in the context of the AMP instead of the FTP) > > Reviewed By: ekmett, austin > > Differential Revision: https://phabricator.haskell.org/D253 > }}} Off-topic for this ticket but why not also generalize `filterM`, `forever`, ..., `replicateM_`? Are there hangups about the letter M in the names of some of these functions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 13:22:12 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 13:22:12 -0000 Subject: [GHC] #9656: Process and thread init/deinit hooks for C libraries In-Reply-To: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> References: <044.b177ccd0bbfb3ee4ab190e66d95fbea0@haskell.org> Message-ID: <059.6552ab310651a64792de3fb09a488d4f@haskell.org> #9656: Process and thread init/deinit hooks for C libraries -------------------------------------+------------------------------------- Reporter: 3noch | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: FFI Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): (Let me know if this discussion has moved elsewhere.) I've wondered about this question, too. I have a multithreaded Haskell program that makes some calls into a JVM. To do this, each OS thread calling into the JVM needs to have some data initialized. While I could do the forkOS approach, I want to have any Haskell thread call into Java, rather than having to send a message to my forkOS'd Haskell thread, wait for it to be scheduled, have it do the call, send a message back, etc. One idea is to have a capability-local data structure, but that doesn't work because multiple OS threads might execute a capability (at different times). So I have to manage the initialization in the C code: whenever the C code is invoked in a given OS thread, the thread checks whether its data structures are initialized. No conclusions here, just wanted to chime with my experience on this topic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 13:39:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 13:39:02 -0000 Subject: [GHC] #8894: Clean up `Coercible` plumbing In-Reply-To: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> References: <046.4ff81593c1e79cd88b8ae53f5e67a33a@haskell.org> Message-ID: <061.af1c04ad856607ebc9a255ce09c47841@haskell.org> #8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8904 Test Case: | Blocking: | Differential Revisions: Phab:D300 | -------------------------------------+------------------------------------- Changes (by nomeata): * differential: => Phab:D300 Comment: I gave it a shot (Phab:D300), but I get {{{ HC [stage 1] utils/dll-split/dist-install/build/tmp/dll-split /home/jojo/build/haskell/ghc-validate/libraries/base/dist-install/build /libHSbase_ESD4aQEEWwsHtYJVc1BwtJ-ghc7.9.20141002.so: undefined reference to `base_DataziCoerce_DZCCoercible_con_info' }}} Is there really a data constructor being generated for an empty class? (Feel free to continue discussing this on Phab:D300). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 14:05:25 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 14:05:25 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.b53250ef027a1be778881cd2b1e15286@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by augustss): Replying to [comment:17 goldfire]: > Unfortunately, this, too, violates the substitution lemma. We probably want to be able to solve `(a ~ a)` with reflexivity, for ''any'' `a`. But, you're suggesting that a particular value for `a`, namely `T Bool`, will ''not'' equal itself. I'm saying it's neither equal to itself, nor unequal to itself. `T Bool` is in some sense ill formed, so asking if it's equal to itself is nonsensical, because it's not a a type. Can you use reflexivity to conclude `Int Bool ~ Int Bool`? No, because it's an ill-formed typed. The case with `T Bool` is not as severely ill form, though. If you want to keep `T Bool` you have to have a different explanation what makes a type. Types a made from `data`, `newtype`, and `type family`. But for `type family` certain of the the types are actually equal to other existing types. But if no equation holds then it's a new (empty) type, distinct from all other types. I can go along with that explanation, but it's not very satisfactory to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 14:07:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 14:07:13 -0000 Subject: [GHC] #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx Message-ID: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I am having problems building yi on 32 bit architectures (i386, hurd-i386, kfreebsd-i386) on Debian: {{{ Loading package parallel-3.2.0.4 ... linking ... done. Loading package reflection-1.2.0.1 ... linking ... done. Loading package split-0.2.2 ... linking ... done. Loading package utf8-string-0.3.7 ... linking ... done. Loading package void-0.6.1 ... linking ... done. Loading package zlib-0.5.4.1 ... linking ... done. Loading package lens-4.1.2.1 ... linking ... done. Loading package parsec-3.1.3 ... linking ... done. Loading package terminfo-0.3.2.5 ... linking ... done. GHCi runtime linker: fatal error: I found a duplicate definition for symbol __x86.get_pc_thunk.bx whilst processing object file /usr/lib/haskell-packages/ghc/lib/i386-freebsd- ghc-7.6.3/vty-5.2.1/libHSvty-5.2.1.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. }}} (Full log at https://buildd.debian.org/status/fetch.php?pkg=yi&arch=kfreebsd-i386&ver=0.7.1-3&stamp=1410882226) It does not happen on amd64. This happens on the Debian auto-builders and I did not reproduce it locally yet, but maybe someone can already tell me what?s wrong from looking at it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 14:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 14:45:32 -0000 Subject: [GHC] #9142: LLVM 3.5.0 rejects aliases used by LLVM codegen In-Reply-To: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> References: <046.897d054798b2596bcd97c79499f7bfeb@haskell.org> Message-ID: <061.d3cb06080586cb65738bd5b2a1dd526e@haskell.org> #9142: LLVM 3.5.0 rejects aliases used by LLVM codegen -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 4213 | Differential Revisions: Phab:D155 | -------------------------------------+------------------------------------- Comment (by bgamari): jrp, I would love to try (and IIRC have successfully done builds of similar scale with this patch in the past) unfortunately the various AMP- related breakage throughout the ecosystem makes doing this quite tricky at the moment. Hopefully in a few weeks this will have cleared up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 15:09:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 15:09:40 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.ad7ddd8f6d9e1efdf23438f72e1d2d4a@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:27 rwbarton]: > Off-topic for this ticket but why not also generalize `filterM`, `forever`, ..., `replicateM_`? Are there hangups about the letter M in the names of some of these functions? `filterM` cannot be generalized to `Traversable` in any sensible way?it needs something stronger. `forever` and `replicateM_` should be easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 15:26:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 15:26:43 -0000 Subject: [GHC] #9658: Prettyprint constraints in type signatures can omit necessary parentheses Message-ID: <051.729c40b7d3b349724f12a1d337527b9b@haskell.org> #9658: Prettyprint constraints in type signatures can omit necessary parentheses -------------------------------------+------------------------------------- Reporter: Blaisorblade | Owner: Type: bug | Status: new Priority: low | Milestone: 7.8.4 Component: GHCi | Version: 7.8.3 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: -------------------------------------+------------------------------------- GHCi prettyprinting can omit parentheses around constraints, even when they are necessary for the signature to be syntactically valid. This breaks the workflow where one uses type inference to generate type annotations to add to the program. Admittedly, this is nitpicking, but it'd be nice to fix. The example I'm running into is the following (in the context of https://github.com/Blaisorblade/learning- syntactic/blob/e198381e07103d436f4ade24f36d344682dbe5b1/src/Syntactic.hs): {{{#!hs num = inj . Num > :t num num :: NUM :<: sup => Int -> sup (Full Int) }}} Adding the type annotation in gives: {{{ src/Syntactic.hs:115:20: parse error on input `=>' }}} To fix the parse error, I need to add parentheses around the constraint: {{{#!hs num :: (NUM :<: sup) => Int -> sup (Full Int) }}} (Here this happens to be the wrong type signature, but that's orthogonal). I imagine that's just because the constraint uses an operator (probably only possible with TypeOperators). This happens whether I explicitly supply the signature or not, and it also happens on GHC 7.6.3. Misc: I selected milestone, difficulty, priority because it's possible and because fixing this sounds easy; sorry if I shouldn't have. I also didn't check whether this affects HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 15:46:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 15:46:37 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.0852389ce66cc4aad6ef5a5262ab9b1e@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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 simonpj): * owner: nomeata => * status: closed => new * resolution: wontfix => Comment: A simple analysis that discovers surely-converging expressions is surely a good thing. I would regret discarding the work you did on that, even if it's not very promising in terms of payoff. Do you have that piece in a branch somewhere? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 15:56:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 15:56:02 -0000 Subject: [GHC] #8655: Evaluate know-to-terminate-soon thunks In-Reply-To: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> References: <046.a721a316fc9137ead5b1c62e57ca37a3@haskell.org> Message-ID: <061.49e2799cb6b06c4fbbf1aedb80286ffd@haskell.org> #8655: Evaluate know-to-terminate-soon thunks -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 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: | -------------------------------------+------------------------------------- Comment (by nomeata): I think the branch [http://git.haskell.org/ghc.git/shortlog/refs/heads/wip /cbv-conv-thunk wip/cbv-conv-thunk] reflected the latest state of my work, which itself is branched off [http://git.haskell.org/ghc.git/shortlog/refs/heads/wip/nested-cpr wip /nested-cpr] (or an older version of that branch ? git isn?t very good in keeping track of the history of branches, unfortuantely). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 18:44:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 18:44:50 -0000 Subject: [GHC] #7984: hsc2hs --cross-compile does not handle negative #enum In-Reply-To: <049.61cc524756b01502c75ea520468c0a78@haskell.org> References: <049.61cc524756b01502c75ea520468c0a78@haskell.org> Message-ID: <064.fa14cc67e1da2b8f098840f0d8f58898@haskell.org> #7984: hsc2hs --cross-compile does not handle negative #enum -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: hsc2hs | Version: 7.6.3 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 singpolyma): * status: new => patch * difficulty: => Unknown Comment: https://phabricator.haskell.org/D301 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 19:07:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 19:07:41 -0000 Subject: [GHC] #7490: ghc-stage1 panic when building a cross-compiler or cross-building a compiler In-Reply-To: <049.8184bf9377eb14f5459700a01fd62871@haskell.org> References: <049.8184bf9377eb14f5459700a01fd62871@haskell.org> Message-ID: <064.6bbbe7b1268a13550c8e1708aa3c66ca@haskell.org> #7490: ghc-stage1 panic when building a cross-compiler or cross-building a compiler -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: worksforme | Keywords: cross-compilation Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 19:57:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 19:57:18 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.c28024a78e05eaba253d803fe4b0a480@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: Reopening due to changeset:d6d5c127b86dc186b25add2843cb83fc12e72a85. David, your `dropWhileEndLE` is not available outside GHC, right? So `GHC.Windows` should not use it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 19:57:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 19:57:32 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.16701c4284f14ee5e97bb91cb96d7fb6@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => dfeuer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 20:08:20 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 20:08:20 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.17d7adb35ef4226ab8de6932c238e66e@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:15 nomeata]: > Reopening due to changeset:d6d5c127b86dc186b25add2843cb83fc12e72a85. David, your `dropWhileEndLE` is not available outside GHC, right? So `GHC.Windows` should not use it? Ay, you're right. That one should just use `Data.List.dropWhileEnd` instead. Now I just have to figure out how to modify the commit (ugh). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 20:08:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 20:08:56 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.a4b3c5eb13aeb6bfaf77687d3f966e7d@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: nomeata => Comment: Given the general doubt about these changes, I?ll unassign this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 20:09:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 20:09:54 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.782755deab5c5deaee6063e2e607f357@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 7.10.1 Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: Runtime | than a day) performance bug | Blocked By: Test Case: | Related Tickets: #8598 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: nomeata => Comment: I think the conclusion was that Nested CPR was not worth it. The branch is still there if someone wants to pick it up. Unassigning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 20:14:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 20:14:19 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.2b37bfc287639f85d95dd2ca844b9060@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"9bf5228fdc1937f44901a945553eea3cb0f14faa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9bf5228fdc1937f44901a945553eea3cb0f14faa" Use dropWhileEndLE p instead of reverse . dropWhile p . reverse Summary: Using `dropWhileEndLE` tends to be faster and easier to read than the `reverse . dropWhile p . reverse` idiom. This also cleans up some other, nearby, messes. Fix #9616 (incorrect number formatting potentially leading to incorrect numbers in output). Test Plan: Run validate Reviewers: thomie, rwbarton, nomeata, austin Reviewed By: nomeata, austin Subscribers: simonmar, ezyang, carter, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D259 GHC Trac Issues: #9623, #9616 Conflicts: compiler/basicTypes/OccName.lhs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 20:14:19 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 20:14:19 -0000 Subject: [GHC] #9616: Incorrect numbers from HpcMarkup.markup_plugin In-Reply-To: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> References: <045.62543f73d6d6d97fee65adbd6d383235@haskell.org> Message-ID: <060.196dfa9365062d8c96d32eafc9863322@haskell.org> #9616: Incorrect numbers from HpcMarkup.markup_plugin -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Code | Version: 7.9 Coverage | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Incorrect | Blocked By: result at runtime | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D259 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"9bf5228fdc1937f44901a945553eea3cb0f14faa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9bf5228fdc1937f44901a945553eea3cb0f14faa" Use dropWhileEndLE p instead of reverse . dropWhile p . reverse Summary: Using `dropWhileEndLE` tends to be faster and easier to read than the `reverse . dropWhile p . reverse` idiom. This also cleans up some other, nearby, messes. Fix #9616 (incorrect number formatting potentially leading to incorrect numbers in output). Test Plan: Run validate Reviewers: thomie, rwbarton, nomeata, austin Reviewed By: nomeata, austin Subscribers: simonmar, ezyang, carter, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D259 GHC Trac Issues: #9623, #9616 Conflicts: compiler/basicTypes/OccName.lhs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 20:14:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 20:14:49 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.ec83aaacb5ea75b05fe5cdd29bdbaf3d@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: I amended the patch for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 21:07:18 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 21:07:18 -0000 Subject: [GHC] #9659: Offer branchless conditional (CMOV) primop Message-ID: <045.89a2b002dcd8e3271d7338218e0f6614@haskell.org> #9659: Offer branchless conditional (CMOV) primop -------------------------------------+------------------------------------- Reporter: dfeuer | 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: -------------------------------------+------------------------------------- I'd like to see something similar to C's `?:`, like {{{#!hs ifInt#, boolInt# :: Int# -> Int# -> Int# -> Int# }}} We could then write things like {{{#!hs ifInt# (x <# y) 12# (x +# 17#) boolInt# potato cannon (y ># 2) }}} When the value of the test is difficult to predict, this would be better than the usual branching `if` or `case`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 21:08:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 21:08:46 -0000 Subject: [GHC] #9659: Offer branchless conditional (CMOV) primop In-Reply-To: <045.89a2b002dcd8e3271d7338218e0f6614@haskell.org> References: <045.89a2b002dcd8e3271d7338218e0f6614@haskell.org> Message-ID: <060.f87f8c59984913f8211f0e83ebe6c436@haskell.org> #9659: Offer branchless conditional (CMOV) primop -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > I'd like to see something similar to C's `?:`, like > > {{{#!hs > ifInt#, boolInt# :: Int# -> Int# -> Int# -> Int# > }}} > > We could then write things like > > {{{#!hs > ifInt# (x <# y) 12# (x +# 17#) > boolInt# potato cannon (y ># 2) > }}} > > When the value of the test is difficult to predict, this would be better > than the usual branching `if` or `case`. New description: I'd like to see something similar to C's `?:`, like {{{#!hs ifI#, boolI# :: Int# -> Int# -> Int# -> Int# }}} We could then write things like {{{#!hs ifI# (x <# y) 12# (x +# 17#) boolI# potato cannon (y ># 2) }}} When the value of the test is difficult to predict, this would be better than the usual branching `if` or `case`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 21:31:26 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 21:31:26 -0000 Subject: [GHC] #6135: Unboxed Booleans In-Reply-To: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> References: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> Message-ID: <058.ec28024e9927adcb096d786a01e48bec@haskell.org> #6135: Unboxed Booleans -------------------------------------+------------------------------------- Reporter: benl | Owner: Type: feature | Status: new request | Milestone: 7.8.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8103, 8103 Type of failure: | Related Tickets: #605 None/Unknown | Test Case: | primops/should_run/T6135 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: jstolarek => * status: closed => new * resolution: fixed => Comment: It appears that this works as intended for `<#`, `>#`, `<=#`, and `>=#`, but not for `==#`. If I write something like {{{#!hs foo x = tagToEnum# ((x <# 3#) `orI#` (x ># 100#) `orI#` (x ==# 12#) `orI#` (x ==# 15#)) }}} I get (in 7.8.3) Core doing something like {{{#!hs foo x = case x of 12# -> True 15# -> True _ -> tagToEnum# ((x <# 3#) `orI#` (x ># 100#)) }}} (with different syntax, or course) and branching assembly to match. If this transformation is important in some other context, it would be great to have something that acts just like `==#` but that doesn't do that, for the times when we actually don't want it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 2 21:39:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Oct 2014 21:39:40 -0000 Subject: [GHC] #8379: sync-all broken when using the GitHub mirror In-Reply-To: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> References: <044.114df031cf2877f0c03690bd4ee1bfc8@haskell.org> Message-ID: <059.81f8ab5a208706b1256735d71510abc5@haskell.org> #8379: sync-all broken when using the GitHub mirror -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8667 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jyrinx): * status: closed => new * resolution: fixed => Comment: As far as I can tell, the `-r` option isn't working: {{{ $ ./sync-all -r git://github.com/ghc get == running git config core.ignorecase true == running git submodule init == running git submodule update Cloning into 'libffi-tarballs'... Username for 'https://github.com': lukemaurer Password for 'https://lukemaurer at github.com': remote: Repository not found. fatal: repository 'https://github.com/lukemaurer/libffi-tarballs.git/' not found Clone of 'https://github.com/lukemaurer/libffi-tarballs.git' into submodule path 'libffi-tarballs' failed git failed: 256 at ./sync-all line 112. == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tarball == Checking for obsolete Git repository URL }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 00:26:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 00:26:07 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.1061c260eca0eccea2309ff60eb4e990@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:28 dfeuer]: > Replying to [comment:27 rwbarton]: > > Off-topic for this ticket but why not also generalize `filterM`, `forever`, ..., `replicateM_`? Are there hangups about the letter M in the names of some of these functions? > > `filterM` cannot be generalized to `Traversable` in any sensible way?it needs something stronger. `forever` and `replicateM_` should be easy. I mean generalize from Monad to Applicative, not from [] to Traversable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 01:13:07 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 01:13:07 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.6ed0cae19dbda98803b6c5e2a582a284@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 03:08:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 03:08:12 -0000 Subject: [GHC] #9660: unnecessary indirect jump when returning a case scrutinee Message-ID: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> #9660: unnecessary indirect jump when returning a case scrutinee -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I happened to be looking at the Cmm for this code (ghc 7.8.3, -O2) {{{#!hs f :: Int -> Int f x = if x < 0 then x else x+1 }}} and I noticed something a bit funny about it: {{{ c12e: if ((Sp + -8) < SpLim) goto c12z; else goto c12A; c12z: R2 = R2; R1 = Test.f_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; c12A: I64[Sp - 8] = c12b; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c12b; else goto c12c; c12c: call (I64[R1])(R1) returns to c12b, args: 8, res: 8, upd: 8; c12b: Hp = Hp + 16; if (Hp > HpLim) goto c12y; else goto c12x; c12y: HpAlloc = 16; R1 = R1; call stg_gc_unpt_r1(R1) returns to c12b, args: 8, res: 8, upd: 8; c12x: _s11Q::I64 = I64[R1 + 7]; if (%MO_S_Lt_W64(_s11Q::I64, 0)) goto c12u; else goto c12v; c12u: Hp = Hp - 16; R1 = R1 & (-8); /* <--- */ Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; /* <--- */ c12v: I64[Hp - 8] = GHC.Types.I#_con_info; I64[Hp] = _s11Q::I64 + 1; R1 = Hp - 7; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; }}} On the two marked lines, we untag R1 (which is `x`) and enter it. However, we know at this point that `x` is already in WHNF so we could simply return it by replacing the two lines with `call (P64[Sp])(R1)`, if I'm not mistaken. That will save a load and an indirect jump (which we actually know is to `I#_con_info`, which would just retag R1 and return to the address on the stack anyways). I think the same optimization should be available any time we do an algebraic `case` and in a branch simply return the scrutinee. I looked at what it would take to fix this. It looks almost easy: if we add a new `LambdaFormInfo` constructor `LFUnknownCon` meaning that we know the identifier is bound to a saturated application of an unknown constructor, then we could set the `cg_lf` of the case binder variable of an algebraic case statement to `LFUnknownCon`, and return `ReturnIt` for `LFUnknownCon` variables in `getCallMethod`. I think that would do it. Does that sound right? Is there a better way? (In my original example we actually know the constructor has to be `I#`. But if the case was on a type with more than one constructor we wouldn't know statically which one we got, just that it has to be one of them.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 03:31:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 03:31:40 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.b52d710babee33c27b80e2b821e846a6@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by ip1981): Patch for GHC: https://github.com/ip1981/ghc/commit/836b7623ca70231fafc49838adc2f884c9e662c8 (also attached) Patch for unix module: https://github.com/haskell/unix/pull/8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 03:32:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 03:32:57 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.920dbd9858c9454b430c7367c94b4dc3@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Replying to [comment:40]: > Maybe I should try installing statically linked ghc and see if that makes difference. Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build fails already in the build phase: {{{ : cat utils/hpc/hpc.wrapper >> inplace/bin/hpc chmod +x inplace/bin/hpc Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream compiler/ghc.mk:640: recipe for target 'compiler/stage2/dll-split.stamp' failed make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:64: recipe for target 'all' failed make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 06:21:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 06:21:28 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code Message-ID: <045.71f979b880084609920e19d23d40fbfe@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This started as a comment on #6135, but Jan Stolarek requested that I file a separate report. The branchless tests `<#`, `>#`, `<=#`, and `>=#`, and their wordy cousins, seem to work properly, but `==#` and `eqWord#` don't. If I write {{{#!hs foo x = tagToEnum# ((x <# 3#) `orI#` (x ># 100#) `orI#` (x ==# 12#) `orI#` (x ==# 15#)) }}} I get (in 7.8.3 and in 7.9) {{{#!hs IsDigit.foo :: GHC.Prim.Int# -> GHC.Types.Bool [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType , Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (x3_a2if [Occ=Once!] :: GHC.Prim.Int#) -> case x3_a2if of wild_Xe { __DEFAULT -> GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.orI# (GHC.Prim.<# wild_Xe 3) (GHC.Prim.># wild_Xe 100)); 12 -> GHC.Types.True; 15 -> GHC.Types.True }}] IsDigit.foo = \ (x3_a2if :: GHC.Prim.Int#) -> case x3_a2if of wild_Xe { __DEFAULT -> GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.orI# (GHC.Prim.<# wild_Xe 3) (GHC.Prim.># wild_Xe 100)); 12 -> GHC.Types.True; 15 -> GHC.Types.True }}} and branching assembly to match. Jan Stolarek indicates this is probably a problem with constant folding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 06:23:36 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 06:23:36 -0000 Subject: [GHC] #6135: Unboxed Booleans In-Reply-To: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> References: <043.cd549fe6606c2420e878b67f7f91b738@haskell.org> Message-ID: <058.7e312f221fe16f38b69195635cc7e015@haskell.org> #6135: Unboxed Booleans -------------------------------------+------------------------------------- Reporter: benl | Owner: Type: feature | Status: closed request | Milestone: 7.8.1 Priority: normal | Version: 7.4.1 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 8103, 8103 Type of failure: | Related Tickets: #605 None/Unknown | Test Case: | primops/should_run/T6135 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed Comment: Per jstolarek's request, opening a separate ticket for `==#`, #9661 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 08:15:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 08:15:10 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.dd70c1d3609820b62d3cda32f6a522c3@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): After some thinking I don't think it's constant folding but more generally the special rules for `==#`. As promised here are some hints how to get started on this one: 1. Try to reproduce the problem with a simpler example, eg. using only two comparison primops and `orI#`. Try out different combinations of comparison primops. See also whether this happens for `andI#`. We want to be sure that this only depends on presence of `==#` and not other operators (don't forget `/=#`). 2. Once you have a smaller test case follow the transformation that GHC is performing to arrive at the result. Is it turning the simpler test case into the final result in one step or are there any intermediate steps? 3. My guess would be that the culprit is `litEq` function in `PrelRules.lhs` module. The comment above it claims to do exactly what you've reported here. However, I'm not sure what the fix should be. Disabling this is probably not a good idea, since in some cases we really want that transformation to happen. We'd need to think more but first let's confirm whether `litEq` is the cause or not. You can verify that by disabling that rule and seeing whether the code compiles without branches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 08:39:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 08:39:52 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.ce7fc14a3f06623c025695fb7ec8bed8@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:19 nomeata]: > I amended the patch for you. Something seems wrong. The patch you linked to still isn't right for Windows, and people way above my pay grade continue to complain on Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 09:51:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 09:51:40 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.b596bcf74050c542bbd82da3d7f8640a@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 jstolarek]: > After some thinking I don't think it's constant folding but more generally the special rules for `==#`. As promised here are some hints how to get started on this one: > > 1. Try to reproduce the problem with a simpler example, eg. using only two comparison primops and `orI#`. Try out different combinations of comparison primops. See also whether this happens for `andI#`. We want to be sure that this only depends on presence of `==#` and not other operators (don't forget `/=#`). This happens with both `==#` and `/=#`. It does not appear to happen with the others. Furthermore, it appears to happen only when one of the arguments is known at compile time. > 2. Once you have a smaller test case follow the transformation that GHC is performing to arrive at the result. Is it turning the simpler test case into the final result in one step or are there any intermediate steps? There are intermediate steps, but it starts very early. For example, {{{#!hs --Desugar equals0AndEquals2 equals0AndEquals2 = \ x_a1wL y_a1wM -> andI# (==# x_a1wL 0) (==# y_a1wM 2) == Gentle simplification ==> equals0AndEquals2 equals0AndEquals2 = \ x_a1wL y_a1wM -> andI# (case x_a1wL of _ { __DEFAULT -> 0; 0 -> 1 }) (case y_a1wM of _ { __DEFAULT -> 0; 2 -> 1 }) -- Nothing changes for a bit .... == Simplifier phase 2 ==> equals0AndEquals2 equals0AndEquals2 = \ x_a1wL y_a1wM -> case x_a1wL of _ { __DEFAULT -> 0; 0 -> case y_a1wM of _ { __DEFAULT -> 0; 2 -> 1 } } > 3. My guess would be that the culprit is `litEq` function in `PrelRules.lhs` module. The comment above it claims to do exactly what you've reported here. However, I'm not sure what the fix should be. Disabling this is probably not a good idea, since in some cases we really want that transformation to happen. We'd need to think more but first let's confirm whether `litEq` is the cause or not. You can verify that by disabling that rule and seeing whether the code compiles without branches. I'm confident you're right, but I won't have time to do that experiment until after Yom Kippur. The comment says {{{ -- This is a Good Thing, because it allows case-of case things -- to happen, and case-default absorption to happen. For -- example: -- -- if (n ==# 3#) || (n ==# 4#) then e1 else e2 -- will transform to -- case n of -- 3# -> e1 -- 4# -> e1 -- m -> e2 }}} There are a couple `tagToEnum#` invocations missing there, but let's look at the whole process. We're presumably starting with {{{#!hs if (n == 3) || (n == 4) then e1 else e2 }}} Expanding `if`, {{{#!hs case (n == 3) || (n == 4) of True -> e1 False -> e2 }}} Expanding `(||)`, {{{#!hs case (case n == 3 of {True -> True; False -> n == 4}) of True -> e1 False -> e2 }}} Case of case gets us {{{#!hs case n == 3 of True -> case True of {True -> e1; False -> e2} False -> case n == 4 of {True -> e1; False -> e2} }}} Case of known constructor or whatever it's called produces {{{#!hs case n == 3 of True -> e1 False -> case n == 4 of True -> e1 False -> e2 }}} So we can get this far without knowing anything about what `(==)` means. Now let's add part of that knowledge: {{{#!hs case n# ==# 3# of 1# -> e1 0# -> case n# ==# 4# of 1# -> e1 0# -> e2 }}} In this case, this is probably just fine, but I imagine the example is intended to suggest that there are (perhaps many) more tests, so that a different pattern matching strategy may be in order. I would venture to guess that what we want to do is attack it at this stage?recognizing that we're looking at nested case of `==#` with a shared operand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 10:33:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 10:33:48 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.0b1f56231ef05cb4798553593cdb893b@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:2 dfeuer]: > Furthermore, it appears to happen only when one of the arguments is known at compile time. That seems right. In `litEq` (literal equality) you'll see that we expect one of the arguments to be a literal. Also, `litEq` works for both equality and inequality tests. > There are a couple `tagToEnum#` invocations missing there The comment was written for the old primops and should have been updated when the new ones were introduced. This rule is intended for primops, not `(==)`. > but let's look at the whole process. > (...) I think the order of inlining should be different here: first calls to `==#`, then a call to `orI#` (at least that's what the Core you pasted suggests). This won't change the final result but it may be important for devising a solution. > So we can get this far without knowing anything about what (==) means. Now let's add part of that knowledge: > > {{{#!hs > case n# ==# 3# of > 1# -> e1 > 0# -> case n# ==# 4# of > 1# -> e1 > 0# -> e2 > }}} When you rewrite the transformation to work on the `==#` primop this should be the result that you get, but I don't think that you can get such transformation by just inlining definition of `(==)`. The problem is that calls to `tagToEnum#` are not currently optimized away in Core (#8317). This stage should be followed by case merging to get the final result shown in the comment. After writing all this I really wonder what will happen when we disable `litEq`. It might not be as bad as I initially thought. After all, with these new primops we don't want branches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 11:40:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 11:40:40 -0000 Subject: [GHC] #9662: stack overflow in type checker Message-ID: <046.dd8b7f2f1cb39f3fdbde8cd7b54fa2d7@haskell.org> #9662: stack overflow in type checker -------------------------------------+------------------------------------- Reporter: Lemming | 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: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The attached program causes a stack overflow when loading into ghci-7.8.3 or ghci-7.9.20140929: {{{ $ ghci-7.8.3 -Wall BackpermuteTypeLoop.hs GHCi, version 7.8.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. [1 of 1] Compiling BackpermuteTypeLoop ( BackpermuteTypeLoop.hs, interpreted ) *** Exception: stack overflow }}} I have no idea, what's going on. The problem may be even not critical, because the program is not type-correct anyway. If you replace the `id` argument by the out-commented `modify` argument, you will get a nice type error message. The problem arised when using the Accelerate framework and it involves the `modify` function which helps tupling function arguments and untupling function results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 14:56:04 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 14:56:04 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.cee083dc4afb299e384d73d0493fb68f@haskell.org> #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: | -------------------------------------+------------------------------------- Comment (by simonpj): Goals: * Save a few characters: say `deriving( C )` rather than `deriving instance C a => C (T a)` * Make it possible for a library author to make a class `C` which can be used in `..deriving( C )` just like built-in classes. * Ultimately: remove the built-in code for deriving `Eq`, `Ord` etc with generic code. Concerns * Conflict between this feature and GND for newtypes. * Current proposal is that this new feature is not available for `newtype`s. * An alternative: a declared property of the class says "do not use GND" in `deriving` clauses. (Examples: `Show`, `Read`, and one or two others.) Maybe we don't even need to make this user-controllable; a handful of built-in classes may suffice. * Another alternative: fail if there ambiguity. * Richard wants it to be a property of the class ''and'' over-rideable at the `deriving` site. * For a top-level instance `instance C a => C (T a)`, this is always an empty instance, filled in by generic defaults if they exist. But what about `deriving instance C a => C (T a)`. Does that mean precisely the same thing? * If you say `data T a = ... deriving( C )`, and change to `data T a = ...; deriving instance C a => C (T a)`, does that make a difference? * Possible principle. Use per-class control for `newtype ... deriving( C )` situation, but per-instance control for `deriving instance` and `instance` declarations. Another question: * Just having one generic default method may not be enough. Maybe two are needed to give a well-founded instance. * Better: class author writes an explicit `MINIMAL` pragma with an empty minimal set. That says, fully explicitly, that the class author is happy with instances that have no explicit methods. * I think we converged on the latter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 15:41:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 15:41:14 -0000 Subject: [GHC] #9660: unnecessary indirect jump when returning a case scrutinee In-Reply-To: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> References: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> Message-ID: <062.0a84d621bfef38d7ff34c53285c69cdd@haskell.org> #9660: unnecessary indirect jump when returning a case scrutinee -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 15:59:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 15:59:55 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.73c5edcc85fad67ed77ef67ec6181346@haskell.org> #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: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:34 simonpj]: > * Make it possible for a library author to make a class `C` which can be used in `..deriving( C )` just like built-in classes. > * Ultimately: remove the built-in code for deriving `Eq`, `Ord` etc with generic code. IMHO the value of theses two goals should not be underestimated, as this feature would allow for custom Prelude to provide (for instance) custom `Eq`/`Ord` instances different from the default ones generated by GHC while allowing to use automatic derivation as if they were built-ins (which I don't think `RebindableSyntax` already allows at this point). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 16:10:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 16:10:30 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.729caf0b60a15310b0f08af0d2c0f66a@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Even with changeset:eb3533997e33602007a1a1a760a72bfcb4fba3ee/ghc it?s still broken? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 16:34:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 16:34:19 -0000 Subject: [GHC] #9623: Use Data.List.dropWhileEnd In-Reply-To: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> References: <045.7e48c974cbe610bb3de5fe953a49f42c@haskell.org> Message-ID: <060.71c7f0b148368753f370c7be58699e57@haskell.org> #9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.8.3 (other) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Sorry, I think probably some people hadn't pulled that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 17:48:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 17:48:37 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.10c8722371ff194960605e04310c4168@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 jstolarek]: > When you rewrite the transformation to work on the `==#` primop this should be the result that you get, but I don't think that you can get such transformation by just inlining definition of `(==)`. The problem is that calls to `tagToEnum#` are not currently optimized away in Core (#8317). I doubt this is going to make much of a difference in most cases, but we'll have to see (I can probably look into it tomorrow night). My overriding philosophy is that band-aids are bad, and band-aids that complicate other things are very bad. If `litEq` is currently serving primarily as a band-aid for #8317, I think we should rip it off and wait for a proper fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 17:59:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 17:59:27 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.77123e834eea3e654b850ef65fb8888a@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: monoidal Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D233 | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"e4a597f2f527ba0cd15cb51dda15cb51871c984e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e4a597f2f527ba0cd15cb51dda15cb51871c984e" Revert "Basic Python 3 support for testsuite driver (Trac #9184)" This reverts commit 084d241b316bfa12e41fc34cae993ca276bf0730. This is a possible culprit of Windows breakage reported at ghc-devs. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 18:48:31 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 18:48:31 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.fecb2cd2f7e621759ab0db0e12448eea@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D233 | -------------------------------------+------------------------------------- Changes (by monoidal): * owner: monoidal => * status: closed => new * resolution: fixed => Comment: I reverted this, since it's likely to have broken the Windows build. I will investigate, but it might take some time since I don't have a Windows build set up. I suspect this is caused by the change to `findTFiles`, which previously joined paths with '/', while I changed it to `os.walk` + `os.path.join`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 18:59:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 18:59:39 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.0167e4bc4d958203a4b37d3bc7dff13a@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): No, I think that `litEq` rule is independent from #8317. Band-aid for `tagToEnum#` is somewhere else, so this ticket should be fixed independently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 20:04:19 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 20:04:19 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.16d3721e027070db9d097e4c3dc1efc2@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I hope that works. As a side note, we consider redefining `not` as `not x = dataToTag# (x /=# 1#)`, which should work better for branchless stuff and I ''think'' should work exactly the same for branchy stuff. That'll be one less thing I need to add to a branchless `Bool` module. I already need `complementBL x = tagToEnum# (dataToTag# `xorI#` 1#)` to play as nicely as possible with `&&!` and `||!`, I think; I'd rather not have to add `notBL` if that can replace `not` without any negative consequences. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 21:14:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 21:14:51 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.ddb0080676ebd5206a3e2f2e1d91a7bb@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * type: bug => feature request Comment: I think GHC is doing the right thing here, or at least not the wrong thing. It's wrong to think of `(==#)` as "branchless equality". It's just a function whose value is `1#` if its arguments are equal, and `0#` if they aren't. This fact needs to be visible to GHC in order to optimize code like {{{#!hs f :: Int -> (Int,Int) f x = if x == 0 -- defined in terms of ==# then (x', 1) -- here GHC can inline and then constant-fold x' to 257 else (x-1, x') where x' = 1000 * x + 257 }}} and this is the purpose of the `litEq` rule. As a result, GHC may not output assembly containing the number of branches that you intended. This is the normal function of an optimizing compiler; if GHC was not free to replace your program with an equivalent one, then users would be forced to perform all kinds of optimizations by hand to get efficient code. I would note that this behavior is not specific to GHC. If you compile this C program with gcc (Debian 4.9.1-14) at optimization level `-O1` or higher {{{#!c void g(); void h(); void f(int x) { if ((x == 0) OR (x == 5)) g(); else h(); } }}} you will get identical assembly output (with two branches, not an `or` instruction) whether you set `-DOR=|` or `-DOR=||`. So C does not give you control over branchlessness either. I understand that depending on the characteristics of the input, the "branchless" code may be faster (e.g. for the C function above, `x` randomly drawn from the set 0 (49%), 5 (49%), 10 (2%)). However, with certain other distributions of the input value, the "branchy" version is likely to be faster. So there is no right or wrong answer here. In general it takes a lot of engineering effort to get a compiler to reliably produce two different optimized outputs for two different programs that it can see are semantically identical. In this case maybe there is an easy solution: add a new `secretlyEquality#` which is the same as `(==#)`, but where that fact is hidden from GHC for long enough for `secretlyEquality#` to survive the stages that transform `(==#)` unscathed. This approach is intrinsically somewhat fragile (for example, the LLVM backend may introduce additional branches anyways), but it has the merit of ease of implementation. In any case, I would like to see some benchmarks showing that there are performance gains to be had in real programs from control over branchlessness before expending any effort on implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 21:18:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 21:18:00 -0000 Subject: [GHC] #9663: Windows build process should give better message if you forgot to clone tarballs Message-ID: <045.1da0869ddf56108fdfa02fd69e07ae82@haskell.org> #9663: Windows build process should give better message if you forgot to clone tarballs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you forget to clone ghc-tarballs into the directory when building on Windows, configure will report that it can't find a working C compiler. It would be nice if there was a better error message here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 22:20:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 22:20:25 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.95825bffa6b7929d257665891e8fa097@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:7 rwbarton]: > I think GHC is doing the right thing here, or at least not the wrong thing. > > It's wrong to think of `(==#)` as "branchless equality". It's just a function whose value is `1#` if its arguments are equal, and `0#` if they aren't. This fact needs to be visible to GHC in order to optimize code like ... > and this is the purpose of the `litEq` rule. I wonder if there's another way to accomplish that, but see below. > As a result, GHC may not output assembly containing the number of branches that you intended. This is the normal function of an optimizing compiler; if GHC was not free to replace your program with an equivalent one, then users would be forced to perform all kinds of optimizations by hand to get efficient code. With the exception of some bottom-of-the-stack `base` code with module dependency nightmares, people who use such primops are usually trying to do something specific for performance reasons, and we should be careful not to interfere excessively if we can avoid doing so. Your preferred `==#` can be implemented in terms of mine, I believe, like this: {{{#!hs bartonEq x y = case feuerEq x y of 1# -> 1# _ -> 0# }}} Going the other way around, however, is impossible. If you prefer, we can give `feuerEq` a different name so current code will continue to work the same. > I understand that depending on the characteristics of the input, the "branchless" code may be faster (e.g. for the C function above, `x` randomly drawn from the set 0 (49%), 5 (49%), 10 (2%)). However, with certain other distributions of the input value, the "branchy" version is likely to be faster. So there is no right or wrong answer here. Of course. > In any case, I would like to see some benchmarks showing that there are performance gains to be had in real programs from control over branchlessness before expending any effort on implementation. That ship has long since sailed?the massive breaking primBool change was undertaken specifically to support this sort of thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 22:30:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 22:30:22 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.3ee21853a28e3547746a1761aa4d4029@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:8 dfeuer]: > With the exception of some bottom-of-the-stack `base` code with module dependency nightmares, people who use such primops are usually trying to do something specific for performance reasons, and we should be careful not to interfere excessively if we can avoid doing so. Everyone who uses `==` on `Int` is using `==#`, that was the point of my Haskell `f` example above. Let's not lose track of the big picture here. > Your preferred `==#` can be implemented in terms of mine, I believe, like this: > > {{{#!hs > bartonEq x y = case feuerEq x y of > 1# -> 1# > _ -> 0# > }}} > > Going the other way around, however, is impossible. If you prefer, we can give `feuerEq` a different name so current code will continue to work the same. I don't understand what `bartonEq` or `feuerEq` is or what the difference between them is supposed to be. They look equal to me. > > In any case, I would like to see some benchmarks showing that there are performance gains to be had in real programs from control over branchlessness before expending any effort on implementation. > > That ship has long since sailed?the massive breaking primBool change was undertaken specifically to support this sort of thing. No, it was undertaken to allow GHC to find better code to generate under some circumstances. It was not undertaken to give the user control over whether GHC produces branchless code or branching code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 22:44:10 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 22:44:10 -0000 Subject: [GHC] #9660: unnecessary indirect jump when returning a case scrutinee In-Reply-To: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> References: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> Message-ID: <062.061f899f4a419c98261e319226d3582f@haskell.org> #9660: unnecessary indirect jump when returning a case scrutinee -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: dfeuer (removed) Comment: In fact it doesn't seem strictly necessary to add a new constructor to LambdaFormInfo... this proof-of-concept patch validates and produces the expected improved Cmm; nofib coming next... {{{ diff --git a/compiler/codeGen/StgCmmClosure.hs b/compiler/codeGen/StgCmmClosure.hs index b65d56b..df0f6be 100644 --- a/compiler/codeGen/StgCmmClosure.hs +++ b/compiler/codeGen/StgCmmClosure.hs @@ -22,7 +22,7 @@ module StgCmmClosure ( LambdaFormInfo, -- Abstract StandardFormInfo, -- ...ditto... mkLFThunk, mkLFReEntrant, mkConLFInfo, mkSelectorLFInfo, - mkApLFInfo, mkLFImported, mkLFArgument, mkLFLetNoEscape, + mkApLFInfo, mkLFImported, mkLFArgument, mkLFLetNoEscape, mkLFUnknownCon, lfDynTag, maybeIsLFCon, isLFThunk, isLFReEntrant, lfUpdatable, @@ -241,6 +241,9 @@ mkLFThunk thunk_ty top fvs upd_flag NonStandardThunk (might_be_a_function thunk_ty) +mkLFUnknownCon :: LambdaFormInfo +mkLFUnknownCon = LFCon $ error "tried to access constructor of case binder at compile time" + -------------- might_be_a_function :: Type -> Bool -- Return False only if we are *sure* it's a data type diff --git a/compiler/codeGen/StgCmmExpr.hs b/compiler/codeGen/StgCmmExpr.hs index b2b64f8..6b6ffef 100644 --- a/compiler/codeGen/StgCmmExpr.hs +++ b/compiler/codeGen/StgCmmExpr.hs @@ -441,7 +441,11 @@ cgCase scrut bndr alt_type alts ; let sequel = AssignTo alt_regs do_gc{- Note [scrut sequel] -} ; ret_kind <- withSequel sequel (cgExpr scrut) ; restoreCurrentCostCentre mb_cc - ; _ <- bindArgsToRegs ret_bndrs + ; case alt_type of + AlgAlt _ -> case ret_bndrs of + [ret_bndr] -> void $ bindToReg ret_bndr mkLFUnknownCon + _ -> error "wat" + _ -> void $ bindArgsToRegs ret_bndrs ; cgAlts (gc_plan,ret_kind) (NonVoid bndr) alt_type alts } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 3 22:44:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Oct 2014 22:44:51 -0000 Subject: [GHC] #9660: unnecessary indirect jump when returning a case scrutinee In-Reply-To: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> References: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> Message-ID: <062.d84ed243c01aeab7f6eca3f00f1107f7@haskell.org> #9660: unnecessary indirect jump when returning a case scrutinee -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: dfeuer (added) Comment: (Oops, edit conflict...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 05:36:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 05:36:40 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.eb4ecc8936e1b29e855d61662108c705@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:9 rwbarton]: > It was not undertaken to give the user control over whether GHC produces branchless code or branching code. Yes, it was undertaken exactly for that reason! Read the original report for #6135 and PrimBool wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 06:49:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 06:49:03 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.834c809ffb260ab6bbf6e93045afefe7@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): This looks sensible to me based on a quick sanity check and smoke test, but I don't have a good sense of how to test it for correctness robustly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 07:59:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 07:59:47 -0000 Subject: [GHC] #9664: Add identity functor to base Message-ID: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `base` already provides a `Const`ant functor, but the even more useful `Id`entity (or `Identity`) functor does not exist in `base` yet. This was already [https://groups.google.com/forum/#!msg/haskell-core- libraries/_nReDCbROew/Mdmf0zIloysJ proposed to the CLC back in early 2013], and already missed inclusion in GHC 7.8 However, in order to implement this, coordination with `transformers` is desirable, as `transformers` currently provides a non-transforming `Data.Functor.Identity`, and we'd like to avoid name clashes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 09:10:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 09:10:58 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.cd45e4e4a041099459ed4bb2851f23f1@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): Looks like dll-split fails on ghci-less build on almost everything #9552. I propose to disable fatal error there in disabled ghci case (I'll try to come with a patch this weelend for it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 12:34:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 12:34:59 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.6266d3fe85fa418333460a8d7a91b118@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ross): I suggest doing a major release of transformers at the same time as the next major GHC release, with Data.Functor.Identity removed and added to base. This version would depend on the new version of base to force an upgrade. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 18:08:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 18:08:18 -0000 Subject: [GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide Message-ID: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> #9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: task | Status: new Priority: high | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- If one wants to support older versions of GHC, it is hard to find out whether one can use a certain LANGUAGE extension. One has to go to older versions of the GHC manual to find out whether the corresponding documentation was already there, or browse release notes. Requests: 1. Document for new LANGUAGE extensions that they are available since version 7.10. For example, by adding "(Since GHC 7.10)" to the heading of the new feature. 2. Do this also for the previous LANGUAGE extensions, by adding e.g., "(Since GHC 7.6)" etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 18:51:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 18:51:39 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.3ef8bf28a3a0b312a46ba0d4d6deff37@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D310 | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => patch * differential: Phab:D233 => Phab:D310 Comment: `findTFiles` was indeed the reason for the build failure, resubmitting for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 20:15:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 20:15:11 -0000 Subject: [GHC] #9666: runtime crashing with +RTS -w -h Message-ID: <048.a72435c7d7e08f5f9304d55291b7fcca@haskell.org> #9666: runtime crashing with +RTS -w -h -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime Difficulty: Unknown | crash Blocked By: | Test Case: (see Related Tickets: | description) | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- A combination of the RTS flags -w and -h makes executables generated with ghc crash at runtime. Does not happen always; my current guess is that a gc run triggers the bug. Reproducible with the following input: '''Main.hs''' {{{#!hs module Main where import qualified Data.Map.Strict as M main = print $ M.lookup 10 $ M.fromList [ (i,i) | i<-[1..10000000] ] }}} {{{ > ghc -rtsopts Main.hs && ./Main +RTS -w -h [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... Main: internal error: heapCensus, unknown object: 4093 (GHC version 7.8.3 for x86_64_unknown_linux) }}} optimization level did not change the outcome. I am aware that -w is marked experimental, and I don't need it. Just noticed the crashing. @simon: you get added to Cc (one more time) every time I press "preview", it seems. Doubt that is intentional.. I'll leave you in Cc just so you get this message. (hmm.. where is the bug-tracker bug-tracker..) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 20:29:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 20:29:23 -0000 Subject: [GHC] #7780: GHC HEAD dll fails to build on Windows In-Reply-To: <047.7e5ddf4ebd5ce7d534b18129d5da342a@haskell.org> References: <047.7e5ddf4ebd5ce7d534b18129d5da342a@haskell.org> Message-ID: <062.183cfa9521fb09910eebc759f92aaf31@haskell.org> #7780: GHC HEAD dll fails to build on Windows ----------------------------------------+---------------------------------- Reporter: rassilon | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"2a8ea4745d6ff79d6ce17961a64d9013243fc3c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a8ea4745d6ff79d6ce17961a64d9013243fc3c6" ghc.mk: fix list for dll-split on GHCi-less builds To reproduce build failure it's enough to try to build GHC on amd64 with the following setup: $ cat mk/build.mk # for #9552 GhcWithInterpreter = NO It gives: Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Bitmap BlockId ... dll-split among other things makes sure all mentioned modules are used by DynFlags. '#ifdef GHCI' keeps is from happening. Patch moves those 42 modules under 'GhcWithInterpreter' guard. Fixes Issue #9552 Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 20:29:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 20:29:23 -0000 Subject: [GHC] #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date In-Reply-To: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> References: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> Message-ID: <062.f0e607eea05855f3b31554ac6f19ea5f@haskell.org> #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date ----------------------------------------------+--------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Comment (by Sergei Trofimovich ): In [changeset:"2a8ea4745d6ff79d6ce17961a64d9013243fc3c6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a8ea4745d6ff79d6ce17961a64d9013243fc3c6" ghc.mk: fix list for dll-split on GHCi-less builds To reproduce build failure it's enough to try to build GHC on amd64 with the following setup: $ cat mk/build.mk # for #9552 GhcWithInterpreter = NO It gives: Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Bitmap BlockId ... dll-split among other things makes sure all mentioned modules are used by DynFlags. '#ifdef GHCI' keeps is from happening. Patch moves those 42 modules under 'GhcWithInterpreter' guard. Fixes Issue #9552 Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 20:33:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 20:33:40 -0000 Subject: [GHC] #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date In-Reply-To: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> References: <047.a5a0d83a85e9f507ac92882847117a99@haskell.org> Message-ID: <062.188f96a4ac61f0c602600e155e40a218@haskell.org> #9552: powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Building | Difficulty: Unknown GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => closed * resolution: => fixed * architecture: Other => Unknown/Multiple * milestone: => 7.10.1 Comment: I've moved all ghci-related modules under 'ifeq(ghci)' in makefile. I think it will help you as I've got exactly the same list on GHCI-less amd64. Please reopen if it still fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 20:38:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 20:38:12 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.d1855673e2a721df058d336d4e6b9a18@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:42 juhpetersen]: > Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build fails already in the build phase: > > Redundant modules: Bitmap BlockId ... With #9552 being hopefully fixed as https://git.haskell.org/ghc.git/commitdiff/2a8ea4745d6ff79d6ce17961a64d9013243fc3c6 you should pass that stage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 4 23:41:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Oct 2014 23:41:29 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.bb12dd17e8aaa8881ae6e9f32ca06e05@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Changes (by mgmeier): * status: new => patch * differential: => Phab:D311 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 00:44:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 00:44:34 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family Message-ID: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm marking this as a Feature request rather than a bug (though it was unexpected behavior for me!) In my code base i had the following types {{{#!hs data Prod = Pair Prod Prod | Unit data VProd (vect :: * -> * ) (prd:: Prod ) val where VLeaf :: !(v a) -> VProd v Unit a VPair :: !(VProd v pra a) -> !(VProd v prb b ) ->VProd v (Pair pra prb) (a,b) data MVProd (vect :: * -> * -> * ) (prd:: Prod ) (st :: * ) val where MVLeaf :: !(mv st a) -> MVProd mv Unit st a MVPair :: !(MVProd mv pra st a) -> !(MVProd mv prb st b ) -> MVProd mv (Pair pra prb) st (a,b) }}} which are meant as a way of modeling vectors of tuples as tuples (err trees) of vectors however, sometimes type inference would fail in explosive ways like {{{ *Numerical.Data.Vector.Pair Data.Vector VG> (VPair (VLeaf (va :: Vector Int)) (VLeaf (vb:: Vector Int))) <- return $ VG.fromList [(1::Int,2::Int),(3,5)] :: (VProd Vector (Pair Unit Unit) (Int,Int)) :24:16: Could not deduce (a ~ Int) from the context (t1 ~ 'Pair pra prb, t2 ~ (a, b)) bound by a pattern with constructor VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: Prod) b. VProd v pra a -> VProd v prb b -> VProd v ('Pair pra prb) (a, b), in a pattern binding in interactive GHCi command at :24:2-59 or from (pra ~ 'Unit) bound by a pattern with constructor VLeaf :: forall (v :: * -> *) a. v a -> VProd v 'Unit a, in a pattern binding in interactive GHCi command at :24:9-32 ?a? is a rigid type variable bound by a pattern with constructor VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: Prod) b. VProd v pra a -> VProd v prb b -> VProd v ('Pair pra prb) (a, b), in a pattern binding in interactive GHCi command at :24:2 Expected type: t0 a Actual type: Vector Int In the pattern: va :: Vector Int In the pattern: VLeaf (va :: Vector Int) In the pattern: VPair (VLeaf (va :: Vector Int)) (VLeaf (vb :: Vector Int)) :24:43: Could not deduce (b ~ Int) from the context (t1 ~ 'Pair pra prb, t2 ~ (a, b)) bound by a pattern with constructor VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: Prod) b. VProd v pra a -> VProd v prb b -> VProd v ('Pair pra prb) (a, b), in a pattern binding in interactive GHCi command at :24:2-59 or from (pra ~ 'Unit) bound by a pattern with constructor VLeaf :: forall (v :: * -> *) a. v a -> VProd v 'Unit a, in a pattern binding in interactive GHCi command at :24:9-32 or from (prb ~ 'Unit) bound by a pattern with constructor VLeaf :: forall (v :: * -> *) a. v a -> VProd v 'Unit a, in a pattern binding in interactive GHCi command at :24:36-58 ?b? is a rigid type variable bound by a pattern with constructor VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: Prod) b. VProd v pra a -> VProd v prb b -> VProd v ('Pair pra prb) (a, b), in a pattern binding in interactive GHCi command at :24:2 Expected type: t0 b Actual type: Vector Int In the pattern: vb :: Vector Int In the pattern: VLeaf (vb :: Vector Int) In the pattern: VPair (VLeaf (va :: Vector Int)) (VLeaf (vb :: Vector Int)) :24:65: Couldn't match type ?(Int, Int)? with ?Int? Expected type: VProd Vector ('Pair 'Unit 'Unit) (Int, Int) Actual type: VProd Vector ('Pair 'Unit 'Unit) (Int, (Int, Int)) In the first argument of ?GHC.GHCi.ghciStepIO :: IO a_a5BR -> IO a_a5BR?, namely ?return $ VG.fromList [(1 :: Int, 2 :: Int), (3, 5)] :: VProd Vector (Pair Unit Unit) (Int, Int)? In a stmt of an interactive GHCi command: (VPair (VLeaf (va :: Vector Int)) (VLeaf (vb :: Vector Int))) <- GHC.GHCi.ghciStepIO :: IO a_a5BR -> IO a_a5BR (return $ VG.fromList [(1 :: Int, 2 :: Int), (3, 5)] :: VProd Vector (Pair Unit Unit) (Int, Int)) :24:65: Couldn't match expected type ?IO (VProd t0 t1 t2)? with actual type ?VProd Vector ('Pair 'Unit 'Unit) (Int, Int)? In the first argument of ?GHC.GHCi.ghciStepIO :: IO a_a5BR -> IO a_a5BR?, namely ?return $ VG.fromList [(1 :: Int, 2 :: Int), (3, 5)] :: VProd Vector (Pair Unit Unit) (Int, Int)? In a stmt of an interactive GHCi command: (VPair (VLeaf (va :: Vector Int)) (VLeaf (vb :: Vector Int))) <- GHC.GHCi.ghciStepIO :: IO a_a5BR -> IO a_a5BR (return $ VG.fromList [(1 :: Int, 2 :: Int), (3, 5)] :: VProd Vector (Pair Unit Unit) (Int, Int)) }}} I then experimented with using Data Families instead {{[#!hs data Prod = Pair Prod Prod | Unit data family VProd (vect :: * -> * ) (prd:: Prod ) val -- where data instance VProd v Unit a where VLeaf :: !(v a) -> VProd v Unit a data instance VProd v (Pair pra prb ) (a,b) where VPair :: !(VProd v pra a) -> !(VProd v prb b ) ->VProd v (Pair pra prb) (a,b) data family MVProd (vect :: * -> * -> * ) (prd:: Prod ) (st :: * ) val -- where data instance MVProd mv Unit st a where MVLeaf :: !(mv st a) -> MVProd mv Unit st a data instance MVProd mv (Pair pra prb) st (a,b) where MVPair :: !(MVProd mv pra st a) -> !(MVProd mv prb st b ) -> MVProd mv (Pair pra prb) st (a,b) }}} and type inference would chug along quite happily on the same example. Attached is the file needed to (somewhat minimally) reproduce this I guess what I'm saying here is I've quite a funny tension, I'm writing a patently closed data type, which has a perfectly reasonable GADT definition, but I need to use an (Open!) data family definition to get good type inference in the use sites! This seems like something where (roughly) when the GADT constructors satisfy something analogous to the no overlap condition of a valid data family, similarly strong type inference might be possible? I'm not sure if this makes sense, so i'm posing it as a feature request because i'm Not quite sure what the implications would be within type inference, but it'd probably be quite nice for end users because they'd suddenly get much better type inference for a large class of GADTs (i think) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 00:45:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 00:45:56 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.d774ed8ec8af4b4c2d3bd9d3341754d4@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by carter: Old description: > I'm marking this as a Feature request rather than a bug (though it was > unexpected behavior for me!) > > In my code base i had the following types > > {{{#!hs > data Prod = Pair Prod Prod | Unit > > data VProd (vect :: * -> * ) (prd:: Prod ) val where > VLeaf :: !(v a) -> VProd v Unit a > VPair :: !(VProd v pra a) -> !(VProd v prb b ) ->VProd v (Pair pra > prb) (a,b) > > data MVProd (vect :: * -> * -> * ) (prd:: Prod ) (st :: * ) val > where > MVLeaf :: !(mv st a) -> MVProd mv Unit st a > MVPair :: !(MVProd mv pra st a) -> !(MVProd mv prb st b ) -> MVProd > mv (Pair pra prb) st (a,b) > > }}} > > which are meant as a way of modeling vectors of tuples as tuples (err > trees) of vectors > > however, sometimes type inference would fail in explosive ways > like > {{{ > > *Numerical.Data.Vector.Pair Data.Vector VG> (VPair (VLeaf (va :: Vector > Int)) (VLeaf (vb:: Vector Int))) <- return $ VG.fromList > [(1::Int,2::Int),(3,5)] :: (VProd Vector (Pair Unit Unit) (Int,Int)) > > :24:16: > Could not deduce (a ~ Int) > from the context (t1 ~ 'Pair pra prb, t2 ~ (a, b)) > bound by a pattern with constructor > VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: > Prod) b. > VProd v pra a -> VProd v prb b -> VProd v > ('Pair pra prb) (a, b), > in a pattern binding in > interactive GHCi command > at :24:2-59 > or from (pra ~ 'Unit) > bound by a pattern with constructor > VLeaf :: forall (v :: * -> *) a. v a -> VProd v 'Unit a, > in a pattern binding in > interactive GHCi command > at :24:9-32 > ?a? is a rigid type variable bound by > a pattern with constructor > VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: Prod) > b. > VProd v pra a -> VProd v prb b -> VProd v ('Pair pra > prb) (a, b), > in a pattern binding in > interactive GHCi command > at :24:2 > Expected type: t0 a > Actual type: Vector Int > In the pattern: va :: Vector Int > In the pattern: VLeaf (va :: Vector Int) > In the pattern: > VPair (VLeaf (va :: Vector Int)) (VLeaf (vb :: Vector Int)) > > :24:43: > Could not deduce (b ~ Int) > from the context (t1 ~ 'Pair pra prb, t2 ~ (a, b)) > bound by a pattern with constructor > VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: > Prod) b. > VProd v pra a -> VProd v prb b -> VProd v > ('Pair pra prb) (a, b), > in a pattern binding in > interactive GHCi command > at :24:2-59 > or from (pra ~ 'Unit) > bound by a pattern with constructor > VLeaf :: forall (v :: * -> *) a. v a -> VProd v 'Unit a, > in a pattern binding in > interactive GHCi command > at :24:9-32 > or from (prb ~ 'Unit) > bound by a pattern with constructor > VLeaf :: forall (v :: * -> *) a. v a -> VProd v 'Unit a, > in a pattern binding in > interactive GHCi command > at :24:36-58 > ?b? is a rigid type variable bound by > a pattern with constructor > VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: Prod) > b. > VProd v pra a -> VProd v prb b -> VProd v ('Pair pra > prb) (a, b), > in a pattern binding in > interactive GHCi command > at :24:2 > Expected type: t0 b > Actual type: Vector Int > In the pattern: vb :: Vector Int > In the pattern: VLeaf (vb :: Vector Int) > In the pattern: > VPair (VLeaf (va :: Vector Int)) (VLeaf (vb :: Vector Int)) > > :24:65: > Couldn't match type ?(Int, Int)? with ?Int? > Expected type: VProd Vector ('Pair 'Unit 'Unit) (Int, Int) > Actual type: VProd Vector ('Pair 'Unit 'Unit) (Int, (Int, Int)) > In the first argument of ?GHC.GHCi.ghciStepIO :: > IO a_a5BR -> IO a_a5BR?, namely > ?return $ VG.fromList [(1 :: Int, 2 :: Int), (3, 5)] :: > VProd Vector (Pair Unit Unit) (Int, Int)? > In a stmt of an interactive GHCi command: > (VPair (VLeaf (va :: Vector Int)) > (VLeaf (vb :: Vector Int))) <- GHC.GHCi.ghciStepIO :: > IO a_a5BR -> IO a_a5BR > (return $ VG.fromList [(1 :: > Int, 2 :: Int), (3, 5)] :: > VProd Vector (Pair Unit > Unit) (Int, Int)) > > :24:65: > Couldn't match expected type ?IO (VProd t0 t1 t2)? > with actual type ?VProd Vector ('Pair 'Unit 'Unit) (Int, > Int)? > In the first argument of ?GHC.GHCi.ghciStepIO :: > IO a_a5BR -> IO a_a5BR?, namely > ?return $ VG.fromList [(1 :: Int, 2 :: Int), (3, 5)] :: > VProd Vector (Pair Unit Unit) (Int, Int)? > In a stmt of an interactive GHCi command: > (VPair (VLeaf (va :: Vector Int)) > (VLeaf (vb :: Vector Int))) <- GHC.GHCi.ghciStepIO :: > IO a_a5BR -> IO a_a5BR > (return $ VG.fromList [(1 :: > Int, 2 :: Int), (3, 5)] :: > VProd Vector (Pair Unit > Unit) (Int, Int)) > }}} > > I then experimented with using Data Families instead > > {{[#!hs > > data Prod = Pair Prod Prod | Unit > > data family VProd (vect :: * -> * ) (prd:: Prod ) val -- where > data instance VProd v Unit a where > VLeaf :: !(v a) -> VProd v Unit a > > data instance VProd v (Pair pra prb ) (a,b) where > VPair :: !(VProd v pra a) -> !(VProd v prb b ) ->VProd v (Pair pra > prb) (a,b) > > data family MVProd (vect :: * -> * -> * ) (prd:: Prod ) (st :: * ) > val -- where > data instance MVProd mv Unit st a where > MVLeaf :: !(mv st a) -> MVProd mv Unit st a > data instance MVProd mv (Pair pra prb) st (a,b) where > MVPair :: !(MVProd mv pra st a) -> !(MVProd mv prb st b ) -> > MVProd mv (Pair pra prb) st (a,b) > > }}} > > and type inference would chug along quite happily on the same example. > > Attached is the file needed to (somewhat minimally) reproduce this > > I guess what I'm saying here is I've quite a funny tension, I'm writing a > patently closed data type, which has a perfectly reasonable GADT > definition, but I need to use an (Open!) data family definition to get > good type inference in the use sites! > > This seems like something where (roughly) when the GADT constructors > satisfy something analogous to the no overlap condition of a valid data > family, similarly strong type inference might be possible? > I'm not sure if this makes sense, so i'm posing it as a feature request > because i'm Not quite sure what the implications would be within type > inference, but it'd probably be quite nice for end users because they'd > suddenly get much better type inference for a large class of GADTs (i > think) New description: I'm marking this as a Feature request rather than a bug (though it was unexpected behavior for me!) In my code base i had the following types {{{#!hs data Prod = Pair Prod Prod | Unit data VProd (vect :: * -> * ) (prd:: Prod ) val where VLeaf :: !(v a) -> VProd v Unit a VPair :: !(VProd v pra a) -> !(VProd v prb b ) ->VProd v (Pair pra prb) (a,b) data MVProd (vect :: * -> * -> * ) (prd:: Prod ) (st :: * ) val where MVLeaf :: !(mv st a) -> MVProd mv Unit st a MVPair :: !(MVProd mv pra st a) -> !(MVProd mv prb st b ) -> MVProd mv (Pair pra prb) st (a,b) }}} which are meant as a way of modeling vectors of tuples as tuples (err trees) of vectors however, sometimes type inference would fail in explosive ways like {{{ *Numerical.Data.Vector.Pair Data.Vector VG> (VPair (VLeaf (va :: Vector Int)) (VLeaf (vb:: Vector Int))) <- return $ VG.fromList [(1::Int,2::Int),(3,5)] :: (VProd Vector (Pair Unit Unit) (Int,Int)) :24:16: Could not deduce (a ~ Int) from the context (t1 ~ 'Pair pra prb, t2 ~ (a, b)) bound by a pattern with constructor VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: Prod) b. VProd v pra a -> VProd v prb b -> VProd v ('Pair pra prb) (a, b), in a pattern binding in interactive GHCi command at :24:2-59 or from (pra ~ 'Unit) bound by a pattern with constructor VLeaf :: forall (v :: * -> *) a. v a -> VProd v 'Unit a, in a pattern binding in interactive GHCi command at :24:9-32 ?a? is a rigid type variable bound by a pattern with constructor VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: Prod) b. VProd v pra a -> VProd v prb b -> VProd v ('Pair pra prb) (a, b), in a pattern binding in interactive GHCi command at :24:2 Expected type: t0 a Actual type: Vector Int In the pattern: va :: Vector Int In the pattern: VLeaf (va :: Vector Int) In the pattern: VPair (VLeaf (va :: Vector Int)) (VLeaf (vb :: Vector Int)) :24:43: Could not deduce (b ~ Int) from the context (t1 ~ 'Pair pra prb, t2 ~ (a, b)) bound by a pattern with constructor VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: Prod) b. VProd v pra a -> VProd v prb b -> VProd v ('Pair pra prb) (a, b), in a pattern binding in interactive GHCi command at :24:2-59 or from (pra ~ 'Unit) bound by a pattern with constructor VLeaf :: forall (v :: * -> *) a. v a -> VProd v 'Unit a, in a pattern binding in interactive GHCi command at :24:9-32 or from (prb ~ 'Unit) bound by a pattern with constructor VLeaf :: forall (v :: * -> *) a. v a -> VProd v 'Unit a, in a pattern binding in interactive GHCi command at :24:36-58 ?b? is a rigid type variable bound by a pattern with constructor VPair :: forall (v :: * -> *) (pra :: Prod) a (prb :: Prod) b. VProd v pra a -> VProd v prb b -> VProd v ('Pair pra prb) (a, b), in a pattern binding in interactive GHCi command at :24:2 Expected type: t0 b Actual type: Vector Int In the pattern: vb :: Vector Int In the pattern: VLeaf (vb :: Vector Int) In the pattern: VPair (VLeaf (va :: Vector Int)) (VLeaf (vb :: Vector Int)) :24:65: Couldn't match type ?(Int, Int)? with ?Int? Expected type: VProd Vector ('Pair 'Unit 'Unit) (Int, Int) Actual type: VProd Vector ('Pair 'Unit 'Unit) (Int, (Int, Int)) In the first argument of ?GHC.GHCi.ghciStepIO :: IO a_a5BR -> IO a_a5BR?, namely ?return $ VG.fromList [(1 :: Int, 2 :: Int), (3, 5)] :: VProd Vector (Pair Unit Unit) (Int, Int)? In a stmt of an interactive GHCi command: (VPair (VLeaf (va :: Vector Int)) (VLeaf (vb :: Vector Int))) <- GHC.GHCi.ghciStepIO :: IO a_a5BR -> IO a_a5BR (return $ VG.fromList [(1 :: Int, 2 :: Int), (3, 5)] :: VProd Vector (Pair Unit Unit) (Int, Int)) :24:65: Couldn't match expected type ?IO (VProd t0 t1 t2)? with actual type ?VProd Vector ('Pair 'Unit 'Unit) (Int, Int)? In the first argument of ?GHC.GHCi.ghciStepIO :: IO a_a5BR -> IO a_a5BR?, namely ?return $ VG.fromList [(1 :: Int, 2 :: Int), (3, 5)] :: VProd Vector (Pair Unit Unit) (Int, Int)? In a stmt of an interactive GHCi command: (VPair (VLeaf (va :: Vector Int)) (VLeaf (vb :: Vector Int))) <- GHC.GHCi.ghciStepIO :: IO a_a5BR -> IO a_a5BR (return $ VG.fromList [(1 :: Int, 2 :: Int), (3, 5)] :: VProd Vector (Pair Unit Unit) (Int, Int)) }}} I then experimented with using Data Families instead {{{#!hs data Prod = Pair Prod Prod | Unit data family VProd (vect :: * -> * ) (prd:: Prod ) val -- where data instance VProd v Unit a where VLeaf :: !(v a) -> VProd v Unit a data instance VProd v (Pair pra prb ) (a,b) where VPair :: !(VProd v pra a) -> !(VProd v prb b ) ->VProd v (Pair pra prb) (a,b) data family MVProd (vect :: * -> * -> * ) (prd:: Prod ) (st :: * ) val -- where data instance MVProd mv Unit st a where MVLeaf :: !(mv st a) -> MVProd mv Unit st a data instance MVProd mv (Pair pra prb) st (a,b) where MVPair :: !(MVProd mv pra st a) -> !(MVProd mv prb st b ) -> MVProd mv (Pair pra prb) st (a,b) }}} and type inference would chug along quite happily on the same example. Attached is the file needed to (somewhat minimally) reproduce this I guess what I'm saying here is I've quite a funny tension, I'm writing a patently closed data type, which has a perfectly reasonable GADT definition, but I need to use an (Open!) data family definition to get good type inference in the use sites! This seems like something where (roughly) when the GADT constructors satisfy something analogous to the no overlap condition of a valid data family, similarly strong type inference might be possible? I'm not sure if this makes sense, so i'm posing it as a feature request because i'm Not quite sure what the implications would be within type inference, but it'd probably be quite nice for end users because they'd suddenly get much better type inference for a large class of GADTs (i think) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 00:55:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 00:55:06 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.8578dd1446a2997adab30f7ae2b71029@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): basically I want something that has the closed-ness of a GADT, and the inferency goodness of a data family. Whether this is a new thing or a "special stronger case of gadt", is another matter i'm happy to try to help someone figure out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 01:33:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 01:33:32 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.55fffbc2ec1d12b7a7290a1f110ec199@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:9 rwbarton]: > I don't understand what `bartonEq` or `feuerEq` is or what the difference between them is supposed to be. They look equal to me. You're right. I got confused. Sorry. I still think we should have that `secretEq#` that acts the same as `==#` but without the `litEq` modification. I'm not the one to come up with a good justification?all I want it for at the moment is `isSpace`, whicn is not exactly a hotspot in most code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 08:47:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 08:47:54 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.150810ac3990a3b498aa9306a14561f9@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:1 ross]: > I suggest doing a major release of transformers at the same time as the next major GHC release, with Data.Functor.Identity removed and added to base. This version would depend on the new version of base to force an upgrade. Terrific! I'll draft a `transformers`-patch in our locally forked repo over at http://git.haskell.org/packages/transformers.git and migrate `Data.Functor.Identity` into GHC HEAD's `base` so we can start using that in GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 09:23:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 09:23:20 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.29e0adee216f53764f23e61ee87d349a@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Changes (by hvr): * cc: ekmett (added) * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 11:39:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 11:39:23 -0000 Subject: [GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide In-Reply-To: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> References: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> Message-ID: <066.252b64ea3e40fe8f0c45f3d7ace98df0@haskell.org> #9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: task | Milestone: Priority: high | Version: 7.9 Component: | Keywords: Documentation | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): This reminded me I had that information in a text file for personal reference, I've placed it in LanguagePragmaHistory for everyone to see, which I guess may be helpful to whoever implements this task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 12:29:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 12:29:26 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.d509ec91e605d2e73fa2c70478a1ed35@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Runtime | Version: 7.8.1-rc2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Rocket Science Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: #9186, #9480 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 12:30:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 12:30:38 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly In-Reply-To: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> References: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> Message-ID: <064.f1714a565acdffa6dd915e64cfe73120@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 13:33:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 13:33:11 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.27e05b4a6c1b1844c3bc40eaf75263fd@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D313 | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D313 Comment: @ross: please take a look at http://git.haskell.org/packages/transformers.git/commitdiff/refs/heads/wip/T9664 ... does that look ok to you? I had to conditionally expose the `Data.Functor.Identity` module, as otherwise it gets more complicated to tweak GHC's build-system to cope with a `transformers` that would only work with GHC>=7.9 & base>=4.8, as the in-tree `transformers` packages needs to be compiled multiple times, once with the bootstrapping compiler (which is either GHC 7.6 or GHC 7.8 for GHC HEAD), and later-on on with GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 14:13:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 14:13:48 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.b6213b9f88771047f7c46d209d2e7be6@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by ekmett): I'd personally prefer to wait for 7.12 to allow folks who have longer support cycles to catch up unless it is causing an active pain point for us in maintenance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 14:46:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 14:46:49 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.1423f8abdcd078c55b915e7a8c32c218@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: komadori Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hamish): * cc: hamish (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 14:53:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 14:53:04 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.dcf470e795682fd6891ac90bb82a1e36@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by dreixel): Do we know of anyone actually using this? We've warned it would be removed in 7.10. I don't think it causes much maintenance issues, but that alone shouldn't be a reason to keep it around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 15:00:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 15:00:19 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.3a55d45d903f595306070767422e8fb1@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by ekmett): My knee jerk _was_ to actually remove it, but then I looked with a quick google search and there is at least type-eq still using it, with a somewhat confused upgrade path, and explicit "future uncertain" comments in the code, which has dependencies upon it splintering out through haskell-names and fay, etc. http://hackage.haskell.org/package/type-eq -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 15:37:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 15:37:05 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.fcd80a72cde3888d96576fc09f22615b@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by hvr): Fwiw, if everything goes according to plan, the GHC 7.11 branch will open up in roughly 6 weeks... so that's probably `OldTypeable` upper bound for its time-to-live, if we can't sort out the `type-eq` issue in time for GHC 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 16:07:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 16:07:45 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.a4dd9a14943e9ce3916a4b06ca43dc2b@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by mgmeier): The only reason for haskell-names to use the type-eq package seems to be in its module `Language.Haskell.Names.Annotated`: {{{ -- This should be incorporated into Data.Typeable soon import Type.Eq }}} using `dynamicEq` and `(:~:)` from that import. Does the current `Data.Typeable` facilitate this functionality yet? If so, type-eq dependency could be dropped from haskell-names (and fay, in consequence), as far as I can see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 17:12:31 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 17:12:31 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.77210d3020b1090a1932bcc50cc1192d@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): The big difference I see between the original and hvr's version is that the original installs a thunk in the `IORef` and then immediately forces it, whereas hvr's version forces it, and then installs it in the `IORef`. I don't think this difference can be observed, but I'm no expert. I think parcs's modification is just a milder step on the way to hvr's, which looks likely to be the simplest/best, but that would take benchmarking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 17:16:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 17:16:15 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.aae1134ffe3601d5c5d469cb8b39cf84@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Actually, one possible complication (maybe): the current version guarantees allocation (and therefore an opportunity to switch threads). I don't think the proposed one does this. I also don't know if that's a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 18:26:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 18:26:23 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.4a9a542700f291bd22403fc4ac207288@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by snoyberg): Herbert asked me to weigh in with some data from Stackage builds. Here's what I wrote to him: I have a Stackage build running on my system right now in the testing phase, so I have access to all of the log files. This is a Stackage 7.8.3 + Haskell Platform build, so it uses a few less packages than the normal 7.8 and has a few older packages (I can test on 7.8 w/o HP as well if it would be useful). Of 651 packages built in this run, only two of the logs mentioned the string OldTypeable. type-eq (version 0.4.2) certainly has the deprecation warning in many places. haskell-names mentions OldTypeable as well, but it seems to simply be dealing with all of the files in base, not a real dependency. If any other data from Stackage would be useful, let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 20:06:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 20:06:12 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.baae308d0e0cb9d23014f567518ccc93@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): a version that doesn't (in general) trigger the heap check would probably be better, at least in some cases I can probably manufacture. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 20:07:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 20:07:12 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.b4fe01ebd0434426a23f6f9a1cb964df@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): Reason being that the definition of atomicModify does a CAS retry loop internally. (though maybe yielding to the scheduler could be a good thing! ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 20:15:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 20:15:36 -0000 Subject: [GHC] #7103: Compiler panic, when loading wxc in GHCi In-Reply-To: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> References: <047.6b074afcb8273c102b0aaa4eb9707092@haskell.org> Message-ID: <062.adc9d44d0b9d1ef26912dde9a564f2e4@haskell.org> #7103: Compiler panic, when loading wxc in GHCi -------------------------------------+------------------------------------ Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------ Comment (by razvan.panda): Confirming bug on GHC 7.8.3 (Haskell Platform) Windows 8.1 64 bit: {{{ Loading package network-2.6.0.2 ... ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): loadArchive "c:/Program Files/Haskell Platform/2014.2.0.0/mingw/x86_64-w64-mingw32/lib\\libws2_32.a": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc.exe: Unknown PEi386 section name `.idata$4' (while processing: c:/Program Files/Haskell Platform/2014.2.0.0/mingw/x86_64-w64-mingw32/lib\libws2_32.a) cabal.exe: Error: some packages failed to install: persistent-1.3.3 failed during the building phase. The exception was: ExitFailure 1 persistent-template-1.3.2.2 depends on persistent-1.3.3 which failed to install. yesod-form-1.3.16 depends on persistent-1.3.3 which failed to install. yesod-markdown-0.9.2 depends on persistent-1.3.3 which failed to install. yesod-persistent-1.2.3.1 depends on persistent-1.3.3 which failed to install. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 20:44:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 20:44:45 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.a969b24a369f818c18ac7c875dfc9935@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:10 carter]: > Reason being that the definition of atomicModify does a CAS retry loop internally. (though maybe yielding to the scheduler could be a good thing! ) If it's CAS, then yeah, it's probably reasonably safe to avoid the heap check, since CAS can't be interrupted by anything else on the same OS thread. The only exception is if a program (knowingly or unknowingly) uses `atomicModifyIORef'` to allow a thread switch. But I want to emphasize that I don't know enough about these inner workings to know if this change could actually cause this sort of problem. I just raised the issue so better-informed people like you can come up with a good answer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 21:11:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 21:11:14 -0000 Subject: [GHC] #8790: rts: unrust 'libbfd' debug symbols parser In-Reply-To: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> References: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> Message-ID: <060.3b3eadb0faab1e118ba29519ddc6a2cc@haskell.org> #8790: rts: unrust 'libbfd' debug symbols parser -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: D193 | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"cb0a503a44bf016de3d9042906c6ac0c0821ffea/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cb0a503a44bf016de3d9042906c6ac0c0821ffea" rts: unrust 'libbfd' debug symbols parser Summary: Patch does the following: - fixes detection of working libbfd on modern linux platforms (where bfd_uncompress_section_contents is a macro) - disables 'bfd' by default and adds '--enable-bfd-debug' configure option. As bfd's ABI is unstable the feature is primarily useful by ghc hackers. Not done (subject for another patch): - one-time bfd object memory leak in DEBUG_LoadSymbols - in '-dynamic' mode debugging symbols are loaded only for current executable, not all libraries it is linked against. Fixes Issue #8790 Signed-off-by: Sergei Trofimovich Test Plan: built unregisterised ghc on amd64 and ran './hello +RTS -Di' there Reviewers: simonmar, austin Reviewed By: simonmar, austin Subscribers: thomie, simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D193 GHC Trac Issues: #8790 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 21:13:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 21:13:20 -0000 Subject: [GHC] #8790: rts: unrust 'libbfd' debug symbols parser In-Reply-To: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> References: <045.6af0a0aed0fe74b74157783dadb6b926@haskell.org> Message-ID: <060.356ceaedcaaedec8dafb7e4f6dfb40e6@haskell.org> #8790: rts: unrust 'libbfd' debug symbols parser -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: D193 | -------------------------------------+------------------------------------- Changes (by slyfox): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 21:39:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 21:39:44 -0000 Subject: [GHC] #9660: unnecessary indirect jump when returning a case scrutinee In-Reply-To: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> References: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> Message-ID: <062.63de13858d1be1aa372c32ec7c872ae8@haskell.org> #9660: unnecessary indirect jump when returning a case scrutinee -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well, initial results are somewhat inconclusive: {{{ Min -0.1% -0.1% -6.3% -6.2% -7.4% Max +0.1% +0.0% +7.5% +7.5% +3.6% Geometric Mean -0.0% -0.0% -0.2% -0.2% -0.0% }}} I believe the large variations are due to the same kind of issues I encountered in #8279. Got sucked into investigating that for a while, with no real progress. Anyways it seems like it ought to be a clear win; what's the best way to implement this for real? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 23:02:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 23:02:55 -0000 Subject: [GHC] #9668: Unicode info is out of date Message-ID: <045.4162c8318981414b1b75ed9710354b32@haskell.org> #9668: Unicode info is out of date -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: Unicode | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The automatically generated `WCsubst.c` was last generated in 2011. The Unicode standard has been updated several times since then. I would like to try to replace that whole mechanism with something a little more cache- friendly, but at the very list the tables need to be right. Unfortunately, the script that generates this file gives no information about its input format, or just where a file with the right format is supposed to come from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 23:05:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 23:05:42 -0000 Subject: [GHC] #9668: Unicode info is out of date In-Reply-To: <045.4162c8318981414b1b75ed9710354b32@haskell.org> References: <045.4162c8318981414b1b75ed9710354b32@haskell.org> Message-ID: <060.45dfa07ab2a9e21c314c608f05acaf52@haskell.org> #9668: Unicode info is out of date -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Unicode Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > The automatically generated `WCsubst.c` was last generated in 2011. The > Unicode standard has been updated several times since then. I would like > to try to replace that whole mechanism with something a little more > cache-friendly, but at the very list the tables need to be right. > Unfortunately, the script that generates this file gives no information > about its input format, or just where a file with the right format is > supposed to come from. New description: The automatically generated `WCsubst.c` was last generated in 2011. The Unicode standard has been updated several times since then. I would like to try to replace that whole mechanism with something a little more cache- friendly, but at the very least the tables need to be right. Unfortunately, the script that generates this file gives no information about its input format, or just where a file with the right format is supposed to come from. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 5 23:44:19 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Oct 2014 23:44:19 -0000 Subject: [GHC] #9668: Unicode info is out of date In-Reply-To: <045.4162c8318981414b1b75ed9710354b32@haskell.org> References: <045.4162c8318981414b1b75ed9710354b32@haskell.org> Message-ID: <060.52968a0eb64bfcd2d52094f7bf374167@haskell.org> #9668: Unicode info is out of date -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Unicode Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Yes, we really ought to have a `Note: [Unicode standard updates]` that documents everything that needs to happen when a new Unicode standard is released. (e.g. if there are magic constants in the Haskell `isSpace` that need to change if a formerly reserved character becomes whitespace, that should be listed too.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 03:30:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 03:30:21 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.cfd9c30af19057163e4105f3e95168b1@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------------+--------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 Differential Revisions: | ---------------------------------------+--------------------------- Comment (by dkwright): Happening for me with 2014.2.0.0 as well. Loading this code (stripped down from something more practical), example.hs, in ghci and typing {{{main}}}, gives the error: {{{ module Main where import Criterion.Main main :: IO() main = putStrLn "example" }}} Without the import of Criterion.Main, no error. It looks like it's a dependency on ieee754 from Criterion.Main that does it. Error: {{{ SNIP Loading package ansi-wl-pprint-0.6.7.1 ... linking ... done. Loading package blaze-builder-0.3.3.4 ... linking ... done. Loading package cassava-0.4.2.0 ... linking ... done. Loading package MonadRandom-0.3 ... linking ... done. Loading package exceptions-0.6.1 ... linking ... done. Loading package nats-0.2 ... linking ... done. Loading package semigroups-0.15.3 ... linking ... done. Loading package transformers-compat-0.3.3.4 ... linking ... done. Loading package void-0.6.1 ... linking ... done. Loading package contravariant-1.2 ... linking ... done. Loading package tagged-0.7.2 ... linking ... done. Loading package distributive-0.4.4 ... linking ... done. Loading package comonad-4.2.2 ... linking ... done. Loading package semigroupoids-4.2 ... linking ... done. Loading package bifunctors-4.1.1.1 ... linking ... done. Loading package prelude-extras-0.4 ... linking ... done. Loading package profunctors-4.2.0.1 ... linking ... done. Loading package free-4.9 ... linking ... done. Loading package transformers-base-0.4.3 ... linking ... done. Loading package monad-control-0.3.3.0 ... linking ... done. Loading package either-4.3.1 ... linking ... done. Loading package ieee754-0.7.3 ... : m: The specified module could n ot be found. can't load .so/.DLL for: m.dll (addDLL: could not load DLL) *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 04:56:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 04:56:27 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.9d08fb254c8c57c6b23fd60b8e9a08d3@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Thanks slyfox! That fixed my DYNAMIC_GHC_PROGRAMS=NO build. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 07:12:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 07:12:42 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.9b120839e65e8cf9e56b7aa2b064a5b3@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): It looks like my fears were unjustified. If I run this: {{{#!hs silly = \current -> (True, True) {-# INLINE flipper #-} stupid = newIORef False >>= \r -> let flop = atomicModifyIORef' r silly in forever flop main = do flippy <- forkIO stupid mapM_ print [x | x <- [1..], x `rem` 10000000 == 0] }}} with just one thread, and try either of the above implementations, it prints things just fine. I don't see any obvious signs of allocation anywhere in the `stupid` thread, so I would speculate that maybe `atomicModifyMutVar#` always gives the scheduler a go. This looks like a real good catch by parcs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 07:27:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 07:27:02 -0000 Subject: [GHC] #9668: Unicode info is out of date In-Reply-To: <045.4162c8318981414b1b75ed9710354b32@haskell.org> References: <045.4162c8318981414b1b75ed9710354b32@haskell.org> Message-ID: <060.14e6a3ec5b99a6647bba92f48d2049f7@haskell.org> #9668: Unicode info is out of date -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Unicode Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 rwbarton]: > Yes, we really ought to have a `Note: [Unicode standard updates]` that documents everything that needs to happen when a new Unicode standard is released. (e.g. if there are magic constants in the Haskell `isSpace` that need to change if a formerly reserved character becomes whitespace, that should be listed too.) > > (Also, the User's Guide should mention the version of the Unicode standard ghc implements, if it doesn't do so already.) It appears that all that's required is running `libraries/base/cbits/ubconfc` and feeding it the appropriate specification table as standard input. This replaces `WCsubst.c` and everything (including `isSpace`) works. If I manage to write a Haskell version of this system, the requirements will be similarly simple. The only trouble is figuring out just what table it's supposed to be fed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 09:37:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 09:37:02 -0000 Subject: [GHC] #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx In-Reply-To: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> References: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> Message-ID: <061.5ccfeaab7fcbec629b54cd90f8b68542@haskell.org> #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rzetterberg): My comment disappeared, so I'll try again! I encountered the same problem with a library I'm developing. My library uses a C++ static library that uses some Qt functionality. Qt has a tool called qmake that can generate makefiles for Qt-projects. When I looked at symbols in the library with the nm tool I saw that for each object file included __x86.get_pc_thunk.bx was exported. I looked at the generated makefile and saw that -fPIC was added to CFLAGS and CXXFLAGS. Which I thought was wierd since I'm building a static library. I removed -fPIC from CFLAGS and CXXFLAGS and rebuilt the library. When I looked at the symbols again __x86.get_pc_thunk.bx was not exported. I then ran {{{ cabal clean cabal configure cabal build }}} '''And my build was successful!''' I looked at the library that fails for you and I saw that in the cabal- file -fPIC is added to cc-options: https://github.com/coreyoconnor/vty/blob/master/vty.cabal#L117 Maybe that's the source of the problem? I'm no expert but it seems that this a library bug and not a ghc bug. Hopefully this saves the ghc devs and OP some time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 10:22:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 10:22:23 -0000 Subject: [GHC] #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx In-Reply-To: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> References: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> Message-ID: <061.062d2a84e2f7108c094a5364532689c1@haskell.org> #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for the investigation. I thought `-fPIC` is required in some cases, or for some architectures? But I must admint that I?m still mostly ignorant about linker issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 10:25:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 10:25:11 -0000 Subject: [GHC] #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx In-Reply-To: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> References: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> Message-ID: <061.1b2ce8f5cb3a28c33f4879e885e0b280@haskell.org> #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): @tell nomeata I just saw #9657 , and FTR there Vty has some GHC panic bugs open already so that might be worth looking for. Also Yi is known to have problem with Haddocking on 7.6.3 (#9170) so maybe this is the variant of that. By the way, I see you're using some patched sources for Vty 5.x support which makes this rather? hard to reproduce even if I wanted to [11:22] nomeata lets you know: To reach me, better use mail than lambdabot messages; I tend to read them too late. Consider it noted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 10:32:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 10:32:49 -0000 Subject: [GHC] #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx In-Reply-To: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> References: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> Message-ID: <061.01374b7d527b1f8a5616c40a8f2f2eb3@haskell.org> #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): > By the way, I see you're using some patched sources for Vty 5.x support which makes this rather? hard to reproduce even if I wanted to You can fetch the patch from http://anonscm.debian.org/darcs/pkg- haskell/yi/patches/vty-5.1-compat if you want to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 11:20:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 11:20:26 -0000 Subject: [GHC] #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx In-Reply-To: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> References: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> Message-ID: <061.dc6219d52ebcf36e42b734b34ddb6215@haskell.org> #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rzetterberg): Replying to [comment:2 nomeata]: > Thanks for the investigation. I thought `-fPIC` is required in some cases, or for some architectures? But I must admint that I?m still mostly ignorant about linker issues. That's true! After reading about linking a bit more: You need `-fPIC` on x86_64 when building shared libraries. And all static libaries that the shared library links against must also be built with `-fPIC`. I guess the "solution" I posted is more a non-portable hack. I'm not well versed in linking either. Hopefully it will atleast give some clues to the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 12:11:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 12:11:31 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses Message-ID: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've seen many different people complain about this in various different contexts. One of the most common I personally see is when using Persistent with a large number of entities, which results in multi-minute build times for that single module. Usually, these reports have come from private repositories, which makes for a difficult repro. Also, the usage of Template Haskell in those modules tends to confuse the issue. So I'd like to report this issue from a completely separate project, with the guess that this represents an issue that is affecting many other users. Steps to reproduce: * `cabal unpack fpco-api-1.2.0.1` * `cd fpco-api-1.2.0.1` * `cabal install` * `ghc --make -isrc/library src/library/FP/API/Types.hs` * `touch src/library/FP/API/Types.hs` Then, to see the time and memory usage of compiling just the one module, run: * `time ghc -O2 --make -isrc/library src/library/FP/API/Types.hs +RTS -s` On my system (16GB RAM, quadcore i7), the results are: {{{ $ time ghc -O2 --make -isrc/library src/library/FP/API/Types.hs +RTS -s [3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o ) 51,846,533,568 bytes allocated in the heap 6,799,246,288 bytes copied during GC 389,297,584 bytes maximum residency (22 sample(s)) 11,330,472 bytes maximum slop 1041 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2041 colls, 0 par 9.19s 9.19s 0.0045s 0.0998s Gen 1 22 colls, 0 par 4.33s 4.33s 0.1969s 0.5436s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 34.21s ( 37.74s elapsed) GC time 13.52s ( 13.53s elapsed) EXIT time 0.07s ( 0.07s elapsed) Total time 47.81s ( 51.34s elapsed) Alloc rate 1,515,662,937 bytes per MUT second Productivity 71.7% of total user, 66.8% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 real 0m51.375s user 0m50.864s sys 0m0.456s }}} By contrast, with optimizations turned off: {{{ $ time ghc -O0 --make -isrc/library src/library/FP/API/Types.hs +RTS -s [3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o ) 12,767,593,936 bytes allocated in the heap 1,078,202,664 bytes copied during GC 179,551,768 bytes maximum residency (13 sample(s)) 6,684,544 bytes maximum slop 439 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 623 colls, 0 par 1.24s 1.24s 0.0020s 0.0651s Gen 1 13 colls, 0 par 0.76s 0.76s 0.0586s 0.2397s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 8.28s ( 9.23s elapsed) GC time 2.00s ( 2.00s elapsed) EXIT time 0.05s ( 0.05s elapsed) Total time 10.34s ( 11.28s elapsed) Alloc rate 1,542,443,897 bytes per MUT second Productivity 80.6% of total user, 73.9% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 real 0m11.304s user 0m11.108s sys 0m0.172s }}} and -O1: {{{ $ time ghc -O1 --make -isrc/library src/library/FP/API/Types.hs +RTS -s [3 of 3] Compiling FP.API.Types ( src/library/FP/API/Types.hs, src/library/FP/API/Types.o ) 45,550,443,664 bytes allocated in the heap 5,721,700,512 bytes copied during GC 358,036,456 bytes maximum residency (21 sample(s)) 9,167,176 bytes maximum slop 906 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1642 colls, 0 par 7.70s 7.70s 0.0047s 0.1031s Gen 1 21 colls, 0 par 3.68s 3.69s 0.1756s 0.4968s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.00s ( 0.00s elapsed) MUT time 30.21s ( 33.09s elapsed) GC time 11.38s ( 11.39s elapsed) EXIT time 0.07s ( 0.07s elapsed) Total time 41.68s ( 44.55s elapsed) Alloc rate 1,507,571,106 bytes per MUT second Productivity 72.7% of total user, 68.0% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 real 0m44.577s user 0m44.164s sys 0m0.368s }}} Note that this module is essentially just 900 lines of data declarations, with a large number of derived classes, and a few manually written helper functions and instances. This high memory usage hasn't just resulted in user complaints: automated Jenkins and Travis jobs will often times fail without optimizations disabled, which can be problematic for proper testing and production code. In the case of fpco-api, I've worked around this by adding `-O0` to the cabal file, but it would be much nicer to not have to do that. For some other examples of complaints along these lines: * https://groups.google.com/d/msg/yesodweb/MX1bnOFu8Hc/VLQXhnvpIkMJ * https://groups.google.com/d/msg/yesodweb/XPWixNjuOnM/FN26bmkudgwJ I believe there are a few other threads discussing this, if it would be helpful. I did my testing on GHC 7.8.3 64-bit, Ubuntu 12.04. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 12:47:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 12:47:37 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.8eb1db3df24a3eae31d50d11626cceef@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): I've attached a file (generate.hs) to hopefully give a simpler view of the problem. This module (which depends only on base) will generate a Haskell source file which itself depends only on base. You can test this out with `runghc generate.hs > Bar.hs && time ghc --make Bar.hs +RTS -s`. You can also edit the generate.hs file to change which classes are derived and how many datatypes are generated. In my testing, without switching optimization flags, I noticed the following (all results generated when using 200 types): * All classes: 247MB max residency, 17.7s runtime * Removing `Generic`: 109MB, 13.4s * Removing `Generic` and `Data`: 78MB, 9.4s * Removing all but `Typeable`: 23MB, 1.1s * Removing all deriving: 13MB, 0.6s -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 16:30:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 16:30:48 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.7956f7acfdcec918ee8cab6faf1dee2b@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): ok, my remarks about the heapcheck stuff were wrong and such. please ignore them :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 18:57:05 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 18:57:05 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.a3e6460d709ebb2288f0b5a755ac06db@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------------+--------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 Differential Revisions: | ---------------------------------------+--------------------------- Changes (by bjornbm): * cc: bjorn.buckwalter@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 20:19:15 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 20:19:15 -0000 Subject: [GHC] #9660: unnecessary indirect jump when returning a case scrutinee In-Reply-To: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> References: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> Message-ID: <062.1641d261ae980b50c2cfa645285b13fe@haskell.org> #9660: unnecessary indirect jump when returning a case scrutinee -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): It ought to be a clear win. To be extra sure I'd compare the sizes of object files in nofib built both ways, find some object files that differ, and then compare the assembly output for those modules, just to be sure that nothing unexpected is happening. I'd also double-check any nofib results that appear to vary by more than a few percent. You can use perf to count instructions, which should go down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 20:28:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 20:28:06 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.42c55323f1bdcde76b796bbfef99afb7@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): @hvr's version is basically just a more concise way to write @parcs' proposed version. I'm happy with either. Someone want to put up a diff? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 22:13:27 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 22:13:27 -0000 Subject: [GHC] #1257: Bytecode generator can't handle unboxed tuples In-Reply-To: <044.e337dd273e83366d6de11ad7555ce4f4@haskell.org> References: <044.e337dd273e83366d6de11ad7555ce4f4@haskell.org> Message-ID: <059.bb233f512c43af9f3c3a40ca86d2db22@haskell.org> #1257: Bytecode generator can't handle unboxed tuples -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: GHCi | Version: 6.6 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: dsrun014 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rodlogic): * cc: hvr (added) Comment: Could someone expand a bit on why there are infinite family of return conventions for unboxed tuples? And possibly how could this restriction be lifted? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 22:15:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 22:15:17 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.81472fb679dc49d69289352e71504d4e@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:14 simonmar]: > @hvr's version is basically just a more concise way to write @parcs' proposed version. I'm happy with either. Someone want to put up a diff? I'll be happy to do that. I realized today that if I replace `evaluate` with its specification, I do indeed get the same Core for parcs's and hvr's versions, which of course (conditionally) proves that what you say is true. But using `evaluate` itself gives somewhat different core, because it uses `seq#` to order things properly instead of `case`. I haven't inspected the Cmm or asm output, so I don't know if this makes any difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 6 22:16:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Oct 2014 22:16:38 -0000 Subject: [GHC] #1257: Bytecode generator can't handle unboxed tuples In-Reply-To: <044.e337dd273e83366d6de11ad7555ce4f4@haskell.org> References: <044.e337dd273e83366d6de11ad7555ce4f4@haskell.org> Message-ID: <059.851c115b5a1d499f0c31ff534dd568c4@haskell.org> #1257: Bytecode generator can't handle unboxed tuples -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: GHCi | Version: 6.6 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: dsrun014 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rodlogic): * cc: rodlogic (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 02:48:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 02:48:42 -0000 Subject: [GHC] #9356: scanl does not participate in list fusion In-Reply-To: <045.ab578058deeca9329303e3b009a823aa@haskell.org> References: <045.ab578058deeca9329303e3b009a823aa@haskell.org> Message-ID: <060.14d6ddcbc576d7da02b8f98a569a6457@haskell.org> #9356: scanl does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: infoneeded => patch Comment: I added an explanation, and simplified some things. Phab:D314 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 04:23:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 04:23:56 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.2503b374307f81ec389223b52b595f32@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: | Version: 7.6.3 libraries/base | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch Comment: Phab:D793 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 04:56:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 04:56:46 -0000 Subject: [GHC] #9368: Add strictly accumulating scanl' to Data.List In-Reply-To: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> References: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> Message-ID: <060.e9c6a8abfffec8814561866003ce5b24@haskell.org> #9368: Add strictly accumulating scanl' to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.3 Component: | Keywords: libraries/base | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9345 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch Comment: Phab: D314 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 05:47:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 05:47:28 -0000 Subject: [GHC] #9668: Unicode info is out of date In-Reply-To: <045.4162c8318981414b1b75ed9710354b32@haskell.org> References: <045.4162c8318981414b1b75ed9710354b32@haskell.org> Message-ID: <060.f1271cf6be243cef2a14cf4e59678009@haskell.org> #9668: Unicode info is out of date -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Unicode Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * status: new => patch Comment: Phab:D316 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 05:47:38 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 05:47:38 -0000 Subject: [GHC] Batch modify: #229, #3676, #5666, #5672, #5827, #6101, #7011, #7104, #7309, #7860, #8354, #8362, #8647, #8664, #8666, #8752, #8772, #9169, #9220, #9281, #9539, #9594, #4442, #3606, #4022 Message-ID: <20141007054738.1BA2F3A2FF@ghc.haskell.org> Batch modification to #229, #3676, #5666, #5672, #5827, #6101, #7011, #7104, #7309, #7860, #8354, #8362, #8647, #8664, #8666, #8752, #8772, #9169, #9220, #9281, #9539, #9594, #4442, #3606, #4022 by thoughtpolice: component to Core Libraries Comment: Moving over to new owning component 'Core Libraries'. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 05:48:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 05:48:24 -0000 Subject: [GHC] Batch modify: #4144, #9345, #806, #1473, #2189, #2408, #2496, #2528, #2628, #3231, #3628, #4102, #5364, #5466, #5797, #5859, #5982, #5983, #7045, #7161, #7353, #7373, #7634, #7985, #8010, #8345, #8517, #8684, #8767, #8793, #8850, #9043, #9114, #9132, #9236, #9240, #9306, #9330, #9368, #9395, #9434, #9496, #9510, #9526, #9527, #9537, #9542, #9586, #9588, #9631, #9638, #9644, #2614, #3517, #3977, #4413, #4861, #8532, #9283, #9385, #2140, #3065 Message-ID: <20141007054824.A331B3A2FF@ghc.haskell.org> Batch modification to #4144, #9345, #806, #1473, #2189, #2408, #2496, #2528, #2628, #3231, #3628, #4102, #5364, #5466, #5797, #5859, #5982, #5983, #7045, #7161, #7353, #7373, #7634, #7985, #8010, #8345, #8517, #8684, #8767, #8793, #8850, #9043, #9114, #9132, #9236, #9240, #9306, #9330, #9368, #9395, #9434, #9496, #9510, #9526, #9527, #9537, #9542, #9586, #9588, #9631, #9638, #9644, #2614, #3517, #3977, #4413, #4861, #8532, #9283, #9385, #2140, #3065 by thoughtpolice: component to Core Libraries Comment: Moving over to new owning component 'Core Libraries'. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 05:48:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 05:48:48 -0000 Subject: [GHC] Batch modify: #5966, #7473, #7604, #8342, #8482, #9044, #9266, #4215, #5014, #5251 Message-ID: <20141007054848.CC15D3A2FF@ghc.haskell.org> Batch modification to #5966, #7473, #7604, #8342, #8482, #9044, #9266, #4215, #5014, #5251 by thoughtpolice: component to Core Libraries Comment: Moving over to new owning component 'Core Libraries'. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 05:49:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 05:49:29 -0000 Subject: [GHC] Batch modify: #8695, #9079 Message-ID: <20141007054929.291283A2FF@ghc.haskell.org> Batch modification to #8695, #9079 by thoughtpolice: component to Core Libraries Comment: Moving over to new owning component 'Core Libraries'. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 05:50:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 05:50:05 -0000 Subject: [GHC] Batch modify: #1062, #7666 Message-ID: <20141007055005.738EE3A2FF@ghc.haskell.org> Batch modification to #1062, #7666 by thoughtpolice: component to Core Libraries Comment: Moving over to new owning component 'Core Libraries'. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 05:50:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 05:50:20 -0000 Subject: [GHC] Batch modify: #3998, #5761, #7997, #8419, #8844, #8943, #9135, #9292, #9322, #3649, #5376, #2123 Message-ID: <20141007055020.70EE93A2FF@ghc.haskell.org> Batch modification to #3998, #5761, #7997, #8419, #8844, #8943, #9135, #9292, #9322, #3649, #5376, #2123 by thoughtpolice: component to Core Libraries Comment: Moving over to new owning component 'Core Libraries'. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 05:50:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 05:50:46 -0000 Subject: [GHC] Batch modify: #427, #2280, #3575, #3620, #5278 Message-ID: <20141007055046.657533A2FF@ghc.haskell.org> Batch modification to #427, #2280, #3575, #3620, #5278 by thoughtpolice: component to Core Libraries Comment: Moving over to new owning component 'Core Libraries'. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 05:51:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 05:51:05 -0000 Subject: [GHC] Batch modify: #5942, #8621, #8859, #9393, #3980, #5063, #1487, #8293 Message-ID: <20141007055105.808B63A2FF@ghc.haskell.org> Batch modification to #5942, #8621, #8859, #9393, #3980, #5063, #1487, #8293 by thoughtpolice: component to Core Libraries Comment: Moving over to new owning component 'Core Libraries'. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 08:11:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 08:11:53 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.b91a68150d7f8a74af4b8af466a3ea6c@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rehno-lindeque): I have a largish repo of (private) persistent entities I could reformat in order to make public if it would be helpful for anyone working on this. On my macbook air running ubuntu it takes several minutes to build from scratch: {{{ cabal clean && cabal configure && time cabal build real 9m3.969s user 16m2.376s sys 4m9.406s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 08:15:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 08:15:32 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.e6aaca7eb9241171f164ced07fd90d8c@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): One thing that would help woul dbe if someone could characterise where the time is going. Build a profiled compiler (`GhcProfiled=YES` in your `build.mk`) and do some of the above tests. Using `-dshow-passes` also is good at showing if there is a big size blow- up anywhere. My fear is that these deriving clauses simply generate a lot of code, and that (naturally) takes a long time to compile. My hope is that there is a "big eater" somewhere that we can kill. But we need more information, and would appreciate help in getting it. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 08:17:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 08:17:39 -0000 Subject: [GHC] #9658: Prettyprint constraints in type signatures can omit necessary parentheses In-Reply-To: <051.729c40b7d3b349724f12a1d337527b9b@haskell.org> References: <051.729c40b7d3b349724f12a1d337527b9b@haskell.org> Message-ID: <066.440425b0c6f056ca0cdc46397bc11e1b@haskell.org> #9658: Prettyprint constraints in type signatures can omit necessary parentheses -------------------------------------+------------------------------------- Reporter: | Owner: Blaisorblade | Status: new Type: bug | Milestone: 7.8.4 Priority: low | Version: 7.8.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"48089ccf4f1f239b3268b2cb52b8aa0f7356485b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="48089ccf4f1f239b3268b2cb52b8aa0f7356485b" Use correct precedence when printing contexts with class operators Fixes Trac #9658 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 08:26:39 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 08:26:39 -0000 Subject: [GHC] #9368: Add strictly accumulating scanl' to Data.List In-Reply-To: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> References: <045.c5882d9b85fff21d73e20b2d0fb38719@haskell.org> Message-ID: <060.2aa4adfbb6c76e2e3e13f058d5d400b1@haskell.org> #9368: Add strictly accumulating scanl' to Data.List -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #9345 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: core-libraries-committee@? (added) Comment: > Note: this patch does not add scanl' to Data.List, but only to GHC.List. I don't know that I have enough community support as yet to add it publicly, but I want it for Data.List.inits, and it seems sensible (to me) to put it next to scanl. I don?t think there will be doubts about it. It has pretty obvious semantics, and it is clear that it?s nice to have it. If you make a proposal you will get affirmative silence and a +1 from me :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 08:35:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 08:35:52 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.b8fc348aaf106955a0ae483cf130cfe0@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): I've attached show-passes-fpco-api.txt?, which contains the -dshow-passes output for fpco-api's FP.API.Types module. I'll see about getting a profiled compiler built as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 09:25:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 09:25:00 -0000 Subject: [GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> In-Reply-To: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> References: <047.78a9f8902f35fdab762234f4057a7fd3@haskell.org> Message-ID: <062.9aa37d7df0a0c44848286e50005a59e5@haskell.org> #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by tibbe): * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 09:25:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 09:25:18 -0000 Subject: [GHC] #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 In-Reply-To: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> References: <049.1dc64d9da3fa936aad83b3c8f408b65e@haskell.org> Message-ID: <064.cc6ea236a4ab9360f7d8d43c85cd5449@haskell.org> #7898: SpecConstr explodes when compiling module BSP of frag-1.1.2 -------------------------------------+------------------------------------- Reporter: tinctorius | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by tibbe): * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 09:26:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 09:26:13 -0000 Subject: [GHC] #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc-citeproc In-Reply-To: <045.b3bb12ede69a22b49498521b36f8f9a8@haskell.org> References: <045.b3bb12ede69a22b49498521b36f8f9a8@haskell.org> Message-ID: <060.f296489b5b0a8f058a33bc54b92eb1c9@haskell.org> #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc- citeproc -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1 Resolution: fixed | 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 tibbe): * milestone: => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 09:26:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 09:26:31 -0000 Subject: [GHC] #7068: Extensive Memory usage (regression) In-Reply-To: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> References: <048.46c0d25d18210bbbc1624918ba7e4607@haskell.org> Message-ID: <063.a1dff6b99428c5fc201758cdb64f8e65@haskell.org> #7068: Extensive Memory usage (regression) -------------------------------------+------------------------------------- Reporter: waldheinz | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.4.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by tibbe): * milestone: 7.10.1 => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 09:51:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 09:51:11 -0000 Subject: [GHC] #7928: GHC fails to terminate while compiling with optimization level 2 In-Reply-To: <055.5e12f490967583ad649664b167419770@haskell.org> References: <055.5e12f490967583ad649664b167419770@haskell.org> Message-ID: <070.6daf1fe9e33fa3394b927132392fe7df@haskell.org> #7928: GHC fails to terminate while compiling with optimization level 2 -------------------------------------+------------------------------------- Reporter: Ptharien's | Owner: Flame | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #7898, #7944 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * difficulty: => Unknown Comment: Given that it may be related to #8852 that was fixed in HEAD, does it still fail? Could you try HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 10:36:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 10:36:05 -0000 Subject: [GHC] #9658: Prettyprint constraints in type signatures can omit necessary parentheses In-Reply-To: <051.729c40b7d3b349724f12a1d337527b9b@haskell.org> References: <051.729c40b7d3b349724f12a1d337527b9b@haskell.org> Message-ID: <066.4dc858328de798d5b43b1bbe4e5a0596@haskell.org> #9658: Prettyprint constraints in type signatures can omit necessary parentheses -------------------------------------+------------------------------------- Reporter: | Owner: Blaisorblade | Status: closed Type: bug | Milestone: 7.8.4 Priority: low | Version: 7.8.3 Component: GHCi | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: ghci/scripts/T9658 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => ghci/scripts/T9658 * resolution: => fixed Comment: Fixed, thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 11:09:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 11:09:09 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.9a235c40e131e35941ef2ca65dd3715c@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Comment (by simonpj): Here is the state of play on `StaticPtr`, as I understand it today, is this: * [https://ghc.haskell.org/trac/ghc/blog/simonpj/StaticPointers My blog post] represents, I believe, a consensus. * In that blog post, Plan A requires some support from `Typable`/`TypeRep`. A new wiki page [wiki:Typeable] describes a design to do exactly that. This will be new to most of you; take a look. * The [wiki:StaticPointers] wiki page is out of date; Matthieu and Facundo are planning to update it None of this amounts to a full Plan; but it does represent progress. I think Matthieu and Facundo are the main driving forces. I'm hoping that you (perhaps with help from others) will * work through the proposed design a bit more, to check that it does what you need; * develop a plan for how we can more from where we are to the new glorious story with minimum disruption * develop an implementation Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 11:24:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 11:24:27 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.77126967469193572c779aef747633b0@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): I've attached ghc.prof, which is a profile from compiling the Bar.hs module generated by the attached generate.hs. The hotspot appears to be the SimplTopBinds cost center, though my lack of experience with the GHC codebase prevents me from understanding what that means. If there are any other reports (e.g. heap profiles) that would be useful, let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 12:16:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 12:16:14 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.b048113a9438abc3c42776d004c16699@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by augustss): Just to follow up on my last comment. Treating type family names as some kind of type constructors means that we still have logic programming on the type level, just some better syntax for relation symbols that act as functions. I was hoping for functional programming at the type level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 12:42:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 12:42:01 -0000 Subject: [GHC] #9665: Add "since" information to LANGUAGE extensions in GHC user guide In-Reply-To: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> References: <051.0c91deb9283c869eec678c3caa22587e@haskell.org> Message-ID: <066.beb82c25c420643537e40b87362a0dd6@haskell.org> #9665: Add "since" information to LANGUAGE extensions in GHC user guide -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: task | Milestone: Priority: high | Version: 7.9 Component: | Keywords: Documentation | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for it. Can someone submit a doc patch? I strongly suggest implementing it as an extra column in the (allegedly-comprehensive) [http://www.haskell.org/ghc/docs/latest/html/users_guide/flag- reference.html#idp14238080 listing of all extensions], currently section 4.20.12. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 13:45:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 13:45:00 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.b335b5fb092f84590a26462aa256923f@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: kolmodin Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Driver | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by kolmodin): * owner: => kolmodin -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 13:52:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 13:52:47 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.4660d972c46e87746b8c55519fd4d96e@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------ Reporter: carter | Owner: carter Type: feature request | Status: closed Priority: high | Milestone: 7.8.3 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: 9094 | Related Tickets: #8439 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"460eebec65811c6a7bbe11645df322dda868e80d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="460eebec65811c6a7bbe11645df322dda868e80d" Remove RAWCPP_FLAGS Summary: #9094 mentions to "remove the RAW_CPP bits from the ghc build system because they're not longer needed", "once the CPP settings ticket is merged #8683" #8683 was merged with 34f7e9a3c99850859901ca74370f55f1d4e2279a, Phab:D26. Test Plan: harbormaster Reviewers: carter, austin Reviewed By: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D240 GHC Trac Issues: #9094 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 13:52:48 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 13:52:48 -0000 Subject: [GHC] #9094: remove RAW_CPP In-Reply-To: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> References: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> Message-ID: <060.039016d3f307d17b826e0673af4dd710@haskell.org> #9094: remove RAW_CPP -------------------------------------+------------------------------------ Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 8683 Blocking: | Related Tickets: #8683 -------------------------------------+------------------------------------ Comment (by Austin Seipp ): In [changeset:"460eebec65811c6a7bbe11645df322dda868e80d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="460eebec65811c6a7bbe11645df322dda868e80d" Remove RAWCPP_FLAGS Summary: #9094 mentions to "remove the RAW_CPP bits from the ghc build system because they're not longer needed", "once the CPP settings ticket is merged #8683" #8683 was merged with 34f7e9a3c99850859901ca74370f55f1d4e2279a, Phab:D26. Test Plan: harbormaster Reviewers: carter, austin Reviewed By: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D240 GHC Trac Issues: #9094 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 13:54:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 13:54:55 -0000 Subject: [GHC] #9094: remove RAW_CPP In-Reply-To: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> References: <045.99520725c7120b8fcb5e4c616ee15b05@haskell.org> Message-ID: <060.af373871437453ea2640e276564ef8a0@haskell.org> #9094: remove RAW_CPP -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: 8683 None/Unknown | Related Tickets: #8683 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: This should now be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 14:43:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 14:43:20 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.64cc3ab6d3463f381d980f2d45dd3400@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 14:45:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 14:45:01 -0000 Subject: [GHC] #7015: Add support for 'static' In-Reply-To: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> References: <044.1994f384c0e68f47785f0dd81be2574d@haskell.org> Message-ID: <059.c58a09a9777afecf755dd2670ce025a0@haskell.org> #7015: Add support for 'static' -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.4.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D119 | -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => new Comment: Taking out of patch status. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 15:22:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 15:22:12 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.05893dcf743be5e7a23907130ea58e1a@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Can you create a minimal example? I can't run your example in the original post because it has unstated dependencies, and the attached file has a lot of stuff that's presumably unrelated. But, it sounds like you want some sort of type-level injectivity guarantee on a GADT. Interesting thought. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 15:44:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 15:44:47 -0000 Subject: [GHC] #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx In-Reply-To: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> References: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> Message-ID: <061.39552ce3dad1de098881ffe1f7cfc11d@haskell.org> #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by siddhanathan): As of now, the issue is currently present on Yi HEAD (486367706a). 32bit Ubuntu 14.04 with no custom config. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 16:27:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 16:27:21 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.39c0ba0a4347c4097dd5fb44e95d49c3@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, a reproducible example would be great. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 16:41:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 16:41:53 -0000 Subject: [GHC] #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx In-Reply-To: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> References: <046.82a1fe71fb72c9fe5a1faa13b3b7e01c@haskell.org> Message-ID: <061.88f609f82b63c9b201d49250f09cb731@haskell.org> #9657: I found a duplicate definition for symbol: __x86.get_pc_thunk.bx -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => wontfix Comment: The ghci linker doesn't understand whatever magic gcc/binutils uses to deduplicate multiple `__x86.get_pc_thunk.bx` symbols. That's not too surprising, there's a lot of kinds of magic that the ghci linker doesn't understand and this is one of the reasons that in 7.8 ghci uses dynamic libraries by default. I don't think the library author should need to specify `-fpic` in `cc- options` though. Cabal should invoke ghc with `-shared` when building the C files for a dynamic Haskell library, and ghc should then invoke gcc with `-fPIC`. In fact I just tried removing `-fpic` from `vty.cabal` and building it in a sandbox with `--ghc-options=-v` and I see {{{ /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O2 -O2 -x c \ cbits/mk_wcwidth.c -o /tmp/ghc11196_0/ghc11196_1.s -fPIC -U__PIC__ -D__PIC__ \ -Wimplicit -S '-D__GLASGOW_HASKELL__=708' [....] }}} so it seems that Cabal and ghc are both doing the right thing, and the vty author can remove `-fpic`. Maybe submit a bug report there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 18:16:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 18:16:25 -0000 Subject: [GHC] #9067: Optimize clearNursery by short-circuiting when we get to currentNursery In-Reply-To: <045.c7f02cf5a52be23a613e87f34c2ef3ee@haskell.org> References: <045.c7f02cf5a52be23a613e87f34c2ef3ee@haskell.org> Message-ID: <060.46eb9259216b6c462467e974a9846b24@haskell.org> #9067: Optimize clearNursery by short-circuiting when we get to currentNursery -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D318 | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D318 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 18:29:28 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 18:29:28 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.343b92a90f542781d3b8d9e865fc8af2@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): oh, looks like i uploaded the wrong Pair.hs file http://lpaste.net/raw/112106 is the correct one, i'll upload that in a jiffy -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 18:31:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 18:31:10 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.2bb0f2b0a7fd4ca7f8c901e2e3105aef@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): That should load in ghci, and then you can follow the steps in the top level comments to reproduce the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 18:33:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 18:33:13 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.25ba2b479eb044ee313a021b801921e3@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): The only dependencies needed are Vector and Primitive packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 18:52:44 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 18:52:44 -0000 Subject: [GHC] #9356: scanl does not participate in list fusion In-Reply-To: <045.ab578058deeca9329303e3b009a823aa@haskell.org> References: <045.ab578058deeca9329303e3b009a823aa@haskell.org> Message-ID: <060.922ee858d26e846bce2a5975a69dc1d1@haskell.org> #9356: scanl does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"d45693a5384460d22a6437b9cda463b4ec4b6a37/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d45693a5384460d22a6437b9cda463b4ec4b6a37" Make scanl fuse; add scanl' Summary: Make scanl a good producer and a good consumer for fold/build fusion. Add strictly-accumulating scanl', which is required for Data.List.inits. Reviewers: nomeata, austin Reviewed By: austin Subscribers: spacekitteh, thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D314 GHC Trac Issues: #9356 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 19:36:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 19:36:45 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.a93742a50109c3ab32d8a3d3c0989235@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: | Owner: skeuchel Blaisorblade | Status: patch Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: fusion Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: D322 | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * differential: => D322 * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 19:37:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 19:37:13 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.89368823205d871ccb807c78dc3fa8f0@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: | Owner: skeuchel Blaisorblade | Status: patch Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: fusion Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D322 | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: D322 => Phab:D322 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 19:50:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 19:50:25 -0000 Subject: [GHC] #9356: scanl does not participate in list fusion In-Reply-To: <045.ab578058deeca9329303e3b009a823aa@haskell.org> References: <045.ab578058deeca9329303e3b009a823aa@haskell.org> Message-ID: <060.ddd79887408ca3d718364c6c3185408a@haskell.org> #9356: scanl does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 22:03:32 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 22:03:32 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.0a709a53ae45a8d55822a953c19a6a7f@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. The code is indeed pretty big, with a "term size" of over 200,000. A module of a few hundred lines is more like 40,000. The simplifier is run many times over this code so it's perhaps not surprising that it takes most of the compile time. Still, I wonder if there is anything non-linear going on, tickled by the form of the boilerplate code. The occurrence analyser runs exacty as often as the simplifier, yet only uses 5% of the time. You could try adding `-auto-all` (or whatever the flag is) for `Simplify` to get more detailed cost centre information on the simplifier? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 7 22:09:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Oct 2014 22:09:12 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.bd70d64ded237a43e4f2f77edce3143c@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Lennart, I don't understand comment:19 at all. Can you give an example to illustrate what you mean? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 06:11:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 06:11:01 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.82b99eadacefc80e21e7238445184925@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): I'd be happy to add the appropriate flag... but I'm afraid I don't really know the right way to do it. Is anyone reading this able to give me some advice? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 06:53:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 06:53:26 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.49e359765090165173ae87c9ab87a691@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: | Owner: skeuchel Blaisorblade | Status: patch Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: fusion Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D322 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"d14d3f92d55a352db7faf62939127060716c4694/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d14d3f92d55a352db7faf62939127060716c4694" Make Data.List.takeWhile fuse: fix #9132 Summary: Rewrites takeWhile to a build/foldr form; fuses repeated applications of takeWhile. Reviewers: nomeata, austin Reviewed By: nomeata Subscribers: thomie, carter, ezyang, simonmar Projects: #ghc Differential Revision: https://phabricator.haskell.org/D322 GHC Trac Issues: #9132 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 07:26:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 07:26:48 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.97ea8a930085a83e6a6f3f1ccee54964@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by dreixel): I don't see what's the issue with `type-eq`. Simply changing the imports in `Type.Eq.Poly` and `Type.Eq.Higher` from {{{ import Data.OldTypeable hiding (cast) }}} to {{{ import Data.Typeable hiding (cast, (:~:)) }}} seems to work. If this is the only example we could find on Hackage, I think it's safe to go ahead and remove `OldTypeable`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 07:34:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 07:34:00 -0000 Subject: [GHC] #9649: symbols should/might be type level lists of chars In-Reply-To: <045.7eed415602713344419f19bba35ae3f7@haskell.org> References: <045.7eed415602713344419f19bba35ae3f7@haskell.org> Message-ID: <060.c775e49e273c62887cb358a8327157fa@haskell.org> #9649: symbols should/might be type level lists of chars -------------------------------------+------------------------------------- Reporter: ibotty | Owner: ibotty Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * cc: simonpj@?, diatchki@? (added) Comment: Richard: I didn't think of that workaround you propose, but it might just work, yes. Still, if ibotty would want to work on this, could simonpj and/or iavor provide some guidance? I too have found this problem annoying, as right now you can't really do much with `Symbol`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 09:40:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 09:40:07 -0000 Subject: [GHC] #9670: Make Data.List.tails a good producer for list fusion Message-ID: <045.53ecc54eb7a39dea158b99c57adf8e43@haskell.org> #9670: Make Data.List.tails a good producer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.3 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Its structure is trivially an unfold, so it should work well as a producer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 09:41:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 09:41:08 -0000 Subject: [GHC] #9670: Make Data.List.tails a good producer for list fusion In-Reply-To: <045.53ecc54eb7a39dea158b99c57adf8e43@haskell.org> References: <045.53ecc54eb7a39dea158b99c57adf8e43@haskell.org> Message-ID: <060.5a4400bc86236b1c8d058fe871e02e02@haskell.org> #9670: Make Data.List.tails a good producer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: fusion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D325 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D325 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 10:56:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 10:56:27 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.d17ac79bf8ade9f444ba6b97a85b0b26@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): It's `-fprof-auto`. Manual page [http://www.haskell.org/ghc/docs/latest/html/users_guide/flag- reference.html#idp14739632 here]. Sorry was on train. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 13:35:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 13:35:23 -0000 Subject: [GHC] #9662: stack overflow in type checker In-Reply-To: <046.dd8b7f2f1cb39f3fdbde8cd7b54fa2d7@haskell.org> References: <046.dd8b7f2f1cb39f3fdbde8cd7b54fa2d7@haskell.org> Message-ID: <061.75c350babfa00d75642e617894ec390b@haskell.org> #9662: stack overflow in type checker -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Whoa! That is a real bug. Interestingly, it's fine in GHC 7.6. I'll make sure it gets fixed in HEAD at least. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 14:31:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 14:31:51 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.0bed3c400672f91a1cb44055d4ee1361@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by ekmett): I have no objection to pulling the plug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 19:41:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 19:41:38 -0000 Subject: [GHC] #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm In-Reply-To: <045.3ecedf0980b076ccd1110fcb386f8214@haskell.org> References: <045.3ecedf0980b076ccd1110fcb386f8214@haskell.org> Message-ID: <060.cbe5307ba5f0817f4599f3f2992313f2@haskell.org> #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: tc124 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): What is odd is it does not fail in norma mode. Only in the following modes (today's -HEAD): {{{ Unexpected failures: typecheck/should_compile tc124 [exit code non-0] (hpc,optasm,optllvm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 19:52:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 19:52:59 -0000 Subject: [GHC] #8849: Unregisterised compiler: arithmetic failure In-Reply-To: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> References: <047.9ee4d36bdad2511c808fcc03f7b6b140@haskell.org> Message-ID: <062.ba3dec5d4fbda24b170ad39d1c35fcc5@haskell.org> #8849: Unregisterised compiler: arithmetic failure -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Easy (less than 1 result at runtime | hour) Test Case: arith005 | Blocked By: Blocking: 8819 | Related Tickets: #8819 Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * priority: normal => high * difficulty: Unknown => Easy (less than 1 hour) Comment: This ticket blocks #8819 which is priority high. The commit mentioned in comment:5 applied cleanly when I prepared a patch file for the released 7.8.3 tarball. You should be able to just cherry- pick it. If not, please assign the ticket to me and let me know what you prefer: phabricator, patch file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 8 22:36:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Oct 2014 22:36:41 -0000 Subject: [GHC] #9671: Allow expressions in patterns Message-ID: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: patterns, pattern | Operating System: synonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've outlined a proposal for extending pattern synonyms to depend on terms (PatternFamilies), the name is less than ideal but I'll keep the page under that name for now. The proposal's introduction has been rewritten. The simplest use case are patterns that matches only when a set contains an element (`IsMember`) or when a set does not contain an element (`NotMember`): [[Image(wiki:PatternFamilies:member.png)]] {{{#!hs hasKeys :: Set Item -> IO () hasKeys (IsMember "keys") = leaveHouse hasKeys (NotMember "keys") = findKeys >> leaveHouse }}} or a pattern that matches a map if the key exists: [[Image(wiki:PatternFamilies:lookup.png)]] used like this: {{{#!hs age :: Map Person Age -> String age (Lookup "Alice" 60) = "Alice is 60 years old!" age (Lookup "Alice" age) = "Alice is " ++ show age ++ "." age (Lookup "Bob" _) = "No info on Alice but we know how old Bob is." age _ = "..." }}} Further details and examples can be found here: PatternFamilies, I discussed it with several people ICFP 2014. This would not require a new extension but would extend PatternSynonyms. This feature can be quite useful, especially when working with deeply nested structures (ASTs, JSON, XML, ...). If people are fine with it I will implement it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 9 02:24:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Oct 2014 02:24:45 -0000 Subject: [GHC] #9388: Narrow the scope of the notorious "state hack" In-Reply-To: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> References: <046.7a09c98dccc7fdc88e7d6487f232f87a@haskell.org> Message-ID: <061.7ce1dfd2a8a3faebe9ea0c20f060bbde@haskell.org> #9388: Narrow the scope of the notorious "state hack" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 9 07:27:57 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Oct 2014 07:27:57 -0000 Subject: [GHC] #1257: Bytecode generator can't handle unboxed tuples In-Reply-To: <044.e337dd273e83366d6de11ad7555ce4f4@haskell.org> References: <044.e337dd273e83366d6de11ad7555ce4f4@haskell.org> Message-ID: <059.11d4ffdc1936b1081d12d1f6a8156347@haskell.org> #1257: Bytecode generator can't handle unboxed tuples -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.4.1 Component: GHCi | Version: 6.6 Resolution: wontfix | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: dsrun014 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): The problem is at the boundary between compiled code and interpreted code. We have a few special-purpose stack frames that do the impedence matching between the two worlds, one for each return convention. The problem with unboxed tuples is that there aren't a fixed number of return conventions, so we can't cover all the cases with a few stack frames. I haven't thought about this for a long term, but perhaps there's a way to make a generic stack frame that takes some kind of descriptor to describe the convention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 9 11:59:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Oct 2014 11:59:47 -0000 Subject: [GHC] #9672: Error message too long (full case statement printed) Message-ID: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> #9672: Error message too long (full case statement printed) -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Imho, it does not make sense to print the other branches of a case when a type error is discovered in one branch. When you see the following example, you will agree with me. {{{ src/full/Agda/TypeChecking/Errors.hs:540:35: Couldn't match type ?[Char]? with ?TCMT IO Doc? Expected type: TCM Doc Actual type: [Char] In the expression: "Module cannot be imported since it has open interaction points" In a case alternative: SolvedButOpenHoles -> "Module cannot be imported since it has open interaction points" In a stmt of a 'do' block: }}} {{{#!hs case err of { InternalError s -> panic s NotImplemented s -> fwords $ "Not implemented: " ++ s NotSupported s -> fwords $ "Not supported: " ++ s CompilationError s -> sep [fwords "Compilation error:", text s] GenericError s -> fwords s GenericDocError d -> return d TerminationCheckFailed because -> fwords "Termination checking failed for the following functions:" $$ (nest 2 $ fsep $ punctuate comma $ map (pretty . dropTopLevelModule) $ concatMap termErrFunctions because) $$ fwords "Problematic calls:" $$ (nest 2 $ fmap (P.vcat . nub) $ mapM prettyTCM $ sortBy (compare `on` callInfoRange) $ concatMap termErrCalls because) PropMustBeSingleton -> fwords "Datatypes in Prop must have at most one constructor when proof irrelevance is enabled" DataMustEndInSort t -> fsep $ pwords "The type of a datatype must end in a sort." ++ [prettyTCM t] ++ pwords "isn't a sort." ShouldEndInApplicationOfTheDatatype t -> fsep $ pwords "The target of a constructor must be the datatype applied to its parameters," ++ [prettyTCM t] ++ pwords "isn't" ShouldBeAppliedToTheDatatypeParameters s t -> fsep $ pwords "The target of the constructor should be" ++ [prettyTCM s] ++ pwords "instead of" ++ [prettyTCM t] ShouldBeApplicationOf t q -> fsep $ pwords "The pattern constructs an element of" ++ [prettyTCM q] ++ pwords "which is not the right datatype" ShouldBeRecordType t -> fsep $ pwords "Expected non-abstract record type, found " ++ [prettyTCM t] ShouldBeRecordPattern p -> fsep $ pwords "Expected record pattern" NotAProjectionPattern p -> fsep $ pwords "Not a valid projection for a copattern: " ++ [prettyA p] DifferentArities -> fwords "The number of arguments in the defining equations differ" WrongHidingInLHS -> do { fwords "Unexpected implicit argument" } WrongHidingInLambda t -> do { fwords "Found an implicit lambda where an explicit lambda was expected" } WrongIrrelevanceInLambda t -> do { fwords "Found an irrelevant lambda where a relevant lambda was expected" } WrongNamedArgument a -> fsep $ pwords "Function does not accept argument " ++ [prettyTCM a] WrongHidingInApplication t -> do { fwords "Found an implicit application where an explicit application was expected" } HidingMismatch h h' -> fwords $ "Expected " ++ verbalize (Indefinite h') ++ " argument, but found " ++ verbalize (Indefinite h) ++ " argument" RelevanceMismatch r r' -> fwords $ "Expected " ++ verbalize (Indefinite r') ++ " argument, but found " ++ verbalize (Indefinite r) ++ " argument" ColorMismatch c c' -> fsep $ pwords "Expected argument color to be" ++ [prettyTCM c'] ++ pwords "but found color" ++ [prettyTCM c] NotInductive t -> fsep $ [prettyTCM t] ++ pwords "is not an inductive data type" UninstantiatedDotPattern e -> fsep $ pwords "Failed to infer the value of dotted pattern" IlltypedPattern p a -> fsep $ pwords "Type mismatch" IllformedProjectionPattern p -> fsep $ pwords "Ill-formed projection pattern " ++ [prettyA p] CannotEliminateWithPattern p a -> do { let ...; fsep $ pwords "Cannot eliminate type" ++ prettyTCM a : if isProj then pwords "with projection pattern" ++ ... else pwords "with pattern" ++ prettyA p : pwords "(did you supply too many arguments?)" } TooManyArgumentsInLHS a -> fsep $ pwords "Left hand side gives too many arguments to a function of type" ++ [prettyTCM a] WrongNumberOfConstructorArguments c expect given -> fsep $ pwords "The constructor" ++ [prettyTCM c] ++ pwords "expects" ++ [text (show expect)] ++ pwords "arguments (including hidden ones), but has been given" ++ [text (show given)] ++ pwords "(including hidden ones)" CantResolveOverloadedConstructorsTargetingSameDatatype d cs -> fsep $ pwords ("Can't resolve overloaded constructors targeting the same datatype (" ++ show (qnameToConcrete d) ++ "):") ++ map pretty cs DoesNotConstructAnElementOf c t -> fsep $ pwords "The constructor" ++ [prettyTCM c] ++ pwords "does not construct an element of" ++ [prettyTCM t] ConstructorPatternInWrongDatatype c d -> fsep $ [prettyTCM c] ++ pwords "is not a constructor of the datatype" ++ [prettyTCM d] IndicesNotConstructorApplications [i] -> fwords "The index" $$ nest 2 (prettyTCM i) $$ fsep (pwords "is not a constructor (or literal) applied to variables" ++ pwords "(note that parameters count as constructor arguments)") IndicesNotConstructorApplications is -> fwords "The indices" $$ nest 2 (vcat $ map prettyTCM is) $$ fsep (pwords "are not constructors (or literals) applied to variables" ++ pwords "(note that parameters count as constructor arguments)") IndexVariablesNotDistinct vs is -> fwords "The variables" $$ nest 2 (vcat $ map (\ v -> prettyTCM (I.Var v [])) vs) $$ fwords "in the indices" $$ nest 2 (vcat $ map prettyTCM is) $$ fwords "are not distinct (note that parameters count as constructor arguments)" IndicesFreeInParameters vs indices pars -> fwords "The variables" $$ nest 2 (vcat $ map (\ v -> prettyTCM (I.Var v [])) vs) $$ fwords "which are used (perhaps as constructor parameters) in the index expressions" $$ nest 2 (vcat $ map prettyTCM indices) $$ fwords "are free in the parameters" $$ nest 2 (vcat $ map prettyTCM pars) ShadowedModule x [] -> (throwImpossible (Impossible "src/full/Agda/TypeChecking/Errors.hs" 404)) ShadowedModule x ms@(m : _) -> fsep $ pwords "Duplicate definition of module" ++ [prettyTCM x <> text "."] ++ pwords "Previous definition of" ++ [help m] ++ pwords "module" ++ [prettyTCM x] ++ pwords "at" ++ [prettyTCM r] where help m = do { ... } r = case ... of { [] -> ... r : _ -> ... } defSiteOfLast [] = noRange defSiteOfLast ns = nameBindingSite (last ns) ModuleArityMismatch m EmptyTel args -> fsep $ pwords "The module" ++ [prettyTCM m] ++ pwords "is not parameterized, but is being applied to arguments" ModuleArityMismatch m tel@(ExtendTel _ _) args -> fsep $ pwords "The arguments to " ++ [prettyTCM m] ++ pwords "does not fit the telescope" ++ [prettyTCM tel] ShouldBeEmpty t [] -> fsep $ [prettyTCM t] ++ pwords "should be empty, but that's not obvious to me" ShouldBeEmpty t ps -> fsep ([prettyTCM t] ++ pwords "should be empty, but the following constructor patterns are valid:") $$ nest 2 (vcat $ map (showPat 0) ps) ShouldBeASort t -> fsep $ [prettyTCM t] ++ pwords "should be a sort, but it isn't" ShouldBePi t -> fsep $ [prettyTCM t] ++ pwords "should be a function type, but it isn't" NotAProperTerm -> fwords "Found a malformed term" SetOmegaNotValidType -> fwords "Set\969 is not a valid type" InvalidType v -> fsep $ [prettyTCM v] ++ pwords "is not a valid type" SplitOnIrrelevant p t -> fsep $ pwords "Cannot pattern match" ++ [prettyA p] ++ pwords "against irrelevant type" ++ [prettyTCM t] DefinitionIsIrrelevant x -> fsep $ text "Identifier" : prettyTCM x : pwords "is declared irrelevant, so it cannot be used here" VariableIsIrrelevant x -> fsep $ text "Variable" : prettyTCM x : pwords "is declared irrelevant, so it cannot be used here" UnequalBecauseOfUniverseConflict cmp s t -> fsep $ [prettyTCM s, notCmp cmp, ....] UnequalTerms cmp s t a -> do { (d1, d2, d) <- prettyInEqual s t; fsep $ [...] ++ pwords "of type" ++ [...] ++ [...] } UnequalTypes cmp a b -> prettyUnequal a (notCmp cmp) b UnequalColors a b -> error "TODO guilhem 4" HeterogeneousEquality u a v b -> fsep $ pwords "Refuse to solve heterogeneous constraint" ++ [prettyTCM u] ++ pwords ":" ++ [prettyTCM a] ++ pwords "=?=" ++ [prettyTCM v] ++ pwords ":" ++ [prettyTCM b] UnequalRelevance cmp a b -> fsep $ [prettyTCM a, notCmp cmp, ....] ++ pwords "because one is a relevant function type and the other is an irrelevant function type" UnequalHiding a b -> fsep $ [prettyTCM a, text "!=", ....] ++ pwords "because one is an implicit function type and the other is an explicit function type" UnequalSorts s1 s2 -> fsep $ [prettyTCM s1, text "!=", ....] NotLeqSort s1 s2 -> fsep $ pwords "The type of the constructor does not fit in the sort of the datatype, since" ++ [prettyTCM s1] ++ pwords "is not less or equal than" ++ [prettyTCM s2] TooFewFields r xs -> fsep $ pwords "Missing fields" ++ punctuate comma (map pretty xs) ++ pwords "in an element of the record" ++ [prettyTCM r] TooManyFields r xs -> fsep $ pwords "The record type" ++ [prettyTCM r] ++ pwords "does not have the fields" ++ punctuate comma (map pretty xs) DuplicateConstructors xs -> fsep $ pwords "Duplicate constructors" ++ punctuate comma (map pretty xs) ++ pwords "in datatype" DuplicateFields xs -> fsep $ pwords "Duplicate fields" ++ punctuate comma (map pretty xs) ++ pwords "in record" UnexpectedWithPatterns ps -> fsep $ pwords "Unexpected with patterns" ++ (punctuate (text " |") $ map prettyA ps) WithClausePatternMismatch p q -> fsep $ pwords "With clause pattern " ++ [prettyA p] ++ pwords " is not an instance of its parent pattern " ++ [prettyTCM q] MetaCannotDependOn m ps i -> fsep $ pwords "The metavariable" ++ [prettyTCM $ MetaV m []] ++ pwords "cannot depend on" ++ [pvar i] ++ pwords "because it" ++ deps where pvar = prettyTCM . var deps = case map pvar ps of { [] -> ... [x] -> ... xs -> ... } MetaOccursInItself m -> fsep $ pwords "Cannot construct infinite solution of metavariable" ++ [prettyTCM $ MetaV m []] BuiltinMustBeConstructor s e -> fsep $ [prettyA e] ++ pwords "must be a constructor in the binding to builtin" ++ [text s] NoSuchBuiltinName s -> fsep $ pwords "There is no built-in thing called" ++ [text s] DuplicateBuiltinBinding b x y -> fsep $ pwords "Duplicate binding for built-in thing" ++ [text b <> comma] ++ pwords "previous binding to" ++ [prettyTCM x] NoBindingForBuiltin x -> fsep $ pwords "No binding for builtin thing" ++ [text x <> comma] ++ pwords ("use {-# BUILTIN " ++ x ++ " name #-} to bind it to 'name'") NoSuchPrimitiveFunction x -> fsep $ pwords "There is no primitive function called" ++ [text x] BuiltinInParameterisedModule x -> fwords $ "The BUILTIN pragma cannot appear inside a bound context " ++ "(for instance, in a parameterised module or as a local declaration)" IllegalLetInTelescope tb -> fsep $ [pretty tb] ++ pwords " is not allowed in a telescope here." NoRHSRequiresAbsurdPattern ps -> fwords $ "The right-hand side can only be omitted if there " ++ "is an absurd pattern, () or {}, in the left-hand side." AbsurdPatternRequiresNoRHS ps -> fwords $ "The right-hand side must be omitted if there " ++ "is an absurd pattern, () or {}, in the left-hand side." LocalVsImportedModuleClash m -> fsep $ pwords "The module" ++ [text $ show m] ++ pwords "can refer to either a local module or an imported module" SolvedButOpenHoles -> "Module cannot be imported since it has open interaction points" UnsolvedMetas rs -> fsep (pwords "Unsolved metas at the following locations:") $$ nest 2 (vcat $ map prettyTCM rs) UnsolvedConstraints cs -> fsep (pwords "Failed to solve the following constraints:") $$ nest 2 (vcat $ map prettyConstraint cs) where prettyConstraint :: ProblemConstraint -> TCM Doc prettyConstraint c = f (prettyTCM c) where r = ... .... CyclicModuleDependency ms -> fsep (pwords "cyclic module dependency:") $$ nest 2 (vcat $ map pretty ms) FileNotFound x files -> fsep (pwords "Failed to find source of module" ++ [pretty x] ++ pwords "in any of the following locations:") $$ nest 2 (vcat $ map (text . filePath) files) OverlappingProjects f m1 m2 -> fsep (pwords "The file" ++ [text (filePath f)] ++ pwords "can be accessed via several project roots. Both" ++ [pretty m1] ++ pwords "and" ++ [pretty m2] ++ pwords "point to this file.") AmbiguousTopLevelModuleName x files -> fsep (pwords "Ambiguous module name. The module name" ++ [pretty x] ++ pwords "could refer to any of the following files:") $$ nest 2 (vcat $ map (text . filePath) files) ClashingFileNamesFor x files -> fsep (pwords "Multiple possible sources for module" ++ [text $ show x] ++ pwords "found:") $$ nest 2 (vcat $ map (text . filePath) files) ModuleDefinedInOtherFile mod file file' -> fsep $ pwords "You tried to load" ++ [text (filePath file)] ++ pwords "which defines the module" ++ [pretty mod <> text "."] ++ pwords "However, according to the include path this module should" ++ pwords "be defined in" ++ [text (filePath file') <> text "."] ModuleNameDoesntMatchFileName given files -> fsep (pwords "The name of the top level module does not match the file name. The module" ++ [pretty given] ++ pwords "should be defined in one of the following files:") $$ nest 2 (vcat $ map (text . filePath) files) BothWithAndRHS -> fsep $ pwords "Unexpected right hand side" NotInScope xs -> fsep (pwords "Not in scope:") $$ nest 2 (vcat $ map name xs) where name x = fsep [...] suggestion s | elem ':' s = parens $ text "did you forget space around the ':'?" | elem "->" two = parens $ text "did you forget space around the '->'?" | otherwise = empty where two = ... NoSuchModule x -> fsep $ pwords "No such module" ++ [pretty x] AmbiguousName x ys -> vcat [fsep $ pwords "Ambiguous name" ++ [...] ++ pwords "It could refer to any one of", nest 2 $ vcat $ map nameWithBinding ys, ....] AmbiguousModule x ys -> vcat [fsep $ pwords "Ambiguous module name" ++ [...] ++ pwords "It could refer to any one of", nest 2 $ vcat $ map help ys, ....] where help :: ModuleName -> TCM Doc help m = do { ... } UninstantiatedModule x -> fsep (pwords "Cannot access the contents of the parameterised module" ++ [pretty x <> text "."] ++ pwords "To do this the module first has to be instantiated. For instance:") $$ nest 2 (hsep [text "module", pretty x <> text "'", ....]) ClashingDefinition x y -> fsep $ pwords "Multiple definitions of" ++ [pretty x <> text "."] ++ pwords "Previous definition at" ++ [prettyTCM $ nameBindingSite $ qnameName y] ClashingModule m1 m2 -> fsep $ pwords "The modules" ++ [prettyTCM m1, text "and", ....] ++ pwords "clash." ClashingImport x y -> fsep $ pwords "Import clash between" ++ [pretty x, text "and", ....] ClashingModuleImport x y -> fsep $ pwords "Module import clash between" ++ [pretty x, text "and", ....] PatternShadowsConstructor x c -> fsep $ pwords "The pattern variable" ++ [prettyTCM x] ++ pwords "has the same name as the constructor" ++ [prettyTCM c] DuplicateImports m xs -> fsep $ pwords "Ambiguous imports from module" ++ [pretty m] ++ pwords "for" ++ punctuate comma (map pretty xs) ModuleDoesntExport m xs -> fsep $ pwords "The module" ++ [pretty m] ++ pwords "doesn't export the following:" ++ punctuate comma (map pretty xs) NotAModuleExpr e -> fsep $ pwords "The right-hand side of a module definition must have the form 'M e1 .. en'" ++ pwords "where M is a module name. The expression" ++ [pretty e, text "doesn't."] FieldOutsideRecord -> fsep $ pwords "Field appearing outside record declaration." InvalidPattern p -> fsep $ pretty p : pwords "is not a valid pattern" RepeatedVariablesInPattern xs -> fsep $ pwords "Repeated variables in left hand side:" ++ map pretty xs NotAnExpression e -> fsep $ [pretty e] ++ pwords "is not a valid expression." NotAValidLetBinding nd -> fwords $ "Not a valid let-declaration" NothingAppliedToHiddenArg e -> fsep $ [pretty e] ++ pwords "cannot appear by itself. It needs to be the argument to" ++ pwords "a function expecting an implicit argument." NothingAppliedToInstanceArg e -> fsep $ [pretty e] ++ pwords "cannot appear by itself. It needs to be the argument to" ++ pwords "a function expecting an instance argument." NoParseForApplication es -> fsep $ pwords "Could not parse the application" ++ [pretty $ C.RawApp noRange es] AmbiguousParseForApplication es es' -> fsep (pwords "Don't know how to parse" ++ [pretty_es <> (text ".")] ++ pwords "Could mean any one of:") $$ nest 2 (vcat $ map pretty' es') where pretty_es :: TCM Doc pretty_es = pretty $ C.RawApp noRange es pretty' :: C.Expr -> TCM Doc .... BadArgumentsToPatternSynonym x -> fsep $ pwords "Bad arguments to pattern synonym " ++ [prettyTCM x] TooFewArgumentsToPatternSynonym x -> fsep $ pwords "Too few arguments to pattern synonym " ++ [prettyTCM x] UnusedVariableInPatternSynonym -> fsep $ pwords "Unused variable in pattern synonym." NoParseForLHS IsLHS p -> fsep $ pwords "Could not parse the left-hand side" ++ [pretty p] NoParseForLHS IsPatSyn p -> fsep $ pwords "Could not parse the pattern synonym" ++ [pretty p] AmbiguousParseForLHS lhsOrPatSyn p ps -> fsep (pwords "Don't know how to parse" ++ [pretty_p <> text "."] ++ pwords "Could mean any one of:") $$ nest 2 (vcat $ map pretty' ps) where pretty_p :: TCM Doc pretty_p = pretty p pretty' :: C.Pattern -> TCM Doc .... IncompletePatternMatching v args -> fsep $ pwords "Incomplete pattern matching for" ++ [prettyTCM v <> text "."] ++ pwords "No match for" ++ map prettyTCM args UnreachableClauses f pss -> fsep $ pwords "Unreachable" ++ pwords (plural (length pss) "clause") where plural 1 thing = thing plural n thing = thing ++ "s" CoverageFailure f pss -> fsep (pwords "Incomplete pattern matching for" ++ [prettyTCM f <> text "."] ++ pwords "Missing cases:") $$ nest 2 (vcat $ map display pss) where display ps = do { ... } nicify f ps = do { ... } CoverageCantSplitOn c tel cIxs gIxs | length cIxs /= length gIxs -> (throwImpossible (Impossible "src/full/Agda/TypeChecking/Errors.hs" 750)) | otherwise -> addCtxTel tel $ vcat ([fsep $ pwords "I'm not sure if there should be a case for the constructor" ++ [...] ++ pwords "because I get stuck when trying to solve the following" ++ pwords "unification problems (inferred index \8799 expected index):"] ++ zipWith (\ c g -> nest 2 $ prettyTCM c <+> text "\8799" <+> prettyTCM g) cIxs gIxs) CoverageCantSplitIrrelevantType a -> fsep $ pwords "Cannot split on argument of irrelevant datatype" ++ [prettyTCM a] CoverageCantSplitType a -> fsep $ pwords "Cannot split on argument of non-datatype" ++ [prettyTCM a] SplitError e -> prettyTCM e WithoutKError a u v -> fsep $ pwords "Cannot eliminate reflexive equation" ++ [prettyTCM u] ++ pwords "=" ++ [prettyTCM v] ++ pwords "of type" ++ [prettyTCM a] ++ pwords "because K has been disabled." NotStrictlyPositive d ocs -> fsep $ pwords "The datatype" ++ [prettyTCM d] ++ pwords "is not strictly positive, because" ++ prettyOcc "it" ocs where prettyOcc _ [] = [] prettyOcc it (OccCon d c r : ocs) = concat [...] prettyOcc it (OccClause f n r : ocs) = concat [...] prettyR NonPositively = pwords "negatively" prettyR (ArgumentTo i q) = pwords "as the" ++ [...] ++ pwords "argument to" ++ [...] th 0 = text "first" th 1 = text "second" th 2 = text "third" th n = text (show $ n - 1) <> text "th" .... IFSNoCandidateInScope t -> fsep $ pwords "No variable of type" ++ [prettyTCM t] ++ pwords "was found in scope." SafeFlagPostulate e -> fsep $ pwords "Cannot postulate" ++ [pretty e] ++ pwords "with safe flag" SafeFlagPragma xs -> let plural | length xs == 1 = ... | otherwise = ... in fsep $ [fwords ("Cannot set OPTION pragma" ++ plural)] ++ map text xs ++ [fwords "with safe flag."] SafeFlagNoTerminationCheck -> fsep (pwords "Cannot use NO_TERMINATION_CHECK pragma with safe flag.") SafeFlagNonTerminating -> fsep (pwords "Cannot use NON_TERMINATING pragma with safe flag.") SafeFlagTerminating -> fsep (pwords "Cannot use TERMINATING pragma with safe flag.") SafeFlagPrimTrustMe -> fsep (pwords "Cannot use primTrustMe with safe flag") NeedOptionCopatterns -> fsep (pwords "Option --copatterns needed to enable destructor patterns") } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 9 14:01:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Oct 2014 14:01:29 -0000 Subject: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations In-Reply-To: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> References: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> Message-ID: <063.d9fe87cb92497973d201f8b08ef53aba@haskell.org> #7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime | Version: 7.6.1 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Feuerbach): Another report of this bug: https://github.com/haskell- fswatch/hfsnotify/issues/51 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 9 14:37:34 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Oct 2014 14:37:34 -0000 Subject: [GHC] #9672: Error message too long (full case statement printed) In-Reply-To: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> References: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> Message-ID: <066.7d490590c37b7354acd30f9ad6d65ae6@haskell.org> #9672: Error message too long (full case statement printed) -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Totally agree. But it's not entirely straightforward * The other branches might be highly relevant. Eg {{{ f x = case x of True -> False False -> 'x' }}} * The printing machinery doesn't (currently) know or take account of where the original focus point was. Making it do so would be possible, but would take real work. I'd be happy if someone wanted to develop ideas here. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 9 15:20:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Oct 2014 15:20:41 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.635ab04c47008f1b6c91849d5a93e478@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D246 | -------------------------------------+------------------------------------- Comment (by simonpj): I'm afraid I'm very confused by this thread. * There are two different Phab tickets: Phab:D246 is linked to this ticket, but Phab:D297 (I believe) may supercede it. If so please let's redirect the "Differential revision" field of this ticket, and explicit mark the moribund one as moribund. * The wiki page GhcAstAnnotations does not appear to reflect any of the discussion. Indeed it appears to describe only the first bullet from comment:3 * comment:3 identifies two issues, which Alan (in comment:4) agreed were separate. Yet [http://www.haskell.org/pipermail/ghc- devs/2014-October/006487.html Neil certainly thinks] that the new Phab:D297 is exclusively about issue 1. So maybe the new design encompasses both issue 1 and issue 2? I have no idea. * There has been quite a lot of [http://www.haskell.org/pipermail/ghc- devs/2014-October/006482.html traffic on ghc-devs] that is not captured anywhere. That's fine: an email list is good for discussion. But my input bandwidth is low and struggle to make sense of it all. And the conclusions from the discussion may be useful. * Alan has posted a [http://www.haskell.org/pipermail/haskell- cafe/2014-October/116267.html useful summary] to Haskell Cafe, which isn't captured on a wiki anywhere. * Alan has done some work identifying users for the new features, and written some email notes about that; again this would be useful to capture. I am too slow to take a big patch and try to reverse-engineer the thought process that went into it. Would be possible to update the wiki page (presumably GhcAstAnnotations) to state * The problem we are trying to solve * The user-visible (or at least visible-to-client-of-GHC-API) design * Other notes about the implementation. Covering the larger picture about the GHC API improvements you are making (eg no landmines) would be helpful. Maybe you need more than one page. I'm delighted you are doing this. But I don't want to throw a lot of code into GHC without a clear, shared consensus about what it is we are trying do to, and how we are doing it. Thanks. Simon (drowning in review requests) PJ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 9 15:35:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Oct 2014 15:35:31 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.5641fc4a8c42301ce218222caf9d2a5e@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Changes (by alanz): * differential: D246 => D297 * version: 7.8.3 => 7.9 Old description: > Two different kinds of annotation are proposed to be added to HsSyn > > 1. Additional elements to explictly track the location of all syntactic > elements not currently tracked. In particular, locations of reserved > words and punctuation. > > 2. A top-level type parameter that allows a tool-writer to thread an > application-specific annotation through the syntax tree. > > These two could potentially be merged, if the default annotation > parameter is capable of tracking the first category of information. > > Discussion of the feature is at GhcAstAnnotations New description: Add Annotations to HsSyn to explicitly track the locations of all non- blank source code elements to allow tools to parse a Haskell file, modify the AST and then produce an updated version of the source preserving the layout for unchanged parts. Discussion of the feature is at GhcAstAnnotations Note: an early effort was at Phab:D297, but this was abandoned as unworkable. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 9 15:36:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Oct 2014 15:36:45 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.3bc4a7c31e1368bf1a0bcbd3fa4a705e@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Description changed by alanz: Old description: > Add Annotations to HsSyn to explicitly track the locations of all non- > blank source code elements to allow tools to parse a Haskell file, modify > the AST and then produce an updated version of the source preserving the > layout for unchanged parts. > > Discussion of the feature is at GhcAstAnnotations > > Note: an early effort was at Phab:D297, but this was abandoned as > unworkable. New description: Add Annotations to HsSyn to explicitly track the locations of all non- blank source code elements to allow tools to parse a Haskell file, modify the AST and then produce an updated version of the source preserving the layout for unchanged parts. Discussion of the feature is at GhcAstAnnotations Note: an early effort was at Phab:D246, but this was abandoned as unworkable. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 9 19:13:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Oct 2014 19:13:02 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.ab46033d2b9fef91e9966102118c5d73@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): I have updated the Wiki page to reflect the current status, including an overview of the current design https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations#design I have also captured the summary status in GhcApiWorkInProgress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 9 19:38:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Oct 2014 19:38:40 -0000 Subject: [GHC] #9660: unnecessary indirect jump when returning a case scrutinee In-Reply-To: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> References: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> Message-ID: <062.7c5b4f321cb66adf0e028d9e5a3d844b@haskell.org> #9660: unnecessary indirect jump when returning a case scrutinee -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by schyler): Could you show the core difference (for us who don't really understand the original ticket that well)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 9 22:44:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Oct 2014 22:44:40 -0000 Subject: [GHC] #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm In-Reply-To: <045.3ecedf0980b076ccd1110fcb386f8214@haskell.org> References: <045.3ecedf0980b076ccd1110fcb386f8214@haskell.org> Message-ID: <060.7360e25dc253cc894940c3be6ef8f57a@haskell.org> #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: tc124 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): Slightly more trimmed example causing lint crash on the following commandline: {{{ inplace/bin/ghc-stage2 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug- output -no-user-package-db -rtsopts -fno-ghci-history -c tc124.hs -O -fasm -fno-warn-incomplete-patterns *** Core Lint errors : in result of Simplifier *** : Warning: In the type ?a_12 -> a_anm -> a_anm? @ a_12 is out of scope *** Offending Program *** }}} {{{#!hs {-# LANGUAGE RankNTypes #-} module Foo where data T = T { t1 :: forall a. a -> a } -- Test pattern bindings for polymorphic fields f :: T -> (Int,Char) f t = let T { t1 = my_t1 } = t in (my_t1 3, my_t1 'c') }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 00:21:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 00:21:47 -0000 Subject: [GHC] #9236: hGetContents leads to late/silent failures In-Reply-To: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> References: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> Message-ID: <060.524e9df2caf69aa3bcfce10936271e13@haskell.org> #9236: hGetContents leads to late/silent failures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #8213 Test Case: | Blocking: | Differential Revisions: Phab:D327 | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * differential: => Phab:D327 Comment: I decided to try this out, and it seems to work. In particular, it did ''not'' cause problems with broken pipes, and it ''did'' find a bug in Haddock. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 08:24:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 08:24:57 -0000 Subject: [GHC] #9422: EPT caching on --make can make spurious instances visible In-Reply-To: <045.91a3ec26e8fbfdfd2348192932411b44@haskell.org> References: <045.91a3ec26e8fbfdfd2348192932411b44@haskell.org> Message-ID: <060.e3566644356fb460406f3ed34f9e1f58@haskell.org> #9422: EPT caching on --make can make spurious instances visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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: | -------------------------------------+------------------------------------- Comment (by ezyang): In our most recent Backpack information, SPJ described a nice and simple way of solving this problem. Continue to maintain a global EPT, but with every type class instance, record the module it originated from. Now, when we do a lookup into the EPT table, we need to check if that module is transitively reachable from the current module; if it is not, then it is discarded. The transitivity check can be done lazily, so, hopefully, when this bad behavior doesn't occur, we can avoid doing all of the work of slurping in all the imports to figure out what type instances are available and which are not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 08:58:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 08:58:52 -0000 Subject: [GHC] #9594: Cleanup of filepath package In-Reply-To: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> References: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> Message-ID: <060.1a98e19bff2cfbb517119886abaea630@haskell.org> #9594: Cleanup of filepath package -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: upstream Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: filepath Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8752 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) * status: patch => upstream Comment: This is being handled upstream over at https://github.com/haskell/filepath/pull/1 now -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 09:02:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 09:02:03 -0000 Subject: [GHC] #7473: getModificationTime gives only second-level resolution In-Reply-To: <045.e4643e54563d29d7370456429b4f7379@haskell.org> References: <045.e4643e54563d29d7370456429b4f7379@haskell.org> Message-ID: <060.9e7f6eac9b6f07430504773b0b1e9c83@haskell.org> #7473: getModificationTime gives only second-level resolution -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.1 Libraries | Keywords: directory Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) * keywords: => directory -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 09:02:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 09:02:32 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.f29367f8b94aee6320cec34bf73f1f4b@haskell.org> #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: | -------------------------------------+------------------------------------- Comment (by dreixel): I've written up most of the points discussed so far on a wiki-page: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#Usingstandardderivingforgenericfunctions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 09:04:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 09:04:22 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.645b47e390d48883a673a6da28ebecd8@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * cc: core-libraries-committee@? (added) Comment: Just a heads-up: I want to implement the changes described in the following wiki page, which would mean there are no longer internally generated datatypes for which we then need `Typeable` instances: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#Amoreconservativefirstapproachtothisproblem -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 09:47:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 09:47:03 -0000 Subject: [GHC] #7473: getModificationTime gives only second-level resolution In-Reply-To: <045.e4643e54563d29d7370456429b4f7379@haskell.org> References: <045.e4643e54563d29d7370456429b4f7379@haskell.org> Message-ID: <060.d741c801db07cb828647c507d5590f07@haskell.org> #7473: getModificationTime gives only second-level resolution -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.1 Libraries | Keywords: directory Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by redneb): I have a patch for this issue that is basically ready. The only thing preventing me from submitting it is the fact that when `getFileAttributesExStandard` was added in Win32 the version number was not bumped properly. Because of that, I cannot use the MIN_VERSION_Win32 macro which is needed in order to provide a version of `getModificationTime` that works with all version of the Win32 package. If you bump one of the first 3 components of the version number of Win32, then I will finish and submit my patch. See also [1]. [1] https://github.com/haskell/win32/issues/13 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 09:52:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 09:52:29 -0000 Subject: [GHC] #9673: ghc-7.8.3 fails to build on aarch64 Message-ID: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> #9673: ghc-7.8.3 fails to build on aarch64 -------------------------------+--------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+--------------------------------------- (I first mentioned this recently in ticket:7942#comment:42 but I thought better to open a new ticket for this.) I tried to build ghc-7.8.3 on aarch64 Linux (Fedora 21 development) with the patch from #7942, and ran into: {{{ "inplace/bin/ghc-cabal" copy libraries/haskell2010 dist-install "strip" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' 'v dyn ' Installing library in /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/haskell2010-1.1.2.0 "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" --force --global-package-db "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. rts-1.0: Warning: library-dirs: /usr/lib64/ghc-7.8.3/rts-1.0 doesn't exist or isn't a directory rts-1.0: Warning: include-dirs: /usr/lib64/ghc-7.8.3/include doesn't exist or isn't a directory rts-1.0: cannot find any of ["libHSrts.a","libHSrts.p_a","libHSrts- ghc7.8.3.so","libHSrts-ghc7.8.3.dylib","HSrts-ghc7.8.3.dll"] on library path (ignoring) "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg : "" Registering ghc-prim-0.3.1.0... "inplace/bin/ghc-cabal" register libraries/integer-gmp dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin /ghc-pkg : "" ghc-cabal: Installed package ID not registered: "ghc-prim-0.3.1.0-inplace" ghc.mk:901: recipe for target 'install_packages' failed Makefile:64: recipe for target 'install' failed make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 }}} The problem seems to be that the installed (dynlinked) ghc-pkg does give any output!! (eg "ghc-pkg --version" returns "", same for --help.) When I try the built binaries I find that ghc-7.8.3/utils/ghc-pkg/dist/build/tmp/ghc-pkg (which is statically linked) works normally (ie it outputs --help and --version) whereas $DESTDIR/$libdir/ghc-7.8.3/bin/ghc-pkg gives no output on stdout! A workaround is to build with DYNAMIC_GHC_PROGRAMS=NO (ticket:7942#comment:44) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 10:00:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 10:00:16 -0000 Subject: [GHC] #7473: getModificationTime gives only second-level resolution In-Reply-To: <045.e4643e54563d29d7370456429b4f7379@haskell.org> References: <045.e4643e54563d29d7370456429b4f7379@haskell.org> Message-ID: <060.e9a2040c48b6699111ef8b99ad34a144@haskell.org> #7473: getModificationTime gives only second-level resolution -------------------------------------+------------------------------------- Reporter: duncan | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.1 Libraries | Keywords: directory Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): We should be able to make that happen. We'll need to reach out to Bryan O'Sullivan to get the version bump done; Win32 isn't under core libraries control. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 10:13:26 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 10:13:26 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.48b9a2b0bab5d769020ef7750476a777@haskell.org> #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): Simon, Richard, others, I'm making progress on this one but before going too far I want to get a green light on my design proposal (points 1-3). I've also bumped into some problems and have a couple of questions. My design proposal is to implement only injectivity of type A (ie. plain injectivity in all arguments). The consequences of this are: 1. A user is allowed to write at most one injectivity condition. 2. That condition must contain only the result type variable on the LHS of `->` and all other type variables on the RHS of `->`. In other words if I declare `type family P a b = r` then I'm only allowed to write `r -> a b` or `r -> b a` injectivity condition. Questions here: a) can I add a restriction that type variables on the RHS must be given in exactly the same order as they were given in the head declaration? This would make the implementation simpler; b) where should this check be done? In the renamer? 3. Once we check 2) we must verify that the type family is indeed injective. Not sure where this should happen? My guess is that during typechecking of a type family equations. Algorithm is outlined [wiki:InjectiveTypeFamilies#Implementationoutline here]. Does the implementation plan outlined so far look sensible? Are there any misconceptions? 4. Once we pass these checks injectivity becomes a binary property, so we can discard injectivity conditions written by the user and replace it with a `Bool`. Richard, when we first spoke about injective type families you suggested that all the magic will go into `isDecomposableTyCon` in `types/TyCon.lhs`. I've added a `Bool` field to `SynTyCon` data constructor of `TyCon` data type and made `isDecomposableTyCon` use that field to tell whether a type family is injective or not. (Checks described in 2 and 3 are not implemented. When a user writes injectivity declaration for a type family I just assume it is correct.) Sadly, this does not work. Here's an example test case: {{{#!hs type family F a = r | r -> a where F Int = Bool F Bool = Int F a = a foo :: F a -> F a foo = id }}} This fails with: {{{ Couldn't match type ?F a0? with ?F a? NB: ?F? is a type function, and may not be injective The type variable ?a0? is ambiguous Expected type: F a -> F a Actual type: F a0 -> F a0 In the ambiguity check for: forall a. F a -> F a To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ?foo?: foo :: F a -> F a }}} I added traces to verify that `isDecomposableTyCon` is called for `F` type family and it correctly returns `True`. Out of curiosity I turned on `AllowAmbiguousTypes` and added a definition like this: {{{ bar :: Int -> Int bar = foo }}} That failed with: {{{ Couldn't match type ?F a0? with ?Int? The type variable ?a0? is ambiguous Expected type: Int -> Int Actual type: F a0 -> F a0 In the expression: foo In an equation for ?bar?: bar = foo }}} I imagine that getting this one to work definitely requires more changes than just `isDecomposableTyCon`. Then again GHC can already deal with some cases of injectivity: {{{#!hs type family F a = r | r -> a where F Int = Int F Bool = Bool F a = a foo :: F a -> F a foo = id bar :: Int -> Int bar = foo }}} That works perfectly fine in GHC 7.8. I tried to analyse what's going on with `-ddump-tc-trace` but the dumps are 600-1000 lines long. Of course the source code itself is even longer, so I'd appreciate any directions where should I start looking. One final question. Assuming that `SynTyCon` really should have a new field, I believe this field should be stored in interface files. After all we want injectivity information to propagate from one module to another. Now I wonder how this interacts with open type families. I understand that these are typechecked progressively as we find more equations. I haven't looked at the implementation but my intuition from reading GHC papers is that in a given module we import open type family equations from other modules, collect equations from current module and proceed with type checking of an open type family. Is that intuition correct? If so then I believe that checking of injectivity (point 3 of my outline) should be done during this stage (I believe it would be best to combine it with checking equation overlapping). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 10:30:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 10:30:48 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.2845b48f254f41f089ac32681ea8d098@haskell.org> #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 heisenbug): Replying to [comment:73 jstolarek]: > Simon, Richard, others, > > I'm making progress on this one but before going too far I want to get a green light on my design proposal (points 1-3). I've also bumped into some problems and have a couple of questions. > Just a side question. I have a type level Map: {{{ type family Map (f :: k -> l) (ks :: [k]) :: [l] where ... }}} When I declare this as injective (presumably) with {{{ type family Map (f :: k -> l) (ks :: [k]) = result :: [l] | result -> ks where ... }}} then `f` must be injective for this to work. Concretely, will this invocation be considered injective by GHC (`:set -XDataKinds`) ? {{{ Map IO '[Int, (), Bool] }}} Thanks, Gabor -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 11:15:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 11:15:25 -0000 Subject: [GHC] #8584: Pattern synonym type signatures In-Reply-To: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> References: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> Message-ID: <060.4d37a45bd8488ec0dbcf21908e8ba68c@haskell.org> #8584: Pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: pattern synonyms (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: 5144 Unknown/Multiple | Related Tickets: 8581 Type of failure: | None/Unknown | Test Case: | Blocking: 8968 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Link to [wiki:PatternSynonyms] for pattern synonym signatures -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 11:22:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 11:22:02 -0000 Subject: [GHC] #8584: Pattern synonym type signatures In-Reply-To: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> References: <045.c6cdcd563c8eae8b80969790ee87e736@haskell.org> Message-ID: <060.7fbd3d8fc372b7ba5f25e23de46bcff0@haskell.org> #8584: Pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: pattern synonyms (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: 5144 Unknown/Multiple | Related Tickets: 8581 Type of failure: | None/Unknown | Test Case: | Blocking: 8968 | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Currently, the only way to specify a type signature for a pattern synonym > is by adding type annotations to the right-hand side, like this: > > {{{ > {-# LANGUAGE PatternSynonyms, ScopedTypeVariables #-} > > pattern Single x = ([x] :: [Int]) > }}} > > Bespoke syntax for adding type signatures for pattern synonyms would > probably be useful. New description: Currently, the only way to specify a type signature for a pattern synonym is by adding type annotations to the right-hand side, like this: {{{ {-# LANGUAGE PatternSynonyms, ScopedTypeVariables #-} pattern Single x = ([x] :: [Int]) }}} Bespoke syntax for adding type signatures for pattern synonyms would probably be useful. Link to [wiki:PatternSynonyms] for pattern synonym signatures for specification. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 12:02:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 12:02:06 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.0ae7d3b8d3eae92c4f2854f87ac8fe35@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by dreixel): I have only one concern: the patch also removes `Typeable{1..7}`. Michael, could you perhaps check how much code is using these (deprecated) classes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 13:02:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 13:02:15 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.b81e1326b1a2a333462ef6387a5a9db9@haskell.org> #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): Good question. I have not considered such case earlier. Here are some thoughts: Currently your `Map` function will work only for type constructors because unsaturated type families are not allowed. These are certainly injective. First step in my current outline of the algorithm that decides whether a type family is injective or not says: "If a RHS contains a call to a type family we conclude that the type family is not injective. I am not certain if this extends to self-recursion -- see discussion below." This would lead to conclusion that `Map` is not injective because `Map` calls itself. Now let's say I manage to find a way to allow self-recursion (see discussion on the wiki page). I'm left with the problematic call to `f`. As stated earlier currently this must be an injective type constructor. So it seems that declaring `Map` injective should be safe because type constructors are generative and it seems possible to deduce `f`, `a` and `b` from `Map f [a, b] ~ [Maybe Int, Maybe Char]`. At the moment I have no idea how to formulate an algorithm for such a deduction. Could this be done by the current constraint solver? What if we were allowed to have partially applied type families (say, because we've implemented ideas from singletons) and `f` could be a type family? Would knowing that `f` is injective allow us to declare `Map` as injective? Injectivity says you can deduce LHS from RHS but I think that it would not be a good idea to try to solve `Map f [a, b] ~ [Int, Char]`. And so the restriction on not having calls to type families on the RHS would rightly declare `Map` as not injective. So if we had partially applied type families and thus `f` was allowed to be either a type constructor a type family we should declare `Map` as not injective. This contrasts with earlier paragraph, where knowing that `f` must be a type constructor allowed us to declare `Map` as injective. Does that make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 13:43:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 13:43:14 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.d14429241fc29682671b0e3020f810fe@haskell.org> #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): * I think it's very straightforward to allow injectivity of form `r -> `. That is, the rhs is unconstrained but the lhs must be `r`. * So injectivity isn't a binary property; rather it's a `Bool` per argument. Making this list a field of `SynTyCon` is probably right, with ordinary synonyms being all false. * We are not (at least for now) changing System FC. So the only effect of injectivity is to add extra "Derived" unification constraints, very much like functional dependencies. If we see {{{ [W] F t ~ F s }}} then we don't decopose it. Instead we add {{{ [D] t ~ s }}} That guides inference, but does not produce proof terms. So, no, nothing to do with `isDecomposableTyCon`. Much more like the `try_improvement` code in `TcInteract.doTopReactFunEq`. * I don't understand the discussion of `Map`. Are you perhaps discussing how to verify some (not shown here) implementation of a closed type family `Map` is in fact injective? * Verifying injectivity for open families: if the RHSs unify then the LHSs should be identical under that substitution. Eg {{{ type instance F a Int = a -> Int type instance F Int a = Int -> a }}} These are consistent (and hence allowed) and are injective in both arguments. * My brain is too small to think about verifying injectivity for closed families. Richard? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 14:15:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 14:15:20 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.8c7a9615dab4bca2675a7f14a405d05f@haskell.org> #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): Replying to [comment:76 simonpj]: > * We are not (at least for now) changing System FC. So the only effect of injectivity is to add extra "Derived" unification constraints, very much like functional dependencies. If we see > {{{ > [W] F t ~ F s > }}} > then we don't decopose it. Instead we add > {{{ > [D] t ~ s > }}} What is the meaning of `[W]` and `[D]`? "Wanted" and "derived"? > * I don't understand the discussion of `Map`. Are you perhaps discussing how to verify some (not shown here) implementation of a closed type family `Map` is in fact injective? Yes, I was discussing how to verify whether this definition of `Map` is injective: {{{#!hs type family Map (f :: k -> l) (ks :: [k]) :: [l] where Map f '[] = '[] Map f (x ': xs) = f x ': Map f xs }}} > * Verifying injectivity for open families: if the RHSs unify then the LHSs should be identical under that substitution. Eg > {{{ > type instance F a Int = a -> Int > type instance F Int a = Int -> a > }}} > These are consistent (and hence allowed) and are injective in both arguments. Ah, I haven't thought about allowing substitution when RHSs unify. Wiki updated. > * My brain is too small to think about verifying injectivity for closed families. Richard? I only remind that I outlined an algorithm on the wiki :-) Richard, it would be great if you could take a look and say whether it makes sense. In the meantime I have almost implemented checking correctness of injectivity condition (point 2 from [comment:73 my earlier comment]). Renamer seems to be the right place for doing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 14:23:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 14:23:30 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.dabf830a8ac8dbdad67f0f9e32335235@haskell.org> #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): Yes "Wanted" and "Derived". You'll see lots of this with `-ddump-tc- trace` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 14:52:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 14:52:40 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.a2ca8903a377838f07e53d06c381ae07@haskell.org> #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 goldfire): Replying to [comment:73 jstolarek]: > 2. That condition must contain only the result type variable on the LHS of `->` and all other type variables on the RHS of `->`. In other words if I declare `type family P a b = r` then I'm only allowed to write `r -> a b` or `r -> b a` injectivity condition. Questions here: a) can I add a restriction that type variables on the RHS must be given in exactly the same order as they were given in the head declaration? This would make the implementation simpler; b) where should this check be done? In the renamer? I'm ambivalent on this design decision (that the variables have to be in the same order in the annotation). I suppose it simplifies the implementation. Yes, the renamer seems like a fine-enough place to do the check. > > 3. Once we check 2) we must verify that the type family is indeed injective. Not sure where this should happen? My guess is that during typechecking of a type family equations. Algorithm is outlined [wiki:InjectiveTypeFamilies#Implementationoutline here]. Please see updates to the wiki page, labeled '''RAE''' ... '''End RAE'''. > > Does the implementation plan outlined so far look sensible? Are there any misconceptions? > > 4. Once we pass these checks injectivity becomes a binary property, so we can discard injectivity conditions written by the user and replace it with a `Bool`. Richard, when we first spoke about injective type families you suggested that all the magic will go into `isDecomposableTyCon` in `types/TyCon.lhs`. I've added a `Bool` field to `SynTyCon` data constructor of `TyCon` data type and made `isDecomposableTyCon` use that field to tell whether a type family is injective or not. (Checks described in 2 and 3 are not implemented. When a user writes injectivity declaration for a type family I just assume it is correct.) Sadly, this does not work. Here's an example test case: > > {{{#!hs > type family F a = r | r -> a where > F Int = Bool > F Bool = Int > F a = a > > foo :: F a -> F a > foo = id > }}} > > This fails with: > > {{{ > Couldn't match type ?F a0? with ?F a? > NB: ?F? is a type function, and may not be injective > The type variable ?a0? is ambiguous > Expected type: F a -> F a > Actual type: F a0 -> F a0 > In the ambiguity check for: forall a. F a -> F a > To defer the ambiguity check to use sites, enable AllowAmbiguousTypes > In the type signature for ?foo?: foo :: F a -> F a > }}} > > I added traces to verify that `isDecomposableTyCon` is called for `F` type family and it correctly returns `True`. > > Out of curiosity I turned on `AllowAmbiguousTypes` and added a definition like this: > > {{{ > bar :: Int -> Int > bar = foo > }}} > > That failed with: > > {{{ > Couldn't match type ?F a0? with ?Int? > The type variable ?a0? is ambiguous > Expected type: Int -> Int > Actual type: F a0 -> F a0 > In the expression: foo > In an equation for ?bar?: bar = foo > }}} > > I imagine that getting this one to work definitely requires more changes than just `isDecomposableTyCon`. Yes, Simon's comment above is correct -- I was just wrong about the `isDecomposableTyCon` thing. Actually, injective type families still need to say "no" to `isDecomposableTyCon`, because of the '''left''' and '''right''' coercion formers, which assume generativity. > Then again GHC can already deal with some cases of injectivity: > > {{{#!hs > type family F a = r | r -> a where > F Int = Int > F Bool = Bool > F a = a > > foo :: F a -> F a > foo = id > > bar :: Int -> Int > bar = foo > }}} > > That works perfectly fine in GHC 7.8. What works perfectly fine? Not the code you wrote above, because it contains a not-currently-parsed injectivity annotation. I tried it without the injectivity annotation, and it does indeed work. But not because of injectivity, at all: it's because GHC is clever enough to figure out that `F` is just an identity function, and so the `F a`s in `foo`'s type become `a`. If you swap the `Int` and `Bool` RHSs in the definition (which preserves injectivity), the code fails to compile. > > I tried to analyse what's going on with `-ddump-tc-trace` but the dumps are 600-1000 lines long. Of course the source code itself is even longer, so I'd appreciate any directions where should I start looking. Fair warning: 1000 lines of `-ddump-tc-trace` isn't long at all! :) > > One final question. Assuming that `SynTyCon` really should have a new field, I believe this field should be stored in interface files. After all we want injectivity information to propagate from one module to another. Now I wonder how this interacts with open type families. I understand that these are typechecked progressively as we find more equations. I haven't looked at the implementation but my intuition from reading GHC papers is that in a given module we import open type family equations from other modules, collect equations from current module and proceed with type checking of an open type family. Is that intuition correct? If so then I believe that checking of injectivity (point 3 of my outline) should be done during this stage (I believe it would be best to combine it with checking equation overlapping). Agreed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 14:54:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 14:54:51 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.5ac07d08b9b2ead209a54da9abfee212@haskell.org> #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 goldfire): Replying to [comment:75 jstolarek]: > Good question. I have not considered such case earlier. Here are some thoughts: > > Currently your `Map` function will work only for type constructors because unsaturated type families are not allowed. These are certainly injective. > > First step in my current outline of the algorithm that decides whether a type family is injective or not says: "If a RHS contains a call to a type family we conclude that the type family is not injective. I am not certain if this extends to self-recursion -- see discussion below." This would lead to conclusion that `Map` is not injective because `Map` calls itself. > > Now let's say I manage to find a way to allow self-recursion (see discussion on the wiki page). I'm left with the problematic call to `f`. As stated earlier currently this must be an injective type constructor. So it seems that declaring `Map` injective should be safe because type constructors are generative and it seems possible to deduce `f`, `a` and `b` from `Map f [a, b] ~ [Maybe Int, Maybe Char]`. At the moment I have no idea how to formulate an algorithm for such a deduction. Could this be done by the current constraint solver? This should just work with the algorithm already stated. (Except for the self-recursion bit, which I responded to on the wiki page.) Unification should do the work for you. > > What if we were allowed to have partially applied type families (say, because we've implemented ideas from singletons) and `f` could be a type family? Would knowing that `f` is injective allow us to declare `Map` as injective? Injectivity says you can deduce LHS from RHS but I think that it would not be a good idea to try to solve `Map f [a, b] ~ [Int, Char]`. And so the restriction on not having calls to type families on the RHS would rightly declare `Map` as not injective. So if we had partially applied type families and thus `f` was allowed to be either a type constructor a type family we should declare `Map` as not injective. This contrasts with earlier paragraph, where knowing that `f` must be a type constructor allowed us to declare `Map` as injective. > > Does that make sense? No. Under the singletons work, we gave a different kind to non-injective functions, so Gabor's kind -- using `->`, not any other arrow -- requires an injective argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 14:57:30 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 14:57:30 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.1c54cd00e5a6cd382c3f1b89cfeefa0c@haskell.org> #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 goldfire): Replying to [comment:76 simonpj]: > * My brain is too small to think about verifying injectivity for closed families. Richard? I've put some comments on the wiki page. But the whole thing makes me a little nervous, as closed type families are really squirrelly. I would want something resembling a proof before feeling truly confident. As a first pass, we could always treat the equations of a closed family as independent (like an open family). I believe that such a treatment would be fully conservative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 16:23:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 16:23:22 -0000 Subject: [GHC] #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm In-Reply-To: <045.3ecedf0980b076ccd1110fcb386f8214@haskell.org> References: <045.3ecedf0980b076ccd1110fcb386f8214@haskell.org> Message-ID: <060.901225d65a77641dd49b47d32500faa8@haskell.org> #9567: tc124 fails as '*** Core Lint errors : in result of Simplifier ***' in WAY=optasm -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: tc124 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. The bug is in the `ApplyTo` case of `simplUtils.contInputType`, which does not work right for type arguments. This needs a little thought. Thanks for boiling it down so much. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 16:36:18 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 16:36:18 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.47c5cbdb982eaf0d3519c61a5e4ac653@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for the wiki page -- extremely helpful. I'm concerned about the proliferation of data types. As I read it you intend to have a new data type for each constructor of each data type in `HsSyn`. That's a LOT of new data types! And I bet you'll soon want Eq, Ord, Data instances for them as well as Typeable. Indeed you say {{{ data AnnClassDecl = AnnClassDecl { aclassdecl_class :: SrcSpan , aclassdecl_mwhere :: Maybe SrcSpan , aclassdecl_mbraces :: Maybe (SrcSpan,SrcSpan) } deriving (Eq,Data,Typeable,Show) }}} I wonder if something simpler and more dynamically-typed might do. Suppose you had {{{ lookupApiAnns :: Typeable value => ApiAnns -> SrcSpan -> String -> Maybe value }}} so that `ApiAnns` is really a map from `(SrcSpan, String, TypeRep)` to values, where `TypeRep` there is the `TypeRep` of the value. The `String` is the dynamic bit. Now you could say {{{ processHsClassDecl :: ApiAnns -> LTyClDecl n -> ... processHsClassDecl anns (L l (ClassDecl { ..} )) = r where Just kwd_loc = lookupAPiAnns anns loc "class-keyword" :: Maybe SrcSpan Just mb_loc = lookupApiAnns anns loc "class-mwhere" :: Maybe (Maybe SrcSpan) ... }}} OK so you might type those strings in wrong -- but if you do the look up will fail. I don't want this to sink under the sheer weight of gratuitous declarations. Oh and you could use the same string in lots of places. e.g. "where- keyword" might be used in a number of constructs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 17:19:56 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 17:19:56 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.d4b8cbd9c516dad339921643cd319431@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Alan and I debated this point, and I was the one who suggested the many data types approach (although I wouldn't go as far as saying I advocate it - I'm somewhat neutral). My concern was that if you do the dynamic approach you have to document each one of those strings, and the documentation has to be correct or the users won't have a clue what is going on, and if you update it all your clients will break and no one will realise. The documentation will basically be as long as the data types, but won't be statically checked on either side, and will very likely end up being wrong. Maybe a hybrid approach is to have location information for keywords like "of", "case", "where", "(" and ")". You can have a fixed static enumeration of keywords, so you have type safety, and every keyword is optionally in every AST. The number of keywords is relatively small, and which keyword is contained within each AST node doesn't require documenting (the lexical structure makes it pretty obvious). You end up with no requirement for fragile docs, one data type with a fairly small number of entries, and reasonable safety for both the producer and consumer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 17:20:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 17:20:22 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.8b2f1e1c3979b2979f471fb3aa95797f@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 17:24:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 17:24:47 -0000 Subject: [GHC] #9674: Foldable doesn't have any laws Message-ID: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> #9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: -------------------------------------+------------------------------------- The documentation for `Foldable` doesn't list any laws. I don't know exactly what its laws may be, but there are, at least, several implicit in the default method definitions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 17:27:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 17:27:40 -0000 Subject: [GHC] #9674: Foldable doesn't have any laws In-Reply-To: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> References: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> Message-ID: <060.37fcd02146d5e4e7c66cde56557f49c3@haskell.org> #9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): The laws should be given in terms of `foldMap` and various monoids from `Data.Monoid` rather than `foldr` or `toList`, otherwise the laws will be inaccurate where infinite snoc-lists and the like are involved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 17:30:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 17:30:09 -0000 Subject: [GHC] #9674: Foldable doesn't have any laws In-Reply-To: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> References: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> Message-ID: <060.2f1120f155e7c920a2d09fc2e1719759@haskell.org> #9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * type: bug => task * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 17:46:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 17:46:22 -0000 Subject: [GHC] #9674: Foldable doesn't have any laws In-Reply-To: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> References: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> Message-ID: <060.d0c7acb7e2fedcedf355ceebc0f20c37@haskell.org> #9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): `Foldable` is anything for which `foldMap` is defined, with a bunch of coherence conditions on how the other members relate to `foldMap`. `foldr` defines directly in terms of `foldMap` {{{ foldr f z t = appEndo (foldMap (Endo . f) t) z }}} Then `toList` defines in terms of `foldr` without any infinite re- association concerns, because of the properties of `(:)` {{{ toList = foldr (:) [] }}} The numerical members added as a result of the latest proposal can be defined in terms of `foldMap`, and are definable to be equal to the following up to a finite number of reassociations of `(+)` and `(*)`. {{{ sum = getSum . foldMap Sum product = getProduct . foldMap Product }}} This statement allows both the `foldl` and `foldr` interpretations of `sum` and `product` as employed now and doesn't rule out the existence of infinite containers -- like, you know, lists. It is preferable to define these this way in terms of `foldMap` rather than the more obvious definition in terms of `sum = sum . toList` because the latter definition may be undefined for infinite snoc-lists or Foldable containers where the infinite recursion occurs some place other than the right, so these laws are more defined. The class offers you the ability to define `foldMap` in terms of `foldr` and vice versa. However, defining `foldMap` in terms of `foldr` is only really specifiable in the finite case, so really ultimately the behavior up to finite reassociation is given by `foldMap` and the behavior of `foldr` is induced. This default definition of `foldMap` in terms of `foldr` only works for structures with infinite recursion only occurring on the right, so it doesn't work out to state it properly as a law in the infinite case. I'd need to go through in more detail, but in general the remaining laws should be be able to be stated as claiming the answers provided should be equivalent to what you'd get with the default definitions under minor assumptions about the fact that dictionaries passed for things like `Ord` in the case of things like `maximum`/`minimum` are law abiding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 17:53:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 17:53:52 -0000 Subject: [GHC] #9674: Foldable doesn't have any laws In-Reply-To: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> References: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> Message-ID: <060.b1aa7a49784e3d312aeedee92e365fa5@haskell.org> #9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Two other obvious laws are `foldMap f . fmap g = foldMap (f . g)` and `fold = foldMap id`. These together imply `foldMap f = fold . fmap f`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 18:02:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 18:02:02 -0000 Subject: [GHC] #9674: Foldable doesn't have any laws In-Reply-To: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> References: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> Message-ID: <060.a79dcf85a569225f38fa02dc809fd889@haskell.org> #9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I just realized the better law is the last: `foldMap f = fold . fmap f` implies the other two. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 18:03:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 18:03:49 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.56c2246721c15de4a5083a0286b73f6b@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): I share Neil's concern about the fragility of the string lookup. A user of this feature would have to keep track of the string key, as well as the shape of the returned structure used for the particular annotation, and would not know until runtime failure that there was a problem. I think the hybrid approach where there is a specific enumerated type for the keyword/feature being looked up could be workable, but requires the API user to consult the parser.y.pp file to see exactly what fits in where. From a user of the feature point of view, having a straightforward mapping from the constructor name to the annotation name which can then be interrogated via e.g. ghci is definitely beneficial. This does require an explosion of types, but this is pretty much a once- off exercise. Is there a code size problem if many classes are derived for each one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 18:10:57 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 18:10:57 -0000 Subject: [GHC] #9674: Foldable doesn't have any laws In-Reply-To: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> References: <045.36aee1726cf0a1cc8513396efd92e6c8@haskell.org> Message-ID: <060.04a84921646067b834cd162b30f8088b@haskell.org> #9674: Foldable doesn't have any laws -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: Documentation bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): `foldMap f = fold . fmap f` assumes you have a `Functor` instance as well, so any such law would need that caveat. `fold = foldMap id` holds universally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 18:17:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 18:17:41 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.78d25b3b781a462670baab1fe318557c@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Why does the user require consulting parser.y.pp? Things like the Let constructor obviously have a Let keyword and an In keyword. Things like instance declaration obviously have Instance and Where. They seem fairly predictable, and if you do want to comment it, that could be as short as "-- instance ... [where]". Or do you have in mind nodes which wouldn't be as clear, or places where the thing you are indexing isn't so obviously a keyword? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 19:13:46 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 19:13:46 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.da38863d5ed7020da31598061f089ac2@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by simonpj): I don't have data, but people are already complaining about the amount of code generated by data type declarations #9669. Have you counted how many data constructors there are in `HsSyn`? It's a LOT. It just feels like a sledgehammer to crack a nut. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 19:22:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 19:22:09 -0000 Subject: [GHC] #9671: Allow expressions in patterns In-Reply-To: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> References: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> Message-ID: <066.e355ad444eb8ad40fbf9df2c9ecde544@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: 7.10.1 request | Version: Priority: normal | Keywords: patterns, pattern Component: Compiler | synonyms Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Your examples all use constants, but I assume you are going to allow this: {{{ f :: Person -> Map Person Age -> Age f p (Lookup p a) = a f p _ = error ("No info on " ++ show p) }}} Now this is jolly confusing. In the pattern `(Lookup p a)`, `p` is a bound occurence while `a` is a binding occurrence. This distinction is made syntactically by view patterns: {{{ f :: Person -> Map Person Age -> Age f p ((\m -> lookup m p) -> a) = a }}} Here the stuff on the left of the view-pattern arrow `->` are bound occurrences, while the stuff on the right is binding. You could even have {{{ f p (Lookup p p) = p }}} meaning {{{ f p1 (Lookup p1 p2) = p2 }}} To me, the lack of syntactic cues for what is bound and what is binding seems quite serious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 20:14:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 20:14:44 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.fdb1389a051856d8f92bbd0c93932668@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): Replying to [comment:20 NeilMitchell]: > Why does the user require consulting parser.y.pp? Things like the Let constructor obviously have a Let keyword and an In keyword. Things like instance declaration obviously have Instance and Where. They seem fairly predictable, and if you do want to comment it, that could be as short as "-- instance ... [where]". Or do you have in mind nodes which wouldn't be as clear, or places where the thing you are indexing isn't so obviously a keyword? Some of the structures are nested quite deeply, an/or reused in multiple roles. But I think anyone working at the detail level of the annotations is going to be looking closely at the relationship between the source, the parse tree and the annotations anyway, so it should not be a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 21:51:06 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 21:51:06 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.9bf7f86153476072e1d842142129eade@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * owner: komadori => gintas Comment: I am looking into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 21:52:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 21:52:35 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.9d64b8cc814c4dd735ff125f0458fcec@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by komadori): That's good :-). I've had no time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 10 23:59:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Oct 2014 23:59:48 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures Message-ID: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Compile- Difficulty: Unknown | time performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have attached a file that, when compiled, results in very large amount of memory usage by GHC. The memory used is in the order of tens of gigabytes, but I've not been able to successfully compile the file due to lack of physical memory. This is on Debian GNU/Linux (Jessie) using Haskell Platform 2014.2.0.0 with GHC 7.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 00:09:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 00:09:28 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.094478355e40a08806680cb3a6629b2d@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by schyler): It's intriguing to know that this file only contains a single record and no 'actual' code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 01:11:28 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 01:11:28 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.72b1f99576a244e0b631d2f31e5f67cf@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well, the data declaration does define ~3000 record accessors, each of which pattern matches on a record with ~3000 fields... it's easy for some things to become quadratic (intermediate program code size, strictness/demand info) even if in the end, the code size is only linear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 03:00:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 03:00:02 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.95871da05c19cec12e6c3c217f2afa60@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: ? Component: NoFib | Version: benchmark suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9571 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): We should consider incorporating something along the lines of [https://github.com/ccurtsinger/stabilizer Stabilizer] in order to reduce the magnitude of the effects seen in #8279. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 04:43:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 04:43:02 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.dab515692a11f8bc97f87d05c33b9cee@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): So then we'd just be piggybacking on typeability of Symbols (and instances for MetaCons/MetaData) to get the `Typeable` instance for things like `M1 i c p`? I have vague recollections of Richard mentioning that having every Symbol/Nat be Typeable. I don't recall what came of it though. Do we have that now in HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 06:17:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 06:17:39 -0000 Subject: [GHC] #9676: Data.List.isSuffixOf can be very inefficient Message-ID: <045.eeef3e586222f9b3ebd00734e3d3ae2c@haskell.org> #9676: Data.List.isSuffixOf can be very inefficient -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `Data.List.isSuffixOf` reverses both lists it is given. Thus, for example, {{{#!hs [12] `isSuffixOf` [1::Int .. (10^9)] }}} will build the complete list `[10^9, (10^9-1)..1]` in memory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 06:19:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 06:19:39 -0000 Subject: [GHC] #9676: Data.List.isSuffixOf can be very inefficient In-Reply-To: <045.eeef3e586222f9b3ebd00734e3d3ae2c@haskell.org> References: <045.eeef3e586222f9b3ebd00734e3d3ae2c@haskell.org> Message-ID: <060.69d859cf4392eda17256893a01db5024@haskell.org> #9676: Data.List.isSuffixOf can be very inefficient -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D330 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D330 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 07:10:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 07:10:12 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.39e06628db710b174a21e8fa8ed6d09f@haskell.org> #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): Replying to [comment:79 goldfire]: > I'm ambivalent on this design decision (that the variables have to be in the same order in the annotation). I suppose it simplifies the implementation. I guess my argument about simpler implementation is not that important. I mean the code is quite simple in both cases. It's more like a choice between linear and quadratic algorithm. I'd went for linear, even if it adds an extra restriction on the user code. > Yes, Simon's comment above is correct -- I was just wrong about the `isDecomposableTyCon` thing. OK. Reverting :-) > What works perfectly fine? Not the code you wrote above, because it contains a not-currently-parsed injectivity annotation. I tried it without the injectivity annotation, and it does indeed work. Yes, that's what I meant. > But not because of injectivity, at all: it's because GHC is clever enough to figure out that `F` is just an identity function Right. Still, I wondering how this works. I mean there are probably no special cases in the typechecker that try to guess whether a type family is an identity function? > Fair warning: 1000 lines of `-ddump-tc-trace` isn't long at all! :) I imagine, given that my source file was 8 lines of code. Still, it's a bit steep learning curve. Replying to [comment:80 goldfire]: > Under the singletons work, we gave a different kind to non-injective functions Ah, right. Replying to [wiki:InjectiveTypeFamilies wiki comments]: > I believe this would also have to check that all variables mentioned in the LHS are mentioned in the RHS. Or, following along with Simon's idea in comment:76:ticket:6018, those variables that appear in the injectivity annotation must be mentioned in the RHS. I haven't thought about that. I believe you're right. > We have to be careful with the word overlap here. I think we want "overlaps" to be "is subsumed by". I don't see the difference between "overlaps" and "is subsumed by". :-( Now, in 4c I wrote: > if unification [of the RHSs] succeeds and there are type variables involved we substitute unified type variables on the LHS and check whether this LHS overlaps with any of the previous equations. If it does we proceed to the next equation You replied with this: > you want to know of the equation at hand is reachable, given the LHS substitution. Even if it is reachable, the (substituted) LHS may coincide with the LHS of the earlier equation whose RHS unified with the current RHS. I don't see the difference between your version and mine. > Even subtler, it's possible that certain values for type variables are excluded if the current LHS is reachable (for example, some variable a couldn't be Int, because if a were Int, then a previous equation would have triggered). Perhaps these exclusions can also be taken into account. Hm... can you give an example where this would be useful? > '''RAE:''' But it seems that, under this treatment, any self-recursion would automatically lead to a conclusion of "not injective", just like any other use of a type family. For example: > > {{{#!hs > type family IdNat n where > IdNat Z = Z > IdNat (S n) = S (IdNat n) > }}} > > `IdNat` is injective. But, following the algorithm above, GHC would see the recursive use of `IdNat`, not know whether `IdNat` is injective, and then give up, concluding "not injective". Is there a case where the special treatment of self-recursion leads to a conclusion of "injective"? '''End RAE''' This example is just like my `NatToMaybe`. My idea here was that RHSs of these two equations won't unify - first returns `Z`, second returns `S something`. These are distinct constructors that have no chance of being unified. (I assumed that we are able to detect that.) There are no calls to type families other than self-recursion and so we can declare `IdNat` to be injective. I admit I am not 100% certain that allowing self- recursion is safe. It's just that I was unable to come up with an example that would show that my algorithm: a:) declares injective function to be non-injective; b) declares a non-injective function to be injective. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 09:20:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 09:20:47 -0000 Subject: [GHC] #9672: Error message too long (full case statement printed) In-Reply-To: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> References: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> Message-ID: <066.3da26cb9ba19086d072848bed9494a61@haskell.org> #9672: Error message too long (full case statement printed) -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by andreas.abel): A simple-minded fix is to just surpress the printing of the error context if it is too long. Let's say, if it is more than 7 lines (or put some other magic number here), it does not print it, as it will probably not be helpful to the user. I hardly ever read the surrounding context of an error, I just look at the error position and jump to that line in my editor. The problem with long error contexts is that errors scroll way up in my terminal and I have to go a long way back to read the error position. Also, it is not easy to get an overview over all the errors one got. If there was a flag --short-error-messages, I had it on always, for that very reason. Andreas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 09:33:02 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 09:33:02 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.b1b5d330b621909cc8671c36bb7a9e16@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: ? Component: NoFib | Version: benchmark suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9571 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Somewhat related, there's a new serious attempt at [wiki:Building/Shake Shaking up GHC] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 10:20:18 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 10:20:18 -0000 Subject: [GHC] #9604: Python test runner assumes native Python on Windows In-Reply-To: <045.eaed88e165e20cf0975a545fb150c6a7@haskell.org> References: <045.eaed88e165e20cf0975a545fb150c6a7@haskell.org> Message-ID: <060.6f8e68651f31b868715ecddcb9835bc6@haskell.org> #9604: Python test runner assumes native Python on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): The first patch has landed via 1032554a7084a12d38a08beaaeb7a07088883e29 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 10:32:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 10:32:07 -0000 Subject: [GHC] #9604: Python test runner assumes native Python on Windows In-Reply-To: <045.eaed88e165e20cf0975a545fb150c6a7@haskell.org> References: <045.eaed88e165e20cf0975a545fb150c6a7@haskell.org> Message-ID: <060.b865942e42fbbe77718f0a1d331f0157@haskell.org> #9604: Python test runner assumes native Python on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"034b2035d6099c8a253bb1fbd1864001a27b44d6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="034b2035d6099c8a253bb1fbd1864001a27b44d6" Extend windows detection in testsuite to recognize MSYS target Currently, the detection recognizes the following `uname -s` strings: - `CYGWIN_NT-6.3` - `MINGW32_NT-6.3` - `MINGW64_NT_6.3` However, MSYS2 provides an additional target, in which case `uname -s` returns a string such as `MSYS_NT-6.3`. In all these cases, the system ought to be recognized as being a `windows` os by the testsuite runner. See also #9604 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 10:32:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 10:32:42 -0000 Subject: [GHC] #9604: Python test runner assumes native Python on Windows In-Reply-To: <045.eaed88e165e20cf0975a545fb150c6a7@haskell.org> References: <045.eaed88e165e20cf0975a545fb150c6a7@haskell.org> Message-ID: <060.631d175f9ef39559155cfb38ae0165b4@haskell.org> #9604: Python test runner assumes native Python on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 13:26:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 13:26:59 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.b546e97d756f0c8df72a540b32977a0e@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D313 | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) Comment: @ross, any comments? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 13:54:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 13:54:17 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.38404714cb09dcfd858cf2731301be82@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): The multiple annotation approach seems promising, first stab results in Annotation types {{{ #!haskell data AnnModule = AnnModule SrcSpan deriving (Eq,Data,Typeable,Show) data AnnWhere = AnnWhere SrcSpan deriving (Eq,Data,Typeable,Show) -- Should this be AnnBraces? The tokens are ITocurly / ITccurly data AnnCurlies = AnnCurlies (SrcSpan,SrcSpan) deriving (Eq,Data,Typeable,Show) data AnnSemi = AnnSemi SrcSpan deriving (Eq,Data,Typeable,Show) data AnnComma = AnnComma SrcSpan deriving (Eq,Data,Typeable,Show) -- | Pragma declaration, e.g. '{-# SOURCE' '#-}' data AnnPragma = AnnPragma (SrcSpan,SrcSpan) deriving (Eq,Data,Typeable,Show) }}} Helper functions in parser {{{ #!haskell -- | Given a list of @Maybe annotation@, add the @Just@ ones to the -- given location ams :: Located a -> [Maybe (SrcSpan -> P ())] -> P (Located a) ams a@(L l _) bs = (mapM_ (\a -> a l) $ catMaybes bs) >> return a mj :: (Outputable a,Typeable a,Show a,Eq a) => (SrcSpan -> a) -> Located e -> Maybe (SrcSpan -> P ()) mj c l = Just (\s -> addAnnotation s (c (gl $l))) mm :: (Outputable a,Typeable a,Show a,Eq a) => (SrcSpan -> a) -> Maybe SrcSpan -> Maybe (SrcSpan -> P ()) mm c Nothing = Nothing mm c (Just l) = Just (\s -> addAnnotation s (c l)) mm2 :: (Outputable a,Typeable a,Show a,Eq a) => ((SrcSpan,SrcSpan) -> a) -> Maybe (SrcSpan,SrcSpan) -> Maybe (SrcSpan -> P ()) mm2 c Nothing = Nothing mm2 c (Just (l1,l2)) = Just (\s -> addAnnotation s (c (l1,l2))) }}} Example rule in parser {{{ module :: { Located (HsModule RdrName) } : maybedocheader 'module' modid maybemodwarning maybeexports 'where' body {% fileSrcSpan >>= \ loc -> ams (L loc (HsModule (Just $3) $5 (fst $ snd $7) (snd $ snd $7) $4 $1 ) ) [mj AnnModule $3, mj AnnWhere $6 ,mm2 AnnCurlies (fst $ fst $7),mm AnnSemi (snd $ fst $7)] } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 15:17:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 15:17:04 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.9d980f6d6f6ca17b9f8ee7868dd94ecb@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D329 | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * status: new => patch * differential: => Phab:D329 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 16:49:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 16:49:17 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.cb733304f0c7d287b541851a8f8365ca@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Interesting extreme benchmark, maybe it will reveal some low-hanging fruit of algorithmic improvement. But is there actually a chance that the resulting code will be usable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 17:36:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 17:36:52 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.5908146cc8d192575074d8c0645fc2d1@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Polarina): The idea behind the code is to load all the OpenGL function pointers at program startup and store them in a data structure, rather than load them at runtime as needed; and to support multiple OpenGL contexts as there is no guarantee that two different contexts provide the same set of function pointers for the same set of functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 18:22:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 18:22:32 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.7f1bbed30c44cbb459fe55078cf121a4@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by NeilMitchell): I had a slightly different design in mind. {{{ data Ann = AnnModule | AnnWhere | AnnSemi | AnnOpen | AnnClose }}} Then you can basically have a function: {{{ getAnnotation :: ASTNode -> Ann -> Maybe SrcSpan }}} You'd be down to only a single annotation. Things like Pragma could use AnnOpen for the {-# and AnnClose for the #-} bit. As long as you have a separate annotation constructor for each part of a pair, then everything is associated with a Maybe SrcSpan, and you don't have to pack the SrcSpan inside the Ann field. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 18:40:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 18:40:47 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.ac09db987c9370981f7f1927ed5dd322@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): That could work, and it is a lot simpler. The stuff for paired SrcSpans just doubles everything up at the moment, as I work it through. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 18:52:22 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 18:52:22 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.f1866309ae1ae621b533a63c641805f4@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by ekmett): @dreixel: A quick skim of my own projects reveals 100+ locations affected in a way that makes them very awkward to patch around with CPP, as they affect public APIs and I've currently agreed to maintain many of my packages back to ghc 7.4 -- an agreement that will bump to 7.6 upon the release of 7.10, etc. So as a data point, deleting those 20 lines will cost me personally several hundred lines worth of easily-screwed-up support work if it is done as part of GHC 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 19:12:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 19:12:47 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.5f43f8750a3d83ca5fc1a40708dbe80d@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by mgmeier): I agree with dreixel and ekmett on this one. After doing some checking, it doesn't seem like a good idea to remove these deprecated types yet. Does anyone happen to know when or why it was decided to deprecate them, or where to read up on that (mailarchive/forum)? I'll revert the phab diff with arcanist accordingly, as soon as I figure out how ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 19:20:29 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 19:20:29 -0000 Subject: [GHC] #9677: "operation not permitted" when running tests on Windows Message-ID: <045.5475ee1151ed504243ac223a5c5055f5@haskell.org> #9677: "operation not permitted" when running tests on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I run ghc tests on windows using "make test", I see instances of the following: =====> T5442d(normal) 86 of 4093 [0, 1, 0] cd ./cabal && $MAKE -s --no-print-directory T5442d T5442d.run.stdout 2>T5442d.run.stderr [Errno 1] Operation not permitted: './cabal/package.conf.T5442d.global' [Errno 90] Directory not empty: './cabal/package.conf.T5442d.global' [Errno 1] Operation not permitted: './cabal/package.conf.T5442d.user' [Errno 90] Directory not empty: './cabal/package.conf.T5442d.user' [Errno 1] Operation not permitted: './cabal/package.conf.T5442d.extra' Not sure if these are legitimately harmful, but something is going wrong. I am running ghc head on latest msys2. I also tried running the process as administrator to rule out permission issues due to handling symlinks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 19:40:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 19:40:24 -0000 Subject: [GHC] #9678: Warning about __sync_fetch_and_nand semantics from gcc Message-ID: <045.23b8870530d0cafb1b87a515eec9fc0e@haskell.org> #9678: Warning about __sync_fetch_and_nand semantics from gcc -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- When building ghc, I'm getting warnings about __sync_fetch_and_nand that the semantics have changed for gcc 4.4+. I'm building on Windows, but I don't think that matters. Is this an indication of a problem or does that warning just need to be silenced? I ran the build with gcc 4.8.3: $ inplace/mingw/bin/gcc -v Using built-in specs. COLLECT_GCC=C:\msys64\home\Gintas\ghc\inplace\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=C:/msys64/home/Gintas/ghc/inplace/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.8.3 /lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-4.8.3/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with- sysroot=/c/mingw483/x86_64-483-posix-seh-rt_v3-rev0/mingw64 --with-gxx- include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable- languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version- specific-runtime-libs --disable-isl-version-check --disable-cloog-version- check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with- tune=core2 --with-libiconv --with-system-zlib --with- gmp=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- mpfr=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- mpc=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- isl=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --with- cloog=/c/mingw483/prerequisites/x86_64-w64-mingw32-static --enable-cloog- backend=isl --with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw483/x86_64-483-posix-seh- rt_v3-rev0/mingw64/opt/include -I/c/mingw483/prerequisites/x86_64-zlib- static/include -I/c/mingw483/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw483/x86_64-483-posix-seh- rt_v3-rev0/mingw64/opt/include -I/c/mingw483/prerequisites/x86_64-zlib- static/include -I/c/mingw483/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw483/x86_64-483-posix-seh- rt_v3-rev0/mingw64/opt/lib -L/c/mingw483/prerequisites/x86_64-zlib- static/lib -L/c/mingw483/prerequisites/x86_64-w64-mingw32-static/lib' Thread model: posix gcc version 4.8.3 (x86_64-posix-seh-rev0, Built by MinGW-W64 project) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 20:48:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 20:48:10 -0000 Subject: [GHC] #9678: Warning about __sync_fetch_and_nand semantics from gcc In-Reply-To: <045.23b8870530d0cafb1b87a515eec9fc0e@haskell.org> References: <045.23b8870530d0cafb1b87a515eec9fc0e@haskell.org> Message-ID: <060.cfb908f6e88448b295b2be9978eef569@haskell.org> #9678: Warning about __sync_fetch_and_nand semantics from gcc -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by tibbe): * status: new => closed * resolution: => wontfix Comment: It's only a problem if you're not on GCC 4.4+. The warning is a bit annoying because it's there even though we want the post GCC 4.4 semantics. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 22:02:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 22:02:36 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.8b9f3814f655d9a21ac4e16921728d77@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:13 mgmeier]: > Does anyone happen to know when or why it was decided to deprecate them, or where to read up on that (mailarchive/forum)? I can point you to 0c7507a09bfac5710b76eb4c1517789ce3b3a3ff ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 22:11:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 22:11:50 -0000 Subject: [GHC] #9549: deriveConstants fails on OpenBSD In-Reply-To: <045.280f1382fe569e58794f97c954f259a6@haskell.org> References: <045.280f1382fe569e58794f97c954f259a6@haskell.org> Message-ID: <060.32441f295f915005f7690878dccef5be@haskell.org> #9549: deriveConstants fails on OpenBSD -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: OpenBSD | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D332 | -------------------------------------+------------------------------------- Changes (by roland): * differential: => Phab:D332 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 22:15:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 22:15:26 -0000 Subject: [GHC] #9549: deriveConstants fails on OpenBSD In-Reply-To: <045.280f1382fe569e58794f97c954f259a6@haskell.org> References: <045.280f1382fe569e58794f97c954f259a6@haskell.org> Message-ID: <060.69cc1c3c0eaeb6ed8e5b803a884ec2c5@haskell.org> #9549: deriveConstants fails on OpenBSD -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: OpenBSD | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D332 | -------------------------------------+------------------------------------- Comment (by roland): The above patch (Phab:D332) switches from nm to objdump if System.Info.os == "openbsd". /usr/bin/objdump is part of the OpenBSD base system, so should always be there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 23:13:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 23:13:01 -0000 Subject: [GHC] #9679: testsuite/.gitignore does not cover some test outputs on Windows Message-ID: <045.b09b4535aecb931940ceef6ecdec91bc@haskell.org> #9679: testsuite/.gitignore does not cover some test outputs on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Some test suite outputs on Windows are not covered by testsuite/.gitignore, polluting the output of 'git status'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 23:13:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 23:13:37 -0000 Subject: [GHC] #9679: testsuite/.gitignore does not cover some test outputs on Windows In-Reply-To: <045.b09b4535aecb931940ceef6ecdec91bc@haskell.org> References: <045.b09b4535aecb931940ceef6ecdec91bc@haskell.org> Message-ID: <060.cb71eea3593db825b3b777799aa70e25@haskell.org> #9679: testsuite/.gitignore does not cover some test outputs on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 23:36:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 23:36:26 -0000 Subject: [GHC] #9679: testsuite/.gitignore does not cover some test outputs on Windows In-Reply-To: <045.b09b4535aecb931940ceef6ecdec91bc@haskell.org> References: <045.b09b4535aecb931940ceef6ecdec91bc@haskell.org> Message-ID: <060.d877a87447a51728ea0b06fad415d0fa@haskell.org> #9679: testsuite/.gitignore does not cover some test outputs on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D333 | -------------------------------------+------------------------------------- Changes (by gintas): * differential: => D333 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 11 23:42:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Oct 2014 23:42:50 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.c9908e0d4313642d0418e13ffaf58198@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by ekmett): They definitely belong deprecated, it is just a matter that we shouldn't be so quick to remove them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 00:00:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 00:00:25 -0000 Subject: [GHC] #9680: Autogenerated lib/include/HsTimeConfig.h is checked in Message-ID: <045.8b29702254c4489839dd215524f6b850@haskell.org> #9680: Autogenerated lib/include/HsTimeConfig.h is checked in -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 | None/Unknown hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- lib/include/HsTimeConfig.h appears to be generated by the build process, but it's checked into the depot. After I run make it shows up as modified under git status, preventing "arc diff" etc. I am building on Windows, but I don't think this is OS-specific. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 00:06:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 00:06:35 -0000 Subject: [GHC] #9680: Autogenerated lib/include/HsTimeConfig.h is checked in In-Reply-To: <045.8b29702254c4489839dd215524f6b850@haskell.org> References: <045.8b29702254c4489839dd215524f6b850@haskell.org> Message-ID: <060.bdb900d04cfbe76474706a373a54824e@haskell.org> #9680: Autogenerated lib/include/HsTimeConfig.h is checked in -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D334 | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => patch * differential: => Phab:D334 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 00:07:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 00:07:05 -0000 Subject: [GHC] #9680: Autogenerated lib/include/HsTimeConfig.h is checked in In-Reply-To: <045.8b29702254c4489839dd215524f6b850@haskell.org> References: <045.8b29702254c4489839dd215524f6b850@haskell.org> Message-ID: <060.1131a955a38dcd0caa0240c41871a195@haskell.org> #9680: Autogenerated lib/include/HsTimeConfig.h is checked in -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: patch => new * differential: Phab:D334 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 00:07:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 00:07:33 -0000 Subject: [GHC] #9678: Warning about __sync_fetch_and_nand semantics from gcc In-Reply-To: <045.23b8870530d0cafb1b87a515eec9fc0e@haskell.org> References: <045.23b8870530d0cafb1b87a515eec9fc0e@haskell.org> Message-ID: <060.8a0178d9b9d00517f74beeb5eabb5045@haskell.org> #9678: Warning about __sync_fetch_and_nand semantics from gcc -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: closed => new * resolution: wontfix => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 00:08:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 00:08:04 -0000 Subject: [GHC] #9678: Warning about __sync_fetch_and_nand semantics from gcc In-Reply-To: <045.23b8870530d0cafb1b87a515eec9fc0e@haskell.org> References: <045.23b8870530d0cafb1b87a515eec9fc0e@haskell.org> Message-ID: <060.bb4895147fc91d22fbc792420d916f36@haskell.org> #9678: Warning about __sync_fetch_and_nand semantics from gcc -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D334 | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => patch * differential: => Phab:D334 Comment: The warning is intended to be suppressed once callsites are taken care of. Why not do just that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 00:09:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 00:09:01 -0000 Subject: [GHC] #9679: testsuite/.gitignore does not cover some test outputs on Windows In-Reply-To: <045.b09b4535aecb931940ceef6ecdec91bc@haskell.org> References: <045.b09b4535aecb931940ceef6ecdec91bc@haskell.org> Message-ID: <060.41e54782f4efb327b74be8759b389b21@haskell.org> #9679: testsuite/.gitignore does not cover some test outputs on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D333 | -------------------------------------+------------------------------------- Changes (by gintas): * differential: D333 => Phab:D333 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 00:35:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 00:35:44 -0000 Subject: [GHC] #9680: Autogenerated lib/include/HsTimeConfig.h is checked in In-Reply-To: <045.8b29702254c4489839dd215524f6b850@haskell.org> References: <045.8b29702254c4489839dd215524f6b850@haskell.org> Message-ID: <060.bb2fccf8cc00b41d321d57acf66b4c85@haskell.org> #9680: Autogenerated lib/include/HsTimeConfig.h is checked in -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => closed * resolution: => wontfix Comment: This is for libraries/time. The package source is outside the ghc repo; submitted pull request at https://github.com/haskell/time/pull/3 , closing bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 00:48:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 00:48:36 -0000 Subject: [GHC] #9681: Printing of "\n" in error messages is broken Message-ID: <045.abc102fa93d2a130d37cc7ab11f8ef8d@haskell.org> #9681: Printing of "\n" in error messages is broken -------------------------------------+------------------------------------- Reporter: oerjan | 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: 1+"\n" | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The code excerpts in error messages from GHC 7.8.3 are misformatted when the original code contains the string "\n" - the \n escape is simply lost. Example with GHCi: {{{ Prelude> 1+"\n" :2:2: No instance for (Num [Char]) arising from a use of `+' In the expression: 1 + "" In an equation for `it': it = 1 + "" }}} The printing of the string "\n " is also strangely formatted, although technically equivalent: {{{ Prelude> 1+"\n " :3:2: No instance for (Num [Char]) arising from a use of `+' In the expression: 1 + "\n\ \ " In an equation for `it': it = 1 + "\n\ \ " }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 08:24:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 08:24:55 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.e6ab2fd5e400405d5a72dc5e0816ff1c@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:21 carter]: > Has anyone reproduced this issue on linux with GHC 7.8.3? The patch to #8935 that introduced the regression reported in this ticket has been reverted (see comment:14). You should not see the issue on OS X and also not on Linux. I verified the latter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 08:31:50 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 08:31:50 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.61273f2025f7f8c4f2c48678fbadbce1@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:13 rwbarton]: > OK, this is quite annoying, it consistently fails when I do `cabal install -v`, but consistently succeeds when I do `cabal install -v3`! So with more verbose output you could build compdata. That you could do so consistently looks promising. Perhaps I missed laziness somewhere in my patch for #8935. I'll go check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 08:46:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 08:46:01 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.33f2fc0644ada5ad47a8e9bd48b9bc87@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): I created a plot to see what kind of complexity problem we have to look for. I gotta run now, so it?s not as polished as it should, and I didn?t have time yet to actually try to make sense of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 09:09:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 09:09:04 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.f539baf799fc59f54d010714441a9bd6@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: ? Component: NoFib | Version: benchmark suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: 9571 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Reflecting on why this ticket didn't go anywhere, perhaps the scope is too broad. Rather than "make nofib awesome" maybe we need a few separate tickets - the one to switch nofib to Shake just requires integrating the code that is already written. The other issues such as criterion/stabilizer and changing the set of benchmarks might do best being tackled as individual pieces. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 10:45:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 10:45:01 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.8ed65fb5df9643f9ae5c455c7102a1a5@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #8778 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dreixel): * related: => #8778 Comment: I think so... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 12:06:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 12:06:44 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.a56592b3d3fd263cf1de0dc30ee2df05@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 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 hvr): * milestone: => 7.10.1 Comment: Replying to [comment:23 simonpj]: > Richard (who owns this ticket anyway) is willing to implement this before 7.10. Thanks. (milestone set according to this hint) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 12:49:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 12:49:30 -0000 Subject: [GHC] #9297: Packages linked against certain Windows .dll files give warnings at runtime In-Reply-To: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> References: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> Message-ID: <065.0d17e3d47f023e80613406d175da6967@haskell.org> #9297: Packages linked against certain Windows .dll files give warnings at runtime -------------------------------------+------------------------------------- Reporter: | Owner: simonmar RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: #2283 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #2283 Comment: Fwiw, the code emitting that warning is in `rts/Linker.c`, and has the following comment attached: {{{#!c /* Ticket #2283. Long description: http://support.microsoft.com/kb/132044 tl;dr: If C/C++ compiler sees __declspec(dllimport) ... foo ... it generates call *__imp_foo, and __imp_foo here has exactly the same semantics as in __imp_foo = GetProcAddress(..., "foo") */ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 12:50:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 12:50:30 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.aa92ae548f04d88b5843264469ccf812@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255 | -------------------------------------+------------------------------------- Comment (by mlen): Sorry, I didn't mean to confuse anyone. I should've added the link to phabricator as soon as I pushed to it, I guess. Replying to [comment:18 thoughtpolice]: > I need to do a review on the testsuite changes in the patch, but it seems fine at a quick glance (I mostly wonder about the changes to the testsuite driver). The purpose of changes in test driver was to make it possible to remove compile time flag. Test T9230 wouldn't make any sense if it was run with `-fno-warn-tabs`, so I had to remove that flag for this test. I hope it is still possible for this patch to be released with GHC 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 14:46:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 14:46:33 -0000 Subject: [GHC] #9682: Implement "Add bifunctor related classes to base"-Proposal Message-ID: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> #9682: Implement "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- See [http://www.haskell.org/pipermail/libraries/2014-April/022844.html original libraries@ proposal] for more details -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 14:59:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 14:59:48 -0000 Subject: [GHC] #9682: Implement "Add bifunctor related classes to base"-Proposal In-Reply-To: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> References: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> Message-ID: <057.ba3bb841afa96a22f8e94cbe9d8fed16@haskell.org> #9682: Implement "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D336 | -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:D336 Comment: the first third of this task is up for review at Phab:D336 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 17:04:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 17:04:38 -0000 Subject: [GHC] #9683: ghc: panic! (the 'impossible' happened) [Cant do annotations without GHCi] Message-ID: <048.44005199e43277450218210121321732@haskell.org> #9683: ghc: panic! (the 'impossible' happened) [Cant do annotations without GHCi] -----------------------------+--------------------------------------- Reporter: jeffmaner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: arm | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------+--------------------------------------- The Haskell Platform instructed me to report this as a bug. :) I'm trying to install The Haskell Platform on my Samsung Chromebook, using the wheezy chroot (armv7l GNU/Linux). Actually, I'm trying to install Elm. I've installed the Platform. Installing Elm via `cabal install Elm-0.13 elm-repl-0.3 elm-reactor-0.1 elm-get-0.1.3` , I eventually encounter: [ 3 of 19] Compiling Data.Vector.Fusion.Stream.Size ( Data/Vector/Fusion/Stream/Size.hs, dist/build/Data/Vector/Fusion/Stream/Size.o ) Data/Vector/Fusion/Stream/Size.hs:25:10: Warning: No explicit method nor default method for `*' In the instance declaration for `Num Size' Data/Vector/Fusion/Stream/Size.hs:25:10: Warning: No explicit method nor default method for `abs' In the instance declaration for `Num Size' Data/Vector/Fusion/Stream/Size.hs:25:10: Warning: No explicit method nor default method for `signum' In the instance declaration for `Num Size' [ 4 of 19] Compiling Data.Vector.Internal.Check ( Data/Vector/Internal/Check.hs, dist/build/Data/Vector/Internal/Check.o ) [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for arm-unknown-linux): Cant do annotations without GHCi {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} base:GHC.Exts.ForceSpecConstr{d raqj} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 17:14:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 17:14:23 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.6237912cd0e65b25b56c239890f94a65@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:23 trommler]: > Replying to [comment:13 rwbarton]: > > OK, this is quite annoying, it consistently fails when I do `cabal install -v`, but consistently succeeds when I do `cabal install -v3`! > So with more verbose output you could build compdata. That you could do so consistently looks promising. Perhaps I missed laziness somewhere in my patch for #8935. > > I'll go check. I rebased the patch for #8935 and cannot reproduce the issue for compdata version 0.8.1.0 and 0.9. I also built Haskell Platform [https://build.opensuse.org/project/show/devel:languages:haskell:platform] and pandoc [https://build.opensuse.org/project/show/devel:languages:haskell:pandoc] on OBS and did not see the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 19:20:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 19:20:54 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.b7efba077fa4c7ce404c9661415ce0d6@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: kolmodin Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Driver | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D337 | -------------------------------------+------------------------------------- Changes (by kolmodin): * differential: => Phab:D337 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 20:25:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 20:25:07 -0000 Subject: [GHC] #9445: GHC Panic: Tick Exhausted with high factor In-Reply-To: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> References: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> Message-ID: <063.16a12e0d094d2db5c1efeac6f1aa5f9f@haskell.org> #9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: panic Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: 5539 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by coffeecup.winner): I've got the same error building SFML with Haskell Platform 2014.2 32bit on Windows 7 64bit. Factor of 10000 worked for me (haven't tried more than 1000 and less than 10000). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 20:39:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 20:39:12 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.e9750ac051786001b9c2ae2310253f1a@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Did some GHC profiling, and the problem is clearly the huge number of useless variables in the pattern match in the Core for the record selector functions, here for a three-field-record (I?ll spare us the 3000-field- record): {{{ Test.field3 :: Test.Foo -> GHC.Types.Int -> GHC.Types.Int [GblId[[RecSel]], Arity=1, Caf=NoCafRefs, Str=DmdType] Test.field3 = \ (ds_dm2 :: Test.Foo) -> case ds_dm2 of _ [Occ=Dead] { Test.Foo ds1_dm3 ds2_dm4 ds3_dm5 -> ds3_dm5 } }}} See the attached heap profile, `IdInfo`, `Var`, `IntMap` and `[]` are the biggest chunks. The problem is that a data type declaration like {{{ data R = R { field1 :: T1, field2 :: T2 } }}} generates Haskell code of the form {{{ field3 (R {field3 = x}) = x }}} which is then turned in to the form above by general code that also handles multiple fields, field puns, and further patterns in the field. While the submitter?s code above may or may not be reasonable it migth be worth improving the situation for the benefot of modules with medium-sized records (including GHC?s own DynFlags module). I see a two approaches: 1. Avoid generating actual Core for these selector. Make them implicitly availailbe, and only generated them in STG or later. I am not sure if there is precedence for such implicit things. 2. Extend the this code somehow: {{{ AltCon = DataAlt DataCon | LitAlt Literal | DEFAULT }}} I have two ideas here. Either special-case the single-field-match, i.e. a new constructor {{{ | FieldSelAlt DataCon Int }}} which binds only one variable, the field indicated by the `Int` variable. This would get rid of the quadraticness of the representation. But quite a bit of code would have to handle two cases, and there would be no unique representation of the same match. The other one is to extend `DataAlt` by a bit field: {{{ = DataAlt DataCon [Bool] }}} (with a more suitable data structure for `[Bool]`, e.g. some kind of `BitField`). The idea is that this field specifies what fields of the constructor are actually used by the match. The number of variables bound by such an alternative would equal to the number of `True`s in the list. This would improve every alternative where not all variables are used. It might make some code more complicated ? I could imagine that some compiler phases expect that within a case alternative, there is a locally bound name for every field ? but maybe it?s not too bad. This would still be quadratic (but with a much lower factor ? one bit instead of whatever `Id` + `IdInfo` + `(:)` + whatnot use). We can even get rid of that by making the `BitField` a data type like {{{ data BitField = Empty | Singleton Int | ManyBits ByteString | All }}} (`Empty` would be useful for `Con {}` patterns. Not sure if `All` is useful. Maybe `data BitField = Empty | Singleton Int | All` is actually enough, if few-but-more-than-one-field-patterns are rare.) At this point I?m hoping for someone experienced (e.g. SPJ, of course) to tell us which of these ideas are totally whacky, and which are worth pursuing, and if so, what problems to expect. But this is not a promise that I?ll implement it :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 21:57:33 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 21:57:33 -0000 Subject: [GHC] #9626: Test command lines munged on Windows when running on msys Python In-Reply-To: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> References: <045.ba8ed1b1be50ccb2745f2f043c7174ed@haskell.org> Message-ID: <060.0a2b6ebe4d3def7bcbe4ca094b88ef6a@haskell.org> #9626: Test command lines munged on Windows when running on msys Python -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): This may have been fixed by a recent release of msys2, but I am not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 21:58:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 21:58:00 -0000 Subject: [GHC] #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python In-Reply-To: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> References: <045.6b2d2b3d1bd35df290e16aad746006bd@haskell.org> Message-ID: <060.362e699ce982229e531961774166c9a0@haskell.org> #9014: GHC 7.8.2 Win64 tarball includes gfortran/gcj/python -------------------------------------+------------------------------------- Reporter: refold | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 (Type checker) | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * cc: gintas (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 22:01:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 22:01:47 -0000 Subject: [GHC] #9684: Broken build on OS X (incompatible pthread_setname_np API) Message-ID: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> #9684: Broken build on OS X (incompatible pthread_setname_np API) -------------------------------------+------------------------------------- Reporter: mlen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: MacOS X pthread_setname_np | Type of failure: Building Architecture: Unknown/Multiple | GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | 674c631ea111233daa929ef63500d75ba0db8858 -------------------------------------+------------------------------------- Build is broken on OS X because it is only possible to set thread name for the current thread and `pthread_setname_np` accepts a single argument. This function appeared in 10.6. If that OS version needs to be supported, the best thing that can be done is conditional compilation. A short summary of inconsistencies between different *nix systems can be found here: http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a -thread-in-pthreads-linux/7989973#7989973 The error log: {{{ rts/posix/OSThreads.c:138:30: error: too many arguments to function call, expected 1, have 2 pthread_setname_np(*pId, name); ~~~~~~~~~~~~~~~~~~ ^~~~ /usr/include/pthread.h:471:1: note: 'pthread_setname_np' declared here __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_2) ^ /usr/include/Availability.h:159:50: note: expanded from macro '__OSX_AVAILABLE_STARTING' #define __OSX_AVAILABLE_STARTING(_osx, _ios) __AVAILABILITY_INTERNAL##_osx ^ :65:1: note: expanded from here __AVAILABILITY_INTERNAL__MAC_10_6 ^ /usr/include/AvailabilityInternal.h:3912:72: note: expanded from macro '__AVAILABILITY_INTERNAL__MAC_10_6' #define __AVAILABILITY_INTERNAL__MAC_10_6 __attribute__((availability(macosx,introduced=10.6))) ^ 1 error generated. }}} I can see two possible solutions for OS X: 1. disable setting thread name by conditional compilation. 2. write some trampoline code to work around the fact that it is only possible to set thread name for the current thread. The latter would look like this: {{{ struct wrapper { char *name; void *param; void *(*cont)(void *); }; void *trampoline(void *ctx) { struct wrapper *params = (struct wrapper *)ctx; void *param = params->param; void *(*cont)(void *) = params->cont; #ifdef MACOSX pthread_setname_np(params->name); #elif pthread_setname_np(pthread_self(), params->name); #endif free(params); return cont(param); } int createOSThread (OSThreadId* pId, char *name, OSThreadProc *startProc, void *param) { struct wrapper *ctx = malloc(sizeof(struct wrapper)); ctx->name = name; ctx->cont = startProc; ctx->param = param; int result = pthread_create(pId, NULL, (void *(*)(void *))trampoline, &ctx); if (!result) { pthread_detach(*pId); } else { free(ctx); } return result; } }}} It looks very hackish and I think it'd be better to go with (1), since the original change was made for debugging purposes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 22:06:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 22:06:26 -0000 Subject: [GHC] #9684: Broken build on OS X (incompatible pthread_setname_np API) In-Reply-To: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> References: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> Message-ID: <058.efa1df16a8ae42b071d9c62e28928aed@haskell.org> #9684: Broken build on OS X (incompatible pthread_setname_np API) -------------------------------------+------------------------------------- Reporter: mlen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | pthread_setname_np Type of failure: Building | Architecture: Unknown/Multiple GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | 674c631ea111233daa929ef63500d75ba0db8858| -------------------------------------+------------------------------------- Changes (by mlen): * cc: rodlogic (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 22:11:25 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 22:11:25 -0000 Subject: [GHC] #9685: GHC fails to build with mingw32-make on Windows Message-ID: <045.13b70a7884f3c365add55a5ab5f3ac02@haskell.org> #9685: GHC fails to build with mingw32-make on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be nice to be able to build ghc on Windows with mingw32-make which is bundled with the prebuilt gcc package that we are using for the ghc build. mingw32-make might be faster (due to less overhead associated with POSIX compatibility, forks etc.) and more reliable - msys2's make is a bit glitchy because it needs to fork off a lot of processes and sometimes runs into issues with fork(), which should not be a problem for mingw32-make. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 22:14:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 22:14:30 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.a40da33bcdaa3ef4921b3e83bd85f5da@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255 | -------------------------------------+------------------------------------- Changes (by mlen): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 22:15:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 22:15:12 -0000 Subject: [GHC] #9685: GHC fails to build with mingw32-make on Windows In-Reply-To: <045.13b70a7884f3c365add55a5ab5f3ac02@haskell.org> References: <045.13b70a7884f3c365add55a5ab5f3ac02@haskell.org> Message-ID: <060.6307434603501616a65e706678ab81fc@haskell.org> #9685: GHC fails to build with mingw32-make on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): One of the issues is that a sed command line is being corrupted (I have a workaround for that), the other one presents itself like this: "/usr/local/bin/ghc" -M -static -H64m -O0 -fasm -package-db libraries/bootstrapping.conf -package-name ghc-7.9 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Win32-2.3.0.2 -package array-0.5.0.0 -package base-4.7.0.1 -package bin-package- db-0.0.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package hoopl-3.10.0.2 -package hpc-0.6.0.2 -package process-1.2.0.0 -package time-1.4.2 -package transformers-0.4.1.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -DSTAGE=1 -Rghc-timing -O -fasm -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -dep-makefile compiler/stage1/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg- deps compiler/basicTypes/Avail.hs compiler/basicTypes/BasicTypes.lhs compiler/basicTypes/ConLike.lhs compiler/basicTypes/DataCon.lhs compiler/basicTypes/PatSyn.lhs compiler/basicTypes/Demand.lhs compiler/utils/Exception.hs compiler/main/GhcMonad.hs compiler/main/Hooks.lhs compiler/basicTypes/Id.lhs compiler/basicTypes/IdInfo.lhs compiler/basicTypes/Literal.lhs compiler/llvmGen/Llvm.hs compiler/llvmGen/Llvm/AbsSyn.hs compiler/llvmGen/Llvm/MetaData.hs compiler/llvmGen/Llvm/PpLlvm.hs compiler/llvmGen/Llvm/Types.hs compiler/llvmGen/LlvmCodeGen.hs compiler/llvmGen/LlvmCodeGen/Base.hs compiler/llvmGen/LlvmCodeGen/CodeGen.hs compiler/llvmGen/LlvmCodeGen/Data.hs compiler/llvmGen/LlvmCodeGen/Ppr.hs compiler/llvmGen/LlvmCodeGen/Regs.hs compiler/llvmGen/LlvmMangler.hs compiler/basicTypes/MkId.lhs compiler/basicTypes/Module.lhs compiler/basicTypes/Name.lhs compiler/basicTypes/NameEnv.lhs compiler/basicTypes/NameSet.lhs compiler/basicTypes/OccName.lhs compiler/basicTypes/RdrName.lhs compiler/basicTypes/SrcLoc.lhs compiler/basicTypes/UniqSupply.lhs compiler/basicTypes/Unique.lhs compiler/basicTypes/Var.lhs compiler/basicTypes/VarEnv.lhs compiler/basicTypes/VarSet.lhs compiler/utils/UnVarGraph.hs compiler/cmm/BlockId.hs compiler/cmm/CLabel.hs compiler/cmm/Cmm.hs compiler/cmm/CmmBuildInfoTables.hs compiler/cmm/CmmPipeline.hs compiler/cmm/CmmCallConv.hs compiler/cmm/CmmCommonBlockElim.hs compiler/cmm/CmmContFlowOpt.hs compiler/cmm/CmmExpr.hs compiler/cmm/CmmInfo.hs compiler/stage1/build/CmmLex.hs compiler/cmm/CmmLint.hs compiler/cmm/CmmLive.hs compiler/cmm/CmmMachOp.hs compiler/cmm/CmmNode.hs compiler/cmm/CmmOpt.hs compiler/stage1/build/CmmParse.hs compiler/cmm/CmmProcPoint.hs compiler/cmm/CmmSink.hs compiler/cmm/CmmType.hs compiler/cmm/CmmUtils.hs compiler/cmm/CmmLayoutStack.hs compiler/cmm/MkGraph.hs compiler/nativeGen/PprBase.hs compiler/cmm/PprC.hs compiler/cmm/PprCmm.hs compiler/cmm/PprCmmDecl.hs compiler/cmm/PprCmmExpr.hs compiler/cmm/Bitmap.hs compiler/codeGen/CodeGen/Platform.hs compiler/codeGen/CodeGen/Platform/ARM.hs compiler/codeGen/CodeGen/Platform/NoRegs.hs compiler/codeGen/CodeGen/Platform/PPC.hs compiler/codeGen/CodeGen/Platform/PPC_Darwin.hs compiler/codeGen/CodeGen/Platform/SPARC.hs compiler/codeGen/CodeGen/Platform/X86.hs compiler/codeGen/CodeGen/Platform/X86_64.hs compiler/codeGen/CgUtils.hs compiler/codeGen/StgCmm.hs compiler/codeGen/StgCmmBind.hs compiler/codeGen/StgCmmClosure.hs compiler/codeGen/StgCmmCon.hs compiler/codeGen/StgCmmEnv.hs compiler/codeGen/StgCmmExpr.hs compiler/codeGen/StgCmmForeign.hs compiler/codeGen/StgCmmHeap.hs compiler/codeGen/StgCmmHpc.hs compiler/codeGen/StgCmmArgRep.hs compiler/codeGen/StgCmmLayout.hs compiler/codeGen/StgCmmMonad.hs compiler/codeGen/StgCmmPrim.hs compiler/codeGen/StgCmmProf.hs compiler/codeGen/StgCmmTicky.hs compiler/codeGen/StgCmmUtils.hs compiler/codeGen/StgCmmExtCode.hs compiler/cmm/SMRep.lhs compiler/coreSyn/CoreArity.lhs compiler/coreSyn/CoreFVs.lhs compiler/coreSyn/CoreLint.lhs compiler/coreSyn/CorePrep.lhs compiler/coreSyn/CoreSubst.lhs compiler/coreSyn/CoreSyn.lhs compiler/coreSyn/TrieMap.lhs compiler/coreSyn/CoreTidy.lhs compiler/coreSyn/CoreUnfold.lhs compiler/coreSyn/CoreUtils.lhs compiler/coreSyn/MkCore.lhs compiler/coreSyn/PprCore.lhs compiler/deSugar/Check.lhs compiler/deSugar/Coverage.lhs compiler/deSugar/Desugar.lhs compiler/deSugar/DsArrows.lhs compiler/deSugar/DsBinds.lhs compiler/deSugar/DsCCall.lhs compiler/deSugar/DsExpr.lhs compiler/deSugar/DsForeign.lhs compiler/deSugar/DsGRHSs.lhs compiler/deSugar/DsListComp.lhs compiler/deSugar/DsMonad.lhs compiler/deSugar/DsUtils.lhs compiler/deSugar/Match.lhs compiler/deSugar/MatchCon.lhs compiler/deSugar/MatchLit.lhs compiler/hsSyn/HsBinds.lhs compiler/hsSyn/HsDecls.lhs compiler/hsSyn/HsDoc.hs compiler/hsSyn/HsExpr.lhs compiler/hsSyn/HsImpExp.lhs compiler/hsSyn/HsLit.lhs compiler/hsSyn/PlaceHolder.hs compiler/hsSyn/HsPat.lhs compiler/hsSyn/HsSyn.lhs compiler/hsSyn/HsTypes.lhs compiler/hsSyn/HsUtils.lhs compiler/iface/BinIface.hs compiler/iface/BuildTyCl.lhs compiler/iface/IfaceEnv.lhs compiler/iface/IfaceSyn.lhs compiler/iface/IfaceType.lhs compiler/iface/LoadIface.lhs compiler/iface/MkIface.lhs compiler/iface/TcIface.lhs compiler/iface/FlagChecker.hs compiler/main/Annotations.hs compiler/main/BreakArray.hs compiler/main/CmdLineParser.hs compiler/main/CodeOutput.lhs compiler/stage1/build/Config.hs compiler/main/Constants.lhs compiler/main/DriverMkDepend.hs compiler/main/DriverPhases.hs compiler/main/PipelineMonad.hs compiler/main/DriverPipeline.hs compiler/main/DynFlags.hs compiler/main/ErrUtils.lhs compiler/main/Finder.lhs compiler/main/GHC.hs compiler/main/GhcMake.hs compiler/main/GhcPlugins.hs compiler/main/DynamicLoading.hs compiler/main/HeaderInfo.hs compiler/main/HscMain.hs compiler/main/HscStats.hs compiler/main/HscTypes.lhs compiler/main/InteractiveEval.hs compiler/main/InteractiveEvalTypes.hs compiler/main/PackageConfig.hs compiler/main/Packages.lhs compiler/main/PlatformConstants.hs compiler/main/PprTyThing.hs compiler/main/StaticFlags.hs compiler/main/SysTools.lhs compiler/main/TidyPgm.lhs compiler/parser/Ctype.lhs compiler/parser/HaddockUtils.hs compiler/stage1/build/Lexer.hs compiler/types/OptCoercion.lhs compiler/stage1/build/Parser.hs compiler/parser/RdrHsSyn.lhs compiler/prelude/ForeignCall.lhs compiler/prelude/PrelInfo.lhs compiler/prelude/PrelNames.lhs compiler/prelude/PrelRules.lhs compiler/prelude/PrimOp.lhs compiler/prelude/TysPrim.lhs compiler/prelude/TysWiredIn.lhs compiler/profiling/CostCentre.lhs compiler/profiling/ProfInit.hs compiler/profiling/SCCfinal.lhs compiler/rename/RnBinds.lhs compiler/rename/RnEnv.lhs compiler/rename/RnExpr.lhs compiler/rename/RnHsDoc.hs compiler/rename/RnNames.lhs compiler/rename/RnPat.lhs compiler/rename/RnSource.lhs compiler/rename/RnSplice.lhs compiler/rename/RnTypes.lhs compiler/simplCore/CoreMonad.lhs compiler/simplCore/CSE.lhs compiler/simplCore/FloatIn.lhs compiler/simplCore/FloatOut.lhs compiler/simplCore/LiberateCase.lhs compiler/simplCore/OccurAnal.lhs compiler/simplCore/SAT.lhs compiler/simplCore/SetLevels.lhs compiler/simplCore/SimplCore.lhs compiler/simplCore/SimplEnv.lhs compiler/simplCore/SimplMonad.lhs compiler/simplCore/SimplUtils.lhs compiler/simplCore/Simplify.lhs compiler/simplStg/SimplStg.lhs compiler/simplStg/StgStats.lhs compiler/simplStg/UnariseStg.lhs compiler/specialise/Rules.lhs compiler/specialise/SpecConstr.lhs compiler/specialise/Specialise.lhs compiler/stgSyn/CoreToStg.lhs compiler/stgSyn/StgLint.lhs compiler/stgSyn/StgSyn.lhs compiler/simplCore/CallArity.hs compiler/stranal/DmdAnal.lhs compiler/stranal/WorkWrap.lhs compiler/stranal/WwLib.lhs compiler/typecheck/FamInst.lhs compiler/typecheck/Inst.lhs compiler/typecheck/TcAnnotations.lhs compiler/typecheck/TcArrows.lhs compiler/typecheck/TcBinds.lhs compiler/typecheck/TcClassDcl.lhs compiler/typecheck/TcDefaults.lhs compiler/typecheck/TcDeriv.lhs compiler/typecheck/TcEnv.lhs compiler/typecheck/TcExpr.lhs compiler/typecheck/TcForeign.lhs compiler/typecheck/TcGenDeriv.lhs compiler/typecheck/TcGenGenerics.lhs compiler/typecheck/TcHsSyn.lhs compiler/typecheck/TcHsType.lhs compiler/typecheck/TcInstDcls.lhs compiler/typecheck/TcMType.lhs compiler/typecheck/TcValidity.lhs compiler/typecheck/TcMatches.lhs compiler/typecheck/TcPat.lhs compiler/typecheck/TcPatSyn.lhs compiler/typecheck/TcRnDriver.lhs compiler/typecheck/TcRnMonad.lhs compiler/typecheck/TcRnTypes.lhs compiler/typecheck/TcRules.lhs compiler/typecheck/TcSimplify.lhs compiler/typecheck/TcErrors.lhs compiler/typecheck/TcTyClsDecls.lhs compiler/typecheck/TcTyDecls.lhs compiler/typecheck/TcType.lhs compiler/typecheck/TcEvidence.lhs compiler/typecheck/TcUnify.lhs compiler/typecheck/TcInteract.lhs compiler/typecheck/TcCanonical.lhs compiler/typecheck/TcSMonad.lhs compiler/typecheck/TcTypeNats.hs compiler/typecheck/TcSplice.lhs compiler/types/Class.lhs compiler/types/Coercion.lhs compiler/types/FamInstEnv.lhs compiler/typecheck/FunDeps.lhs compiler/types/InstEnv.lhs compiler/types/TyCon.lhs compiler/types/CoAxiom.lhs compiler/types/Kind.lhs compiler/types/Type.lhs compiler/types/TypeRep.lhs compiler/types/Unify.lhs compiler/utils/Bag.lhs compiler/utils/Binary.hs compiler/utils/BooleanFormula.hs compiler/utils/BufWrite.hs compiler/utils/Digraph.lhs compiler/utils/Encoding.hs compiler/utils/FastBool.lhs compiler/utils/FastFunctions.lhs compiler/utils/FastMutInt.lhs compiler/utils/FastString.lhs compiler/utils/FastTypes.lhs compiler/stage1/build/Fingerprint.hs compiler/utils/FiniteMap.lhs compiler/utils/GraphBase.hs compiler/utils/GraphColor.hs compiler/utils/GraphOps.hs compiler/utils/GraphPpr.hs compiler/utils/IOEnv.hs compiler/utils/ListSetOps.lhs compiler/utils/Maybes.lhs compiler/utils/MonadUtils.hs compiler/utils/OrdList.lhs compiler/utils/Outputable.lhs compiler/utils/Pair.lhs compiler/utils/Panic.lhs compiler/utils/Pretty.lhs compiler/utils/Serialized.hs compiler/utils/State.hs compiler/utils/Stream.hs compiler/utils/StringBuffer.lhs compiler/utils/UniqFM.lhs compiler/utils/UniqSet.lhs compiler/utils/Util.lhs compiler/utils/ExtsCompat46.hs compiler/vectorise/Vectorise/Builtins/Base.hs compiler/vectorise/Vectorise/Builtins/Initialise.hs compiler/vectorise/Vectorise/Builtins.hs compiler/vectorise/Vectorise/Monad/Base.hs compiler/vectorise/Vectorise/Monad/Naming.hs compiler/vectorise/Vectorise/Monad/Local.hs compiler/vectorise/Vectorise/Monad/Global.hs compiler/vectorise/Vectorise/Monad/InstEnv.hs compiler/vectorise/Vectorise/Monad.hs compiler/vectorise/Vectorise/Utils/Base.hs compiler/vectorise/Vectorise/Utils/Closure.hs compiler/vectorise/Vectorise/Utils/Hoisting.hs compiler/vectorise/Vectorise/Utils/PADict.hs compiler/vectorise/Vectorise/Utils/Poly.hs compiler/vectorise/Vectorise/Utils.hs compiler/vectorise/Vectorise/Generic/Description.hs compiler/vectorise/Vectorise/Generic/PAMethods.hs compiler/vectorise/Vectorise/Generic/PADict.hs compiler/vectorise/Vectorise/Generic/PData.hs compiler/vectorise/Vectorise/Type/Env.hs compiler/vectorise/Vectorise/Type/Type.hs compiler/vectorise/Vectorise/Type/TyConDecl.hs compiler/vectorise/Vectorise/Type/Classify.hs compiler/vectorise/Vectorise/Convert.hs compiler/vectorise/Vectorise/Vect.hs compiler/vectorise/Vectorise/Var.hs compiler/vectorise/Vectorise/Env.hs compiler/vectorise/Vectorise/Exp.hs compiler/vectorise/Vectorise.hs compiler/cmm/Hoopl/Dataflow.hs compiler/cmm/Hoopl.hs compiler/nativeGen/AsmCodeGen.lhs compiler/nativeGen/TargetReg.hs compiler/nativeGen/NCGMonad.hs compiler/nativeGen/Instruction.hs compiler/nativeGen/Size.hs compiler/nativeGen/Reg.hs compiler/nativeGen/RegClass.hs compiler/nativeGen/PIC.hs compiler/utils/Platform.hs compiler/nativeGen/CPrim.hs compiler/nativeGen/X86/Regs.hs compiler/nativeGen/X86/RegInfo.hs compiler/nativeGen/X86/Instr.hs compiler/nativeGen/X86/Cond.hs compiler/nativeGen/X86/Ppr.hs compiler/nativeGen/X86/CodeGen.hs compiler/nativeGen/PPC/Regs.hs compiler/nativeGen/PPC/RegInfo.hs compiler/nativeGen/PPC/Instr.hs compiler/nativeGen/PPC/Cond.hs compiler/nativeGen/PPC/Ppr.hs compiler/nativeGen/PPC/CodeGen.hs compiler/nativeGen/SPARC/Base.hs compiler/nativeGen/SPARC/Regs.hs compiler/nativeGen/SPARC/Imm.hs compiler/nativeGen/SPARC/AddrMode.hs compiler/nativeGen/SPARC/Cond.hs compiler/nativeGen/SPARC/Instr.hs compiler/nativeGen/SPARC/Stack.hs compiler/nativeGen/SPARC/ShortcutJump.hs compiler/nativeGen/SPARC/Ppr.hs compiler/nativeGen/SPARC/CodeGen.hs compiler/nativeGen/SPARC/CodeGen/Amode.hs compiler/nativeGen/SPARC/CodeGen/Base.hs compiler/nativeGen/SPARC/CodeGen/CondCode.hs compiler/nativeGen/SPARC/CodeGen/Gen32.hs compiler/nativeGen/SPARC/CodeGen/Gen64.hs compiler/nativeGen/SPARC/CodeGen/Sanity.hs compiler/nativeGen/SPARC/CodeGen/Expand.hs compiler/nativeGen/RegAlloc/Liveness.hs compiler/nativeGen/RegAlloc/Graph/Main.hs compiler/nativeGen/RegAlloc/Graph/Stats.hs compiler/nativeGen/RegAlloc/Graph/ArchBase.hs compiler/nativeGen/RegAlloc/Graph/ArchX86.hs compiler/nativeGen/RegAlloc/Graph/Coalesce.hs compiler/nativeGen/RegAlloc/Graph/Spill.hs compiler/nativeGen/RegAlloc/Graph/SpillClean.hs compiler/nativeGen/RegAlloc/Graph/SpillCost.hs compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs compiler/nativeGen/RegAlloc/Linear/Main.hs compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs compiler/nativeGen/RegAlloc/Linear/State.hs compiler/nativeGen/RegAlloc/Linear/Stats.hs compiler/nativeGen/RegAlloc/Linear/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/StackMap.hs compiler/nativeGen/RegAlloc/Linear/Base.hs compiler/nativeGen/RegAlloc/Linear/X86/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/X86_64/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/PPC/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/SPARC/FreeRegs.hs target `compil' is not a module name or a source file <> compiler/ghc.mk:656: recipe for target 'compiler/stage1/build/.depend-v.haskell' failed This could be due to a truncation of a long command line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 22:20:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 22:20:00 -0000 Subject: [GHC] #9686: Link option detection does not work for incremental builds on Windows Message-ID: <045.5344aa82eaf7c34a0b72f08bd8458a01@haskell.org> #9686: Link option detection does not work for incremental builds on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- ghc on Linux embeds link options into the resulting binary in order to be able to tell when a binary needs to be recompiled because different link options have been passed in to ghc. This functionality is not present on Windows, forcing users to pass in -fforce-recomp. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 22:23:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 22:23:13 -0000 Subject: [GHC] #9686: Link option detection does not work for incremental builds on Windows In-Reply-To: <045.5344aa82eaf7c34a0b72f08bd8458a01@haskell.org> References: <045.5344aa82eaf7c34a0b72f08bd8458a01@haskell.org> Message-ID: <060.f933a3e90fe1d0fc6d907090d3fe1ad5@haskell.org> #9686: Link option detection does not work for incremental builds on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): I have a patch for this, but I have been having severe trouble with Windows rejecting all binaries with a custom section embedded into them... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 12 23:11:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Oct 2014 23:11:58 -0000 Subject: [GHC] #9684: Broken build on OS X (incompatible pthread_setname_np API) In-Reply-To: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> References: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> Message-ID: <058.0d7f1ba3e96cf4083869311ae1bd9c01@haskell.org> #9684: Broken build on OS X (incompatible pthread_setname_np API) -------------------------------------+------------------------------------- Reporter: mlen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | pthread_setname_np Type of failure: Building | Architecture: Unknown/Multiple GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | Phab:rGHC674c631ea111233daa929ef63500d75ba0db8858| -------------------------------------+------------------------------------- Changes (by hvr): * differential: 674c631ea111233daa929ef63500d75ba0db8858 => Phab:rGHC674c631ea111233daa929ef63500d75ba0db8858 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 00:46:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 00:46:03 -0000 Subject: [GHC] #9687: Missing Typeable instances for built-in types Message-ID: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> #9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | 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: -------------------------------------+------------------------------------- According to the PolyTypeable wiki, https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable, "Users can no longer giving manual instances of `Typeable`; they must be derived." I cannot figure out how to do this for built-in types with missing `Typeable` instances. For example, my code requires a `Typeable` instance for 8-tuples. However, `Typeable` instances are natively only defined for 2- to 7-tuples: {{{ Prelude> :m Data.Typeable Prelude Data.Typeable> typeOf (1) Integer Prelude Data.Typeable> typeOf (1,2) (Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3) (Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4) (Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5) (Integer,Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5,6) (Integer,Integer,Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5,6,7) (Integer,Integer,Integer,Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5,6,7,8) :10:1: No instance for (Typeable (,,,,,,,)) arising from a use of ?typeOf? In the expression: typeOf (1, 2, 3, 4, 5, 6, 7, 8) In an equation for ?it?: it = typeOf (1, 2, 3, 4, 5, 6, 7, 8) Prelude Data.Typeable> }}} Since my code does not define the type of 8-tuples (it is defined in the Prelude, or even in the compiler), it is not possible to "derive" a Typeable instance for it. With the old Typeable class, I could just define it myself: {{{ instance (Typeable a, Typeable b, Typeable c, Typeable d, Typeable e, Typeable f, Typeable g, Typeable h) => Typeable (a,b,c,d,e,f,g,h) where typeOf _ = typerep where typerep = mkTyCon3 "GHC" "Tuple" "(,,,,,,,)" `mkTyConApp` [ typeOf (undefined :: a), typeOf (undefined :: b), typeOf (undefined :: c), typeOf (undefined :: d), typeOf (undefined :: e), typeOf (undefined :: f), typeOf (undefined :: g), typeOf (undefined :: h) ] }}} With the new `Typeable` class, I am completely stumped. How can I "derive" an instance for a pre-defined type? I think this is a bug. `Typeable` instances should be pre-defined for all pre-defined types, including //n//-tuples for all //n//. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 02:10:54 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 02:10:54 -0000 Subject: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.e445470d667821a73794c15c5edfa718@haskell.org> #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Type checker) | Keywords: Resolution: | Architecture: x86 Operating System: MacOS X | Difficulty: Unknown Type of failure: Incorrect | Blocked By: warning at compile-time | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by GregWeber): This issue is being seen while running: cabal install yesod-core https://github.com/yesodweb/yesod/issues/721 I am using ghc 7.8.3 on Ubuntu linux from this Dockerfile: zsol/haskell- platform-2014.2.0.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 05:08:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 05:08:23 -0000 Subject: [GHC] #9688: Improve the interaction between CSE and the join point transformation Message-ID: <045.ad5940048773c77749dabb4d904f5fb8@haskell.org> #9688: Improve the interaction between CSE and the join point transformation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: CSE | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It appears that the join point transformation sometimes interferes with CSE when CSE would be much better. Two examples: === digitToIntMaybe === Suppose we define {{{#!hs isHexDigit :: Char -> Bool isHexDigit c = (fromIntegral (ord c - ord '0')::Word) <= 9 || (fromIntegral (ord c - ord 'a')::Word) <= 5 || (fromIntegral (ord c - ord 'A')::Word) <= 5 digitToInt c | (fromIntegral dec::Word) <= 9 = dec | (fromIntegral hexl::Word) <= 5 = hexl + 10 | (fromIntegral hexu::Word) <= 5 = hexu + 10 | otherwise = error ("Char.digitToInt: not a digit " ++ show c) -- sigh where dec = ord c - ord '0' hexl = ord c - ord 'a' hexu = ord c - ord 'A' -- We could also expand this out in cases manually, but it makes no -- difference as far as I can tell. }}} Suppose we then write a naive `digitToIntMaybe` function: {{{#!hs digitToIntMaybe c | isHexDigit c = Just (digitToInt c) | otherwise = Nothing }}} What I would want this to do is "zip" the nested cases and give Core like this: {{{ $wdigitToIntMaybe $wdigitToIntMaybe = \ ww_s2Ag -> let { x#_a2yy x#_a2yy = -# (ord# ww_s2Ag) 48 } in case tagToEnum# (leWord# (int2Word# x#_a2yy) (__word 9)) of _ { False -> let { x#1_X2z7 x#1_X2z7 = -# (ord# ww_s2Ag) 97 } in case tagToEnum# (leWord# (int2Word# x#1_X2z7) (__word 5)) of _ { False -> let { x#2_X2zh x#2_X2zh = -# (ord# ww_s2Ag) 65 } in case tagToEnum# (leWord# (int2Word# x#2_X2zh) (__word 5)) of _ { False -> Nothing; True -> Just (I# (+# x#2_X2zh 10)) }; True -> Just (I# (+# x#1_X2z7 10)) }; True -> Just (I# x#_a2yy) } digitToIntMaybe digitToIntMaybe = \ w_s2Ad -> case w_s2Ad of _ { C# ww1_s2Ag -> $wdigitToIntMaybe ww1_s2Ag } }}} But instead, the join point transformation triggers, and we get this: {{{ digitToIntMaybe1 digitToIntMaybe1 = \ ww_s2Cp -> error (unpackAppendCString# "Char.digitToInt: not a digit "# ($w$cshowsPrec15 ww_s2Cp ([]))) $wdigitToIntMaybe $wdigitToIntMaybe = \ ww_s2Cp -> let { $j_s2Bc $j_s2Bc = \ _ -> Just (let { a_s2B5 a_s2B5 = int2Word# (-# (ord# ww_s2Cp) 48) } in case tagToEnum# (leWord# a_s2B5 (__word 9)) of _ { False -> let { a1_s2B7 a1_s2B7 = int2Word# (-# (ord# ww_s2Cp) 97) } in case tagToEnum# (leWord# a1_s2B7 (__word 5)) of _ { False -> let { a2_s2B9 a2_s2B9 = int2Word# (-# (ord# ww_s2Cp) 65) } in case tagToEnum# (leWord# a2_s2B9 (__word 5)) of _ { False -> digitToIntMaybe1 ww_s2Cp; True -> I# (+# (word2Int# a2_s2B9) 10) }; True -> I# (+# (word2Int# a1_s2B7) 10) }; True -> I# (word2Int# a_s2B5) }) } in case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 48)) (__word 9)) of _ { False -> case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 97)) (__word 5)) of _ { False -> case tagToEnum# (leWord# (int2Word# (-# (ord# ww_s2Cp) 65)) (__word 5)) of _ { False -> Nothing; True -> $j_s2Bc void# }; True -> $j_s2Bc void# }; True -> $j_s2Bc void# } digitToIntMaybe digitToIntMaybe = \ w_s2Cm -> case w_s2Cm of _ { C# ww1_s2Cp -> $wdigitToIntMaybe ww1_s2Cp } }}} We perform the same three tests twice each, and test for an error condition that obviously can't happen. === `quotRem` and `divMod` === If we define {{{#!hs x `quot` y = fst (x `quotRem` y) x `rem` y = snd (x `quotRem` y) }}} and then write something like {{{#!hs f x y | x `rem` y == 0 = x `quot` y | otherwise = 17 }}} then CSE works some magic and we only calculate `quotRem x y` once. Unfortunately, if we do this: {{{#!hs whatever x y = if x `myRem` y == 0 then (x `myQuot` y) + 14 else x `myQuot` y }}} then the join point transformation fires, collecting the `myQuot x y` expressions in the case branches and preventing CSE from recognizing the much better opportunity to eliminate those calculations altogether. The situation with `divMod` is much worse. The join point transformation applied to the cases defining `divMod` prevents CSE from working magic on it in even simple situations, unless one of the arguments is known, making this definition unusable (the resulting Core is too horrifyingly long to paste here). It would probably be possible to improve the `divMod` situation to something close to the `quotRem` one by making `divMod` `NOINLINE` and adding special `divModLit` rules, but I'd much rather see a general solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 07:51:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 07:51:30 -0000 Subject: [GHC] #9672: Error message too long (full case statement printed) In-Reply-To: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> References: <051.99a860bf6093bb48bfa9c98f3e2d6cd2@haskell.org> Message-ID: <066.a798b3d6a638757d2ddac6a354a5ec51@haskell.org> #9672: Error message too long (full case statement printed) -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Sadly error messages are (ultimately) `Pretty.Doc`s, and we currently lack a way to ask how long they are. Actually that might not be a hard thing to add; one could simply add up the length of the strings in the `Doc` (which is a data structure. That would not tell you how much white space would be printed (you'd have to render it for that), but it would tell you how much payload there was. There is also a currently-fixed constant `TcRnMonad.mAX_CONTEXTS` which says how many layers of "In ..." to print. That could easily be made into a `DynFlag`. So there you are: two fairly easy-to-implement ideas. The relevant function is `TcRnMonad.add_err_tcm`. Anyone want to try this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 08:22:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 08:22:32 -0000 Subject: [GHC] #9297: Packages linked against certain Windows .dll files give warnings at runtime In-Reply-To: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> References: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> Message-ID: <065.0ef783cee7f60594d9fd20e8aa84e7a8@haskell.org> #9297: Packages linked against certain Windows .dll files give warnings at runtime -------------------------------------+------------------------------------- Reporter: | Owner: simonmar RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: #2283 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"c375de0193f66df55fa765a7562f2c1a3d2dba93/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c375de0193f66df55fa765a7562f2c1a3d2dba93" Update `time` submodule to address linker issue See also https://github.com/haskell/time/issues/2 However, while the `time-1.5` package now loads successful in GHCi, the linker warnings as reported in #9297 occur (which let the testsuite fail for a dozen of testcases due to this additional output) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 08:22:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 08:22:50 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.ab7cb220a2e46a3716085fdade63bf21@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, comment:24 seems better. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 08:28:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 08:28:01 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.d9122d7ea800e3574c30dd82873290c1@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): I updated the work in progress on D297 with this approach, and it feels much better, and is less invasive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 08:43:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 08:43:30 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.a4b1e5f2d829743f50e02202684490ee@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): There is one other issue required for source to source conversions, namely original literal values. When literals are parsed, they are converted into an internal representation, and the original string is discarded. I am proposing to amend `HsLit` to be {{{ #!haskell data HsLit = HsChar String Char -- Character | HsCharPrim String Char -- Unboxed character | HsString String FastString -- String | HsStringPrim String ByteString -- Packed bytes | HsInt String Integer -- Genuinely an Int; arises from -- TcGenDeriv, and from TRANSLATION | HsIntPrim String Integer -- literal Int# | HsWordPrim String Integer -- literal Word# | HsInt64Prim String Integer -- literal Int64# | HsWord64Prim String Integer -- literal Word64# | HsInteger String Integer Type -- Genuinely an integer; arises only from -- TRANSLATION (overloaded literals are -- done with HsOverLit) | HsRat String FractionalLit Type -- Genuinely a rational; arises only from -- TRANSLATION (overloaded literals are -- done with HsOverLit) | HsFloatPrim String FractionalLit -- Unboxed Float | HsDoublePrim String FractionalLit -- Unboxed Double deriving (Data, Typeable) }}} where the first parameter in each case is the original source code represetation of the literal. Should this be a `String` or a `FastString`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 08:43:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 08:43:40 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.4a2dd6b9b7bb4e8d8c27143a93733416@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree that it is tantalising that so much `Core` is necessary to generate so little object code. Nevertheless, I am ''deeply'' reluctant to fiddle with the representation of `Core`. Doing so will impose overheads on every pass that deals with Core, and I'm far from convinced that it'll solve the problem. Anything along these lines would risk breaking optimisations. For example, here is how GHC optimises repeated evaluation of the same data constructor. Consider {{{ case x of K a _ _ _ -> ... (case x of K _ _ c _ -> ...a..c..) ... }}} Clearly we'd like to optimise this to {{{ case x of K a _ c _ -> ... ( ...a..c.. ) ... }}} And GHC does so by (effecitvely) transforming to {{{ case x of K a bb cc dd -> let x = K a bb cc dd in ... (case x of K _ _ c _ -> ...a..c..) ... }}} The `let` shadows the outer binding of `x`. Now the inner `case` can see that `x` is bound to `(K a bb cc dd)`, and so it's easy to do case-of- known-constructor to the inner case, giving {{{ case x of K a bb cc dd -> let x = K a bb cc dd in ... (let c = cc in ...a..c..) ... }}} (The `let` doesn't really exist, of course, it's only in the Simplifier's head.) All this is threatened if the outer case binds only `a`. I think a decent alternative approach would be not to generate code for selectors (at least when there are many fields) but rather to inline them at usage sites, via a so-called "compulsory unfolding". That too risks lots of code if you use a lot of record selectors, so it's not exactly a solid fix. The other thing is that I think it's quite likely that GHC has accumulated a space leak. The compiler makes repeated passes over the `Core` program. To avoid a leak, all vestiges of the input of each pass should be gone by the time we have computed the output of that pass. But I would not be amazed if that was not true at all -- that vesiges of pass 1 were still in memory when we were on pass 10. I would '''love''' someone to really look at this for us. It's not easy, but it could give a huge payoff for every GHC compilation, not just these weird corner cases. I certainly think we should be sure this is ''not'' happening before investing effort in optimising particular cases Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 09:00:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 09:00:03 -0000 Subject: [GHC] #9687: Missing Typeable instances for built-in types In-Reply-To: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> References: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> Message-ID: <062.35a436478c80788431f5a361985d1bf6@haskell.org> #9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): What if you say {{{ instance (Typeable a, Typeable b, Typeable c, Typeable d, Typeable e, Typeable f, Typeable g, Typeable h) => Typeable (a,b,c,d,e,f,g,h) }}} using standalone deriving? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 09:02:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 09:02:33 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.9412c6bfd854ba8c67ef35c96c9620c9@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for your input. The way it breaks optimisation is what I meant with ?making some code more complicated?: With a sparse list of bound variables, it would have to check which fields the optimization would like to use and then generated them on demand. I see that that might make the code very ugly.. The compulsory unfolding you mention would still be of the the shape of a huge pattern match, right? So the quadratic behaviour wouldn?t be eliminated. A comparison of the heap profile with and without `-dverbose-core2core` (using this as a poor man?s deepseq after each phase) shows that there might be a space leak, as you guess. (Uploading both graphs.) @Polarina: A work-around for you might be to not use a data constructor, but a newtype around a `Vector (Int -> Int)` (inner type mostly irrelevant). You store the functions therein and your accessor functions would use `unsafeIndex` and `unsafeCoerce` to get them out again. You can wrap that highly unsafe code in a module that can be used in a totally safe way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 09:09:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 09:09:07 -0000 Subject: [GHC] #9684: Broken build on OS X (incompatible pthread_setname_np API) In-Reply-To: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> References: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> Message-ID: <058.1f54133ff36d52171d92a4d00d12251d@haskell.org> #9684: Broken build on OS X (incompatible pthread_setname_np API) -------------------------------------+------------------------------------- Reporter: mlen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | pthread_setname_np Type of failure: Building | Architecture: Unknown/Multiple GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | Phab:rGHC674c631ea111233daa929ef63500d75ba0db8858| -------------------------------------+------------------------------------- Comment (by mlen): Proposed patch: Phab:D338 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 09:09:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 09:09:55 -0000 Subject: [GHC] #9684: Broken build on OS X (incompatible pthread_setname_np API) In-Reply-To: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> References: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> Message-ID: <058.3bc60b7eedf292b172007795c0cca536@haskell.org> #9684: Broken build on OS X (incompatible pthread_setname_np API) -------------------------------------+------------------------------------- Reporter: mlen | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | pthread_setname_np Type of failure: Building | Architecture: Unknown/Multiple GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | Phab:rGHC674c631ea111233daa929ef63500d75ba0db8858,| Phab:D338 | -------------------------------------+------------------------------------- Changes (by mlen): * status: new => patch * differential: Phab:rGHC674c631ea111233daa929ef63500d75ba0db8858 => Phab:rGHC674c631ea111233daa929ef63500d75ba0db8858, Phab:D338 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 09:16:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 09:16:52 -0000 Subject: [GHC] #9688: Improve the interaction between CSE and the join point transformation In-Reply-To: <045.ad5940048773c77749dabb4d904f5fb8@haskell.org> References: <045.ad5940048773c77749dabb4d904f5fb8@haskell.org> Message-ID: <060.f72a88c0cf85f1037ac4ba48f33df562@haskell.org> #9688: Improve the interaction between CSE and the join point transformation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: CSE Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed! It looks like a classic code-specialisation question to me. In `digitToIntMaybe` you use some code `isHexDigit` that just happens to use the same tests as the RHS, `digitToInt`. Moreover there are three ways for `isHexDigit` to succeed. If you duplicate the RHS into those three outcomes you'll get the result you want; this amounts to inlining `$j_s2BC`. But that entails code duplication -- and might gain nothing whatsoever. Or, to put it another way, if the user wrote the above `Core`, complete with the local function `$j_s2BC`, would you expect it to be optimised? It would be cool if so. But I don't yet see how to achieve that at reasonable cost. To put it another way, if you wrote this in C: {{{ if blah then x = e1 else x = e2 if similar-blah then s1 else s2 }}} you'd usually expect to test `blah`, assign to `x`, and then test `similar-blah` and do `s1` or `s2`. But it might be better to duplicate (i.e. specialise) the first `if` into the branches: {{{ if similar-blah then { if blah then x=e1 else x=e2 s1 } else { if blah then x=e1 else x=e2 s2 } }}} and now the inner `if` might be optimised away entirely. These are not simple choices. By representing them as simple inlining choices ("shall I inline `$j_s2Bc`?") GHC piggy backs on a lot of careful heuristics for inlining. But, I agree, it does not always work well. I have taken time to explain here, in the hope that someone can do better! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 09:28:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 09:28:40 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.8245c080f6f39dc6d44447b16a5e076c@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): A space leak seems to be hidden in `DmdAnal`. Maybe strictness annotation calculation for dead variables, which are then never used? I?m preparing a compiler perf test case so that we can track possible improvements. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 09:33:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 09:33:58 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.a7793e166a4ed0fc5d81fcf92c3ab795@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by simonpj): I suggest doing so only if the two can differ. In the case of `String` there can be string gaps, thus {{{ foo :: String foo = "blah blah\ \more blah blah\ \and more" }}} and I guess you want to have all that layout reproduced. Fine. But for integers like `3234242329423`, I don't see how the displayed form could differ. For `Words` perhaps there is binary/hex forms? Regardless, I'm not against this, but very keen that the reasons for keeping the two are documented on a per-literal basis, as I have begun to do above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 10:24:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 10:24:20 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.19417637c035ff355c7d27d5110771d0@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by snoyberg): I don't know how useful that profiling output will be, it gives {{{ bindIO.\ GHC.Base 96.5 17.5 }}} I've uploaded the full output at: https://gist.github.com/snoyberg/ca67756944235e4e2d96 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 10:24:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 10:24:47 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.db31c17a9169cd726718be1657d24264@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"05f962df2ba028fd304fdada9e68e7199822cbf0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="05f962df2ba028fd304fdada9e68e7199822cbf0" Compiler performance benchmark for #9675 so that whoever improves the situation can feel good about it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 12:14:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 12:14:17 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.220020bb58fa34bb0f717eda5def894c@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): As Jan says, `n ==# 3#` is transformed into a case expression by `litEq`. The comment says {{{ -- This stuff turns -- n ==# 3# -- into -- case n of -- 3# -> True -- m -> False -- -- This is a Good Thing, because it allows case-of case things -- to happen, and case-default absorption to happen. For -- example: -- -- if (n ==# 3#) || (n ==# 4#) then e1 else e2 -- will transform to -- case n of -- 3# -> e1 -- 4# -> e1 -- m -> e2 }}} So a chain of equality comparisons will turn into a table-driven jump in the end, which is a good thing. On the other hand, generating branch nests is a bad thing. Arguably, the Big Reason for wanting the tables is for source programs like this: {{{ f 0# = e1 f 1# = e2 f 2# = e3 ... f _ = en }}} Here we really would like to generate a single case with many alternatives. When compiled, without `litEq`, it'd look like {{{ f x = case (x ==# 0#) of 1# -> e1 -- True branch _ -> case (x ==# 1#) of 1# -> e2 -- True branch _ -> ..etc.. }}} (I'm omitting the annoying `tagToEnum` clutter, see #6135.) So perhaps `litEq` should apply only ''when in the context of a `case` expression that immediately scrutinises its result''. So `litEq` would become {{{ case (a ==# k) of 1# -> e1; _ -> e2 ---> case a of { k -> e1; _ -> e2 } }}} Annoyingly, the `CoreSyn.RuleFun` API for built-in rules does not give access to the context of an application (the `SimplCont`), but it would not be hard to make it do so. So if that is the right rewrite, then it'd be another useful project for someone. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 12:23:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 12:23:19 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.eaf28d494c092d439f80097de7265a53@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Heap profiling tells me that most of it is retained by `dmdAnalRhs`, produced by `annotateBndrs/dmdAnalAlt/dmdAnal'`. But even after cluttering most of the module with {{{`seq`}}} and bang patterns, the leak is still there.... and just while I was about to give up I found the problem: The environment part of a DmdType is not seq?ed. Doing that does great good. Patch coming.... :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 12:52:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 12:52:59 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.a52ecf8505b68ac5bd338c0c1f74568f@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): That sounds very plausible -- thank you! Do de-clutter when you are done :-). In fact if you grep for `seq` you'll find a variety of `seqs`, some of which probably do nothing useful while costing execution time. You are in an excellent position to find out, if you feel up to doing so. Really each should be accompanied with a story for why it is there. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 12:55:40 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 12:55:40 -0000 Subject: [GHC] #9681: Printing of "\n" in error messages is broken In-Reply-To: <045.abc102fa93d2a130d37cc7ab11f8ef8d@haskell.org> References: <045.abc102fa93d2a130d37cc7ab11f8ef8d@haskell.org> Message-ID: <060.b405d4b441a3b2cc045da97f94eb6db4@haskell.org> #9681: Printing of "\n" in error messages is broken -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: 1+"\n" | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high * milestone: => 7.10.1 Comment: That's very odd, but can't be hard for someone to find. A nice contained bug-fix, if someone feels like looking. I the offending function is probably `Outputable.pprHsString`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 13:20:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 13:20:23 -0000 Subject: [GHC] #9675: Unreasonable memory usage on large data structures In-Reply-To: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> References: <047.9ab90e8da30a204a6defabed11bcf527@haskell.org> Message-ID: <062.334abebed8dbce125ce8692615853aa1@haskell.org> #9675: Unreasonable memory usage on large data structures -------------------------------------+------------------------------------- Reporter: Polarina | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"d9db81f4ed8ca6e7262f84347174d6b0e2e9a76a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d9db81f4ed8ca6e7262f84347174d6b0e2e9a76a" seqDmdType needs to seq the DmdEnv as well otherwise this can retain large lazy calculations. This fixed one space leak pointed out in #9675. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 14:49:52 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 14:49:52 -0000 Subject: [GHC] Batch modify: #9125, #5987, #7298, #7411, #7478, #7521, #7567, #7602, #7651, #7919, #8228, #8276, #8701, #8736, #8935, #8974, #9007, #9186, #9314, #9345, #9575, #5757, #7028, #7143, #7305, #7475, #7655, #7665, #7695, #8362, #8951, #8975, #8976, #8981, #9034, #9046, #9100, #9237, #9238, #9316, #9371, #9372, #9390, #9415, #9523, #9537, #9620, #8303 Message-ID: <20141013144952.EA0C93A2FF@ghc.haskell.org> Batch modification to #9125, #5987, #7298, #7411, #7478, #7521, #7567, #7602, #7651, #7919, #8228, #8276, #8701, #8736, #8935, #8974, #9007, #9186, #9314, #9345, #9575, #5757, #7028, #7143, #7305, #7475, #7655, #7665, #7695, #8362, #8951, #8975, #8976, #8981, #9034, #9046, #9100, #9237, #9238, #9316, #9371, #9372, #9390, #9415, #9523, #9537, #9620, #8303 by thoughtpolice: milestone to 7.10.1 Comment: Moving (in bulk) to 7.10.4 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 15:03:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 15:03:36 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.9e884b8e047067c83452f31b79f3a14f@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D329 | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: 7.10.1 => 7.8.4 Comment: The `initsR` version, at least, can slip into 7.8.4 without any ripples. Changing milestone back per thoughtpolice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 15:05:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 15:05:46 -0000 Subject: [GHC] #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 In-Reply-To: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> References: <050.5fee54245fb87c6e3084e133f6c420a0@haskell.org> Message-ID: <065.d6d85218839744c2a04b4827f33b41ae@haskell.org> #8960: SpecConstr usage explodes beyond 4GB with GHC 7.8.1 rc 2 -------------------------------------+------------------------------------- Reporter: | Owner: MichalGajda | Status: merge Type: bug | Milestone: 7.8.4 Priority: high | Version: 7.8.1-rc2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: #7068, #7898 time crash | Test Case: cabal | install hPDB | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 15:11:30 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 15:11:30 -0000 Subject: [GHC] #9687: Missing Typeable instances for built-in types In-Reply-To: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> References: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> Message-ID: <062.d5fb25e88b2b4aec5656d318f4b3ea81@haskell.org> #9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by selinger): Simon, what you suggest seems like the logical solution, but doesn't currently work. Test.hs: {{{ import Data.Typeable instance (Typeable a, Typeable b, Typeable c, Typeable d, Typeable e, Typeable f, Typeable g, Typeable h) => Typeable (a,b,c,d,e,f,g,h) }}} And here's what happens when you compile it: {{{ selinger at firefly-virtual:/tmp$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 selinger at firefly-virtual:/tmp$ ghc Test [1 of 1] Compiling Main ( Test.hs, Test.o ) Test.hs:1:1: Typeable instances can only be derived; replace the following instance: instance (Typeable a, Typeable b, Typeable c, Typeable d, Typeable e, Typeable f, Typeable g, Typeable h) => Typeable (a, b, c, d, e, f, g, h) -- Defined at Test.hs:3:10 selinger at firefly-virtual:/tmp$ }}} By the way, this bug doesn't just apply in the case of built-in types such as 8-tuples. It would also apply to any type that is defined by a library, where the library author neglected to derive a Typeable instance. It seems impossible for user code to provide the requisite instances. -- Peter -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 15:40:20 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 15:40:20 -0000 Subject: [GHC] #9252: Generalize hs-boot files to be more like module signatures In-Reply-To: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> References: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> Message-ID: <060.a9b538208a1a92d458ff39c1831231e3@haskell.org> #9252: Generalize hs-boot files to be more like module signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: backpack Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D130 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: https://phabricator.haskell.org/D130 => Phab:D130 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 16:02:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 16:02:41 -0000 Subject: [GHC] #9687: Missing Typeable instances for built-in types In-Reply-To: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> References: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> Message-ID: <062.b681e2d768a8fc9ba8dbf6ff1f5d21ef@haskell.org> #9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by goldfire): `Typeable` instances must be for unapplied type constructors. This works: {{{ deriving instance Typeable (,,,,,,,) }}} But, I agree with the original post that GHC should export `Typeable` instances for ''all'' tuples. Otherwise, code like my line above risks having an instance collision. Incoherent instances avoids this problem, but that's an annoying burden if users have to worry about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 16:07:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 16:07:00 -0000 Subject: [GHC] #9687: Missing Typeable instances for built-in types In-Reply-To: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> References: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> Message-ID: <062.d45a1a8a8b953a2ea40ebc95a5571a5d@haskell.org> #9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): The error message is very confusing though. It would be good if someone felt like improving it. Yes I agree about instances. Should be a question of adding `DeriveAutoTypeable` (or whatever it's called) to the module that defines all the tuple types. Would someone like to do that? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 19:54:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 19:54:07 -0000 Subject: [GHC] #8819: 64bit Testsuite failures in unregisterised 7.8 RCs In-Reply-To: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> References: <047.078a5163c24ff483458aa1a9649d90bf@haskell.org> Message-ID: <062.9583fb2b5076147d87a3ea00d9d3f637@haskell.org> #8819: 64bit Testsuite failures in unregisterised 7.8 RCs -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: 8849, 8933 Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by slyfox): I might have accidentally skipped something or didn't bother fixing in UNREG (but I think I've fixed all perf-unrelated breakages at least in master). Real fixes: * 104a66a461f4f89b8e5ad9c829923bb7ca8ceddb - add missing 'deRefStablePtr' symbol for ghci * 43f1b2ecd1960fa7377cf55a2b97c66059a701ef - fix C codegen to emit negavite constants properly * a93ab43ab5f40cadbedea2f6342b93c245e91434 - fix -fPIC passing * e18525fae273f4c1ad8d6cbe1dea4fc074cac721 - fix prim calls at least on unreg ia64 Testsuite fixes (mostly disabled tests): * ff9f4ad38521e54c5284f9bf4599c3baaefeb228 - disable T7815 on NOSMP * fcdd58d2ddcfd8d420adbcb3f20c1d666bc834e6 - a workaround to disable warnings from gcc due to overrided functions * eb64be7b40b7f29144ebbf9c947e729535a8fd3d - disable memcpy asm code checking * 2fcb36e41f46f80f75e2f245a1a45457f0f7d6d2 - disable 'testwsdeque' on NOSMP * e1d77a1ae619efc4bfe7ce30d7c6b2031ed86f2f - add 32-bit case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 20:38:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 20:38:14 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.b05de407bc4a9f5205f28e4c4cc40f8d@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: Phab:D339 | -------------------------------------+------------------------------------- Changes (by gintas): * differential: => Phab:D339 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 20:38:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 20:38:37 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.adc429a48339b075938b4d731a7baa8e@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: Phab:D339 | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 20:43:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 20:43:46 -0000 Subject: [GHC] #1473: isSpace is too slow In-Reply-To: <044.3c2c0fec916372178c4bf5ce7945c8fa@haskell.org> References: <044.3c2c0fec916372178c4bf5ce7945c8fa@haskell.org> Message-ID: <059.d6a20dce6a0ce298678ead31b0ca4f68@haskell.org> #1473: isSpace is too slow -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 6.6.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * milestone: ? => 7.10.1 Comment: There are some very simple things to do about this, pending a full fix. In particular, as Carter noted, just making sure low codepoints never call out to C should help a lot. Using an unsigned comparison to check the contiguous range should be good too. I think we can probably improve things some more once we've figured out what to do about #9661. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 21:01:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 21:01:23 -0000 Subject: [GHC] #9689: const_str support needed for hsc2hs in cross-compilation mode Message-ID: <047.6b6fe4767ca0068aa88df83be71e3c46@haskell.org> #9689: const_str support needed for hsc2hs in cross-compilation mode -------------------------------------+------------------------------------- Reporter: aosivitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.3 Keywords: zlib ios cross- | Operating System: compilation | Unknown/Multiple Architecture: arm | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Building zlib-0.5.4.1 in cross-compilation mode using ghc-ios fails with the following message: Codec/Compression/Zlib/Stream.hsc:924 directive const_str cannot be handled in cross-compilation mode Is it possible to add support for const_str so that zlib can be built? I am not an experienced GHC developer, but I would be happy to help however I can if it is possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 21:18:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 21:18:06 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.eaa3385d7cdd870465aa4f9de4055e19@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D313 | -------------------------------------+------------------------------------- Comment (by ross): Changing to have Data.Functor.Class import Data.Functor.Identity reduces the ifdefs. Ideally I'd like to avoid a release with conditional exports - is there any way to detect a GHC bootstrap build? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 22:40:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 22:40:36 -0000 Subject: [GHC] #9690: in GHCi map `:editNNN` to $EDITOR +NNN Message-ID: <048.d638787284ec758722156a91451cb512@haskell.org> #9690: in GHCi map `:editNNN` to $EDITOR +NNN -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: feature request | Status: new Priority: normal | 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: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I suggest to treat GHCi REPL commands `:editNNN` (as well as equivalent abbreviations, like `:eNNN` ) where `NNN` is a natural number, as invocations of the text editor with a `+NNN` option. Rationale: When I see a type error in line 42 then I'd like to visit this line directly with `:e42`. Optionally one could implement `:eNNN:CCC` to also target the column `CCC` in that line. `emacs`, `vi` and `pico` all implement the option `+NNN` to land in the line `NNN`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 13 23:16:35 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Oct 2014 23:16:35 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.b88675220dda783d14464b214f84e27f@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:12 simonpj]: > So a chain of equality comparisons will turn into a table-driven jump in the end, which is a good thing. On the other hand, generating branch nests is a bad thing. You call this a "table-driven jump", and that may be the case for something like `0,1,2` (I don't know), but it certainly does ''not'' seem to work like that for, say, `32, 9, 10, 11, 12, 168`, or whatever the numbers are for "is a space". > So perhaps `litEq` should apply only ''when in the context of a `case` expression that immediately scrutinises its result''. So `litEq` would become > {{{ > case (a ==# k) of 1# -> e1; _ -> e2 > ---> > case a of { k -> e1; _ -> e2 } > }}} > Annoyingly, the `CoreSyn.RuleFun` API for built-in rules does not give access to the context of an application (the `SimplCont`), but it would not be hard to make it do so. > > So if that is the right rewrite, then it'd be another useful project for someone. I don't have a clear sense of what you're getting at, but in the situations I'm thinking about (avoiding poorly predicted branches), the compiler may not be able to know what is best, and Reid Barton's "secret" equality predicate may be the best approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 00:48:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 00:48:47 -0000 Subject: [GHC] #8683: add "cpp program" and "cpp program options" to settings file In-Reply-To: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> References: <045.f27c06fcd92f25d0b2de10602ab64893@haskell.org> Message-ID: <060.1c2b878d38aaced695c31b37173d3e47@haskell.org> #8683: add "cpp program" and "cpp program options" to settings file -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: feature | Status: closed request | Milestone: 7.8.3 Priority: high | Version: 7.8.1-rc2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8439 None/Unknown | Test Case: | Blocking: 9094 | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mietek): Does this mean it is now possible to bootstrap {{{cabal-install}}} without specifying {{{--no-doc}}}? (#9174) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 01:21:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 01:21:51 -0000 Subject: [GHC] #9687: Missing Typeable instances for built-in types In-Reply-To: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> References: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> Message-ID: <062.cdfc32ce10065f76bf1ce0bbeeead6b0@haskell.org> #9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by selinger): Great, I confirm that this works: {{{ {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE DeriveDataTypeable #-} import Data.Typeable deriving instance Typeable (,,,,,,,) }}} Solves my problem in the short term. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 01:31:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 01:31:16 -0000 Subject: [GHC] #1476: Template Haskell: splicing types and patterns In-Reply-To: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> References: <044.82d6405cd82a3ed24c1f19d7ab79c38b@haskell.org> Message-ID: <059.a42522fc6275ab7bafa1cecb27a0a37d@haskell.org> #1476: Template Haskell: splicing types and patterns -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Template | Version: 6.6.1 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by liyang): * cc: ghc.haskell.org@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 02:07:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 02:07:26 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.27202625c7d8bd3cc1ced319d7fbe9cf@haskell.org> #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 goldfire): Replying to [comment:82 jstolarek]: > Right. Still, I wondering how this works. I mean there are probably no special cases in the typechecker that try to guess whether a type family is an identity function? Of course, you're right -- GHC doesn't have a special case there. What it does do is so-called ''compatibility'' checking. Two equations of a type family (open or closed) are ''compatible'' if, whenever the LHSs unify with substitution ''s'', applying ''s'' to the RHSs makes them the same. Two equations for an open type family do not have a malignant overlap if they are compatible. And, more relevant here, GHC does the apartness check in closed type families only among incompatible equations. In `F` as originally given, all the equations are compatible with one another, and so GHC always skips the apartness check. Thus, when it sees `F a`, the last equation triggers and reduces `F a` to `a`. This is all described in the closed type families paper, and in the manual. > > We have to be careful with the word overlap here. I think we want "overlaps" to be "is subsumed by". > > I don't see the difference between "overlaps" and "is subsumed by". :-( I would say these equations overlap: > type instance G a Int = a > type instance G Int a = a but neither equation subsumes the other. On the other hand, > type instance H a a = a -- 1 > type instance H Int Int = Int -- 2 equation 1 subsumes equation 2, because anything that matches 2 will also surely match 1. > > Now, in 4c I wrote: > > > if unification [of the RHSs] succeeds and there are type variables involved we substitute unified type variables on the LHS and check whether this LHS overlaps with any of the previous equations. If it does we proceed to the next equation > > You replied with this: > > > you want to know of the equation at hand is reachable, given the LHS substitution. Even if it is reachable, the (substituted) LHS may coincide with the LHS of the earlier equation whose RHS unified with the current RHS. > > I don't see the difference between your version and mine. See new example `E1` on the wiki page. > > > Even subtler, it's possible that certain values for type variables are excluded if the current LHS is reachable (for example, some variable a couldn't be Int, because if a were Int, then a previous equation would have triggered). Perhaps these exclusions can also be taken into account. > > Hm... can you give an example where this would be useful? See new example `E2` on the wiki page. > > > '''RAE:''' But it seems that, under this treatment, any self-recursion would automatically lead to a conclusion of "not injective", just like any other use of a type family. For example: > > > > {{{#!hs > > type family IdNat n where > > IdNat Z = Z > > IdNat (S n) = S (IdNat n) > > }}} > > > > `IdNat` is injective. But, following the algorithm above, GHC would see the recursive use of `IdNat`, not know whether `IdNat` is injective, and then give up, concluding "not injective". Is there a case where the special treatment of self-recursion leads to a conclusion of "injective"? '''End RAE''' > > This example is just like my `NatToMaybe`. My idea here was that RHSs of these two equations won't unify - first returns `Z`, second returns `S something`. These are distinct constructors that have no chance of being unified. (I assumed that we are able to detect that.) There are no calls to type families other than self-recursion and so we can declare `IdNat` to be injective. I admit I am not 100% certain that allowing self- recursion is safe. It's just that I was unable to come up with an example that would show that my algorithm: a:) declares injective function to be non-injective; b) declares a non-injective function to be injective. > What are the steps your algorithm is taking? I don't see how `IdNat` can be considered injective while `Ban` is considered non-injective. A critical step in banning `Ban` is noting that we don't yet know that `Ban` is injective when checking it, so we conclude "not injective". Maybe it's because `Ban`'s recursion is at the top-level? In `IdNat` and `NatToMaybe`, unification fails before seeing the recursive use of the type family. Hmm... maybe. There seems to be something going on here that, if unification succeeds up until it sees the recursive use of the type family, then the family either must be non-injective or non-terminating... because this situation can only arise when the function "collapses" two inputs into the same output through recursion. But I'd want a proof first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 02:54:25 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 02:54:25 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.14f93fb607feef6dce8d5adea7cda648@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): The attached file still doesn't seem too minimal to me.... Do we really need all that `basicUnsafe...` stuff? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 03:20:12 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 03:20:12 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.95105e1ac5b16e02efa394c1179477cd@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Project (more Type of failure: | than a week) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: sweirich@? (added) * difficulty: Unknown => Project (more than a week) * milestone: 7.10.1 => 7.12.1 Comment: I hate to disappoint, but my thesis advisor, cc'd, has forbidden me from taking this on in the near future. To be fair, I didn't push back too strongly, because this is a non-trivial change: 1. It requires a new theory for Core to be worked out (and, ideally, proved type-safe). We need to update Core because rule (*) from comment:15 has to be baked in. 2. It requires a way to infer `Rep` instances. Are these created on-the- fly like `Coercible` ones? Are they generated automatically, but not on- the fly? Do they require the user to request them? 3. It requires a new solver for `Coercible` instances, preferably with some suggestion of completeness. Though I'm not convinced the community would want yet another paper on roles, fixing the deficiencies of the previous paper, I actually think that there's enough to be worked out here that such a paper would be possible to write. And, I'm a little bothered that, even after all of this work, we would still not have a comprehensive solution. I would expect that within the next few years, someone (quite possibly named Edward Kmett) would find a very-legitimate use case that this solution would not address. And then the whole rigamarole would have to be repeated. The real answer, I think, is role polymorphism, which would have the expressiveness of the POPL'11 paper but the flexibility of the current system. This would mean decorating each kind-level arrow with a role and allowing abstraction over those roles. But, these annotations could be drawn from an ordinary promoted datatype! Thus, we would have something like `(->) :: Role -> * -> * -> *`. (There is some similarity between this idea and NoSubKinds.) Inferring these annotations might be problematic, though. It is tantalizing to note that roles are somehow dual to injectivity. That is, if `F`'s argument has a representational role, then `x ? y` implies `F x ? F y` (writing `?` for {{{`Coercible`}}}). Rather similarly, if `F` is injective, then `F x ~ F y` implies `x ~ y`. We might even want to abstract over injectivity, noting that `map f` is injective precisely when `f` is injective. Injectivity abstraction is certainly far off (we don't yet have a useful `map` in types!), but my intuition is that the right solution to the problems described here would also allow injectivity abstraction... and that if it doesn't we might not have the right solution here. Getting much more concrete, I think a better way forward in the short term is to allow something like `deriving {-# UNSAFE #-} instance Monad m => Monad (N m)`, allowing GND to use `unsafeCoerce` instead of `coerce`. This could, instead, be done using Template Haskell without too much bother. We could even go ahead and add `join` to `Monad`. Most GNDs with the enhanced `Monad` would still work, and if they don't, we can make sure that the error message gives useful advice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 04:20:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 04:20:41 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.959e173fac6456b4932e00ccfbb7a16b@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by lukexi): I sent a mail out to the list a bit ago but should have added a comment here: I've completed the work to add the GHC ARM64 calling convention to LLVM [1], and finished up the support in GHC itself [2]. I'm in the process of tidying up the patches for submission. I'm going to try to backport them to 7.8 as well. [1] https://github.com/lukexi/llvm [2] https://github.com/lukexi/ghc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 07:42:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 07:42:42 -0000 Subject: [GHC] #9687: Missing Typeable instances for built-in types In-Reply-To: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> References: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> Message-ID: <062.a7324d0902cccd29087694c3234fb140@haskell.org> #9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by dreixel): Replying to [comment:4 simonpj]: > Yes I agree about instances. Should be a question of adding `DeriveAutoTypeable` (or whatever it's called) to the module that defines all the tuple types. Would someone like to do that? `AutoDeriveTypeable`. But, if I recall correctly, we've decided against that in the past because: 1) It increased the object file size and/or compilation time significantly (though maybe we were also deriving `Data` and `Generic`); 2) Very few people would make use of it; 3) They could always use `StandaloneDeriving`. But perhaps it's time to revisit that decision. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 07:50:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 07:50:00 -0000 Subject: [GHC] #9690: in GHCi map `:editNNN` to $EDITOR +NNN In-Reply-To: <048.d638787284ec758722156a91451cb512@haskell.org> References: <048.d638787284ec758722156a91451cb512@haskell.org> Message-ID: <063.e8d984cb0e3165a5066bb17919a6b497@haskell.org> #9690: in GHCi map `:editNNN` to $EDITOR +NNN -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): I'd rather suggest the following more generic syntax {{{ :edit [+NNN] [] }}} where `NNN` wouldn't need to be necessarily a natural number, and would be passed as-is to the editor command -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 08:01:58 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 08:01:58 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.af450ceec750cb3c943e33293cec6f35@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Well, when a table-driven jump doesn't work GHC generates a binary tree, reverting a table-driven jump whenever it finds a sufficiently dense patch. (I'm not sure this is fully done, but that's the intention.) Even if there are no dense patches, log(N) is better than N. For the second point, I'm suggesting that the `litEq` rule should apply only when the result of the comparison is immediately scrutinised by a `case`. I don't really understand Reid's proposal but it looks dangerously fragile to me. Apart from anything else it sounds as if the programmer has to think about two different equality operations; and that which to use depends on context. But the context can change radically after inlining. It smells bad to me, but I'm open to persuasion. Meanwhile I think changing `litEq` as I suggest would do a nice job. I could be wrong about that too, but it's my working hypothesis. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 09:01:23 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 09:01:23 -0000 Subject: [GHC] #9687: Missing Typeable instances for built-in types In-Reply-To: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> References: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> Message-ID: <062.fc5920d07e9ad95ea6ba3afa7ed0d08f@haskell.org> #9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): A `Typeable` instance for, say, `(,,,,,)` should not increase object file size much, should it? Are you perhaps thinking of `Data` or something like that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 10:05:18 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 10:05:18 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.b3b6ba8cd3fa9ac9a2b3de3f5f1b102f@haskell.org> #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): Richard, either I'm not getting the subtleties of your arguments or you're misunderstanding what I meant to say on the wiki page. Or both :-) I now see the theoretical difference between "overlaps" and "subsumes" but I don't yet see how that is important in my algorithm outline. I re-read parts of the closed type families paper and now I'm not even sure whether I meant "overlaps" or "unifies". Anyway, I believe that my thinking is correct and in my algorithm I have addressed problems that you raised. It looks that I need help with sorting out the terminology so things are clear. Now, looking at your examples: {{{#!hs type family E1 a = r | r -> a where E1 Int = Int -- 1 E1 a = a -- 2 }}} When my algorithm reaches (2) it will attempt to unify `a` with RHS of equation (1). It will succeed with substitution `[ a -> Int ]`. It will apply that substitution to the LHS of (2) and proceed with checking whether after substitution this equation is subsumed (?) by any of the earlier ones. Clearly, it is by the first equation and since this is the last equation we declare `E1` to be injective. In other words I know that (2) will never produce an `Int` since this will equation will never be reached for `a` equal to `Int`. Now `E2`: {{{#!hs type family E2 (a:: Bool) = r | r -> a where E2 False = True E2 True = False E2 a = False }}} I consider almost identical example on the wiki: {{{#!hs type family Bak a = r | r -> a where Bak Int = Char Bak Char = Int Bak a = a }}} The difference is the RHS of the last equation: a concrete type in your example, a type variable in mine. Yet I believe that both examples are intended to demonstrate the same problem - see discussion below that example. > In `IdNat` and `NatToMaybe`, unification fails before seeing the recursive use of the type family. Right. I assumed that noticing that allows us to conlcude that equations of `IdNat` and `NatToMaybe` produce distinct types and thus these type families are injective. Your reasoning in that whole paragraph completely agrees with mine. > But I'd want a proof first. Agreed. As I said, I've been unable to produce a counter-example but that doesn't meant that one does not exist. I have a question about closed type families paper. Paragraph just after Candidate Rule 2 (section 3.2, page 3) says: "As a notational convention, apart(?, ?) considers the lists ? and ? as tuples of types; the apartness check does ''not'' go element-by-element.", where "not" is emphasized. Why is this important? Seems like the choice of representing patterns and types as tuples or lists is just an implementation detail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 10:47:30 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 10:47:30 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.5cdc917e697f601be55a0ecd9aa1a116@haskell.org> #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: | -------------------------------------+------------------------------------- Comment (by hvr): @dreixel, is your code ready for code revision via as a Phab:differential ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 11:01:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 11:01:22 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.6794b37de1dc2e378511716bc0e51bbc@haskell.org> #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: | -------------------------------------+------------------------------------- Comment (by dreixel): No, not yet, I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 12:30:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 12:30:42 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.8136f6d731419f67dd92de1bb98afc62@haskell.org> #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 goldfire): Replying to [comment:84 jstolarek]: > Richard, either I'm not getting the subtleties of your arguments or you're misunderstanding what I meant to say on the wiki page. Or both :-) > > I now see the theoretical difference between "overlaps" and "subsumes" but I don't yet see how that is important in my algorithm outline. I re- read parts of the closed type families paper and now I'm not even sure whether I meant "overlaps" or "unifies". To be clear, I am considering the expressions "two types overlap" and "two types unify" to be synonymous. Subsumption is a finer, directed relation between types than overlap/unify. > {{{#!hs > type family E1 a = r | r -> a where ... > }}} Yes yes yes. You're right here. I was wrong. The wiki page is updated. > > Now `E2`: > > {{{#!hs > type family E2 (a:: Bool) = r | r -> a where > E2 False = True > E2 True = False > E2 a = False > }}} > I consider almost identical example on the wiki: > {{{#!hs > type family Bak a = r | r -> a where > Bak Int = Char > Bak Char = Int > Bak a = a > }}} > The difference is the RHS of the last equation: a concrete type in your example, a type variable in mine. Yet I believe that both examples are intended to demonstrate the same problem - see discussion below that example. I think these cases are different. In yours, the RHS unification (`a` unifies with `Char`) refines the LHS (`a |-> Char`) so that it is subsumed by an earlier equation. This action does not happen in my example, and different reasoning (noting that `False` and `True` are both impossible) is required. > I have a question about closed type families paper. Paragraph just after Candidate Rule 2 (section 3.2, page 3) says: "As a notational convention, apart(?, ?) considers the lists ? and ? as tuples of types; the apartness check does ''not'' go element-by-element.", where "not" is emphasized. Why is this important? Seems like the choice of representing patterns and types as tuples or lists is just an implementation detail. Agreed that choosing a list vs. a tuple is irrelevant, but choosing element-by-element vs. as-a-whole is quite important. For example `(a, a)` is quite apart from `(Int, Bool)`, when considered as a whole, even though `a` is neither apart from `Int` nor `Bool` looking at individual elements. Does that clarify? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 12:39:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 12:39:24 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.415b68d54a9ab7a71ec17134ec0f6a33@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by goldfire): There may be a very easy solution to this problem. At the end of every closed type family, we could just automatically add an equation {{{Foo x y z = Error "Pattern match failure in closed type family `Foo'"}}}, where `Error` is the type-level error function from #9637. I think that would work quite well here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 12:42:13 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 12:42:13 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.2c8f75435eae19f63d6d41930a16d592@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D313 | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:5 ross]: > Changing to have Data.Functor.Class import Data.Functor.Identity reduces the ifdefs. Sure, I can easily change that (at the cost of some minor code duplication) > Ideally I'd like to avoid a release with conditional exports - is there any way to detect a GHC bootstrap build? As for this I'm not sure how that helps here. Assuming we have a way of setting a Cabal flag when we're bootstrapping GHC (i.e. building stage 1), how would this improve the situation of having the `Data.Functor.Identity` module conditionally exposed (which now would be depending on that Cabal flag setting rather than predicating on `impl(ghc>=7.9)`)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 13:59:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 13:59:35 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.a3eb9b06b646b588a9670b0a157be875@haskell.org> #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): > Does that clarify? Yes. I don't yet see how to deal with your `E2` example. It looks like we would need to have pattern-exhaustiveness checking for type families. And this would only be possible for closed kinds I think. Well, for open kinds type family would simply be non-injective. I have a few more questions about implementation. These most likely go to Simon. I've been trying to wrap my head around implementation of `doTopReactFunEq` and I have these questions: 1. What does the term "react" mean? As in the name `doTopReact` and the comment below its type signature: "The work item does not react with the inert set..." (TcInteract, L1412). 2. What is "interaction"? As in the module name `TcInteract` or the comment mentioned above: "... so try interaction with top-level instances". 3. What does `EvTerm` data type represent? 4. What are branches in axioms? 5. I don't understand how canonicalization works. Is there an overview somewhere? Other than `Note [Canonicalization]`, which unfortunately is too vague for me :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 14:17:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 14:17:54 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.233d53ae594a70cf455987edc7d358fd@haskell.org> #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 goldfire): Replying to [comment:86 jstolarek]: > I don't yet see how to deal with your `E2` example. It looks like we would need to have pattern-exhaustiveness checking for type families. And this would only be possible for closed kinds I think. Well, for open kinds type family would simply be non-injective. I don't know how to do this either. Luckily, we can reject `E2` on a first pass. It's possible that the only examples like this are silly in the same way that `E2` is silly, in that the last equation is utterly unreachable. > > I have a few more questions about implementation. These most likely go to Simon. I've been trying to wrap my head around implementation of `doTopReactFunEq` and I have these questions: > > 1. What does the term "react" mean? As in the name `doTopReact` and the comment below its type signature: "The work item does not react with the inert set..." (TcInteract, L1412). > > 2. What is "interaction"? As in the module name `TcInteract` or the comment mentioned above: "... so try interaction with top-level instances". Simon may be able to answer better than I, but I believe these refer to the actions taken in section 7 of the !OutsideIn paper. > > 3. What does `EvTerm` data type represent? These are values of constraint types, including class dictionaries, type equalities, and implicit parameters. `EvTerm`s are desugared in !DsBinds. Write back if that's not enough of an explanation. > > 4. What are branches in axioms? A closed type family with multiple equations leads to a so-called branched axiom. The way overlap works in a closed type family means that we can't have separate axioms for each equation. So, a branched axiom contains potentially many branches; each branch asserts an equality, but later branches can be used only when no previous branch supersedes. Does that help? It's all in the closed type families paper. > > 5. I don't understand how canonicalization works. Is there an overview somewhere? Other than `Note [Canonicalization]`, which unfortunately is too vague for me :-( I think this is also in !OutsideIn. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 14:39:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 14:39:43 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.b7173f26a462c1f12a5b1b6f1045e8b5@haskell.org> #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 don't know how to do this either. Luckily, we can reject E2 on a first pass. Yes, I believe that's what we should do. If we ever have analysis of unreachable equations for type families then we can use it to deal with `E2` but until then we should simply reject it. As for answers to 1-5 I'll read some more and get back if that doesn't help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 16:15:34 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 16:15:34 -0000 Subject: [GHC] #9689: const_str support needed for hsc2hs in cross-compilation mode In-Reply-To: <047.6b6fe4767ca0068aa88df83be71e3c46@haskell.org> References: <047.6b6fe4767ca0068aa88df83be71e3c46@haskell.org> Message-ID: <062.9ea9c353748adfe08dcf23c87eb7065c@haskell.org> #9689: const_str support needed for hsc2hs in cross-compilation mode -------------------------------------+------------------------------------- Reporter: aosivitz | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: hsc2hs | Keywords: zlib ios cross- Resolution: | compilation Operating System: | Architecture: arm Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by aosivitz): Digging a little deeper... The reason why const_str is not currently supported is that strings cannot be calculated for a cross-compiled target platform the same way numbers can. Booleans can be calculated by attempting to compile a specific program that uses the boolean value in a static array size. The compiler must calculate the array size to determine if it is non-negative. (A negative array size is a compiler error.) This trick can be extended to numbers repeatedly using them to form boolean expressions and performing a binary search. A const_str is something like #define VERSION "1.2.3" Since a string is just an array of chars, shouldn't we be able to calculate it at compile time as well? We can get the length of a string by testing for -Warray-bounds and -Werror. And then calculate the value of the array at each index. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 16:56:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 16:56:40 -0000 Subject: [GHC] #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc (was: Rebindable list syntax?) In-Reply-To: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> References: <042.94f63ae1f0ea5e1c87f7145cb04cda4b@haskell.org> Message-ID: <057.fca3bda7dae752ea4b8ad65fd345bc19@haskell.org> #7495: generalizing overloaded list syntax to Sized Lists, HLists, HRecords, etc -------------------------------------+------------------------------------- Reporter: nwf | Owner: carter Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * owner: => carter Comment: I've been working on designing a set of classes that subsumes this proposal. the work in progress in the class design can be found https://github.com/cartazio/HetList/blob/master/HetList.hs It doesn't yet have the analogues machinery to support the older `fromList` style instances, but thats easy to add. As part of the dev I'm making sure I can write useful instances for the fancy HList libs that are in the while, like `HList` and `Vinyl` after another week or two of polish, I hope to have a candidate patch with the right desugaring (plus some extra work to support current style instances if possible) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 21:50:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 21:50:51 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.a1b969be0a7bca1ff542df3abca35c06@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): i can replace most of that with stubs that are defined with`= error "not defined"` if you wanted, might take a bit longer for me to boil down the rest into a more minimal repro, but i'll try to find the time to think about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 21:51:40 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 21:51:40 -0000 Subject: [GHC] #9689: const_str support needed for hsc2hs in cross-compilation mode In-Reply-To: <047.6b6fe4767ca0068aa88df83be71e3c46@haskell.org> References: <047.6b6fe4767ca0068aa88df83be71e3c46@haskell.org> Message-ID: <062.d2a0f9227b5b3bd78559c72ec281b128@haskell.org> #9689: const_str support needed for hsc2hs in cross-compilation mode -------------------------------------+------------------------------------- Reporter: aosivitz | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: hsc2hs | Keywords: zlib ios cross- Resolution: | compilation Operating System: | Architecture: arm Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): You can also get the length of a string with `sizeof`, but I don't think it's possible to extract the characters, at least not as far as anybody knows. The obvious attempts like `/* const char s[]; */ int x[s[0]];` don't work because `s[0]` is not considered a constant expression. IIRC I looked and didn't find a way to detect string constants when cross- compiling with autoconf either. For zlib in particular, I have a patch that avoids the need for string constants: http://lpaste.net/8287391336118616064 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 22:00:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 22:00:03 -0000 Subject: [GHC] #9691: GHC-HEAD runtime is broken on arm Message-ID: <047.9fcb5b64ebe9f7a33ad168c55acc7b20@haskell.org> #9691: GHC-HEAD runtime is broken on arm ----------------------------+---------------------------------------- Reporter: mkbrandt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------+---------------------------------------- I incorporated the patch from #9593 and built GHC HEAD as a cross compiler for arm-unknown-linux-gnueabi. mbrandt at ubuntu:~/ghc-head$ arm-unknown-linux-gnueabi-ghc --version The Glorious Glasgow Haskell Compilation System, version 7.9.20141014 The resulting compiler will compile programs and link them resulting in what appears to be a valid executable (testme.hs is a simple hello world app): mbrandt at ubuntu:~/ghc-head$ file testme testme: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=11ca9da291edb0428c977e506ac1a8f1e398aa57, not stripped When run on the target (an i.MX280 - ARM9EJ-S) the runtime gets hung up before main is evaluated. The program is using 90+% cpu. This behavior is consistent for both HEAD and ghc-7.8.3 with both registerized and unregisterized builds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 22:23:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 22:23:31 -0000 Subject: [GHC] #9689: const_str support needed for hsc2hs in cross-compilation mode In-Reply-To: <047.6b6fe4767ca0068aa88df83be71e3c46@haskell.org> References: <047.6b6fe4767ca0068aa88df83be71e3c46@haskell.org> Message-ID: <062.42957aef5e7be5422bfec9ec4e3902d3@haskell.org> #9689: const_str support needed for hsc2hs in cross-compilation mode -------------------------------------+------------------------------------- Reporter: aosivitz | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: hsc2hs | Keywords: zlib ios cross- Resolution: wontfix | compilation Operating System: | Architecture: arm Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by aosivitz): * status: new => closed * resolution: => wontfix Comment: Yea, I ran into that as well. zlib is the only problem package I've personally encountered, so that patch is great for me. Thanks! I'll close this, and pass on the patch to the zlib maintainer, unless you've already done so. Thanks again! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 14 22:30:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Oct 2014 22:30:16 -0000 Subject: [GHC] #9684: Broken build on OS X (incompatible pthread_setname_np API) In-Reply-To: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> References: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> Message-ID: <058.66cfc4bbc38f412364e40ace7b5506ae@haskell.org> #9684: Broken build on OS X (incompatible pthread_setname_np API) -------------------------------------+------------------------------------- Reporter: mlen | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | pthread_setname_np Type of failure: Building | Architecture: Unknown/Multiple GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | Phab:rGHC674c631ea111233daa929ef63500d75ba0db8858,| Phab:D338 | -------------------------------------+------------------------------------- Comment (by rodlogic): It seems that 4b69d96b3d2758bbc06c58ea44a975c6e08d7400 by Simon Marlow has fixed this issue on OSX, at least. I haven't tried the above change sets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 03:52:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 03:52:35 -0000 Subject: [GHC] #9692: Template Haskell reification for Data Families is buggy? Message-ID: <047.c908a871df417674fd29671ed5adc70e@haskell.org> #9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: TemplateHaskell | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I have found an example where I think that the TH reification for data/newtype families is incorrect, in that if forgets non-instantiated type variables in instance declarations. For the attached example, it will infer the Info: {{{#!hs FamilyI (FamilyD DataFam TyFamReifyDefs.F [PlainTV a_1627399879,PlainTV b_1627399880] (Just StarT)) [DataInstD [] TyFamReifyDefs.F [ConT GHC.Types.Int] [NormalC TyFamReifyDefs.FInt [(NotStrict,VarT x_1627399881)]] []] }}} Note how the variable x is not declared in the body of the DataInstD. Since it does not need to have the same name as the family-declared variable, substituing is non-trivial this way... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 03:55:05 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 03:55:05 -0000 Subject: [GHC] #9692: Template Haskell reification for Data Families is buggy? In-Reply-To: <047.c908a871df417674fd29671ed5adc70e@haskell.org> References: <047.c908a871df417674fd29671ed5adc70e@haskell.org> Message-ID: <062.1958df96cb76c2bc7f9c1a3fd5b7abf6@haskell.org> #9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: TemplateHaskell Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by hpacheco: Old description: > I have found an example where I think that the TH reification for > data/newtype families is incorrect, in that if forgets non-instantiated > type variables in instance declarations. > > For the attached example, it will infer the Info: > > {{{#!hs > FamilyI (FamilyD DataFam TyFamReifyDefs.F [PlainTV a_1627399879,PlainTV > b_1627399880] (Just StarT)) [DataInstD [] TyFamReifyDefs.F [ConT > GHC.Types.Int] [NormalC TyFamReifyDefs.FInt [(NotStrict,VarT > x_1627399881)]] []] > }}} > > Note how the variable x is not declared in the body of the DataInstD. > Since it does not need to have the same name as the family-declared > variable, substituing is non-trivial this way... New description: I have found an example where I think that the TH reification for data/newtype families is incorrect, in that if forgets non-bound type variables in instance declarations. For the attached example, it will infer the Info: {{{#!hs FamilyI (FamilyD DataFam TyFamReifyDefs.F [PlainTV a_1627399879,PlainTV b_1627399880] (Just StarT)) [DataInstD [] TyFamReifyDefs.F [ConT GHC.Types.Int] [NormalC TyFamReifyDefs.FInt [(NotStrict,VarT x_1627399881)]] []] }}} Note how the variable x is not declared in the body of the DataInstD. Since it does not need to have the same name as the family-declared variable, substituting is non-trivial this way... -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 03:56:14 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 03:56:14 -0000 Subject: [GHC] #9692: Template Haskell reification for Data Families is buggy? In-Reply-To: <047.c908a871df417674fd29671ed5adc70e@haskell.org> References: <047.c908a871df417674fd29671ed5adc70e@haskell.org> Message-ID: <062.0655a49ae33cfce7f72d9dd79f363c39@haskell.org> #9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: TemplateHaskell Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hpacheco): * difficulty: Unknown => Easy (less than 1 hour) * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 04:00:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 04:00:16 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.106c5b8d9a364ffdea9ef9006bb92efa@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:14 simonpj]: > Well, when a table-driven jump doesn't work GHC generates a binary tree, reverting a table-driven jump whenever it finds a sufficiently dense patch. (I'm not sure this is fully done, but that's the intention.) Even if there are no dense patches, log(N) is better than N. For sufficiently small N, it is likely better to do a linear search to avoid branch mispredictions (possibly even a branchless search using conditional moves or bit hacks). But it almost certainly depends to a certain extent on details of what is and what is not likely, which may be better known to the programmer than to the compiler. For example: suppose I we have {{{#!hs weird x = case x of 1732 -> 12 37893 -> 4 98231 -> 5 47835 -> 3 98002 -> 17 324 -> 56 _ -> x * 74 }}} If we're applying this to a uniform random distribution of numbers from `1` to `100000`, binary search will give us a tremendously high rate of mispredicted branches, if I understand things correctly (never a certain thing). Looping through all the possibilities will work better. Of course, the compiler does not know anything about the distribution! I'm not saying I know "the right answer" (certainly I don't); I just think this could use a bit more thinking, and I like the idea of giving the programmer more tools to express intention in this realm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 08:00:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 08:00:59 -0000 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> References: <045.426dc6319f98492c5b511466045bc0b5@haskell.org> Message-ID: <060.baac62c9d7a4425750a93e1b890d3886@haskell.org> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------------+--------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: #7097 Differential Revisions: | ---------------------------------------+--------------------------- Comment (by dreixel): I hit this problem too with `criterion` on Windows. `criterion` depends on `hastache`, which depends on `ieee754` without any version bounds. `ieee754-0.7.4` is good, `ieee754-0.7.3` isn't. So I fixed it with the following sequence of commands: {{{ ghc-pkg unregister criterion-1.0.1.0 ghc-pkg unregister hastache-0.6.0 ghc-pkg unregister ieee754-0.7.3 cabal install criterion --constraint="ieee754-0.7.4" }}} Hopefully others can do something similar to this. Also, package authors should update their packages to require `ieee754 >= 0.7.4`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 08:34:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 08:34:27 -0000 Subject: [GHC] #7828: RebindableSyntax and Arrow In-Reply-To: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> References: <058.5acc7f2fae3e2ef4fabd1ed0c67f0c5a@haskell.org> Message-ID: <073.e3a8e130f398624fea42cf262f9cb2ab@haskell.org> #7828: RebindableSyntax and Arrow -------------------------------------+------------------------------------- Reporter: | Owner: AlessandroVermeulen | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.2 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #1537, #3613 Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: Phab:D72 | -------------------------------------+------------------------------------- Comment (by simonpj): See also [http://www.haskell.org/pipermail/glasgow-haskell- users/2014-October/025298.html this ghc-users thread]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 09:01:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 09:01:30 -0000 Subject: [GHC] #8713: Avoid libraries if unneeded (librt, libdl, libpthread) In-Reply-To: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> References: <045.e65f03bd077c86ec4c44c9abb727b716@haskell.org> Message-ID: <060.44c11384cf32701d659965e2cbe721a5@haskell.org> #8713: Avoid libraries if unneeded (librt, libdl, libpthread) -------------------------------------+------------------------------------- Reporter: ip1981 | Owner: Type: bug | Status: upstream Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Other | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Moderate (less Test Case: | than a day) Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- Comment (by kgardas): Hi Igor, thanks for the patch. I'm looking into it and I'm curious if it may be solved by other way. Please what's OS is exactly detected by {{{ $ sh config.guess }}} I'm curious since if it is Solaris than this should be improved to handle Dyson specifically since I think Solaris kernel + GNU libc is not Solaris anymore. And if it is not Solaris than at least patch to DriverPipeline.hs may be done in a little bit more clean way. I don't like using this #ifdef in parameters list construction. If you add proper support for OSDyson, then you can add OSDyson *BSDs, Darwin etc. and be done with this bit in more clean way IMHO. But well, the crucial question is how the OS is identified by config.guess...BTW: generally speaking I hope I'm right here but GHC devs tries to get rid of platform configuration related #ifdefs in the code and use proper Haskell handling of this. In your patch you reverts this goal and this is not good IMHO. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 11:27:35 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 11:27:35 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.a48e1bd8393e800a8342b2764fdc032e@haskell.org> #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've read section 7.4 of OutsideIn(X) paper. Code makes more sense now but still I have some questions. Most importantly I'm trying to understand FINST top-level reaction rule (OutsideIn paper, fig. 24 page 65), which according to my understanding is implemented by `doTopReactFunEq`. Since I don't have LaTeX in the wiki I'll be using following notation: \Q - set of top-level axiom schemes \g - little gamma \d - little delta \th - little theta \t - little tau \e - little epsilon _0 - 0 in a subscript \vec{...} - a vector of values, in paper denoted using overline \in - set membership realtion Now the rule: {{{ forall \vec{a}. F \vec{Xi_0} ~ Xi_0 \in \Q -- (1) \vec{b} = ftv(\vec{Xi_0}) -- (2) \vec{c} = \vec{a} - \vec{b} -- (3) \g fresh -- (4) \th = [\vec{b |-> \t_a},\vec{c |-> \g}] -- (5) \th \vec{Xi_0} = \vec{Xi} -- (6) if (l = w) then \vec{\d} = \vec{\g} else \vec{\d} = \e -- (7) ------------------------------------------------------------- topreact[l](\Q, F \vec{Xi}~Xi) = {\d, \th Xi_0 ~ Xi} -- (8) }}} Here's how I understand (or misunderstand that rule): Premise (1) represents a type family equation written by the user (either from a closed or open type family). `\vec{Xi_0}` represents the LHS of `F` ie. patterns in that equation. So for example if the equation is `F [b] Bool c` then `\vec{Xi_0}` is `([b],Bool, c)`. I'm not sure about `[b]` - I think that's not canonical? Are axioms canonicalized? I'm also not sure about the meaning of `\vec{a}` in (1)'s forall. My intuition would be that these are type variables in the LHS (`b` and `c` in above example). But then I don't know how to understand premise (2). If `\vec{b}` represents free variables if `\vec{Xi_0}` then wouldn't this be identical to `\vec{a}`? This does not make sense because in that situation `\vec{c}` in premise (3) would always be empty. Premise (5) is a substitution used in premise (6) to turn the LHS of the original axiom into LHS of a constraint we are trying to solve. But what does `\t_a` represent? Instantiation of variables in the original axiom to some particular values present in `\vec{Xi}`? Premise (7) says that if a constraint is wanted then we introduce new variables. I'm not sure why. Maybe this will become clear once I understand the rest. I'm not sure if I understand the conclusion (8). Reading the rule I see that if we have `F \vec{Xi} ~ Xi` constraint we use it to figure out the `\th` substitution and then use that substitution to create a new constraint that tries to equate the RHS of our current constraint with the RHS of original axiom. But why do we want this? I could use an example with more comments than in the paper (and the example could be more complicated too). Before proceeding with the implementation I'd like to understand how injectivity affects FINST rule. What is not clear to me is whether the new constraint we are producing is wanted or given? My guess is that we produce a given if the original constraint was given and wanted if the original was wanted. I also wonder whether injectivity gives us a new interaction rule: {{{ INJFEQFEQ interact[l] (F \vec{Xi_1} ~ Xi, F \vec{Xi_2} ~ Xi) = (F \vec{Xi_1} ~ Xi, \vec{ Xi_1 ~ Xi_2 }) }}} where `\vec{ Xi_1 ~ Xi_2 }` represents vector of pairwise constraints. A few more questions unrelated to the paper: 1. Are axioms for associated types treated differently than for open type families? 2. What does `BuiltInSynFamTyCon` constructor represent? 3. `Note [Basic Simplifier Plan]` in `TcInteract` mentions "inert reactions" and "spontaneous reactions". What's the difference between the two? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 11:36:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 11:36:03 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC Message-ID: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | 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: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- First, load the following program into GHCi. '''Fun.hs''' {{{#!hs module Fun where import Language.Haskell.TH stuff = do -- let x = mkName "X" x <- newName "X" sequence $ [dataD (return []) x [] [ normalC x [] ] []] }}} '''thbug.hs''' {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Fun stuff }}} Then comment out the newName, un comment the mkName and reload GHCi. {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): kcLookupKind APromotionErr RecDataConPE Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It is important to note this is a valid program, if you then close GHCi and start it again with the modified file, it will load correctly. Reloading after attempting to compile the newName version will cause a panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 13:35:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 13:35:07 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.85fc3c6df96bc382ac347f984640ec59@haskell.org> #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): Simon, I'm trying to understand your [comment:76 earlier comment]: > * We are not (at least for now) changing System FC. So the only effect of injectivity is to add extra "Derived" unification constraints, very much like functional dependencies. If we see > {{{ > [W] F t ~ F s > }}} > then we don't decopose it. Instead we add > {{{ > [D] t ~ s > }}} > That guides inference, but does not produce proof terms. So, no, nothing to do with `isDecomposableTyCon`. Much more like the `try_improvement` code in `TcInteract.doTopReactFunEq`. First of all, do we ever get a chance of actually seeing `F t ~ F s`? I think this is not canonical and if such constraint ever appears it would be turned into `F t ~ a, F s ~ a`. I'm not sure which of the canonicalization rules in Fig. 21 in OutsideIn paper would be responsible for that conversion because I don't know the meaning of these stylized D, F and T used in the mentioned figure. My guess would be FFLAT[W/G]R rules. Anyway, once we have `F t ~ a, F s ~ a` we could apply my suggested INJFEQFEQ interaction rule to generate `[D] s ~ t`. If my thinking here is right then shouldn't the implementation go into `TcInteract.interactFunEq` (guessing from its name)? I also wonder whether `[W]` is important in your `[W] F t ~ F s` example? I believe this rule is valid for both given and wanted constraints. I don't understand what you mean by "we don't decopose it". What is this "decomposition" that you mention? I believe that the only moment when injectivity interacts with top-level axioms is when we're deducing LHS from RHS. I suspect this might require a new reaction rule, separate from FINST. Are my ideas here correct? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 15:00:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 15:00:23 -0000 Subject: [GHC] #9684: Broken build on OS X (incompatible pthread_setname_np API) In-Reply-To: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> References: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> Message-ID: <058.9605cdc92ec3de1b31aebc120785a30c@haskell.org> #9684: Broken build on OS X (incompatible pthread_setname_np API) -------------------------------------+------------------------------------- Reporter: mlen | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: MacOS X | pthread_setname_np Type of failure: Building | Architecture: Unknown/Multiple GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | Phab:rGHC674c631ea111233daa929ef63500d75ba0db8858,| Phab:D338 | -------------------------------------+------------------------------------- Comment (by mlen): While it builds, it doesn't validate on OSX. {{{ rts/posix/OSThreads.c:132:40: error: unused parameter 'name' [-Werror,-Wunused-parameter] createOSThread (OSThreadId* pId, char *name, ^ 1 error generated. make[1]: *** [rts/dist/build/posix/OSThreads.thr_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 CPUS=6 ./validate 1838.92s user 246.55s system 249% cpu 13:54.58 total }}} That can be solved by adding an `#else` branch with `(void)name;` to shut down the warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 17:06:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 17:06:56 -0000 Subject: [GHC] #9689: const_str support needed for hsc2hs in cross-compilation mode In-Reply-To: <047.6b6fe4767ca0068aa88df83be71e3c46@haskell.org> References: <047.6b6fe4767ca0068aa88df83be71e3c46@haskell.org> Message-ID: <062.08eff04005dc903d94ed38de2a887246@haskell.org> #9689: const_str support needed for hsc2hs in cross-compilation mode -------------------------------------+------------------------------------- Reporter: aosivitz | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: hsc2hs | Keywords: zlib ios cross- Resolution: wontfix | compilation Operating System: | Architecture: arm Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I've sent Duncan the patch, but if you have a chance to test it in earnest, that would be great (I've only tested that it builds under various configurations). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 19:20:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 19:20:44 -0000 Subject: [GHC] #9694: Template Haskell: support other FFI calling conventions Message-ID: <045.6b172d0b0b38c5a76b456a5bc0cd0802@haskell.org> #9694: Template Haskell: support other FFI calling conventions -------------------------------------+------------------------------------- Reporter: mtolly | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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: -------------------------------------+------------------------------------- In the Template Haskell syntax representations, an [https://hackage.haskell.org/package/template-haskell-2.9.0.0/docs /Language-Haskell-TH-Syntax.html#t:Callconv FFI calling convention] can currently only be CCall or StdCall. I'd like to generate code with [http://weblog.luite.com/wordpress/?p=14 GHCJS JavaScript imports], which use a "javascript" calling convention. The [http://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1550008.4.1 FFI section of the Report] mentions other potential conventions, and specifically says that implementations can create new ones as appropriate, so perhaps a new constructor could be added which takes an arbitrary string? Something like: {{{ data Callconv = CCall | StdCall | Callconv String deriving( Show, Eq, Data, Typeable ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 15 21:32:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Oct 2014 21:32:31 -0000 Subject: [GHC] #9688: Improve the interaction between CSE and the join point transformation In-Reply-To: <045.ad5940048773c77749dabb4d904f5fb8@haskell.org> References: <045.ad5940048773c77749dabb4d904f5fb8@haskell.org> Message-ID: <060.f56e9c47614d26e8e3529eeb71249aae@haskell.org> #9688: Improve the interaction between CSE and the join point transformation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: CSE Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 simonpj]: > Or, to put it another way, if the user wrote the above `Core`, complete with the local function `$j_s2BC`, would you expect it to be optimised? Probably so, but I don't really know. I think the basic concept is that we should let more information flow from the analysis of the main body into the analysis of `j`. I think these two steps would probably be a good start, although I imagine they could be refined. Of course, you may well know of seven fatal flaws in this approach. 1. The simple one: If the value of a certain expression is always available when calling `j`, check if that expression is used in `j`; if so, pass it in. This is really just CSE, broadened to cross the boundary between the local function and the main body. 2. The less simple one: If the scrutinee of a `case` in `j` has always been scrutinized before `j` is called, "trim" the branches to only the ones that are still possible, and then consider splitting `j` into its remaining branches. In the examples described above, one relevant `case` will be the outermost one in `j`, and that should pretty much always be merged upwards. Doing the same thing a few times will take care of the rest. I think this basically does what would have happened had `j` been inlined, but we actually ''know'' that we're getting something out of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 04:21:43 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 04:21:43 -0000 Subject: [GHC] #9695: GADT Constraint breaks type inference Message-ID: <047.e8e079175882d77176a49cf5672d6102@haskell.org> #9695: GADT Constraint breaks type inference -------------------------------------+------------------------------------- Reporter: crockeea | 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: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code compiles: {{{ #!haskell {-# LANGUAGE TypeFamilies, MultiParamTypeClasses, GADTs #-} module Foo () where class (Num src, Num tgt) => Bar src tgt where bar :: (tgt, src) type family Type a data CT :: (* -> * -> *) where CT :: --(Type rp ~ Type rq) => rp -> rq -> CT rp rq foo :: (Bar rp rq) => CT rp rq -> CT rp rq foo = let (b', a') = bar in \(CT a b) -> CT (a * a') (b * b') }}} But when I add the [totally irrelevant] constraint to the GADT, `foo` no longer compiles: {{{ Foo.hs:16:22: Could not deduce (Bar t1 t0) arising from a use of ?bar? from the context (Bar rp rq) bound by the type signature for foo :: Bar rp rq => CT rp rq -> CT rp rq at testsuite/Foo.hs:15:8-42 The type variables ?t0?, ?t1? are ambiguous Relevant bindings include b' :: t0 (bound at Foo.hs:16:12) a' :: t1 (bound at Foo.hs:16:16) In the expression: bar In a pattern binding: (b', a') = bar In the expression: let (b', a') = bar in \ (CT a b) -> CT (a * a') (b * b') Foo.hs:17:31: Couldn't match expected type ?rp? with actual type ?t1? ?t1? is untouchable inside the constraints (Type rp ~ Type rq) bound by a pattern with constructor CT :: forall rp rq. Type rp ~ Type rq => rp -> rq -> CT rp rq, in a lambda abstraction at Foo.hs:17:12-17 ?rp? is a rigid type variable bound by the type signature for foo :: Bar rp rq => CT rp rq -> CT rp rq at testsuite/Foo.hs:15:8 Relevant bindings include a :: rp (bound at Foo.hs:17:15) a' :: t1 (bound at Foo.hs:16:16) foo :: CT rp rq -> CT rp rq (bound at Foo.hs:16:1) In the second argument of ?(*)?, namely ?a'? In the first argument of ?CT?, namely ?(a * a')? Foo.hs:17:40: Couldn't match expected type ?rq? with actual type ?t0? ?t0? is untouchable inside the constraints (Type rp ~ Type rq) bound by a pattern with constructor CT :: forall rp rq. Type rp ~ Type rq => rp -> rq -> CT rp rq, in a lambda abstraction at Foo.hs:17:12-17 ?rq? is a rigid type variable bound by the type signature for foo :: Bar rp rq => CT rp rq -> CT rp rq at Foo.hs:15:8 Relevant bindings include b :: rq (bound at Foo.hs:17:17) b' :: t0 (bound at Foo.hs:16:12) foo :: CT rp rq -> CT rp rq (bound at Foo.hs:16:1) In the second argument of ?(*)?, namely ?b'? In the second argument of ?CT?, namely ?(b * b')? }}} The errors can be fixed using `-XScopedTypeVariables` and changing `foo` to: {{{ #!haskell foo :: forall rp rq . (Bar rp rq) => CT rp rq -> CT rp rq foo = let (b' :: rq, a' :: rp) = bar in \(CT a b) -> CT (a * a') (b * b') }}} Why should I need an explicit type on `bar`, when the type can be inferred from its use in `foo` (as it was before the GADT constraint was added)? Is that expected behavior for GADTs? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 04:39:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 04:39:38 -0000 Subject: [GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory Message-ID: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> #9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: x86_64 (amd64) | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I initially filed this as a [http://stackoverflow.com/questions/26333815 /why-do-hgetbuf-hputbuf-etc-allocate-memory question on StackOverflow], assuming that the behavior I'm seeing was intentional, or that I was misinterpreting the profiler results... but Kazu Yamamoto [https://twitter.com/kazu_yamamoto/status/522583112249663488 suggested] I should file this as an issue here. It's my first GHC ticket, so here goes: {{{#!hs main :: IO () main = do buf <- mallocArray 1 echo buf echo :: Ptr Word8 -> IO () echo buf = forever $ do len <- readRawBufferPtr "read" stdin buf 0 1 writeRawBufferPtr "write" stdout buf 0 (fromIntegral len) }}} I expect the only heap allocation here should be my explicit `mallocArray`, but profiling with `+RTS -P` indicates this isn't the case: both the read and write operations do appear to allocate some short-lived heap objects. In contrast: {{{#!hs echo :: Ptr Word8 -> IO () echo buf = forever $ do threadWaitRead $ Fd 0 len <- c_read 0 buf 1 c_write 1 buf (fromIntegral len) yield }}} does not appear to allocate. I did a bit of digging (copying bits of source code from `base` into my own project, to get cost center annotations) and it seems like the allocation might be happening in `throwErrnoIfRetryMayBlock`. See [https://gist.github.com/anonymous/3ba3cfa118e1d05870d4 this gist] for more detail, including core output from `-ddump-simpl`. In all honesty, I don't know whether this is a bug. I was just surprised by it, when I first encountered it using `hGetBuf` / `hPutBuf`, so I'm trying to understand whether this is expected behavior and why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 07:25:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 07:25:32 -0000 Subject: [GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory In-Reply-To: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> References: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> Message-ID: <067.800b451cee4edc7f46e20d5cf2a2ece9@haskell.org> #9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: | Owner: mergeconflict | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by mergeconflict: Old description: > I initially filed this as a [http://stackoverflow.com/questions/26333815 > /why-do-hgetbuf-hputbuf-etc-allocate-memory question on StackOverflow], > assuming that the behavior I'm seeing was intentional, or that I was > misinterpreting the profiler results... but Kazu Yamamoto > [https://twitter.com/kazu_yamamoto/status/522583112249663488 suggested] I > should file this as an issue here. It's my first GHC ticket, so here > goes: > > {{{#!hs > main :: IO () > main = do > buf <- mallocArray 1 > echo buf > > echo :: Ptr Word8 -> IO () > echo buf = forever $ do > len <- readRawBufferPtr "read" stdin buf 0 1 > writeRawBufferPtr "write" stdout buf 0 (fromIntegral len) > }}} > > I expect the only heap allocation here should be my explicit > `mallocArray`, but profiling with `+RTS -P` indicates this isn't the > case: both the read and write operations do appear to allocate some > short-lived heap objects. In contrast: > > {{{#!hs > echo :: Ptr Word8 -> IO () > echo buf = forever $ do > threadWaitRead $ Fd 0 > len <- c_read 0 buf 1 > c_write 1 buf (fromIntegral len) > yield > }}} > > does not appear to allocate. > > I did a bit of digging (copying bits of source code from `base` into my > own project, to get cost center annotations) and it seems like the > allocation might be happening in `throwErrnoIfRetryMayBlock`. See > [https://gist.github.com/anonymous/3ba3cfa118e1d05870d4 this gist] for > more detail, including core output from `-ddump-simpl`. > > In all honesty, I don't know whether this is a bug. I was just surprised > by it, when I first encountered it using `hGetBuf` / `hPutBuf`, so I'm > trying to understand whether this is expected behavior and why. New description: I initially filed this as a [http://stackoverflow.com/questions/26333815 /why-do-hgetbuf-hputbuf-etc-allocate-memory question on StackOverflow], assuming that the behavior I'm seeing was intentional, or that I was misinterpreting the profiler results... but Kazu Yamamoto [https://twitter.com/kazu_yamamoto/status/522583112249663488 suggested] I should file this as an issue here. It's my first GHC ticket, so here goes: {{{#!hs main :: IO () main = do buf <- mallocArray 1 echo buf echo :: Ptr Word8 -> IO () echo buf = forever $ do len <- readRawBufferPtr "read" stdin buf 0 1 writeRawBufferPtr "write" stdout buf 0 (fromIntegral len) }}} I expect the only heap allocation here should be my explicit `mallocArray`, but profiling with `+RTS -P` indicates this isn't the case: both the read and write operations do appear to allocate some short-lived heap objects each time through the loop. (Note: this isn't a space leak, the allocated objects appear to be GC'ed quickly, whatever they are). In contrast: {{{#!hs echo :: Ptr Word8 -> IO () echo buf = forever $ do threadWaitRead $ Fd 0 len <- c_read 0 buf 1 c_write 1 buf (fromIntegral len) yield }}} does not appear to allocate. I did a bit of digging (copying bits of source code from `base` into my own project, to get cost center annotations) and it seems like the allocation might be happening in `throwErrnoIfRetryMayBlock`. See [https://gist.github.com/anonymous/3ba3cfa118e1d05870d4 this gist] for more detail, including core output from `-ddump-simpl`. In all honesty, I don't know whether this is a bug. I was just surprised by it, when I first encountered it using `hGetBuf` / `hPutBuf`, so I'm trying to understand whether this is expected behavior and why. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 07:45:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 07:45:36 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.d2bf3d35e16e251d476cc5986ff6b25e@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: high | Milestone: 7.8.4 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D329 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"cde3a77f9703966145cae481ee35f52dcca2cf7d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cde3a77f9703966145cae481ee35f52dcca2cf7d" Make Data.List.Inits fast Fixes #9345. Use a modified banker's queue to achieve amortized optimal performance for inits. The previous implementation was extremely slow. Reviewed By: nomeata, ekmett, austin Differential Revision: https://phabricator.haskell.org/D329 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 07:45:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 07:45:36 -0000 Subject: [GHC] #9670: Make Data.List.tails a good producer for list fusion In-Reply-To: <045.53ecc54eb7a39dea158b99c57adf8e43@haskell.org> References: <045.53ecc54eb7a39dea158b99c57adf8e43@haskell.org> Message-ID: <060.f238ed846669a8d5a3e6687ce93f09b1@haskell.org> #9670: Make Data.List.tails a good producer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: fusion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D325 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"7e735950a44f7f3c34319ea65631e11e52eb68a7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7e735950a44f7f3c34319ea65631e11e52eb68a7" Make tails a good producer (#9670) Reviewed By: nomeata, austin Differential Revision: https://phabricator.haskell.org/D325 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 07:47:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 07:47:03 -0000 Subject: [GHC] #9670: Make Data.List.tails a good producer for list fusion In-Reply-To: <045.53ecc54eb7a39dea158b99c57adf8e43@haskell.org> References: <045.53ecc54eb7a39dea158b99c57adf8e43@haskell.org> Message-ID: <060.b268e7344db616dc392d0f7014814071@haskell.org> #9670: Make Data.List.tails a good producer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: fusion Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D325 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 07:47:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 07:47:11 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.8fcd72cf4a27e8bf9655692629bfa282@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: closed Priority: high | Milestone: 7.8.4 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D329 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 07:54:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 07:54:40 -0000 Subject: [GHC] #9668: Unicode info is out of date In-Reply-To: <045.4162c8318981414b1b75ed9710354b32@haskell.org> References: <045.4162c8318981414b1b75ed9710354b32@haskell.org> Message-ID: <060.41acaa1c59a63a78b2006adb0457cb5c@haskell.org> #9668: Unicode info is out of date -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Unicode Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): ?Phab:D317 was abandonned, Phab:316 seems to be the current one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 09:59:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 09:59:23 -0000 Subject: [GHC] #8317: Optimize tagToEnum# at Core level In-Reply-To: <048.d63000c93a1f7da8d9258ca78bbef37a@haskell.org> References: <048.d63000c93a1f7da8d9258ca78bbef37a@haskell.org> Message-ID: <063.f0af18ec11db28d38f6228665ab4abc4@haskell.org> #8317: Optimize tagToEnum# at Core level -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: 8326 None/Unknown | Related Tickets: #6135 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 10:30:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 10:30:56 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.3088eef09d5f3813aacf4c21275a8ce4@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 11:24:07 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 11:24:07 -0000 Subject: [GHC] #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 Message-ID: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 -------------------------------------+------------------------------------- Reporter: nich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: aclocal.m4 find | Operating System: perm | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Easy (less than 1 | GHC failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- ./configure produces error message when building on current Fedora (20). According to find ver 4.5.11 the usage '-perm +XXX' has been deprecated since 2005 (use '-perm \XXX' instead). The message '/usr/bin/find: invalid mode '+111' ' is seen several times as a result. Whether this has any material impact I am not qualified to judge. I am actually trying to build HaLVM (from Galois) and first noticed the issue in their fork of GHC. However, this behaviour is also present in git HEAD (commit d7867810d5ffd08c77c30e928bb3dca21beae0b9). Making the obvious one line change in aclocal.m4 resolves the issue, and produces a clean build, for me at least. Patch attached -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 14:03:22 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 14:03:22 -0000 Subject: [GHC] #9698: GHC_PACKAGE_PATH should be more lenient for empty paths Message-ID: <047.c636c8193d3a0be6c7f17bc6acc215b1@haskell.org> #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: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 14:03:56 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 14:03:56 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.23603c0c871064007dd5758da74de2e1@haskell.org> #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: | -------------------------------------+------------------------------------- Comment (by sjoerd_visscher): From the wiki page: "We could try to figure this out in a clever way from the definition of the class being derived, but this is very hard in general." Why is this very hard in general? If I leave out the context in `instance MyClass (MyDatatype a)` then GHC will complain that it is missing `MyClass a`. So can't we use the type checker to give us the required context? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 14:06:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 14:06:23 -0000 Subject: [GHC] #8317: Optimize tagToEnum# at Core level In-Reply-To: <048.d63000c93a1f7da8d9258ca78bbef37a@haskell.org> References: <048.d63000c93a1f7da8d9258ca78bbef37a@haskell.org> Message-ID: <063.122051c5b806d5b71ce2c7584831a80f@haskell.org> #8317: Optimize tagToEnum# at Core level -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: 8326 None/Unknown | Related Tickets: #6135 Test Case: | Blocking: | Differential Revisions: D343 | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => D343 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 14:06:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 14:06:30 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.f04b1f7c38b54f5893f4f1ef4c2591a1@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: D343 | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => D343 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 14:06:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 14:06:59 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.24588c22dca9f45a089f3ac4afbaa389@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: Phab:D343 | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: D343 => Phab:D343 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 14:07:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 14:07:14 -0000 Subject: [GHC] #8317: Optimize tagToEnum# at Core level In-Reply-To: <048.d63000c93a1f7da8d9258ca78bbef37a@haskell.org> References: <048.d63000c93a1f7da8d9258ca78bbef37a@haskell.org> Message-ID: <063.67e99e69e8002775c4086d1c2994b1bc@haskell.org> #8317: Optimize tagToEnum# at Core level -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: 8326 None/Unknown | Related Tickets: #6135 Test Case: | Blocking: | Differential Revisions: Phab:D343 | -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: D343 => Phab:D343 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 16:35:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 16:35:52 -0000 Subject: [GHC] #9699: TH function to list names in scope Message-ID: <050.e1a7513209ad9375a0ec4688679fe797@haskell.org> #9699: TH function to list names in scope -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | 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 [asked about this on stackoverflow](http://stackoverflow.com/questions/26394199/using- templatehaskell-to-list-all-names-in-a-namespace), and apparently it doesn't exist yet. I want a TemplateHaskell function `variablesInScope :: Q [Name]` that returns a list of the `Name`'s of all the variables in scope. TemplateHaskell obviously has this information available in order to implement functions like `reify :: Name -> Q Info` and `lookupValueName :: String -> Q (Maybe Name)`. So it seems like this might be a pretty simple function to add. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 18:05:47 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 18:05:47 -0000 Subject: [GHC] #9695: GADT Constraint breaks type inference In-Reply-To: <047.e8e079175882d77176a49cf5672d6102@haskell.org> References: <047.e8e079175882d77176a49cf5672d6102@haskell.org> Message-ID: <062.0163cc26047d8369f48654b3273eab39@haskell.org> #9695: GADT Constraint breaks type inference -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: > Is that expected behavior for GADTs? Yes. Type inference in the presence of an equality constraint -- even a seemingly-irrelevant one -- is incomplete. The error message definitely needs to get better (#9109), but I'm not sure the behavior can be fixed. The [http://research.microsoft.com/~simonpj/papers/constraints/jfp- outsidein.pdf OutsideIn] paper, section 5.2, gives a nice description of the problem. This section is readable without reading the rest of the paper (although the short, preceding section 5.1 helps somewhat). I'm closing as "invalid", but if you think there's something deeper going on here, please reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 18:06:06 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 18:06:06 -0000 Subject: [GHC] #9109: Improve error messages around "untouchable" type variables In-Reply-To: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> References: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> Message-ID: <062.e6bd74a810c7bd0549f8db4ede92146c@haskell.org> #9109: Improve error messages around "untouchable" type variables -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by goldfire): See #9695 for another example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 18:15:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 18:15:09 -0000 Subject: [GHC] #9109: Improve error messages around "untouchable" type variables In-Reply-To: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> References: <047.8e8e8d32b365719fddf8914f1815c1c6@haskell.org> Message-ID: <062.e2ffcd829a34658a32babdd8999d854b@haskell.org> #9109: Improve error messages around "untouchable" type variables -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 crockeea): * cc: ecrockett0@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 20:13:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 20:13:29 -0000 Subject: [GHC] #9700: Support C structures in Haskell FFI Message-ID: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> #9700: Support C structures in Haskell FFI -------------------------------------+------------------------------------- Reporter: Yuras | 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: Phab:D252 -------------------------------------+------------------------------------- This ticket is for tracking progress on [[CStructures]] language extension proposal. The idea is to support C structures in Haskell FFI. See wiki for details. If it will be accepted, I'm going to implement it in few steps. The first one is to support structures as return value. Platform specific part for that is already implemented, see Phab:D252 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 20:15:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 20:15:52 -0000 Subject: [GHC] #9700: Support C structures in Haskell FFI In-Reply-To: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> References: <044.596a97e8d8f649bed4fc2b5d38a5701e@haskell.org> Message-ID: <059.2dfcaffc9bb37e327bcd25af3d1a6d5b@haskell.org> #9700: Support C structures in Haskell FFI -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D252 | -------------------------------------+------------------------------------- Changes (by Yuras): * owner: => Yuras -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 23:11:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 23:11:10 -0000 Subject: [GHC] #9691: GHC-HEAD runtime is broken on arm In-Reply-To: <047.9fcb5b64ebe9f7a33ad168c55acc7b20@haskell.org> References: <047.9fcb5b64ebe9f7a33ad168c55acc7b20@haskell.org> Message-ID: <062.057072fbda70cdf153c7977754e81695@haskell.org> #9691: GHC-HEAD runtime is broken on arm ----------------------------------------+--------------------------- Reporter: mkbrandt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------+--------------------------- Comment (by mkbrandt): I tried building ghc-7.8.3 for arm-unknown-linux-gnueabi after installing the ELDK to make the environment easier to duplicate. ELDK was version 5.5 configured for armv5te. I confirmed that gcc binaries produced by this SDK would run on the target, but got the same result with arm-unknown-linux- ghc (binary hangs with no output using ~100% of cpu). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 16 23:33:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Oct 2014 23:33:09 -0000 Subject: [GHC] #9689: const_str support needed for hsc2hs in cross-compilation mode In-Reply-To: <047.6b6fe4767ca0068aa88df83be71e3c46@haskell.org> References: <047.6b6fe4767ca0068aa88df83be71e3c46@haskell.org> Message-ID: <062.9d87840590af37ddad22a5a56a5eac25@haskell.org> #9689: const_str support needed for hsc2hs in cross-compilation mode -------------------------------------+------------------------------------- Reporter: aosivitz | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: hsc2hs | Keywords: zlib ios cross- Resolution: wontfix | compilation Operating System: | Architecture: arm Unknown/Multiple | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by aosivitz): Yep, it works for me (ghc 7.8.3, arm) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 01:09:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 01:09:47 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.ce581147a27ff9d380a259622fc15c25@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by akio): Here is one example where the interface changes while there is no code change at all. On my computer (with GHC 7.8.3 on Linux), the attached shell script compiles Main.hs 4 times rather than just once. B.hi seems to contain some rules whose name is not stable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 01:10:53 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 01:10:53 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.621691140a16ba0db2ca45953ff2ae35@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Changes (by akio): * cc: tkn.akio@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 07:45:13 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 07:45:13 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.68457ce9e8ccc57d5c6f5346fd9c9c1f@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Nice example. Here is the diff between such interface files. {{{ -"SPEC $cshowsPrec_a2QX @ [GHC.Types.Char]" [ALWAYS] forall $dShow :: GHC.Show.Show +"SPEC $cshowsPrec_a2Q6 @ [GHC.Types.Char]" [ALWAYS] forall $dShow :: GHC.Show.Show [GHC.Types.Char] }}} It looks similar in 7.6.3 and in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 07:45:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 07:45:52 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.0183ffebdbdddcb1f6905da0601b407f@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:24 trommler]: > > I rebased the patch for #8935 and cannot reproduce the issue for compdata version 0.8.1.0 and 0.9. > I also built Haskell Platform [https://build.opensuse.org/project/show/devel:languages:haskell:platform] and pandoc [https://build.opensuse.org/project/show/devel:languages:haskell:pandoc] on OBS and did not see the issue. Setting environment variable `SUSE_ASNEEDED=1` I can reproduce the bug. That environment variable changes the behaviour of the link editor to include the flag `--as-neeeded` in the link command. From man ld(1): --as-needed --no-as-needed This option affects ELF DT_NEEDED tags for dynamic libraries mentioned on the command line after the --as-needed option. Normally the linker will add a DT_NEEDED tag for each dynamic library mentioned on the command line, regardless of whether the library is actually needed or not. --as-needed causes a DT_NEEDED tag to only be emitted for a library that satisfies an undefined symbol reference from a regular object file or, if the library is not found in the DT_NEEDED lists of other libraries linked up to that point, an undefined symbol reference from another dynamic library. --no-as-needed restores the default behaviour. The important point here is: The order of the linker arguments does matter! I do not understand, however, what adding -v3 changes (see [comment:13 @rwbarton's comment]) to make the build go through. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 07:57:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 07:57:35 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.39b52864c92bb72fe6a2a3407596f23c@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): I think I can root out this instance of non-determinism. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 07:59:47 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 07:59:47 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.44d3ff53086034ddaef1dfbbb8b31992@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: Phab:D343 | -------------------------------------+------------------------------------- Comment (by simonpj): Responding to the writeup on Phab:D343. Before running off to make special cases for comparisons, look at the relevant code for `cgCase`: {{{ cgCase scrut bndr alt_type alts = -- the general case do { dflags <- getDynFlags ; up_hp_usg <- getVirtHp -- Upstream heap usage ; let ret_bndrs = chooseReturnBndrs bndr alt_type alts alt_regs = map (idToReg dflags) ret_bndrs ; simple_scrut <- isSimpleScrut scrut alt_type ; let do_gc | not simple_scrut = True | isSingleton alts = False | up_hp_usg > 0 = False | otherwise = True -- cf Note [Compiling case expressions] gc_plan = if do_gc then GcInAlts alt_regs else NoGcInAlts ; mb_cc <- maybeSaveCostCentre simple_scrut ; let sequel = AssignTo alt_regs do_gc{- Note [scrut sequel] -} ; ret_kind <- withSequel sequel (cgExpr scrut) ; restoreCurrentCostCentre mb_cc ; _ <- bindArgsToRegs ret_bndrs ; cgAlts (gc_plan,ret_kind) (NonVoid bndr) alt_type alts } }}} If `do_gc` is true, we put heap checks at the start of each branch. If `do_gc` is false, we take the max of the branches, and do the heap check before the `case`. I'll use a running example like this: {{{ f = \x -> let y = blah in case of 0# -> DEFAULT -> }}} Things that affect the `do_gc` decision: * If the scrutinee `` requires any non-trivial work, we MUST have `do_gc = True`. For example if `` was `(g x)`, then calling `g` might result in lots of allocation, so any heap check done at the start of `f` is irrelevant to the branches. They must do their own checks. This is the `simple_scrut` check. It succeeds on simple finite computations like `x +# 1` or `x` (if `x` is unboxed). The other cases are all for the simple-srut situation: * If there is just one alternative, then it's always good to amalgamate * If there is heap allocation in the code before the case (`up_hp_usg > 0`), then we are going to do a heap-check upstream anyway. In that case, don't do one in the alterantives too. (The single check might allocate too much space, but the alterantives that use less space simply move `Hp` back down again, which only costs one instruction.) * Otherwise, if there no heap alloation upstream, put heap checks in each alternative. The resoning here was that if one alternative needs heap and the other one doesn't we don't want to pay the runtime for the heap check in the case where the heap-free alternative is taken. Now, what is happening in your example is that * There is no upstream heap usage * Both alternatives allocate Result: you get two heap checks instead of one. But if only ''one'' branch allocated, you'd probably ''want'' to have the heap check in that branch! So I think the criterion should be that (assuming no upstream allocation) * If all the branches allocate, do the heap check before the case * Otherwise pay the price of a heap check in each branch Or alterantively (less code size, slightly slower) * If more than one branch allocates, do the heap check before the case * If only one allocates, do it in the brcnch The difficulty here is that it's hard to find out whether the branches allocate without running the code generator on them, and that's now how the current setup is structured. (When you run the code generator on some code, the monad keeps track of how much allocation is done; see `StgCmmMonad.getHeapUsage`.) It might well be possible to move things around a bit, but it would need a little care. But before doing that, the first thing is to decide what the criteria should be. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 08:29:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 08:29:05 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.2cda9cfe4cc7df8a6dc146ee54a5b418@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Whoa! The name of an auto-generated rule is itself auto-generated, so that a (savvy) user can track back to which function is being specialised. But nothing will go wrong if two rules accidentally have the same name, which seems entirely possible if you suppress the unique. I can see that this is a rather gratuitous source of non-determinism. Joachim, do go ahead and suppress the unique (with an accompanying Note!). Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 09:14:37 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 09:14:37 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.d3ab4b4d56b0380f263a284488fd0610@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): Simple patch, pushed at Phab:D346 for validation. Will push as soon as that goes through. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 10:37:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 10:37:45 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.c66a839cd19a314a9dddeb1646bef62c@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: Phab:D343 | -------------------------------------+------------------------------------- Comment (by jstolarek): Thanks for detailed explanation. I was a bit concerned about all that extra stuff like saving cost centres in the general case. Don't we need to worry that any of these will impact performance of the compiled code? > The difficulty here is that it's hard to find out whether the branches allocate without running the code generator on them Yes, I believe this was our conclusion when we discussed that during my internship. I don't see how to use `StgCmmMonad.getHeapUsage` to implement the solution. We compile all the alternatives in one go by calling `cgAlts (gc_plan,ret_kind) (NonVoid bndr) alt_type alts`, whereas to apply any of the criteria that you proposed we would need to compile the alternatives one by one and analyse their heap usage. My understanding is that if we simply call `cgAlts` in a lambda passed to `getHeapUsage` we will only know how much heap total is used by the compiled alternatives but we won't have any detailed knowledge about each of the alternatives. Is that correct? > But before doing that, the first thing is to decide what the criteria should be. It's a bit hard to tell without doing the actual implementation and measuring the results. I guess there will be some programs that work better with the first criterion and some that work better with the second criterion. That being said, I'd go with the first one. Slightly larger binaries are a small price to pay for possibility of having better performance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 13:06:29 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 13:06:29 -0000 Subject: [GHC] #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 In-Reply-To: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> References: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> Message-ID: <058.3f479052d4d3b371e62db4036c29c5d3@haskell.org> #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 -------------------------------------+------------------------------------- Reporter: nich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: aclocal.m4 find Resolution: | perm Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): The patch changes `\111` to `+111`, which is opposite of what the description says should happen. Can you verify it works for `ghc master`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 13:37:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 13:37:23 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.6b8eb39cd123f935064bacb602cbb7aa@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Difficult (2-5 Type of failure: Other | days) Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"a477e8118137b7483d0a7680c1fd337a007a023b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a477e8118137b7483d0a7680c1fd337a007a023b" Avoid printing uniques in specialization rules Akio found an avoidable cause of non-determinisim: The names of RULES generated by Specialise had uniques in them: "SPEC $cshowsPrec_a2QX @ [GHC.Types.Char]" [ALWAYS] forall ... By using showSDocForUser instead of showSDocDump when building the rule name, this is avoided: "SPEC $cshowsPrec @ [Char]" [ALWAYS] forall ... See #4012, comments 61ff. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 14:07:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 14:07:35 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.7fdda1182770e7f1a354665a084e5902@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: Phab:D343 | -------------------------------------+------------------------------------- Comment (by simonpj): Well, of course the plumbing would need to change a bit. `cgAlts` would have to return something saying which branches allocated. The difficulty is that at the moment the `gc_plan` flag is passed ''into'' `cgAlts` whereas now we are proposing that the plan will depend on something ''returned'' by `cgAlts`. That might be ok, if we tied a recursive knot, provided `cgAlts` was sufficiently lazy in its "plan" parameter. More than that I cannot say without looking a lot harder at the code, something you can do just as well as I, perhaps better. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 16:57:27 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 16:57:27 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.87b476b34b9d8c21af1b9d1e3478f1de@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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 adamgundry): * cc: adamgundry (added) Comment: Type families as currently implemented really are axiomatically-defined functional relations: we don't have an operational semantics for them as functions. I agree that being able to write actual functional programs at the type level would be nice, but we can't yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 16:58:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 16:58:03 -0000 Subject: [GHC] #9637: Type level programming needs an error function In-Reply-To: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> References: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> Message-ID: <062.34ce273f2f66d4caab5a9c295ce3fcfd@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 17 23:56:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Oct 2014 23:56:33 -0000 Subject: [GHC] #9701: GADTs not specialized properly Message-ID: <045.92cfd361991e24d797a63e834e046545@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | 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: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This has probably been raised before, but I can't find a ticket. If I write {{{#!hs data Silly a where Silly :: Ord a => a -> Silly a isItSilly :: a -> Silly a -> Bool isItSilly a (Silly x) = a < x isItSillyInt :: Int -> Silly Int -> Bool isItSillyInt = isItSilly }}} then I get {{{ isItSilly isItSilly = \ @ a_aBq eta_B2 eta1_B1 -> case eta1_B1 of _ { Silly $dOrd_aBs x_aAy -> < $dOrd_aBs eta_B2 x_aAy } isItSillyInt isItSillyInt = isItSilly }}} Although GHC knows that `eta_B2` is an `Int`, and `x_aAy` therefore must be one as well, it looks up the `<` method in the `eta1_B1` dictionary instead of just using `ltInt`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 00:53:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 00:53:41 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.c6f70b17a7f067ea9aa0f50072a10124@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > This has probably been raised before, but I can't find a ticket. If I > write > > {{{#!hs > data Silly a where > Silly :: Ord a => a -> Silly a > > isItSilly :: a -> Silly a -> Bool > isItSilly a (Silly x) = a < x > > isItSillyInt :: Int -> Silly Int -> Bool > isItSillyInt = isItSilly > }}} > > then I get > > {{{ > isItSilly > isItSilly = > \ @ a_aBq eta_B2 eta1_B1 -> > case eta1_B1 of _ { Silly $dOrd_aBs x_aAy -> > < $dOrd_aBs eta_B2 x_aAy > } > > isItSillyInt > isItSillyInt = isItSilly > }}} > > Although GHC knows that `eta_B2` is an `Int`, and `x_aAy` therefore must > be one as well, it looks up the `<` method in the `eta1_B1` dictionary > instead of just using `ltInt`. New description: This has probably been raised before, but I can't find a ticket. If I write {{{#!hs data Silly a where Silly :: Ord a => a -> Silly a isItSilly :: a -> Silly a -> Bool isItSilly a (Silly x) = a < x isItSillyInt :: Int -> Silly Int -> Bool isItSillyInt = isItSilly }}} then I get {{{ isItSilly isItSilly = \ @ a_aBq eta_B2 eta1_B1 -> case eta1_B1 of _ { Silly $dOrd_aBs x_aAy -> < $dOrd_aBs eta_B2 x_aAy } isItSillyInt isItSillyInt = isItSilly }}} Although GHC knows that `eta_B2` and `x_aAy` are `Int`, it looks up the `<` method in the `eta1_B1` dictionary instead of just using `ltInt`. Note: it does not help to `INLINE` `isItSilly`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 06:41:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 06:41:37 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.63e44153cd434d2fdd46446f2255efd7@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: Phab:D343 | -------------------------------------+------------------------------------- Comment (by jstolarek): > Well, of course the plumbing would need to change a bit. (...) Right. I just wanted to make sure that I understood things correctly. I'll try to figure out how to make that change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 11:16:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 11:16:32 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.de47d64941c411b856f6596ba91359c3@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime | Version: 7.8.1-rc2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Rocket Science Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: #9186, #9480 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: simonmar => trommler Comment: I have a fix for [changeset:2f8b4c9330b455d4cb31c186c747a7db12a69251] that validates and also does not introduce the regression reported in #9186. I'll clean up the patch and post it on phabricator. Analysis: On some systems the order of linker options and especially the order libraries are passed to `ld` matters. That behaviour is caused by a patch binutils to change the default of `--no-as-needed` to `--as-needed`. The library ordering issue is the reason for the regression we saw in #9186. On openSUSE you can control the default behaviour of `ld` by setting `SUSE_ASNEEDED=1` in the environment. Given the name of the environment variable I doubt it works on other distributions :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 12:34:36 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 12:34:36 -0000 Subject: [GHC] #9340: Implement new `clz` inline primop In-Reply-To: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> References: <042.27ebe5235e563cbaf1d7d8e3590e2217@haskell.org> Message-ID: <057.0ba22213f58e04070b4323f0ed6b8785@haskell.org> #9340: Implement new `clz` inline primop -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: primop clz ctz (CodeGen) | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: #9532 Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D144 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"612f3d120c65a461a4ad7f212d67bdae005f4975/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="612f3d120c65a461a4ad7f212d67bdae005f4975" Implement optimized NCG `MO_Ctz W64` op for i386 (#9340) Summary: This is an optimization to the CTZ primops introduced for #9340 Previously we called out to `hs_ctz64`, but we can actually generate better hand-tuned code while avoiding the FFI ccall. With this patch, the code {-# LANGUAGE MagicHash #-} module TestClz0 where import GHC.Prim ctz64 :: Word64# -> Word# ctz64 x = ctz64# x results in the following assembler generated by NCG on i386: TestClz.ctz64_info: movl (%ebp),%eax movl 4(%ebp),%ecx movl %ecx,%edx orl %eax,%edx movl $64,%edx je _nAO bsf %ecx,%ecx addl $32,%ecx bsf %eax,%eax cmovne %eax,%ecx movl %ecx,%edx _nAO: movl %edx,%esi addl $8,%ebp jmp *(%ebp) For comparision, here's what LLVM 3.4 currently generates: 000000fc : fc: 0f bc 45 04 bsf 0x4(%ebp),%eax 100: b9 20 00 00 00 mov $0x20,%ecx 105: 0f 45 c8 cmovne %eax,%ecx 108: 83 c1 20 add $0x20,%ecx 10b: 8b 45 00 mov 0x0(%ebp),%eax 10e: 8b 55 08 mov 0x8(%ebp),%edx 111: 0f bc f0 bsf %eax,%esi 114: 85 c0 test %eax,%eax 116: 0f 44 f1 cmove %ecx,%esi 119: 83 c5 08 add $0x8,%ebp 11c: ff e2 jmp *%edx Reviewed By: austin Auditors: simonmar Differential Revision: https://phabricator.haskell.org/D163 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 12:55:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 12:55:14 -0000 Subject: [GHC] #9237: GHC not recognizing "-llibrary" form in implicit linker scripts In-Reply-To: <051.f95f4904e896de4fcf955563f575c874@haskell.org> References: <051.f95f4904e896de4fcf955563f575c874@haskell.org> Message-ID: <066.38029dd519aa1de06beef95266a51521@haskell.org> #9237: GHC not recognizing "-llibrary" form in implicit linker scripts -------------------------------------+------------------------------------- Reporter: | Owner: mmikolajczyk | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by anjefu): * cc: jeff@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 13:16:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 13:16:34 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.6f3e51552b3417e2c0b65a90cb50f944@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: | Owner: skeuchel Blaisorblade | Status: merge Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: fusion Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #9537 performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D322 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => merge * related: => #9537 Comment: `concatMap` will be addressed under #9537, so I'll change the status here to "merge". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 13:37:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 13:37:46 -0000 Subject: [GHC] #9537: concatMap is not a good producer for list fusion (was: concatMap does not participate in list fusion) In-Reply-To: <045.e14a158c8be66f6d40a93a99a32fda56@haskell.org> References: <045.e14a158c8be66f6d40a93a99a32fda56@haskell.org> Message-ID: <060.025c669d3e4956df3d22c0c5dd5d836d@haskell.org> #9537: concatMap is not a good producer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: fusion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D348 | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * status: new => patch * differential: => Phab:D348 Old description: > Joachim Breitner raised this issue in an > [http://www.haskell.org/pipermail/haskell-cafe/2011-December/097228.html > email to haskell-cafe] in 2011, but he never got a response. For some > reason, list comprehensions desugar to `concatMap` forms written to fuse, > but the actual `concatMap` function is not written so. Unless there is a > good reason for this, we should make it fuse. New description: Joachim Breitner raised this issue in an [http://www.haskell.org/pipermail /haskell-cafe/2011-December/097228.html email to haskell-cafe] in 2011, but he never got a response. For some reason, list comprehensions desugar to `concatMap` forms written to fuse fully, but the actual `concatMap` function is not written so. Unless there is a good reason for this, we should make it fuse better. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 14:08:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 14:08:06 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.d9a7087b55a4b8d64dfe97b228161af7@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: | Owner: skeuchel Blaisorblade | Status: merge Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: fusion Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #9537 performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D322 | -------------------------------------+------------------------------------- Comment (by rwbarton): This isn't really a bug fix, so I wouldn't merge it. I'll leave it in 'merge' status though so Austin will see it in case he disagrees. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 14:23:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 14:23:14 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.77928ac9276eb8180b652733b065615e@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"7369d2595a8cceebe457a44c8400828f4df87ea0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7369d2595a8cceebe457a44c8400828f4df87ea0" Remove obsolete Data.OldTypeable (#9639) This finally removes the `Data.OldTypeable` module (which has been deprecated in 7.8), from `base`, compiler and testsuite. The deprecated `Typeable{1..7}` aliases in `Data.Typeable` are not removed yet in order to give existing code a bit more time to adapt. Reviewed By: hvr, dreixel Differential Revision: https://phabricator.haskell.org/D311 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 14:29:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 14:29:12 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.fd5cf41154139f1282c9971c646821fd@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Typeable Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Changes (by hvr): * keywords: => Typeable * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 14:55:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 14:55:55 -0000 Subject: [GHC] #9527: Add Generic instances for Language.Haskell.TH In-Reply-To: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> References: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> Message-ID: <057.2c9ae4a0ca5e6115dac38afc9faf83ca@haskell.org> #9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: goldfire Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: 9526 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: core-libraries-committee@? (added) * owner: ekmett => goldfire Comment: I'm starting some TH work so will take this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 15:06:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 15:06:14 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict In-Reply-To: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> References: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> Message-ID: <059.03ff47eab250c1e0f083381e718595fb@haskell.org> #9038: Foreign calls don't make their arguments look strict -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 1592 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => infoneeded Comment: tibbe's and Simon's cores look identical to me modulo suppressions and alpha-renaming. The only thing that sounds potentially wrong to me here is the behavior of tibbe's original function with `evaluate val`, but it's hard to tell without the actual function and Core output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 15:56:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 15:56:00 -0000 Subject: [GHC] #9132: takeWhile&C. still not fusible In-Reply-To: <051.252bf456ce6fe936293a4484081567fb@haskell.org> References: <051.252bf456ce6fe936293a4484081567fb@haskell.org> Message-ID: <066.92afab170cd6a9d627f62670f0a0192a@haskell.org> #9132: takeWhile&C. still not fusible -------------------------------------+------------------------------------- Reporter: | Owner: skeuchel Blaisorblade | Status: merge Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: fusion Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: #9537 performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D322 | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:25 rwbarton]: > This isn't really a bug fix, so I wouldn't merge it. I'll leave it in 'merge' status though so Austin will see it in case he disagrees. I just don't know how tickets are handled when they are about done, and I figured changing to "merge" was a safer bet than changing to "fixed". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 17:01:56 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 17:01:56 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.d60c420130ca004b45fead5ed485e523@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime | Version: 7.8.1-rc2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Rocket Science Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: #9186, #9480 Test Case: | Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:D349 Comment: Here is my [Phab:D349 patch]. I validated on openSUSE 13.1 running on x86_64. Additionally I back ported the patch to 7.8.3 built, all of Haskell Platform and pandoc and verified I can build compdata-0.8.1.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 17:03:00 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 17:03:00 -0000 Subject: [GHC] #8935: Obscure linker bug leads to crash in GHCi In-Reply-To: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> References: <047.8232648153a9aef6fa07ec75b847f7cb@haskell.org> Message-ID: <062.ebfb487722fb0d03222ea3438d88800f@haskell.org> #8935: Obscure linker bug leads to crash in GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Runtime | Version: 7.8.1-rc2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Rocket Science Unknown/Multiple | Blocked By: Type of failure: GHCi crash | Related Tickets: #9186, #9480 Test Case: | Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 17:47:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 17:47:34 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.98758c04846321c4734c5bbd8bf8d07f@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9377 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by carter): * milestone: => 7.8.4 Comment: Adding a 7.8.4 milestone so this can be considered for the 7.8.4 release, i think this was only applied to the 7.9 (HEAD) branch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 18:28:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 18:28:39 -0000 Subject: [GHC] #9702: Offer a weaker name shadowing warning Message-ID: <045.a53501a68ff02e8671244c2afeca86af@haskell.org> #9702: Offer a weaker name shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: warning, module | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Suppose I have a module {{{#!hs module Survive where import HuntGather flounder = goFishing river where goFishing = ... }}} If the maintainer of `HuntGather` decides to add a `goFishing` function, my module will suddenly get a name shadowing warning, although there is little risk of confusion. So I think it makes a lot of sense to offer, at least, a version that ignores shadowing of *implicitly imported* names, and to use this for `-Wall` instead of the current version. Another step down would be to ignore shadowing of all top-level names, but having three levels of name shadowing warning would be too much trouble by far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 19:00:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 19:00:46 -0000 Subject: [GHC] #9295: Deadlock in forkProcess In-Reply-To: <044.090d8a79b478134070085ba877094a40@haskell.org> References: <044.090d8a79b478134070085ba877094a40@haskell.org> Message-ID: <059.8dc4105075806e919df2556e502fe86f@haskell.org> #9295: Deadlock in forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 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 thoughtpolice): * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 19:03:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 19:03:09 -0000 Subject: [GHC] #9296: Acquire all_tasks_mutex in forkProcess In-Reply-To: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> References: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> Message-ID: <059.d2d0adafa8702d9c1343d80216e5b658@haskell.org> #9296: Acquire all_tasks_mutex in forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | 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 MikolajKonarski): * status: new => closed * resolution: => fixed * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 19:04:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 19:04:12 -0000 Subject: [GHC] #9377: forkProcess unnecessarily sets wait_foreign in hs_exit_ In-Reply-To: <044.bcc13c0b01027f9b1ada7aa07dc59145@haskell.org> References: <044.bcc13c0b01027f9b1ada7aa07dc59145@haskell.org> Message-ID: <059.7fd66eb8706e1024c1bf90267b9207bb@haskell.org> #9377: forkProcess unnecessarily sets wait_foreign in hs_exit_ -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D99 | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * status: new => closed * resolution: => fixed * milestone: => 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 19:46:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 19:46:58 -0000 Subject: [GHC] #9527: Add Generic instances for Language.Haskell.TH In-Reply-To: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> References: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> Message-ID: <057.246ad12a3d9ea88f5d7e46cfd1d38d23@haskell.org> #9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: goldfire Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: 9526 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by luite): While you're at it, could you check if adding `Binary` instances is still problematic? The binary package is not a dependency at the moment. There's a comment in the code about switching to `Binary` (from `Data`) for serialization for annotations: http://git.haskell.org/packages/template- haskell.git/blob/9bcc122819a6f4a2ae7ad569717324b8368e801c:/Language/Haskell/TH/Syntax.hs#l661 Serialization of the other data types is useful for out-of-process TH currently used by GHCJS, possibly in the future for cross compilation (someone started porting the GHCJS code to GHC but appears to have stopped working on it, I hope i have time to pick this up soon) Using the default `Binary` instance based on the `GHC.Generics` is ok for this purpose and works for almost all types. Here is my list of orphan instances: https://github.com/ghcjs/ghcjs- prim/blob/915f263c06b7f4a246c6e02ecdf2b9a0550ed967/GHCJS/Prim/TH/Types.hs#L113-L166 `NameFlavour` requires a handwritten instance because of an `Int#` field. Can this be changed to a strict `Int` field? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 20:00:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 20:00:11 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.cf5b1e0b2c8682316df00d1eb68493c5@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9621 Test Case: | Blocking: | Differential Revisions: Phab:D209 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"ce23745147b9aab99187e266412efa27148a9b19/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ce23745147b9aab99187e266412efa27148a9b19" Generalise `Control.Monad.{foldM,foldM_}` to `Foldable` (#9586) With this change `Control.Monad.foldM` becomes an alias for `Data.Foldable.foldlM`. Reviewed By: austin, ekmett Differential Revision: https://phabricator.haskell.org/D251 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 20:14:11 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 20:14:11 -0000 Subject: [GHC] #9703: Add missing calling conventions to Template Haskell Message-ID: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> #9703: Add missing calling conventions to Template Haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Template Haskell only supports the `CCall` and `StdCall` calling conventions, while GHC supports more: http://git.haskell.org/packages/template- haskell.git/blob/9bcc122819a6f4a2ae7ad569717324b8368e801c:/Language/Haskell/TH/Syntax.hs#l1311 http://git.haskell.org/ghc.git/blob/7369d2595a8cceebe457a44c8400828f4df87ea0:/compiler/prelude/ForeignCall.lhs#l159 `CApiConv`, `PrimCallConv` and `JavaScriptCallConv` are missing, and I think they should just be added unless this is expected to lead to problems. I'd personally like to have `JavaScriptCallConv` so I can remove the horrible hacks to make ghcjs-ffiqq (https://github.com/ghcjs/ghcjs-ffiqq) work. I imagine that `PrimCallConv` would be useful for a package using a similar approach for high performance inline assembly or LLVM with quasiquotes. A small change in GHC required to convert the new constructors, and possibly to check if the required extension is enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 20:25:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 20:25:30 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.f29ca37f2140c44bdbef58fa5a3c3767@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think I've figured out what goes wrong here. As the comments in [https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/specialise/Specialise.lhs the source] explain, there's a certain amount of redundancy between type arguments and dictionary arguments in general. The algorithm therefore ignores the type arguments and focuses on the dictionary arguments. For GADTs, this is not good enough. In particular, we can get something that looks (for a different `isItSilly` definition than the one above) like {{{ GADTDict.isItSillyInt :: GADTDict.Silly GHC.Types.Int -> GADTDict.Silly GHC.Types.Int -> GADTDict.Silly GHC.Types.Int GADTDict.isItSillyInt = \ (ds_dsS :: GADTDict.Silly GHC.Types.Int) (ds1_dsT :: GADTDict.Silly GHC.Types.Int) -> case ds_dsS of _ { GADTDict.Silly $dNum_apb a_ao9 -> case ds1_dsT of _ { GADTDict.Silly $dNum1_apc x_aoa -> GADTDict.Silly @ GHC.Types.Int $dNum1_apc (GHC.Num.+ @ GHC.Types.Int $dNum1_apc a_ao9 x_aoa) } } }}} Here, the compiler doesn't (currently) know what `$dNum1_apc` is; it's something it pulled out of a GADT constructor. But there's more information available: the `GHC.Types.Int` argument forces `$dNum1_apc` to be the `Num` dictionary for `Int`! The fix, presumably, is to recognize when a known (or collected) type argument corresponds to an unknown dictionary?when this happens, replace the dictionary with the right one. What I don't know is whether the necessary information about the correspondence is still readily available at this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 20:46:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 20:46:34 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.c2b110009603ebded248a9aea6fcab28@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: carter MikeIzbicki | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Changes (by carter): * differential: => D350 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 21:07:08 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 21:07:08 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.ff710a101fd237c3f5b45243728ae022@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): What you want here has a number of problems. 1.) It conflicts with `IncoherentInstances` by randomly changing answers based on inlining. 2.) It doesn't really interact well with the notion of typechecking producing a witness that holds the elaborated code and just using the witness. 3.) We actually '''have''' to take the "nearest" instance when you bind instances in local scope. Why? `ImplicitParams` unfortunately exist. If you have `(?x :: Int)` in scope and you come across `let ?x = 12 :: Int in ...` you need to switch to the new witness of `(?x :: Int)`. The same should work if you open a `Dict (?x :: Int)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 21:18:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 21:18:05 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.c07c7415216dc4f2b23e5e5c7303cee7@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: carter MikeIzbicki | Status: patch Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Changes (by carter): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 21:34:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 21:34:45 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.0285cc286eec2ba3c3149f2ab8bcbf33@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): Reid Barton mentioned a fairly simple scheme of skimming the core looking for terms of type `C T` where you have an `instance C T` declaration in scope with no context, and replacing those terms with the dictionary for the witness. That could make cases like `Set`-carrying-a-dictionary-for-`Ord` optimizable for known instances. It'd be the most specific match, should win for `IncoherentInstances`, doesn't collide with the `(?x :: Int)` case. The trick then is selling an optimization for a style of code that currently doesn't get written. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 22:30:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 22:30:05 -0000 Subject: [GHC] #9704: GHC fails with "Loading temp shared object failed" Message-ID: <049.1e96b8f599d87115d367d6587554afa1@haskell.org> #9704: GHC fails with "Loading temp shared object failed" -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: 9074 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- While developing Yesod project on GHC 7.8.3, `cabal install --force- reinstalls` failed with the following error: {{{ [9 of 9] Compiling Application ( Application.hs, dist/dist-sandbox- e4ea4713/build/Application.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib, 9): Symbol not found: _aesonzm0zi8zi0zi1_DataziAesonziTypesziInternal_zdsfromList1_closure Referenced from: /var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib Expected in: flat namespace in /var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: MyBlog-0.0.0 failed during the building phase. The exception was: ExitFailure 1 }}} (Full output at https://gist.github.com/MaxGabriel/847561107e4ee2e869f1. Verbose output at https://gist.github.com/MaxGabriel/10c2c3c253815b3f392a) Following compilation, both aeson-0.8.0.1 and aeson-0.8.0.2 are present in the sandbox. Running `cabal install` again yields the same error (full output at https://gist.github.com/MaxGabriel/9aa530105d68a613de11). The code for the project as it was when the panic happened is available here: https://github.com/MaxGabriel/MyBlog-GHC-Panic Is there more information I could provide to diagnose the bug? I'll probably wipe the sandbox and try recompiling in a bit. Version info: OS : OS X 10.10 (14A389) (Yosemite) Cabal: cabal-install version 1.20.0.3 using version 1.20.0.1 of the Cabal library GHC: The Glorious Glasgow Haskell Compilation System, version 7.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 22:43:51 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 22:43:51 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.20b3cdb0224805645b25c12a7a3f49ca@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): The reason I set about this whole line of thinking was the fact that `Set` cannot implement an efficient `Data.Foldable.elem` method. Wrapping a `Set` in an `Ord`-carrying GADT would enable such a thing. Unfortunately, if the GADT blocks `Ord` specialization, everything will be rather slow: comparison operators will always be looked up in the dictionary the wrapper points to, and there will be no opportunity for inlining, etc. My position regarding Incoherent Instances (and DysFunctional Dependencies) is that if your program breaks when the compiler hands you a different dictionary than you expected, you get to keep both pieces?humans invented nasal demons for a reason. I'm much more open to arguments against this idea based on implementation complexity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 18 23:28:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Oct 2014 23:28:21 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.abed1d4646a0bcba696552cff7c00370@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I apologize for the terribly undiplomatic tone of my last message. Thinking over the matter some more, I believe that incoherent instances already interact about as badly as they can with GADTs. Specifically, consider what will happen when GADT values coming from two different modules and carrying incoherent instances come together?if I'm not mistaken, there's no way to predict which dictionary will be chosen for any given operation combining them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 02:09:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 02:09:32 -0000 Subject: [GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory In-Reply-To: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> References: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> Message-ID: <067.412fb3dce40ac602ab41780c89d84b26@haskell.org> #9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: | Owner: mergeconflict | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't think this is a big deal, but `throwErrnoIfRetryMayBlock` isn't getting inlined. It probably should get inlined. Also, there is a safe foreign import of `rtsSupportsBoundThreads` in GHC.IO.FD (and also some other module(s) in base), which seems quite unnecessary considering `rtsSupportsBoundThreads` simply returns a constant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 03:58:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 03:58:16 -0000 Subject: [GHC] #9704: GHC fails with "Loading temp shared object failed" In-Reply-To: <049.1e96b8f599d87115d367d6587554afa1@haskell.org> References: <049.1e96b8f599d87115d367d6587554afa1@haskell.org> Message-ID: <064.e4cd8347d0cbed71bdb65ed7785bb751@haskell.org> #9704: GHC fails with "Loading temp shared object failed" -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Compile- | Difficulty: Unknown time crash | Blocked By: Test Case: | Related Tickets: 9074 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by MaxGabriel: Old description: > While developing Yesod project on GHC 7.8.3, `cabal install --force- > reinstalls` failed with the following error: > > {{{ > [9 of 9] Compiling Application ( Application.hs, dist/dist-sandbox- > e4ea4713/build/Application.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.3 for x86_64-apple-darwin): > Loading temp shared object failed: > dlopen(/var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib, > 9): Symbol not found: > _aesonzm0zi8zi0zi1_DataziAesonziTypesziInternal_zdsfromList1_closure > Referenced from: > /var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib > Expected in: flat namespace > in > /var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > cabal: Error: some packages failed to install: > MyBlog-0.0.0 failed during the building phase. The exception was: > ExitFailure 1 > }}} > > (Full output at https://gist.github.com/MaxGabriel/847561107e4ee2e869f1. > Verbose output at > https://gist.github.com/MaxGabriel/10c2c3c253815b3f392a) > > Following compilation, both aeson-0.8.0.1 and aeson-0.8.0.2 are present > in the sandbox. Running `cabal install` again yields the same error (full > output at https://gist.github.com/MaxGabriel/9aa530105d68a613de11). > > The code for the project as it was when the panic happened is available > here: https://github.com/MaxGabriel/MyBlog-GHC-Panic > > Is there more information I could provide to diagnose the bug? > > I'll probably wipe the sandbox and try recompiling in a bit. > > Version info: > OS : OS X 10.10 (14A389) (Yosemite) > Cabal: cabal-install version 1.20.0.3 using version 1.20.0.1 of the Cabal > library > GHC: The Glorious Glasgow Haskell Compilation System, version 7.8.3 New description: While developing Yesod project on GHC 7.8.3, `cabal install --force- reinstalls` failed with the following error: {{{ [9 of 9] Compiling Application ( Application.hs, dist/dist-sandbox- e4ea4713/build/Application.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib, 9): Symbol not found: _aesonzm0zi8zi0zi1_DataziAesonziTypesziInternal_zdsfromList1_closure Referenced from: /var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib Expected in: flat namespace in /var/folders/qk/6s42bj3n6g30fyqf6mc2x_c80000gn/T/ghc13386_0/ghc13386_53.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: MyBlog-0.0.0 failed during the building phase. The exception was: ExitFailure 1 }}} (Full output at https://gist.github.com/MaxGabriel/847561107e4ee2e869f1. Verbose output at https://gist.github.com/MaxGabriel/10c2c3c253815b3f392a) Following compilation, both aeson-0.8.0.1 and aeson-0.8.0.2 are present in the sandbox. Running `cabal install` again yields the same error (full output at https://gist.github.com/MaxGabriel/9aa530105d68a613de11). The code for the project as it was when the panic happened is available here: https://github.com/MaxGabriel/MyBlog-GHC-Panic Is there more information I could provide to diagnose the bug? I'll probably wipe the sandbox and try recompiling in a bit. Version info: OS : OS X 10.10 (14A389) (Yosemite) Cabal: cabal-install version 1.20.0.3 using version 1.20.0.1 of the Cabal library GHC: The Glorious Glasgow Haskell Compilation System, version 7.8.3 Edit: Probably relevant that the original package set was compiled under OS X 10.9 (Mavericks). The reinstall that triggered the panic was under Yosemite. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 05:07:26 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 05:07:26 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.442677d2e0ac81299a2fecf995b7bcd1@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: carter MikeIzbicki | Status: patch Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Comment (by carter): So one complication that came up is that to provide the refitted pure prefetch operations as a naive primop is that the types need to be of the shape ` Addr# -> Int# -> a -> (# a #)` For some reason, the more "obvious" type ` Addr# -> Int# -> a -> a` will make GHC panic! Looking at how seq is defined, another option to consider would be to take a page from seq and define the prefetch operations in the pseudo op style like seq, ie `prefetchSeq addr offset b = case prefetch# addr offset of _ -> b` This would allow giving it the type `Addr# -> Int# -> a -> a`, with the prefetch# operation itself then having a type like `Addr# -> Int# -> State#` and the `has_side_effects=True` attribute Luite has helped sketch out this new design, and has pointed out how the semantics of touch# and seq and seq# relate to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 05:07:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 05:07:42 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.c52ccb9dafaf3a18beee31411286b886@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: patch Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Changes (by carter): * owner: carter => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 05:08:10 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 05:08:10 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.a858b514a22aae2657b409bfa45b5c28@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: infoneeded Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Changes (by carter): * status: patch => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 05:08:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 05:08:24 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.fde8e7498c1231fbc449cfaf0b40c8ca@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Changes (by carter): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 05:09:14 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 05:09:14 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.d880a375497dc1db4e6cb1470638b7a3@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: carter MikeIzbicki | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Changes (by carter): * owner: => carter Comment: I'll get the ball rolling on this new crazy candidate design and then try to collect some feedback -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 09:51:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 09:51:40 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict In-Reply-To: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> References: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> Message-ID: <059.ebdca5872a0d687257da6deb2fc1ed73@haskell.org> #9038: Foreign calls don't make their arguments look strict -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 1592 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): I might have been mistaken. I read the core for `add3` above and assumed that since `add3` isn't worker-wrappered the argument wouldn't be unboxed. I tried calling add3 (which is really the `System.Metrics.Distribution.add` function in the ekg-core package) function in this little test program {{{ module Test where import System.Metrics.Distribution test :: Distribution -> IO () test distrib = add distrib 1.0 }}} and things seem to be unboxed correctly. Here's the demand signature for `add3`: {{{ add3 :: Distribution -> Double -> Int64 -> State# RealWorld -> (# State# RealWorld, () #) [GblId, Arity=4, Caf=NoCafRefs, Str=DmdType , Unf=Unf{Src=, TopLvl=True, Arity=4, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 20 20 0] 156 30}] }}} How do I read the `DmdType ` line? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 11:41:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 11:41:15 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.e3cd358c3cd2b7839f57c825ec1aadf3@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D310 | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"d576fc38d9493c4979217fa36565f1f97fcc03d4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d576fc38d9493c4979217fa36565f1f97fcc03d4" Python 3 support, second attempt (Trac #9184) Summary: This is a fixup of https://phabricator.haskell.org/D233 The only difference is in findTFiles (first commit), which previously broke Windows runner; now I translated literally instead attempting to improve it, and checked it works. Test Plan: I used validate under 2,3 on Linux and under 2 on msys2. On Windows I've seen a large number of failures, but they don't seem to be connected with the patch. Reviewers: hvr, simonmar, thomie, austin Reviewed By: austin Subscribers: thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D310 GHC Trac Issues: #9184 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 12:28:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 12:28:37 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.bf45210a8596d05d29839317568426ae@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: python System | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D310 | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 13:01:30 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 13:01:30 -0000 Subject: [GHC] #670: External Core is broken In-Reply-To: <055.88b18fc8f73ea51f6e466f3eaf31b0f4@haskell.org> References: <055.88b18fc8f73ea51f6e466f3eaf31b0f4@haskell.org> Message-ID: <070.d152adc0acfcd6d42be86b9267d52073@haskell.org> #670: External Core is broken -------------------------------------+------------------------------------- Reporter: | Owner: tim KirstenChevalier | Status: closed Type: bug | Milestone: ? Priority: normal | Version: 6.8.2 Component: External | Keywords: Core | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => wontfix Comment: External Core was removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 13:14:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 13:14:05 -0000 Subject: [GHC] #9705: Panic on a pattern synonym in a class Message-ID: <047.614ec39c173b8238a9064e76b118d842@haskell.org> #9705: Panic on a pattern synonym in a class -------------------------------------+------------------------------------- Reporter: monoidal | 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: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This silly code causes a panic in rnMethodBind: {{{#!hs {-# LANGUAGE PatternSynonyms #-} class C a where pattern P = () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 13:22:12 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 13:22:12 -0000 Subject: [GHC] #8752: System.FilePath.Windows.combine does not really check isAbsolute In-Reply-To: <047.ba20b266365045acfd96ace488f847bb@haskell.org> References: <047.ba20b266365045acfd96ace488f847bb@haskell.org> Message-ID: <062.b5b3faa7318c271cebbc2f131ddbdda6@haskell.org> #8752: System.FilePath.Windows.combine does not really check isAbsolute -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: filepath Resolution: duplicate | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => duplicate Comment: I've migrated this ticket to https://github.com/haskell/filepath/issues/8, where it will be dealt with outside GHC, and then picked up by GHC when next merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 13:26:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 13:26:07 -0000 Subject: [GHC] #9594: Cleanup of filepath package In-Reply-To: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> References: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> Message-ID: <060.09b117ae212e7e97530525575e58a6d0@haskell.org> #9594: Cleanup of filepath package -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: upstream Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: filepath Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8752 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): I see no reason to keep this ticket here - I suggest we close it and deal with it exclusively on GitHub. It's not really of any interest to GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 13:34:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 13:34:09 -0000 Subject: [GHC] #3543: -fext-core doesn't force recompilation when .hcr file doesn't exist In-Reply-To: <042.a500bc81bb090118bd5e70ada170bc6f@haskell.org> References: <042.a500bc81bb090118bd5e70ada170bc6f@haskell.org> Message-ID: <057.3019f7a9deec341360bfe16d57b987c1@haskell.org> #3543: -fext-core doesn't force recompilation when .hcr file doesn't exist -------------------------------------+------------------------------------- Reporter: tim | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.10.1 Component: Driver | Version: 6.10.4 Resolution: wontfix | 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 monoidal): * status: new => closed * resolution: => wontfix Comment: External Core was removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 13:35:42 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 13:35:42 -0000 Subject: [GHC] #9309: Regression when building the 'sizes' application In-Reply-To: <050.a610423a5d1a3ce9edd234ea9f668bd9@haskell.org> References: <050.a610423a5d1a3ce9edd234ea9f668bd9@haskell.org> Message-ID: <065.9fd68cc253bbbacfd9a2f3271f646285@haskell.org> #9309: Regression when building the 'sizes' application -------------------------------------+------------------------------------- Reporter: | Owner: JohnWiegley | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: wontfix | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => wontfix Comment: External Core was removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 13:43:44 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 13:43:44 -0000 Subject: [GHC] #9594: Cleanup of filepath package In-Reply-To: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> References: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> Message-ID: <060.f176c23d06ffba21946415927849dea0@haskell.org> #9594: Cleanup of filepath package -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: upstream Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: filepath Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8752 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): The only thing I think may be of interest to GHC's release-plans is to have those "2 tiny bug fixes" available by the time GHC 7.10.1 gets released. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 13:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 13:45:32 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.65374348371fb43ce84471af2f2822a4@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:6 dfeuer]: > Thinking over the matter some more, I believe that incoherent instances already interact about as badly as they can with GADTs. Specifically, consider what will happen when GADT values coming from two different modules and carrying incoherent instances come together?if I'm not mistaken, there's no way to predict which dictionary will be chosen for any given operation combining them. And you don't even need `-XIncoherentInstances` to cause this problem -- orphan instances are enough. Yes, you're right in that you can unpack two different instances from GADTs, and it's a tossup as to which one gets used. See #8338. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 14:24:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 14:24:23 -0000 Subject: [GHC] #9594: Cleanup of filepath package In-Reply-To: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> References: <045.7967cacd946a62c1d15a0c766e186a82@haskell.org> Message-ID: <060.00b60e36971146e9473a5ab3065d7fb1@haskell.org> #9594: Cleanup of filepath package -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: upstream Priority: normal | Milestone: Component: Core | Version: 7.9 Libraries | Keywords: filepath Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8752 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): The two tiny bug fixes are fairly minor in nature (shipping GHC 7.10.1 without them wouldn't be the end of the world) and they should be fixed within a week or so.[[Image()]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 15:48:48 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 15:48:48 -0000 Subject: [GHC] #9010: TemplateHaskell leads to an "unknown symbol" error In-Reply-To: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> References: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> Message-ID: <063.89c27bec4675dd2c3e89e434410d5cbb@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): Is there any workaround at all for 7.6.3? We're currently hitting this from new Yi dependency (bug filed with library author at https://github.com/Aelve/charsetdetect-ae/issues/1) and I would hate to find out it's ?don't use this library or drop support for 7.6.3?, especially considering there aren't exactly many alternative libraries for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 16:45:09 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 16:45:09 -0000 Subject: [GHC] #7170: Foreign.Concurrent finalizer called twice in some cases In-Reply-To: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> References: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> Message-ID: <063.9c6aa4465491c3ab10f4892484fd8dcc@haskell.org> #7170: Foreign.Concurrent finalizer called twice in some cases -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | ffi/should_run/7170 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by arybczak): * cc: hvr, ekmett (added) * owner: simonmar => * status: closed => new * resolution: fixed => * version: 7.4.2 => 7.8.3 Comment: This is still happening, albeit is much harder to reproduce (I wasn't able to write simple testcase for that). Steps to reproduce (hopefully): 1. git clone https://github.com/scrive/hpqtypes.git 2. git checkout 8b4d57876dc573759c2935064306806b793844c5 (this is the last commit before the workaround I applied to solve the issue) 3. git apply custom_finalizer.diff (to be sure it's haskell that tries to free the same memory twice) 4. Change tests/Main.hs to the following code: {{{ module Main where import Control.Applicative import Control.Concurrent import Control.Exception import Control.Monad import Debug.Trace import System.Environment import qualified Data.ByteString.Char8 as BS import Database.PostgreSQL.PQTypes mkConnSource :: String -> ConnectionSource mkConnSource ci = defaultSource $ defaultSettings { csConnInfo = BS.pack ci } main :: IO () main = do cs <- mkConnSource . head <$> getArgs let dts = defaultTransactionSettings flip finally (runDBT cs dts $ return ()) $ do void . forkIO $ do forM_ [1..100000::Int] $ \n -> trace (show n) $ return () return () threadDelay 1000000 }}} 4. cabal sandbox init 5. cabal install --dependencies-only 6. cabal configure -ftests --ghc-options="-O0" 7. cabal build 8. cd dist/build/tests 9. valgrind ./tests user=postgres The last step must be repeated a couple of times to get the error we are interested in. I attach the output of running it on my machine (valgrind- output.txt). If you look at the output file, at line 1112 I pressed Ctrl-C to interrupt the program, then the finalizer was called for the first time at line 1880 and then for the second time at line 2255, which results in tons of output from valgrind about invalid reads of already freed memory. Relevant file: https://github.com/scrive/hpqtypes/blob/8b4d57876dc573759c2935064306806b793844c5/src/Database/PostgreSQL/PQTypes/Internal/Connection.hs runDBT calls withConnection of the defaultSource (line 89), which is a simple wrapper for {{{bracket connect disconnect}}}. In disconnect (line 152) the destruction of the database connection is forced by calling finalizeForeignPtr. When finalizeForeignPtr is removed, the bug disappears. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 17:27:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 17:27:39 -0000 Subject: [GHC] #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate In-Reply-To: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> References: <046.0473c92f4a34c84959f5237ada18226b@haskell.org> Message-ID: <061.794665771178dd19cb2b46b0b7b0e0cc@haskell.org> #3927: Incomplete/overlapped pattern warnings + GADTs = inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #4139 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by vlopez): * cc: victor@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 17:50:58 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 17:50:58 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.475301f6891caa0ee4959c7b48fc9853@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 dfeuer]: > The algorithm therefore ignores the type arguments and focuses on the dictionary arguments. I just re-read the comment, and I see that I read it wrong. It actually does look at the type arguments, but then it seems to miss the opportunity to grab a better dictionary. I'm not sure why that is yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 20:43:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 20:43:17 -0000 Subject: [GHC] #9010: TemplateHaskell leads to an "unknown symbol" error In-Reply-To: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> References: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> Message-ID: <063.859f2d0e7b64c89fa418909cef0e9adc@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I suggested some hacks at http://stackoverflow.com/a/26454930/190376. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 21:47:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 21:47:13 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.aa5c9b9fde4880f80830acaaf7b95f7d@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 ekmett]: > 3.) We actually '''have''' to take the "nearest" instance when you bind instances in local scope. Why? `ImplicitParams` unfortunately exist. > > If you have `(?x :: Int)` in scope > > and you come across `let ?x = 12 :: Int in ...` you need to switch to the new witness of `(?x :: Int)`. > > The same should work if you open a `Dict (?x :: Int)`. What am I missing here? Core distinguishes dictionaries that came from type classes from implicit parameters, doesn't it? If someone decides to implement some sort of local instance extension, as suggested by [http://okmij.org/ftp/Haskell/tr-15-04.pdf Oleg Kiselyov and Chung-chieh Shan], some restrictions are required to make anything work (as discussed in the paper). I believe the restrictions they describe would probably skirt the problem you consider, because (if my vague understanding is sufficiently correct) the types won't match where the dictionary replacement would be problematic. Also, I realized today that things can be simplified some more, and perhaps in a way you might find more convincing: {{{#!hs data Silly a where Silly :: Num a => a -> Silly a potato :: Int -> Silly Int -> Int potato x (Silly _) = x + x }}} Even here, `potato` uses the dictionary it takes from `Silly`. If there were incoherent instances in the air, this would not really be a result to be proud of. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 19 22:30:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Oct 2014 22:30:38 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.4ae9748ae6add68e6d4c9581cda07876@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I just realized that you might not find that example as convincing as this one: {{{#!hs data Silly a where Silly :: Num a => a -> Silly a double :: Int -> Int double n = n + n oops :: Silly Int -> Int oops (Silly x) = double x }}} Now if `double` gets inlined, it will use the `Num` dictionary from `Silly`, but if it's not inlined, it will use the usual one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 00:32:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 00:32:42 -0000 Subject: [GHC] #9703: Add missing calling conventions to Template Haskell In-Reply-To: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> References: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> Message-ID: <059.7e8a281efe32767c314fa89a06f950b1@haskell.org> #9703: Add missing calling conventions to Template Haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D353 | -------------------------------------+------------------------------------- Changes (by cmsaperstein): * differential: => D353 Comment: I've written a patch for this at https://phabricator.haskell.org/D353 (thanks to Carter for helping me with my first patch!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 04:13:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 04:13:28 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.5b1c7cc1bbc60770da7af6e78ac7d5e2@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * cc: petersen@? (removed) * cc: petersen (added) Comment: Thanks lukexi! That sounds great! Anyway I reported the current problems with building ghc-7.8.3 on aarch64 earlier in #9673. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 05:26:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 05:26:12 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.5fd815bb4c4d2858c82e2094810ac0f2@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): the main patch seem to be https://github.com/lukexi/llvm/commit/dfe74bb48eb05ce7847fa262f6e563d20d0b1fc5 and https://github.com/lukexi/ghc/commit/a80f4aa45d03caf72289d759c80c6490b20e7099 I'll try to have a read through when I have some time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 06:48:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 06:48:02 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit Message-ID: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | 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 was having some discussion about GHC's block structured heap with Sergio Benitez and Adam Belay, and during the discussion it was suggested that the way GHC manages the block structured heap is suboptimal when we're on 64-bit architectures. At the moment, we allocate memory from the operating system per-megablock, storing metadata in the very first megablock. We have to do this because, on 32-bit, we can't generally be too picky about what address our memory ends up living. On 64-bits, we have a lot more flexibility. Here is the proposal: 1. Statically decide on a maximum heap size in a power of two. 2. Next, probe for some appropriately aligned chunk of available virtual address space for this. On POSIX, we can mmap /dev/null using PROT_NONE and MAP_NORESERVE. On Windows, we can use VirtualAlloc with MEM_RESERVE. (There are few other runtimes which do this trick, including GCC Go.) 3. Divide this region into blocks as before. The maximum heap size is now the megablock size, and the block size is still the same as before. Masking to find the block descriptor works as before. 4. To allocate, we keep track of the high-watermark, and mmap in 1MB pages as they are requested. We also keep track of how much metadata we need, and mmap extra pages to store metadata as necessary. We still want to request memory from the operating system in conveniently sized chunks, but we can now abolish the notion of a megablock and the megablock allocator, and work purely with block coalescing. Additionally, the recorded heap location means that we can check if a pointer is HEAP_ALLOCED using a mask and equality check, solving #8199. What do people think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 07:55:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 07:55:46 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.05009cd19e7505ad9748c0e77ac33c99@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by simonpj): Well done for making progress. Some thoughts * If the patch is ready for review, is [wiki:GhcAstAnnotations] also fully up to date? Could you move any discussion of alternatives to the end, under "Other possible design alternatives" so that what remains is actually a description of the feature you propose, and a sketch of its implementation? I'm unsure about which bits of the wiki page are rejected ideas and which are the ones you adopted. * Floating around is also `ExtraCommas`. I think the two are somewhat orthogonal, right? * Does your design say where comments are? That is, can you really round-trip source code? In particular, an excellent criterion could be: can you do Haddock this way? Currently Haddock has a lot of Haddock-specific fields in HsSyn. Could they all be replaced with annotations in your style? If not, what would take to make that possible? It would be highly cool; after all, Haddock may be privileged, but the more we can make it possible for others to do Haddock-like things without changing GHC itself, the better. * You outlined a number of "customers" in an earlier post. Would it be worth adding them to the wiki page? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 08:04:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 08:04:25 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.3be20b699e84fc48b76c1c5eb1c4ffcd@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Implicit parameters. They are indeed treated specially. In particular, the example in comment:10 for implicit parameters would look like this: {{{ data SillyIP a where Silly :: ?plus::(a->a->a) => a -> Silly a -- Inferred type -- double :: (?plus :: Int -> Int -> Int) => Int -> Int double n = ?plus n (n::Int) oops :: Silly Int oops (Silly x) = double x }}} There are no top-level implicit parameters, so `double`'s inferred type is as shown, and it'll pick up `plus` from the `Silly` pattern match. Reverting to the main thread, I'm not sure where this discussion is going. The base assumption is if multiple type-class instances match (e.g. from two enclosing pattern matches, comment:2, or from an enclosing patten- match and the top level) then you are on terribly thin ice is you want to predict which one will be chosen. They are all supposed to have the same value, and if they don't then, well, the ice is thin. One could try to thicken up the ice here, but it's all tangled up with the scoping of instances, overlapping instances, incoherent instances etc... My take on this: brain cycles are more productively invested elsewhere. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 08:13:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 08:13:22 -0000 Subject: [GHC] #9639: Remove OldTypeable In-Reply-To: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> References: <046.8b4654bd53af2f302590920cbcb3a261@haskell.org> Message-ID: <061.cf5e14424bd5fa000e4c04583c4e981e@haskell.org> #9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Typeable Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D311 | -------------------------------------+------------------------------------- Comment (by dreixel): And thanks @mgmeier! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 08:31:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 08:31:59 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.6f6a3c1fdca3f694beb9431e87c78338@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Sounds plausible to me, but what is the benefit? We seem to get * More complicated code (since we still need the megablocks for 32-bit) in exchange for... what? I'm sure there is something, but it would be worth making the cost/benefit tradeoff explicit. Also, as 32-bit architectures wane, would there be a simpler but perhaps- less-performant fallback that would allow the code to be simplified for all architectures? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 09:12:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 09:12:14 -0000 Subject: [GHC] #9705: Panic on a pattern synonym in a class In-Reply-To: <047.614ec39c173b8238a9064e76b118d842@haskell.org> References: <047.614ec39c173b8238a9064e76b118d842@haskell.org> Message-ID: <062.6a193fb97f78f9f87abb87ce97f29404@haskell.org> #9705: Panic on a pattern synonym in a class -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => cactus -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 09:29:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 09:29:34 -0000 Subject: [GHC] #9684: Broken build on OS X (incompatible pthread_setname_np API) In-Reply-To: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> References: <043.1e2e2fbfee985b050dd237895e77b910@haskell.org> Message-ID: <058.801f5729c6c20cb31255fd0c58b903d2@haskell.org> #9684: Broken build on OS X (incompatible pthread_setname_np API) -------------------------------------+------------------------------------- Reporter: mlen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: MacOS X | pthread_setname_np Type of failure: Building | Architecture: Unknown/Multiple GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | Phab:rGHC674c631ea111233daa929ef63500d75ba0db8858,| Phab:D338 | -------------------------------------+------------------------------------- Changes (by mlen): * status: patch => closed * resolution: => fixed Comment: This issue got fixed in 1c35f9f1cb7a293da85d649904ce731a65824cfe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 09:30:08 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 09:30:08 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict In-Reply-To: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> References: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> Message-ID: <059.b8cb5052643f57e9733743906e99f44e@haskell.org> #9038: Foreign calls don't make their arguments look strict -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 1592 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): The notation is ``. SO `` means a lazy arg. So `add3` takes its argument boxed. What I'm missing is a (preferably small) test case in which something isn't unboxed that should be. The one you gave me in comment:4 appears to be fine. Do you have in mind another one that isn't? I suppose I could install ekg etc, if that is necessary. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 10:06:00 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 10:06:00 -0000 Subject: [GHC] #9445: GHC Panic: Tick Exhausted with high factor In-Reply-To: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> References: <048.2f7a5a45710d5090cd0ab03dfe2b8b18@haskell.org> Message-ID: <063.c4dfeca4f75b578a18e7dbddee5a6c21@haskell.org> #9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: panic Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: 5539 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Masei): The error seems to be caused by the Num instance. abs needs a tick-factor of 109 and signum a factor of 1630. Disabling rewrite-rules (-fno-enable-rewrite-rules) let it compile again. I peek at the ghc-source but don't found any related rules. Hope it helps anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 11:32:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 11:32:09 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.d247355e91be0add836e2d693ab8ed60@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:11 simonpj]: > Reverting to the main thread, I'm not sure where this discussion is going. The base assumption is if multiple type-class instances match (e.g. from two enclosing pattern matches, comment:2, or from an enclosing patten-match and the top level) then you are on terribly thin ice is you want to predict which one will be chosen. They are all supposed to have the same value, and if they don't then, well, the ice is thin. Edward Kmett raised two concerns about the sort of specialization I was trying to accomplish: that it would break implicit parameters in some fashion and that it would break incoherent instances, I was attempting to allay those concerns, the latter by showing that the incoherent ice is so thin it's just not worth worrying about?there's so little exploitable predictability about it that we shouldn't worry about making it less predictable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 14:44:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 14:44:56 -0000 Subject: [GHC] #3658: Dynamically link GHCi (and use system linker) on platforms that support it In-Reply-To: <047.129d39e2608fc274aa7ba90c094c6a82@haskell.org> References: <047.129d39e2608fc274aa7ba90c094c6a82@haskell.org> Message-ID: <062.aa874b84ac4aab5b47b0359d31cdc85c@haskell.org> #3658: Dynamically link GHCi (and use system linker) on platforms that support it -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 6.10.4 Resolution: fixed | Keywords: dynamic link Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 1883, | 3242, 3372, 3654, 4244, 5062, | 5197, 6107, 7072, 7103, 7316, | 7389, 7475, 7687 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 Comment: Moving out of 7.8.4 milestone, since it's not really appropriately 'fixed' here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 14:46:45 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 14:46:45 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.bab7ac258825e2ec1c5f0955e65860e2@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9377 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 14:48:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 14:48:23 -0000 Subject: [GHC] #9398: Data.List.cycle is not a good producer In-Reply-To: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> References: <045.1b2fc7c8519fc15639afaf38f848b8de@haskell.org> Message-ID: <060.0b99d27371aeae0e82c054b42763e956@haskell.org> #9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: invalid | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 14:48:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 14:48:31 -0000 Subject: [GHC] #9369: Data.List.unfoldr does not fuse and is not inlined. In-Reply-To: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> References: <045.65901b8a1240e07f02cfac5fc52d9428@haskell.org> Message-ID: <060.86edcf103051c082af5cd473b5565295@haskell.org> #9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D198 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 14:48:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 14:48:47 -0000 Subject: [GHC] #9355: scanr does not participate in stream fusion In-Reply-To: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> References: <045.78e20f25bbc7f21106375cbee9bcd2e6@haskell.org> Message-ID: <060.e1612c2f671e19b6a8154e160bad3d59@haskell.org> #9355: scanr does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 14:48:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 14:48:59 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.7d06f1c267d9a7fac543d770592792c1@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D329 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 14:49:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 14:49:09 -0000 Subject: [GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci In-Reply-To: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> References: <053.f3cac954424b7de2fe1d49fbb5a71e9a@haskell.org> Message-ID: <068.d5607fd1aabc8ad33941d384110e4d0a@haskell.org> #9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: | Owner: artella.coding | Status: closed Type: bug | Milestone: 7.10.1 Priority: high | Version: 7.8.3 Component: GHCi | Keywords: ghci, strict, Resolution: fixed | memory Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 14:58:04 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 14:58:04 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.f679443284e45c0ce817cbe5daeb1532@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: | Version: 7.8.3 libraries/base | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 14:58:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 14:58:19 -0000 Subject: [GHC] #9529: Clean up cseProgram In-Reply-To: <045.1dfdc10036ea0fb30db7b134a1baa1ca@haskell.org> References: <045.1dfdc10036ea0fb30db7b134a1baa1ca@haskell.org> Message-ID: <060.d653783091dc79ce34d460a243b722d3@haskell.org> #9529: Clean up cseProgram -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 14:58:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 14:58:23 -0000 Subject: [GHC] #9536: Implement foldr/cons/build In-Reply-To: <045.6ebfec57f4d10be70298126e95b3e1e6@haskell.org> References: <045.6ebfec57f4d10be70298126e95b3e1e6@haskell.org> Message-ID: <060.4bd304aa8566a59d7a304046d2181951@haskell.org> #9536: Implement foldr/cons/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: | Version: 7.9 libraries/base | Keywords: fusion Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 14:58:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 14:58:32 -0000 Subject: [GHC] #9561: Clean up mergeSATInfo In-Reply-To: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> References: <045.e75f4cf175b68122b78f890c1d8597ac@haskell.org> Message-ID: <060.ad10a30864ddf47aa6f82cb4682b3665@haskell.org> #9561: Clean up mergeSATInfo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 15:01:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 15:01:44 -0000 Subject: [GHC] #9658: Prettyprint constraints in type signatures can omit necessary parentheses In-Reply-To: <051.729c40b7d3b349724f12a1d337527b9b@haskell.org> References: <051.729c40b7d3b349724f12a1d337527b9b@haskell.org> Message-ID: <066.e8c9e96478a409e5009a0017a1a31dde@haskell.org> #9658: Prettyprint constraints in type signatures can omit necessary parentheses -------------------------------------+------------------------------------- Reporter: | Owner: Blaisorblade | Status: merge Type: bug | Milestone: 7.8.4 Priority: low | Version: 7.8.3 Component: GHCi | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Other | Blocked By: Test Case: | Related Tickets: ghci/scripts/T9658 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 15:02:19 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 15:02:19 -0000 Subject: [GHC] #6086: Cross compilation fails using system linker for other architecture binaries In-Reply-To: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> References: <043.597b6a123ebadb92a7c782d400e2185e@haskell.org> Message-ID: <058.a6cdc64ffdaa8b18af601f7352eb7d4d@haskell.org> #6086: Cross compilation fails using system linker for other architecture binaries ----------------------------------------------+--------------------------- Reporter: mtjm | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Build System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ----------------------------------------------+--------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 15:48:44 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 15:48:44 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.7436ad9f02686ad27427ccedf9e7f078@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): There are two parts to this: 1. put all the heap memory together in the address space 2. change where we put the block descriptors Let's just worry about (1) for now. * Windows doesn't overcommit, so we can't do this on Windows * How do we decide what the max heap size should be? Total mem + swap? * I'm worried about the overhead of having to pre-allocate a large number of page tables for the reserved address space * Every Haskell process would show a ridiculous VSIZE Still, from a purely selfish perspective, for those on 64-bit Linux this might make sense and I'd be happy to take that 8% GC win for very little effort, even if it is non-portable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 15:58:13 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 15:58:13 -0000 Subject: [GHC] #9699: TH function to list names in scope In-Reply-To: <050.e1a7513209ad9375a0ec4688679fe797@haskell.org> References: <050.e1a7513209ad9375a0ec4688679fe797@haskell.org> Message-ID: <065.ae576f4663d9b03a78f622b23c9f4ec5@haskell.org> #9699: TH function to list names in scope -------------------------------------+------------------------------------- Reporter: | Owner: MikeIzbicki | Status: new Type: feature | Milestone: request | Version: 7.8.3 Priority: normal | Keywords: Component: Template | Architecture: Unknown/Multiple Haskell | Difficulty: Unknown Resolution: | Blocked By: Operating System: | Related Tickets: Unknown/Multiple | Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed it would not be hard. I'd be open to patches. There are open design questions. Do you mean "all names in scope" (including imported ones)? There may be a lot of those. Or just those bound in this module? Or just those bound by nested (non-top-level) definitions? Moreover, although, say `Data.List.partition` may not be ''lexically'' in scope, it's fine to generate a TH program that refers to it, thus: {{{ module Foo where import Bar( bar ) f x = $(bar 5) }}} where `bar` is a TH function in another module `Bar` where `Data.List.partition` is in scope, and `(bar 5)` expands to code mentioning `partition`. So, is `Data.List.partition` "in scope"? As ever, getting the specification right (and precise) is a big part of the work! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 16:02:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 16:02:07 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.826df7bf0b79eaaeed2617b1f0b42c4d@haskell.org> #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): Re comment:89 and comment:90 I'm struggling with limited personal bandwidth, and daunted by the challenge of giving a tutorial about the type inference engine, which is one of the most complex parts of GHC. Let me make this offer. If you do the rest, I'll do the bit in the type inference engine that exploits injectivity. It won't take long, and then you can see. Decomposition in brief. If you want `Maybe a ~ Maybe b` then it's enough to prove `a ~ b`. From a proof of the latter we can get a proof of the former. No more than that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 16:15:25 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 16:15:25 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.bc868abdad754e2d977f51b3b9a5dc54@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:2 simonmar]: > * Windows doesn't overcommit, so we can't do this on Windows From [http://msdn.microsoft.com/en- us/library/windows/desktop/aa366887%28v=vs.85%29.aspx the documentation for VirtualAlloc] it seems like it's possible to first reserve a memory range with `MEM_RESERVE` and then commit it as needed with `MEM_COMMIT`. [http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx This article] confirms it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 17:06:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 17:06:11 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.d01002382bfee303ee1059373dabaa8d@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): You mention that GCC Go does this. Is there any other prior art? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 17:11:01 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 17:11:01 -0000 Subject: [GHC] #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` Message-ID: <042.122e93bc881743490b8e64ec2198c257@haskell.org> #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | 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: -------------------------------------+------------------------------------- comment:ticket:9111:16 explains that import-cycles containing `Data.Typeable.Internal` (which provides the `Typeable` class `AutoDeriveTypeable` needs to be loaded for being able to operate) inside `base` make it difficult to use `AutoDeriveTypeable`, as well as making it more difficult to de-cycle the `base` import-dependency graph (see also attachment:typeable_deps.pngtypeable_deps.png) This ticket is about trying to find a way to restructure `base` in order to allow to define the `Typeable` instances directly at the type's defining site (and thus allow the use of `AutoDeriveTypeable`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 17:12:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 17:12:32 -0000 Subject: [GHC] #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` In-Reply-To: <042.122e93bc881743490b8e64ec2198c257@haskell.org> References: <042.122e93bc881743490b8e64ec2198c257@haskell.org> Message-ID: <057.577502fd7654aa040fe51f84817ad9be@haskell.org> #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: Libraries | Keywords: Typeable Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9111 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) * component: Compiler => Core Libraries * related: => #9111 * difficulty: Unknown => Difficult (2-5 days) * version: 7.8.3 => * keywords: => Typeable * milestone: => 7.12.1 * owner: => ekmett -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 17:14:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 17:14:23 -0000 Subject: [GHC] #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` In-Reply-To: <042.122e93bc881743490b8e64ec2198c257@haskell.org> References: <042.122e93bc881743490b8e64ec2198c257@haskell.org> Message-ID: <057.fdb833013f3393d61dff57c0ec57b0cb@haskell.org> #9707: (Try to) restructure `base` to allow more use of `AutoDeriveTypeable` -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Core | Version: Libraries | Keywords: Typeable Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Difficult (2-5 Unknown/Multiple | days) Type of failure: | Blocked By: None/Unknown | Related Tickets: #9111 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > comment:ticket:9111:16 explains that import-cycles containing > `Data.Typeable.Internal` (which provides the `Typeable` class > `AutoDeriveTypeable` needs to be loaded for being able to operate) inside > `base` make it difficult to use `AutoDeriveTypeable`, as well as making > it more difficult to de-cycle the `base` import-dependency graph (see > also attachment:typeable_deps.pngtypeable_deps.png) > > This ticket is about trying to find a way to restructure `base` in order > to allow to define the `Typeable` instances directly at the type's > defining site (and thus allow the use of `AutoDeriveTypeable`) New description: comment:ticket:9111:16 explains that import-cycles containing `Data.Typeable.Internal` (which provides the `Typeable` class `AutoDeriveTypeable` needs to be loaded for being able to operate) inside `base` make it difficult to use `AutoDeriveTypeable`, as well as making it more difficult to de-cycle the `base` import-dependency graph (see also attachment:typeable_deps.png) This ticket is about trying to find a way to restructure `base` in order to allow to define the `Typeable` instances directly at the type's definition site (and thus allow the use of `AutoDeriveTypeable`) Removing cycles in `base` is possibly required to make SplitBase easier -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 17:27:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 17:27:28 -0000 Subject: [GHC] #9703: Add missing calling conventions to Template Haskell In-Reply-To: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> References: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> Message-ID: <059.56ba064bdac4900b81eb7521a5f3dff4@haskell.org> #9703: Add missing calling conventions to Template Haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D353 | -------------------------------------+------------------------------------- Comment (by mtolly): Just reported this a bit ago :) https://ghc.haskell.org/trac/ghc/ticket/9694 I'll close my issue and point to this one, but one extra thing I did suggest in my issue: would there be a problem in adding a flexible constructor that takes a String? Since the FFI report suggests that implementations are free to add new callconvs as necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 17:30:14 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 17:30:14 -0000 Subject: [GHC] #9694: Template Haskell: support other FFI calling conventions In-Reply-To: <045.6b172d0b0b38c5a76b456a5bc0cd0802@haskell.org> References: <045.6b172d0b0b38c5a76b456a5bc0cd0802@haskell.org> Message-ID: <060.51f9963d204874cb1a182aaa1668af44@haskell.org> #9694: Template Haskell: support other FFI calling conventions -------------------------------------+------------------------------------- Reporter: mtolly | Owner: Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.3 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: duplicate | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by mtolly): * status: new => closed * resolution: => duplicate Comment: Duplicated by https://ghc.haskell.org/trac/ghc/ticket/9703 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 17:46:09 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 17:46:09 -0000 Subject: [GHC] #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 In-Reply-To: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> References: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> Message-ID: <058.be6519924500e5574adce7e76debbf34@haskell.org> #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 -------------------------------------+------------------------------------- Reporter: nich | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: aclocal.m4 find Resolution: | perm Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nich): Apologies, I diff'ed two commits in the wrong a/b order. I confirm it works for 'ghc master', though as the change is specific to LLVM targets which I don't use, it obviously needs a little more validation. I'll attach the correct diff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 18:46:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 18:46:11 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.9b08368d3b17c476c8b063aee7d79e56@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): > in exchange for... what? The primary benefits of reorganizing the code in this way are: * We get to eliminate the HEAP_ALLOCED check (#8199), which we've seen experimentally to improve performance by about 8% on GC heavy benchmarks, and even more for processes with large heaps. Additionally, we should see a (minor) further improvement, because we no longer have to spend a pile of time at startup copying static data to the heap or follow indirections in code (which is the case for the current patchset). We get to avoid committing a long and complicated patchset. * The HEAP_ALLOCED check gets modestly simpler; we still have to maintain 32-bit megablock handling code, but we can eject most of the bookkeeping involved with managing 64-bit memory mapping * When we allocate data that spans multiple (today's) megablocks, we no longer have to waste the slop space afterwards. This has to be left empty today because the block descriptor was clobbered. > Also, as 32-bit architectures wane, would there be a simpler but perhaps-less-performant fallback that would allow the code to be simplified for all architectures? Unfortunately, the main concept (reserve a huge chunk of virtual address space) doesn't work at all on 32-bit, so I don't think it's possible to simplify the code at all here. > How do we decide what the max heap size should be? Total mem + swap? I thought about this a bit; I suspect for performance reasons we will actually want this hard-coded into the runtime, since the size of this fragment is going to be built into the mask we do when doing the Bdescr calculation. It's not bad if HEAP_ALLOCED does a memory dereference to figure out the base address of the heap, but adding an extra memory dereference to Bdescr might be too much. > I'm worried about the overhead of having to pre-allocate a large number of page tables for the reserved address space also > You mention that GCC Go does this. Is there any other prior art? My understanding is this is pretty common for runtimes which use a contiguous heap. I did some quick looks and the Hotspot JVM runtime also does this: {{{ // first reserve enough address space in advance since we want to be // able to break a single contiguous virtual address range into multiple // large page commits but WS2003 does not allow reserving large page space // so we just use 4K pages for reserve, this gives us a legal contiguous // address space. then we will deallocate that reservation, and re alloc // using large pages const size_t size_of_reserve = bytes + _large_page_size; if (bytes > size_of_reserve) { // Overflowed. warning("Individually allocated large pages failed, " "use -XX:-UseLargePagesIndividualAllocation to turn off"); return NULL; } p_buf = (char *) VirtualAlloc(addr, size_of_reserve, // size of Reserve MEM_RESERVE, PAGE_READWRITE); }}} It also looks like the main Go implementation does this: {{{ // On a 64-bit machine, allocate from a single contiguous reservation. // 128 GB (MaxMem) should be big enough for now. // // The code will work with the reservation at any address, but ask // SysReserve to use 0x0000XXc000000000 if possible (XX=00...7f). // Allocating a 128 GB region takes away 37 bits, and the amd64 // doesn't let us choose the top 17 bits, so that leaves the 11 bits // in the middle of 0x00c0 for us to choose. Choosing 0x00c0 means // that the valid memory addresses will begin 0x00c0, 0x00c1, ..., 0x00df. // In little-endian, that's c0 00, c1 00, ..., df 00. None of those are valid // UTF-8 sequences, and they are otherwise as far away from // ff (likely a common byte) as possible. If that fails, we try other 0xXXc0 // addresses. An earlier attempt to use 0x11f8 caused out of memory errors // on OS X during thread allocations. 0x00c0 causes conflicts with // AddressSanitizer which reserves all memory up to 0x0100. // These choices are both for debuggability and to reduce the // odds of the conservative garbage collector not collecting memory // because some non-pointer block of memory had a bit pattern // that matched a memory address. // // Actually we reserve 136 GB (because the bitmap ends up being 8 GB) // but it hardly matters: e0 00 is not valid UTF-8 either. // // If this fails we fall back to the 32 bit memory mechanism arena_size = MaxMem; bitmap_size = arena_size / (sizeof(void*)*8/4); spans_size = arena_size / PageSize * sizeof(runtime?mheap.spans[0]); spans_size = ROUND(spans_size, PageSize); for(i = 0; i <= 0x7f; i++) { p = (void*)(i<<40 | 0x00c0ULL<<32); p_size = bitmap_size + spans_size + arena_size + PageSize; p = runtime?SysReserve(p, p_size, &reserved); if(p != nil) break; } }}} V8 does not appear to do this. I haven't checked any more yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 18:48:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 18:48:26 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.93e6b79a008297a341a8744d38d19067@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): Sorry, it looks like I misread the Hotspot code, it's using the reservations to do something else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 19:19:36 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 19:19:36 -0000 Subject: [GHC] #9692: Template Haskell reification for Data Families is buggy? In-Reply-To: <047.c908a871df417674fd29671ed5adc70e@haskell.org> References: <047.c908a871df417674fd29671ed5adc70e@haskell.org> Message-ID: <062.8f6e7202b08da48c453f5418198ef103@haskell.org> #9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: TemplateHaskell Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: This gets a bit worse: reifying data families also includes kind parameters. Should be easy enough to fix, though... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 19:53:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 19:53:43 -0000 Subject: [GHC] #9702: Offer a weaker name shadowing warning In-Reply-To: <045.a53501a68ff02e8671244c2afeca86af@haskell.org> References: <045.a53501a68ff02e8671244c2afeca86af@haskell.org> Message-ID: <060.cc063046983031f71a5a815f21642b11@haskell.org> #9702: Offer a weaker name shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: warning, module Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not strongly against, if someone wants to offer a patch, but I'd prefer to see a bunch of people saying "oh yes I'd like that". Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 20:17:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 20:17:51 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.75d8fb46312b5192b4124006c2cee864@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): Would this simplify the engineering needed to eg support "capability/thread local heaps"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 20:54:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 20:54:16 -0000 Subject: [GHC] #9692: Template Haskell reification for Data Families is buggy? In-Reply-To: <047.c908a871df417674fd29671ed5adc70e@haskell.org> References: <047.c908a871df417674fd29671ed5adc70e@haskell.org> Message-ID: <062.ad3113e4f5edfea3a941a32b4ab66a40@haskell.org> #9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: TemplateHaskell Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D355 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D355 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 21:02:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 21:02:48 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.4ada428767fe99bb79ffab189ddd336e@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): No, no difference there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 21:22:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 21:22:11 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.2561e7764f5d263bd4103e61918b3ff1@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): > Next, probe for some appropriately aligned chunk of available virtual address space for this. On POSIX, we can mmap /dev/null using PROT_NONE and MAP_NORESERVE. Is this different from using MAP_ANONYMOUS? BTW, I found that I could mmap 100 TB with PROT_NONE (or even PROT_READ) and MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED with no measurable delay, and I can start 10000 such processes at once, so there doesn't seem to be any significant cost to setting up the page table mappings (at least on my system). Not sure why that is, exactly. The VSZ column in ps looks quite funny of course :) Also, this was on a system with overcommit disabled (vm.overcommit_memory = 2). So PROT_NONE or PROT_READ pages don't count against the commit limit. > To allocate, we keep track of the high-watermark, and mmap in 1MB pages as they are requested. We also keep track of how much metadata we need, and mmap extra pages to store metadata as necessary. By "mmap" here do you mean using mprotect() to make parts of our reserved area writable, or something else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 21:27:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 21:27:49 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.0385951442fe489f5f83924859a80882@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:9 rwbarton]: > Not sure why that is, exactly. Oh, I guess there ''are'' no page table mappings until we access the memory, causing a segmentation fault which the kernel handles by consulting the process's memory map table and allocating a new page with corresponding a page table mapping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 20 21:43:29 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Oct 2014 21:43:29 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.705332e76f476248904f265d28b59251@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thoughtpolice): > I'm worried about the overhead of having to pre-allocate a large number of page tables for the reserved address space Like Reid mentioned, this shouldn't be too much of an issue on Linux, at least, until we get the initial page fault to map things in the first place. But beyond that, we can possibly mitigate some TLB/mapping thrashes a bit on Linux at least using hugetables, which should beef up the page sizes from 4k to 1MB or so. On older Linux systems though this is a bit of a basket case, since you need `hugetblfs`, which is super annoying and before transparent hugepages/mmap flags were introduced in glibc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 07:27:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 07:27:01 -0000 Subject: [GHC] #7942: aarch64 support in ghc In-Reply-To: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> References: <045.737ed365d2d1e19c1d50a2289a84a8b0@haskell.org> Message-ID: <060.d31889660a47972120d6ff81113904b0@haskell.org> #7942: aarch64 support in ghc -------------------------------------+------------------------------------- Reporter: jcapik | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: Component: Compiler | Keywords: Resolution: fixed | Architecture: arm Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: 7623, 8664 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by lukexi): Thanks Carter! I've got one more patch to push up ??I implemented the necessary functions from SMP.h in ARM64 ASM while backporting the ARM64 support to 7.8 (as I needed it... though I'm not sure that will be deemed worthy of inclusion in 7.8.4 since it relies on the LLVM 3.5 support) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 08:09:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 08:09:09 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.fa756bed613fa6db46457b05f274e247@haskell.org> #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): Can I get some more time before I throw in the towel? Say, until next Thursday? Simon, if you were to start working on this what parts of my implementation need to be finished? Everything up to `SynTyCon` storing a list of `Bool`s? In what form would you like my patch? A differential revision? A branch on github? Do you want my work rebased against latest HEAD? > Decomposition in brief. If you want Maybe a ~ Maybe b then it's enough to prove a ~ b. From a proof of the latter we can get a proof of the former. No more than that. Obviously, this is what we currently have for data types and what we want for injective type families. But from the OutsideIn paper my understanding was that *current* treatment of *type families* is different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 12:34:41 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 12:34:41 -0000 Subject: [GHC] #9702: Offer a weaker name shadowing warning In-Reply-To: <045.a53501a68ff02e8671244c2afeca86af@haskell.org> References: <045.a53501a68ff02e8671244c2afeca86af@haskell.org> Message-ID: <060.d2660510b468db48104b836ea58a4a37@haskell.org> #9702: Offer a weaker name shadowing warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: warning, module Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I think this is very related to the discussion started [http://www.haskell.org/pipermail/glasgow-haskell- users/2014-October/025306.html here]. I think that discussion should reach some conclusion before deciding what to do with this ticket. Personally, I'm in favor of taking ''some'' action like the one proposed here and/or in that thread, but I haven't found just the right proposal to champion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 13:12:19 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 13:12:19 -0000 Subject: [GHC] #9705: Panic on a pattern synonym in a class In-Reply-To: <047.614ec39c173b8238a9064e76b118d842@haskell.org> References: <047.614ec39c173b8238a9064e76b118d842@haskell.org> Message-ID: <062.afd092c06f3a744e7b74dc59243885ca@haskell.org> #9705: Panic on a pattern synonym in a class -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by cactus): * status: new => patch Comment: I've pushed a fix for this to the `wip/T9705` branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 13:19:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 13:19:02 -0000 Subject: [GHC] #9262: Allow free variables in reifyInstances In-Reply-To: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> References: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> Message-ID: <062.8e0015bb79d794aa0d030271103b92ff@haskell.org> #9262: Allow free variables in reifyInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D359 | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D359 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 13:21:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 13:21:21 -0000 Subject: [GHC] #9692: Template Haskell reification for Data Families is buggy? In-Reply-To: <047.c908a871df417674fd29671ed5adc70e@haskell.org> References: <047.c908a871df417674fd29671ed5adc70e@haskell.org> Message-ID: <062.008976f543ed0e8871675096b54f6795@haskell.org> #9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: TemplateHaskell Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D355 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"e319d6d2704edc2696f47409f85f4d4ce58a6cc4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e319d6d2704edc2696f47409f85f4d4ce58a6cc4" Reify data family instances correctly. Summary: Fix #9692. The reifier didn't account for the possibility that data/newtype instances are sometimes eta-reduced. It now eta-expands as necessary. Test Plan: th/T9692 Reviewers: simonpj, austin Subscribers: thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D355 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 13:21:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 13:21:21 -0000 Subject: [GHC] #9692: Template Haskell reification for Data Families is buggy? In-Reply-To: <047.c908a871df417674fd29671ed5adc70e@haskell.org> References: <047.c908a871df417674fd29671ed5adc70e@haskell.org> Message-ID: <062.5e8755e8f222fefe4f3d8bd671e86a95@haskell.org> #9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: TemplateHaskell Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D355 | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"f681c3274c4481ab549508fa346892023bf9d9bb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f681c3274c4481ab549508fa346892023bf9d9bb" Test #9692 in th/T9692 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 13:34:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 13:34:49 -0000 Subject: [GHC] #9692: Template Haskell reification for Data Families is buggy? In-Reply-To: <047.c908a871df417674fd29671ed5adc70e@haskell.org> References: <047.c908a871df417674fd29671ed5adc70e@haskell.org> Message-ID: <062.ca42bfbd21e7abf06b0e5dcdd5e38caf@haskell.org> #9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Template | Version: 7.8.3 Haskell | Keywords: TemplateHaskell Resolution: fixed | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: | hour) None/Unknown | Blocked By: Test Case: th/T9692 | Related Tickets: Blocking: | Differential Revisions: Phab:D355 | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => th/T9692 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 13:39:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 13:39:59 -0000 Subject: [GHC] #8953: Reifying poly-kinded type families misses kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.7f26bd2a1a183d9f1609f2d685d70814@haskell.org> #8953: Reifying poly-kinded type families misses kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Old description: > Consider the following two modules: > > {{{ > {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies #-} > > module A where > > type family Poly (a :: k) :: * > type instance Poly (x :: Bool) = Int > type instance Poly (x :: Maybe k) = Double > }}} > > {{{ > {-# LANGUAGE TemplateHaskell #-} > > module B where > > import Language.Haskell.TH > import A > > $( do info <- reify ''Poly > runIO $ putStrLn $ pprint info > return [] ) > }}} > > Compiling with HEAD yields this output: > > {{{ > type family A.Poly (a_0 :: k_1) :: * > type instance A.Poly x_2 = GHC.Types.Double > type instance A.Poly x_3 = GHC.Types.Int > }}} > > The problem is that the type patterns in the reified instances are just > plain variables, without their kind annotations. This omission makes the > instance declarations unfaithful to the original meaning. New description: Consider the following: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, TemplateHaskell #-} import Language.Haskell.TH type family Poly (a :: k) :: * type instance Poly (x :: Bool) = Int type instance Poly (x :: Maybe k) = Double $( do info <- reify ''Poly runIO $ putStrLn $ pprint info return [] ) }}} Compiling with HEAD yields this output: {{{ type family Main.Poly (a_0 :: k_1) :: * type instance Main.Poly x_2 = GHC.Types.Double type instance Main.Poly x_3 = GHC.Types.Int }}} The problem is that the type patterns in the reified instances are just plain variables, without their kind annotations. This omission makes the instance declarations unfaithful to the original meaning. -- Comment (by goldfire): Only one module is required. Previous bug description had two. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 13:43:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 13:43:54 -0000 Subject: [GHC] #9708: Type inference non-determinism due to improvement Message-ID: <046.b82d37e7450cce9a05553877e957cde0@haskell.org> #9708: Type inference non-determinism due to improvement -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- Here's an example that showed up in Iavor's test `TcTypeNatSimple`: {{{ ti7 :: (x <= y, y <= x) => Proxy (SomeFun x) -> Proxy y -> () ti7 _ _ = () }}} From the ambiguity check for `ti7` we get this constraint {{{ forall x y. (x <= y, y <= x) => ( SomeFun x ~ SomeFun alpha , alpha <= y, y <= alpha) }}} where `alpha` is the unification variable that instantiates `x`. Now, from the givens, improvement gives a derived `[D] x~y`, but we can't actually use that to rewrite anything; we have no evidence. From the wanteds we can use improvement in two alternative ways: {{{ 1. (alpha <= y, y <= alpha) => [D] alpha ~ y 2. (x <= y, y <= alpha) => [D] x <= alpha (alpha <= y, y <= x) => [D] alpha <= x And combining the latter two we get [D] (alpha ~ x) }}} It is (2) that we want. But if we get (1) and fix `alpha := y`, we get an error `Can't unify (SomeFun x ~ SomeFun y)`. I think it's a fluke that this test has been working so far; in my new flatten-skolem work it has started failing, which is not unreasonable. What I HATE is that whether type checking succeeds or fails depends on some random choice about which constraint is processed first. The real bug is that the derived Given has no evidence, and can't be used for rewriting. I think Iavor is fixing this deficiency for. I speculate that the same problem might also show up with ordinary type-class functional dependencies, but I have not found a concrete example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 13:45:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 13:45:54 -0000 Subject: [GHC] #8953: Reifying poly-kinded type families misses kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.cbf010ad8654445320dcf73e754346af@haskell.org> #8953: Reifying poly-kinded type families misses kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Urgh. This gets even worse. Look at this: {{{ {-# LANGUAGE DataKinds, PolyKinds, TypeFamilies, TemplateHaskell #-} import Language.Haskell.TH import Data.Proxy type family Silly :: k -> * type instance Silly = (Proxy :: * -> *) type instance Silly = (Proxy :: (* -> *) -> *) $( do info <- reify ''Silly runIO $ putStrLn $ pprint info return [] ) }}} This produces {{{ type family Main.Silly :: k_0 -> * type instance Main.Silly = Data.Proxy.Proxy type instance Main.Silly = Data.Proxy.Proxy }}} Now, there's no variables to annotate! I think the thing to do is to kind- annotate every poly-kinded tycon application, ''and'' every variable on the LHS whose kind includes a kind variable. I guess this conclusion is a bare-bones attempt at the "inference" described in comment:1, but it seems straightforward enough to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 13:58:37 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 13:58:37 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.71d8778825a88351c0a2842d92c78265@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Is it safe to allocate, say, half the address space for the heap? That would offer enough room to grow for a while. Anything that limits the heap to a few terabytes could become a serious limitation within a fairly short time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 14:09:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 14:09:01 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations (was: Reifying poly-kinded type families misses kind annotations) In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.f0ca7f9e9e2e1a47ce36af8dd7909227@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Still getting worse! Now, look at this: {{{ a :: Proxy (Proxy :: * -> *) a = undefined b :: Proxy (Proxy :: (* -> *) -> *) b = undefined $( do info_a <- reify 'a info_b <- reify 'b runIO $ mapM putStrLn $ map pprint [info_a, info_b] return [] ) }}} produces {{{ Main.a :: Data.Proxy.Proxy Data.Proxy.Proxy Main.b :: Data.Proxy.Proxy Data.Proxy.Proxy }}} Yet, the types of `a` and `b` are ''not'' the same, and assigning one to the other rightly results in a type error. Furthermore, we really need to give the kind of ''every'' type variable binder. Consider {{{ type StarProxy (a :: *) = Proxy a }}} Reifying tyvar binders omits any kinds that are `*`, yet the kind annotation here is very relevant (if `-XPolyKinds` is on). Oh, and the original problem (not reifying kind annotation on type variable patterns) can affect ''class'' instances, too, not just ''type'' instances. So, new plan: 1. Never reify a tyvar binder into a `PlainTV`. Always use `KindedTV`. 2. Include a kind annotation (`SigT`) wrapping every use of a poly-kinded tycon. This wrapping will wrap around any arguments the tycon is applied to. 3. If a class or family tyvar is polykinded, include a kind annotation on any pattern used to specialize this tyvar in instance declarations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 14:37:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 14:37:01 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.8c8ef7d33b24f1e3bf33c334920ef247@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): And, while I'm at it, much like in #8884, reified class instances include kind patterns. This needs to be fixed, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 14:45:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 14:45:47 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.6612c60ee80830eaa1a50ccf6952e390@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonmar): Ok, so there's no problem with page tables for the reserved region on Linux. Using total memory + swap is a safe limit for the address space to reserve, since we never want to overcommit with actual heap memory. I still think we should separate this from the question of reorganising the block descriptors, which is probably a good idea and depends on this, but can be tackled separately. Open questions: * Does VirtualAlloc on Windows behave the same way? That is, can we allocate as much address space as we want, without creating page tables and without getting an out of memory error? * What do we do when overcommit is disabled on Linux? * What about OS X? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 15:05:14 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 15:05:14 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.407220a97bdf052efab453e86d1b4ac2@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): I have updated the GhcAstAnnotations page to reflect the current design, as well as to add a section outlining an approach to comments, which is https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations#comments The comments have been added in Phab:D297, causing the file `ApiAnnotations` to be moved into `Lexer.x` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 16:28:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 16:28:11 -0000 Subject: [GHC] #9709: Make restarts itself sometimes, and that's OK Message-ID: <047.7c0fc01059fc26172e59c2fa7057aac7@haskell.org> #9709: Make restarts itself sometimes, and that's OK -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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 fairly frequently get the message that `make` has restarted itself {{{ ghc.mk:100: *** Make has restarted itself 2 times; is there a makefile bug? See http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestarteditself3timesisthereamakefilebug for details. Stop. }}} but then when I say `make` again, things proceed just fine. In particular, this always (I think) happens after I `make clean` in the `libraries` directory. If it matters, I always use the `-j` flag to `make`, sometimes with 2 cores and sometimes with 4. I'm on Mac OS 10.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 16:30:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 16:30:00 -0000 Subject: [GHC] #9710: Clean up Trac versions Message-ID: <047.e9e7ccfe79be5260af9a1e1e7a3f431d@haskell.org> #9710: Clean up Trac versions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- The "Version" pull-down menu in Trac has no apparent ordering principle. This should be fixed. Even better, scrap many of the very old versions, as they're unsupported, anyway. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 17:11:57 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 17:11:57 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.e3b4d773b8b1ed8d11784c9c2a44ed83@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): I did my experiments on a Linux system with overcommit disabled and watched the `Committed_AS` number from `/proc/meminfo`. According to my tests, anonymous pages which have never been mapped with `PROT_WRITE` don't count against the commit limit. Once a page is given `PROT_WRITE` permissions then it counts as committed even if `PROT_WRITE` is removed before the page is ever touched. I would guess we can "un-commit" pages by doing a new mmap over them with `PROT_NONE`, but I didn't test this. Carter tested that on OS X, mmapping 100 TB doesn't take any noticeable time, at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 17:43:53 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 17:43:53 -0000 Subject: [GHC] #9711: Confusing errors when compiling text-1.2.0.0 Message-ID: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> #9711: Confusing errors when compiling text-1.2.0.0 ----------------------------------+--------------------------------------- Reporter: asvyazin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+--------------------------------------- I was trying to install text-1.2.0.0 on my system (Mac OS X 10.7.5 Lion) through cabal (cabal-install-1.20.0.3, cabal-1.20.0.2) and got some compile errors: [29 of 43] Compiling Data.Text.IO ( Data/Text/IO.hs, dist/build/Data/Text/IO.o ) Data/Text/IO.hs:236:29: The last statement in a 'do' block must be an expression n1 <- writeCharBuf raw n '\r' writeCharBuf raw n1 '\n' >>= inner s' Data/Text/IO.hs:237:49: Not in scope: ?n1? Perhaps you meant one of these: ?n? (line 230), ?s1? (line 228) Let's see what we have at 236 line of Data/Text/IO.hs: {{{#!hs writeBlocksCRLF :: Handle -> Buffer CharBufElem -> Stream Char -> IO () writeBlocksCRLF h buf0 (Stream next0 s0 _len) = outer s0 buf0 where outer s1 Buffer{bufRaw=raw, bufSize=len} = inner s1 (0::Int) where inner !s !n = case next0 s of Done -> commit n False{-no flush-} True{-release-} >> return () Skip s' -> inner s' n Yield x s' | n + 1 >= len -> commit n True{-needs flush-} False >>= outer s | x == '\n' -> do n1 <- writeCharBuf raw n '\r' -- 236 line is here!!! writeCharBuf raw n1 '\n' >>= inner s' | otherwise -> writeCharBuf raw n x >>= inner s' commit = commitBuffer h raw len }}} Seems legit? And if I rewrite this two lines as {{{#!hs | x == '\n' -> do n1 <- writeCharBuf raw n '\r'; writeCharBuf raw n1 '\n' >>= inner s' }}} then ghc compiles them fine. Even more interesting - if I rewrite this lines as {{{#!hs | x == '\n' -> do n1 <- writeCharBuf raw n '\r' writeCharBuf raw n1 '\n' >>= inner s' }}} then it compiles them too! Again, with context, look carefully: {{{#!hs Yield x s' | n + 1 >= len -> commit n True{-needs flush-} False >>= outer s | x == '\n' -> do n1 <- writeCharBuf raw n '\r' writeCharBuf raw n1 '\n' >>= inner s' | otherwise -> writeCharBuf raw n x >>= inner s' }}} doesn't work. {{{#!hs Yield x s' | n + 1 >= len -> commit n True{-needs flush-} False >>= outer s | x == '\n' -> do n1 <- writeCharBuf raw n '\r' writeCharBuf raw n1 '\n' >>= inner s' | otherwise -> writeCharBuf raw n x >>= inner s' }}} works! Weird? P.S. GHC version 7.8.3, installed through homebrew -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 18:03:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 18:03:46 -0000 Subject: [GHC] #9711: Confusing errors when compiling text-1.2.0.0 In-Reply-To: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> References: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> Message-ID: <062.268d4123b57d9088fb1b63c8b96157f8@haskell.org> #9711: Confusing errors when compiling text-1.2.0.0 ---------------------------------------+---------------------------------- Reporter: asvyazin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Comment (by rwbarton): This seems rather hard to believe. I get those exact errors (down to the column numbers) when I remove three spaces after `x == '\n'` (like in your last snippet) ''only''. Are you sure you haven't edited this file before trying to build it, possibly inserting tab characters in the process? I guess it's possible that the homebrew build is somehow faulty in a way that would cause this, but difficult to imagine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 18:09:26 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 18:09:26 -0000 Subject: [GHC] #9711: Confusing errors when compiling text-1.2.0.0 In-Reply-To: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> References: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> Message-ID: <062.ef61a71399986234fe51dc18dea2379d@haskell.org> #9711: Confusing errors when compiling text-1.2.0.0 ---------------------------------------+---------------------------------- Reporter: asvyazin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Comment (by rwbarton): Ohh wait, perhaps it is a CPP issue. (Though I can't make sense of it if so.) I forget what the solution to CPP issues on OS X is, but I think it might be "don't use homebrew, download the binary distribution from haskell.org". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 18:12:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 18:12:52 -0000 Subject: [GHC] #9711: Confusing errors when compiling text-1.2.0.0 In-Reply-To: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> References: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> Message-ID: <062.0c57c4784b9fde47bc0009dfe7c64871@haskell.org> #9711: Confusing errors when compiling text-1.2.0.0 ---------------------------------------+---------------------------------- Reporter: asvyazin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Comment (by rwbarton): Does it make any difference if you remove `CPP, ` from line 1 and remove lines 2 and 4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 18:30:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 18:30:10 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict In-Reply-To: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> References: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> Message-ID: <059.ae5250a610dd0127fe3ce092ba097121@haskell.org> #9038: Foreign calls don't make their arguments look strict -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 1592 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by tibbe): I assume that `` is still unboxed, as even though it's marked as "lazy" it's an unboxed type. If so, I don't think there's an issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 19:48:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 19:48:21 -0000 Subject: [GHC] #9712: package "primitive" fails to install under msys2-i686 (Windows) Message-ID: <045.44b3a2c6a330919c7f9b94f8f0acc95b@haskell.org> #9712: package "primitive" fails to install under msys2-i686 (Windows) ---------------------------+--------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.9 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------+--------------------------------------- If you follow the instructions for a 32-bit installation at https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows, installation of alex fails. Not sure if this is an issue with alex or with the environment. Transcript: $ cabal install alex Resolving dependencies... Downloading primitive-0.5.4.0... Configuring primitive-0.5.4.0... Failed to install primitive-0.5.4.0 Build log ( C:\Users\Gintas\AppData\Roaming\cabal\logs\primitive-0.5.4.0.log ): [1 of 1] Compiling Main ( C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.hs, C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\Main.o ) Linking C:\Users\Gintas\Downloads\msys32\tmp\primitive-0.5.4.0-2404\primitive-0.5.4.0\dist\setup\setup.exe ... Configuring primitive-0.5.4.0... setup-Simple-Cabal-1.18.1.3-i386-windows-ghc-7.8.3.exe: Missing dependency on a foreign library: * Missing (or bad) header file: primitive-memops.h This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. If the header file does exist, it may contain errors that are caught by the C compiler at the preprocessing stage. In this case you can re-run configure with the verbosity flag -v3 to see the error messages. The primitive-memops.h file seems to be part of "primitive" itself. Passing in -v3 does not print anything interesting. $ cabal --version cabal-install version 1.20.0.3 using version 1.20.0.1 of the Cabal library $ cabal get primitive && cd primitive-* && cabal configure && cabal build Unpacking to primitive-0.5.4.0\ Resolving dependencies... Configuring primitive-0.5.4.0... Building primitive-0.5.4.0... Preprocessing library primitive-0.5.4.0... [ 1 of 10] Compiling Data.Primitive.Internal.Compat ( Data\Primitive\Internal\Compat.hs, dist\build\Data\Primitive\Internal\Compat.o ) [ 2 of 10] Compiling Data.Primitive.MachDeps ( Data\Primitive\MachDeps.hs, dist\build\Data\Primitive\MachDeps.o ) [ 3 of 10] Compiling Data.Primitive.Internal.Operations ( Data\Primitive\Internal\Operations.hs, dist\build\Data\Primitive\Internal\Operations.o ) [ 4 of 10] Compiling Control.Monad.Primitive ( Control\Monad\Primitive.hs, dist\build\Control\Monad\Primitive.o ) [ 5 of 10] Compiling Data.Primitive.Types ( Data\Primitive\Types.hs, dist\build\Data\Primitive\Types.o ) [ 6 of 10] Compiling Data.Primitive.Array ( Data\Primitive\Array.hs, dist\build\Data\Primitive\Array.o ) Data\Primitive\Array.hs:32:1: Warning: The import of `Control.Monad.ST' is redundant except perhaps to import instances from `Control.Monad.ST' To import instances alone, use: import Control.Monad.ST() [ 7 of 10] Compiling Data.Primitive.ByteArray ( Data\Primitive\ByteArray.hs, dist\build\Data\Primitive\ByteArray.o ) [ 8 of 10] Compiling Data.Primitive.Addr ( Data\Primitive\Addr.hs, dist\build\Data\Primitive\Addr.o ) [ 9 of 10] Compiling Data.Primitive ( Data\Primitive.hs, dist\build\Data\Primitive.o ) [10 of 10] Compiling Data.Primitive.MutVar ( Data\Primitive\MutVar.hs, dist\build\Data\Primitive\MutVar.o ) In-place registering primitive-0.5.4.0... Any idea what's missing here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 19:52:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 19:52:29 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict In-Reply-To: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> References: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> Message-ID: <059.cf41fa067855705c374b840c5ee11056@haskell.org> #9038: Foreign calls don't make their arguments look strict -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 1592 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh yes, arguments of unboxed type are, well, unboxed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 20:36:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 20:36:55 -0000 Subject: [GHC] #9038: Foreign calls don't make their arguments look strict In-Reply-To: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> References: <044.a0c9de83b2174409763abdc46ead5c18@haskell.org> Message-ID: <059.d21ddaa39987ae3fcd5f118fb3641af4@haskell.org> #9038: Foreign calls don't make their arguments look strict -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: worksforme | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: 1592 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by tibbe): * status: infoneeded => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 21:29:52 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 21:29:52 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.867041aa2dce8901638bd117be55d1a1@haskell.org> #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): Sure. Take as long as you need. I was offering to do the type inference piece, which seemed to be the bit you are stalled on. So if you do parser, renamer, and typechecking of the `TyCon` declaration, so we have the injectivity info in the `TyCon`, that would do it I think. In practical terms, a branch in a github repo that I can pull and push to would work well. All I plan to do is add a rule along the lines of {{{ [W] F ty1 ~ rhs [W] F ty2 ~ rhs ===> add a new constraint (if F is injective) [D] ty1 ~ ty2 }}} very like functional dependencies for type classes. I'm not sure that there is time to get this implemented, tested etc before the 7.10 freeze, but we'll see. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 21:48:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 21:48:42 -0000 Subject: [GHC] #9517: hp2ps generates invalid postscript file In-Reply-To: <045.a830b70a270e850cd0392ed106ef100c@haskell.org> References: <045.a830b70a270e850cd0392ed106ef100c@haskell.org> Message-ID: <060.30ba834f83483017194378384fb60133@haskell.org> #9517: hp2ps generates invalid postscript file ------------------------------------+--------------------------- Reporter: JamesM | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ------------------------------------+--------------------------- Comment (by Yxven): I've also encountered this bug. If it helps to have a code base that can create this bug, this commit broke -hc for me. https://github.com/Yxven/roguelike/commit/5bbba34cfea3a12e2e0038f390e8eab9b264289b Changing maximumCoordinate = 100 * tileSize to maximumCoordinate = 5 * tileSize causes hp2ps to bug out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 21:50:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 21:50:24 -0000 Subject: [GHC] #1473: isSpace is too slow In-Reply-To: <044.3c2c0fec916372178c4bf5ce7945c8fa@haskell.org> References: <044.3c2c0fec916372178c4bf5ce7945c8fa@haskell.org> Message-ID: <059.84c757184b5fcdc2bc74dec0825cd738@haskell.org> #1473: isSpace is too slow -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 6.6.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"31571270625a690410b794b7cfe48d866c084e74/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="31571270625a690410b794b7cfe48d866c084e74" Improve isDigit, isSpace, etc. Summary: Make things less branchy; use unsigned comparisons for range checking. Eliminate non-spaces more quickly in common cases in isSpace. Reviewers: ekmett, carter, austin Reviewed By: austin Subscribers: thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D340 GHC Trac Issues: #1473 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 21:50:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 21:50:24 -0000 Subject: [GHC] #9679: testsuite/.gitignore does not cover some test outputs on Windows In-Reply-To: <045.b09b4535aecb931940ceef6ecdec91bc@haskell.org> References: <045.b09b4535aecb931940ceef6ecdec91bc@haskell.org> Message-ID: <060.0f8b8058129bb9527488942c1030e30c@haskell.org> #9679: testsuite/.gitignore does not cover some test outputs on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D333 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"3687089fd55e3c8d2710da5c9fb4b53c6c84e0cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3687089fd55e3c8d2710da5c9fb4b53c6c84e0cf" Updated testsuite/.gitignore to cover artifacts on Windows. Test Plan: git status after a test run Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D333 GHC Trac Issues: #9679 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 21:50:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 21:50:24 -0000 Subject: [GHC] #9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform In-Reply-To: <047.b513f6d5b7f08c66f27c72ad328610e0@haskell.org> References: <047.b513f6d5b7f08c66f27c72ad328610e0@haskell.org> Message-ID: <062.54208b911587d626a220a3f1e4ff6479@haskell.org> #9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform -------------------------------------+------------------------------------- Reporter: angerman | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (LLVM) | Keywords: Resolution: | Architecture: arm Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D208 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"69f63612fc17cd6b3baaa8898c8595bde304ebfb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="69f63612fc17cd6b3baaa8898c8595bde304ebfb" Fixes the ARM build Summary: CodeGen.Platform.hs was changed with the following diff: -#endif globalRegMaybe _ = Nothing +#elif MACHREGS_NO_REGS +globalRegMaybe _ = Nothing +#else +globalRegMaybe = panic "globalRegMaybe not defined for this platform" +#endif which causes globalRegMaybe ot panic for arch ARM. This patch ensures globalRegMaybe is not called on ARM. Signed-off-by: Moritz Angermann Test Plan: Building arm cross-compiler (e.g. --target=arm-apple-darwin10) Reviewers: hvr, ezyang, simonmar, rwbarton, austin Reviewed By: austin Subscribers: dterei, bgamari, simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D208 GHC Trac Issues: #9593 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 21:50:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 21:50:24 -0000 Subject: [GHC] #9549: deriveConstants fails on OpenBSD In-Reply-To: <045.280f1382fe569e58794f97c954f259a6@haskell.org> References: <045.280f1382fe569e58794f97c954f259a6@haskell.org> Message-ID: <060.ffeb20e2b6a9f1df23a64f764ad75f55@haskell.org> #9549: deriveConstants fails on OpenBSD -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: OpenBSD | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D332 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"2cc206505d248ac8c706aa85342a895857c9f091/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2cc206505d248ac8c706aa85342a895857c9f091" Use objdump instead of nm to derive constants on OpenBSD Summary: OpenBSD's nm doesn't support the -P option and there appears to be no other way to get the desired information from it. Reviewers: kgardas, #ghc, austin Reviewed By: kgardas, #ghc, austin Subscribers: austin, ggreif Projects: #ghc Differential Revision: https://phabricator.haskell.org/D332 GHC Trac Issues: #9549 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 21:50:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 21:50:24 -0000 Subject: [GHC] #9537: concatMap is not a good producer for list fusion In-Reply-To: <045.e14a158c8be66f6d40a93a99a32fda56@haskell.org> References: <045.e14a158c8be66f6d40a93a99a32fda56@haskell.org> Message-ID: <060.98bbb03209300e2ba57717650c5778f9@haskell.org> #9537: concatMap is not a good producer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: fusion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D348 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"1e269bf404fb2719bbe8d72154156ef275c9a6f9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1e269bf404fb2719bbe8d72154156ef275c9a6f9" Make Data.List.concatMap fuse better Summary: Fix #9537 precisely as Joachim Breitner proposed in http://www.haskell.org/pipermail/haskell-cafe/2011-December/097228.html Reviewers: austin, nomeata Reviewed By: austin, nomeata Subscribers: thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D348 GHC Trac Issues: #9537 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 21:50:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 21:50:24 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.1daa17cd0d2f6006993838b56669dba3@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"972ba1210d1bb535c41526ce396c0f086d30b59a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="972ba1210d1bb535c41526ce396c0f086d30b59a" Enabled warn on tabs by default (fixes #9230) Summary: This revision enables -fwarn-tabs by default and add a suppression flag, so that GHC compilation won't fail when some files contain tab characters. Test Plan: Additional test case, T9230, was added to cover that change. Reviewers: austin Reviewed By: austin Subscribers: simonmar, ezyang, carter, thomie, mlen Differential Revision: https://phabricator.haskell.org/D255 GHC Trac Issues: #9230 Conflicts: testsuite/driver/testlib.py }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 22:19:51 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 22:19:51 -0000 Subject: [GHC] #9713: Update comment about C helper for dynamic exports. Message-ID: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> #9713: Update comment about C helper for dynamic exports. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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 offending comment is in {{{compiler/deSugar/DsForeign.lhs}}}. The RTS API has changed so that {{{rts_evalIO}}} takes a capability as its first argument; so make the comment reflect reality. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 22:20:49 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 22:20:49 -0000 Subject: [GHC] #9713: Update comment about C helper for dynamic exports. In-Reply-To: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> References: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> Message-ID: <059.b243cdd5a5bd4b2bcbd377b4703741cd@haskell.org> #9713: Update comment about C helper for dynamic exports. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by int-e): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 21 22:45:15 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Oct 2014 22:45:15 -0000 Subject: [GHC] #9679: testsuite/.gitignore does not cover some test outputs on Windows In-Reply-To: <045.b09b4535aecb931940ceef6ecdec91bc@haskell.org> References: <045.b09b4535aecb931940ceef6ecdec91bc@haskell.org> Message-ID: <060.72095d7631e2f1e2b87fecbbfdea2e71@haskell.org> #9679: testsuite/.gitignore does not cover some test outputs on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D333 | -------------------------------------+------------------------------------- Changes (by gintas): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 02:59:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 02:59:37 -0000 Subject: [GHC] #9711: Confusing errors when compiling text-1.2.0.0 In-Reply-To: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> References: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> Message-ID: <062.891d230751e0384337e6e23bd46c8398@haskell.org> #9711: Confusing errors when compiling text-1.2.0.0 ---------------------------------------+---------------------------------- Reporter: asvyazin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Comment (by asvyazin): Actually, yes, it does... After removing CPP stuff there are no errors. It looks like CPP somehow "eats" extra spaces and breaks indentation. I will try binary version from haskell.org later -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 06:46:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 06:46:48 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.41e0c6ba4a1012310a3ff4c7617fbab1@haskell.org> #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): If we're not aiming to get this into 7.10 then I guess there's no rush. Replying to [comment:93 simonpj]: > All I plan to do is add a rule along the lines of > {{{ > [W] F ty1 ~ rhs > [W] F ty2 ~ rhs > ===> add a new constraint (if F is injective) > [D] ty1 ~ ty2 > }}} > very like functional dependencies for type classes. Yes, that's what I meant with my INJFEQFEQ interaction rule in [comment:89 comment 89]: {{{ INJFEQFEQ interact[l] (F \vec{Xi_1} ~ Xi, F \vec{Xi_2} ~ Xi) = (F \vec{Xi_1} ~ Xi, \vec{ Xi_1 ~ Xi_2 }) }}} Sorry if that wasn't clear. (Now I realized that checking whether `F` is injective might be consider a reaction with top-level axiom and thus this should be a reaction rule.) But it seems to me there should be one more rule. Consider this example: {{{#!hs type family F a = r | r -> a where F Char = Bool F Bool = Char F a = a idChar :: (F a ~ Bool) => a -> Char idChar a = a }}} Here we have constraint `F a ~ Bool`. Knowing that `F` is injective and it's RHS is `Bool` we want to deduce that `a` must be `Char`. This one seems more difficult because we have to look through all the equations. My guess would be that when we have to do this before constraint solving (in `TcM` monad?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 07:33:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 07:33:10 -0000 Subject: [GHC] #8648: Initialization of C statics broken in threaded runtime In-Reply-To: <044.f1cfb611748ab32509135bb2aba15bfa@haskell.org> References: <044.f1cfb611748ab32509135bb2aba15bfa@haskell.org> Message-ID: <059.76cce305b7f9e02776bc3b512f7d1b6a@haskell.org> #8648: Initialization of C statics broken in threaded runtime -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 07:55:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 07:55:24 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.de73a2671291837de9e1dc18ce477ccf@haskell.org> #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): Yes, we need to look through all the equations. Very like functional dependencies. Before we forget it, the big un-implemented piece is checking that the type-family equations are indeed injective. Or is that done now? I can't see it in Phab. That's the main reason I'm doubtful we'll make 7.10, unless perhaps you have it ready to go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 08:00:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 08:00:27 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.ab6837c3dbbb8fd6a9d427cd3a7ea51d@haskell.org> #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): > Before we forget it, the big un-implemented piece is checking that the type-family equations are indeed injective. Or is that done now? No, that's not implemented yet - I'm distracted between this and two other GHC projects so I didn't yet have the time :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 08:50:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 08:50:56 -0000 Subject: [GHC] #9537: concatMap is not a good producer for list fusion In-Reply-To: <045.e14a158c8be66f6d40a93a99a32fda56@haskell.org> References: <045.e14a158c8be66f6d40a93a99a32fda56@haskell.org> Message-ID: <060.057875e6a88f8a3350f7d85213459908@haskell.org> #9537: concatMap is not a good producer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: fusion Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D348 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 08:52:38 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 08:52:38 -0000 Subject: [GHC] #1473: isSpace is too slow In-Reply-To: <044.3c2c0fec916372178c4bf5ce7945c8fa@haskell.org> References: <044.3c2c0fec916372178c4bf5ce7945c8fa@haskell.org> Message-ID: <059.5f1fbc7ea084214405ffedefbe7bff42@haskell.org> #1473: isSpace is too slow -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 6.6.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nomeata): dfeuer, is 31571270625a690410b794b7cfe48d866c084e74/ghc sufficient to close this ticket or is there more to be done here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 09:18:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 09:18:45 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.4074df75d827513b2b9c49c25ddad795@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by simonpj): Thank you. Now I understand that all this is focused solely on the source- location of keywords. (Previously I thought that there might be other client-specific information involved.) Could we then just take a moment to review the pros and cons of the proposed approach (the `ApiAnns` approach) compared with the earlier idea of just adding `SrcSpan` info to the `HsSyn` syntax tree itself. That is, like "Richard Eisenberg's response" and "SPJ response to concern re extra noise in AST" in the wiki page. I'll call that the "in-tree approach". Note that using record update syntax, a pass like the renamer would never need to explicitly match or mention the keyword location fields. Advantages of the `ApiAnns` approach * Very non-invasive * Programs that don't need the information don't touch it; this seems like the strongest advantage Advantages of the in-tree approach * The things you want are right there; no extra mappings to carry around, no lookups, no `AnnColon2` stuff. * Seems simple and uniform with the existing source locations. Eg. if a keyword 'do' could so be `mdo`, you might have a `Located Bool` to indicate. But if it's just `do` then we'd get `Located ()`, and then we drop it altogether. The in-tree story amounts to not dropping it. This is really a matter for our customers. Alan (Mr HaRE) is one. Do we have other known customers for this feature? What do they say? Or don't they case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 10:27:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 10:27:16 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.82ebdc085bddb62a3ad869c6d1603b31@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------- Reporter: jcristovao | Owner: Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: GHCi | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ibotty): * cc: ibotty (added) Comment: i would also prefer a command-line option (and make it cabal repl's default). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 14:44:06 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 14:44:06 -0000 Subject: [GHC] #9714: Un-`wire` Integer type Message-ID: <042.d9e6c84c3f736b36a268197d3ac72a0d@haskell.org> #9714: Un-`wire` Integer type -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: Integer | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: #9281 | Blocking: | Differential Revisions: Phab:351 -------------------------------------+------------------------------------- `Integer` is currently a wired-in type for `integer-gmp`. This requires replicating its inner structure in `TysWiredIn.lhs`, which makes it much harder to change `Integer` to a more complex representation (like e.g. for #9281) In order to reduce the redundancy (due to wired-in type mirroring) and simplify the code, as [http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/5823/ suggested by Simon], `Integer` should no longer be a `wired-in` type but rather become a `known-key`-entity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 14:44:23 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 14:44:23 -0000 Subject: [GHC] #9714: Un-`wire` Integer type In-Reply-To: <042.d9e6c84c3f736b36a268197d3ac72a0d@haskell.org> References: <042.d9e6c84c3f736b36a268197d3ac72a0d@haskell.org> Message-ID: <057.f0b7026c6d11e876e852389afb272a5e@haskell.org> #9714: Un-`wire` Integer type -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Integer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: #9281 Blocking: | Differential Revisions: Phab:351 | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 14:44:40 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 14:44:40 -0000 Subject: [GHC] #9714: Un-`wire` Integer type In-Reply-To: <042.d9e6c84c3f736b36a268197d3ac72a0d@haskell.org> References: <042.d9e6c84c3f736b36a268197d3ac72a0d@haskell.org> Message-ID: <057.ca65b846b49f0c8b5622ea39bfc7b542@haskell.org> #9714: Un-`wire` Integer type -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Integer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: #9281 Blocking: | Differential Revisions: Phab:D351 | -------------------------------------+------------------------------------- Changes (by hvr): * differential: Phab:351 => Phab:D351 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 14:50:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 14:50:19 -0000 Subject: [GHC] #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 In-Reply-To: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> References: <043.05075eef32eca9bb127bf506ee6ed361@haskell.org> Message-ID: <058.226d927d4c8409e9d718dd75fcf1288b@haskell.org> #9697: ./configure fails due to obselete usage of 'find -perm' in aclocal.m4 -------------------------------------+------------------------------------- Reporter: nich | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: aclocal.m4 find Resolution: | perm Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 14:57:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 14:57:43 -0000 Subject: [GHC] #9660: unnecessary indirect jump when returning a case scrutinee In-Reply-To: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> References: <047.1e633f1de7b4519aab6fe4534a22ef61@haskell.org> Message-ID: <062.a673f6f2f8ea7ce08c2ceeb4f7a29581@haskell.org> #9660: unnecessary indirect jump when returning a case scrutinee -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:6 schyler]: > Could you show the core difference (for us who don't really understand the original ticket that well)? There is no difference at the Core level. In either case the core is {{{ Test.f = \ (x_arU :: GHC.Types.Int) -> case x_arU of wild_a10j { GHC.Types.I# x1_a10l -> case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.<# x1_a10l 0) of _ [Occ=Dead] { GHC.Types.False -> GHC.Types.I# (GHC.Prim.+# x1_a10l 1); GHC.Types.True -> wild_a10j } } }}} The difference is that in the generated Cmm, we don't re-enter `wild_a10j` in the True case, since we know it has already been reduced to WHNF by the first `case`. > Also, if you dump and attach the ASM I'd be happy to sift through and find the problem. I don't have a copy of the instances I was looking at any more, but in one case the change seemed to affect the unique names chosen, which apparently led to laying out functions in a different order... annoying for trying to diff. My main question here is whether it's actually a good idea to use an error/panic in the LambdaFormInfo, or is it better to add a new constructor. I sort of like the error in that if something goes wrong, it's more likely to do so at compile time than at run time; but it's also a bit ugly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 15:21:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 15:21:00 -0000 Subject: [GHC] #9711: Confusing errors when compiling text-1.2.0.0 In-Reply-To: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> References: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> Message-ID: <062.19c66881348ac612d64e7577561e2061@haskell.org> #9711: Confusing errors when compiling text-1.2.0.0 ---------------------------------------+---------------------------------- Reporter: asvyazin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Comment (by asvyazin): Yes, binary version from haskell.org works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 15:22:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 15:22:00 -0000 Subject: [GHC] #9711: Confusing errors when compiling text-1.2.0.0 In-Reply-To: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> References: <047.42c98e3e6ebea5cec2d3dcaa4b2fff3a@haskell.org> Message-ID: <062.c02188bb9eab116bda9ca27e0e844099@haskell.org> #9711: Confusing errors when compiling text-1.2.0.0 ---------------------------------------+---------------------------------- Reporter: asvyazin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by asvyazin): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 17:23:36 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 17:23:36 -0000 Subject: [GHC] #9715: The most minimal Gloss project causes the profiler to fail silently. Message-ID: <044.6ce93f62a8ca3e7527c71ce3cdf48228@haskell.org> #9715: The most minimal Gloss project causes the profiler to fail silently. -------------------------------------+------------------------------------- Reporter: Yxven | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Runtime Difficulty: Unknown | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If you do this: cabal clean cabal configure --enable-library-profiling cabal configure --enable-executable-profiling cabal build dist\build\rogue\rogue.exe +RTS -p and run it for a few seconds before closing it. it will create a rogue.prof file that contains nothing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 19:12:24 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 19:12:24 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.d119f7220b8536b6bdf842bffd103dc9@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): == Summary of AZ understanding of the landscape == === Pros and cons of current approach === Pros Very non-invasive Programs that don't need the information don't touch it; this seems like the strongest advantage Can also bring out comments, tied to smallest enclosing SrcSpan having an annotation. The comments can be in Haddock mode, to aid tool processing. This makes use of the standard Opt_Haddock and Opt_KeepRawTokenStream settings. Cons Parser.y.pp is more complex Actually using the annotations is more complex === Pros and cons of embedded annotations as per Richard Eisenberg === Pros The things you want are right there; no extra mappings to carry around, no lookups, no AnnColon2 stuff. Seems simple and uniform with the existing source locations. Eg. if a keyword 'do' could so be mdo, you might have a Located Bool to indicate. But if it's just do then we'd get Located (), and then we drop it altogether. The in-tree story amounts to not dropping it. Simpler parser cons Breaks lots of existing code, both in GHC and tools that make use of the AST. === Other thoughts === In terms of HaRe, the AST mainipulation will happen via ghc-exactprint. For this, the annotations are used as a starting point for processing. The mechanism intended in ghc-exactprint is to convert the absolute locations to relative locations, much as combinators in a pretty printer. This way when tooling modifies the AST, the output will honour the original layout as much as possible, given changes. Examples Lifting a declaration will preserve the layout of the original but dedented appropriately. Changing the name of an identifier, resulting in a longer or shorter name, just shifts things around naturally. {{{ foo x = x + y where fn a = a + 2 y = fn x }}} becomes {{{ foo xlong = xlong + y where fn a = a + 2 y = fn xlong }}} * The annotations can be easily accessed via a traversal of the appropriate kind. * There is a middle ground, where each AST element that has annotations tied to it in the current system has a single additional field containing [(SrcSpan,Ann]). Equally, the annotations retrieval function can provide all annotations attached to a given SrcSpan, via the current mechanism. * The most natural way to access the annotations is indirectly via a library such as HaRe or ghc-exactprint, as indicated by e.g. hlint, yi and IHaskell developers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 22 23:38:25 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Oct 2014 23:38:25 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.39a36732c6f2d490b47f3d12543189b1@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by heisenbug): * cc: heisenbug (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 23 04:40:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Oct 2014 04:40:15 -0000 Subject: [GHC] #1473: isSpace is too slow In-Reply-To: <044.3c2c0fec916372178c4bf5ce7945c8fa@haskell.org> References: <044.3c2c0fec916372178c4bf5ce7945c8fa@haskell.org> Message-ID: <059.b1531dc88a47a71b9963a1360ecf3266@haskell.org> #1473: isSpace is too slow -------------------------------------+------------------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 6.6.1 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => fixed Comment: Replying to [comment:11 nomeata]: > dfeuer, is 31571270625a690410b794b7cfe48d866c084e74/ghc sufficient to close this ticket or is there more to be done here? I think it's probably best to close it for now, and deal with any other `isSpace` improvements as part of a broader character-classification overhaul. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 23 10:40:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Oct 2014 10:40:24 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.20d6681aef1729ee5f4407c54a43ef30@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) Old description: > After some promising results with a proof-of-concept implementation, I'm > optimistic we can rewrite `integer-gmp` to use only non-allocating GMP > lib functions without suffering from serious regressions. > > If successful, this would > > - allow to avoid the custom GMP allocator hack, and thus > - avoid issues when linking against other C libraries using GMP, > - simplify code, as we would perform all heap allocations in Haskell > code (and never inside Cmm/C code as its done now), > - and finally maybe even remove a few more superfluous temporary heap > allocations. > > This rewrite can be done incrementally. New description: After some promising results with a proof-of-concept implementation, I'm optimistic we can rewrite `integer-gmp` to use only non-allocating GMP lib functions without suffering from serious regressions. If successful, this would - allow to avoid the custom GMP allocator hack, and thus - avoid issues when linking against other C libraries using GMP, - simplify code, as we would perform all heap allocations in Haskell code (and never inside Cmm/C code as its done now), - and finally maybe even remove a few more superfluous temporary heap allocations. see also wiki:Design/IntegerGmp2 -- Comment: started a wiki-page over at wiki:Design/IntegerGmp2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 23 15:12:09 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Oct 2014 15:12:09 -0000 Subject: [GHC] #9716: The list modules need a bit of post-BBP shaking Message-ID: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> #9716: The list modules need a bit of post-BBP shaking -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.8.3 Keywords: lists | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- We currently have an unfortunately named `Data.List.OldList`, and no terribly clear story to explain it. One concept, due in part to me and in part to Carter: 1. Move all the basics needed to implement `instance Foldable []` from `Data.OldList` to `Data.List.Base` (or some similar name). 2. Move all the "extras" like `inits`, `tails`, and `sort` from `Data.OldList` into `Data.List`. 3. Delete `Data.OldList`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 23 15:14:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Oct 2014 15:14:33 -0000 Subject: [GHC] #9716: The list modules need a bit of post-BBP shaking In-Reply-To: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> References: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> Message-ID: <060.15f55662651b7ab779e3bc4c3bfa242f@haskell.org> #9716: The list modules need a bit of post-BBP shaking -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: lists Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * version: 7.8.3 => 7.9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 00:29:16 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 00:29:16 -0000 Subject: [GHC] #9422: EPT caching on --make can make spurious instances visible In-Reply-To: <045.91a3ec26e8fbfdfd2348192932411b44@haskell.org> References: <045.91a3ec26e8fbfdfd2348192932411b44@haskell.org> Message-ID: <060.7966c1fbccc69718b2012ccaa8a5fd80@haskell.org> #9422: EPT caching on --make can make spurious instances visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: duplicate | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: 8427 accepts invalid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * related: => 8427 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 00:29:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 00:29:43 -0000 Subject: [GHC] #8427: GHC accepts invalid program because of EPS poisoning In-Reply-To: <044.8d7cfe02b3e4ed540e00001a8151e1c6@haskell.org> References: <044.8d7cfe02b3e4ed540e00001a8151e1c6@haskell.org> Message-ID: <059.c1399ca7dc989ac4464782d3220e1bd2@haskell.org> #8427: GHC accepts invalid program because of EPS poisoning -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: GHC | than a day) accepts invalid program | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ezyang): #9422 is a duplicate of this bug, and also has a different strategy for solving the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 01:46:34 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 01:46:34 -0000 Subject: [GHC] #9717: More lazy orphan module loading Message-ID: <045.9158d61e70fef57bd7cb8f0956c9909d@haskell.org> #9717: More lazy orphan module loading -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: backpack | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, when we import a module, we eagerly load all of the orphan modules transitively reachable from it (TcRnDriver:tcRnImports). This is a bit of bummer: as module import hierarchies get deeper and deeper, we'll collect more and more orphan instances and load more and more modules eagerly. The idea is to try to arrange for an orphan module not to be loaded, unless we think that it might have a relevant instance. Instead of just recording a list of orphan modules transitively reachable from a module, we will also record a digest of what type classes and types the orphan provides instances for. (This will be similar to the data we record for `ifInstTys` in `IfaceClsInst`.) Now, when we do any operation involving instances, we check and see if there are also orphans which could provide relevant instances (based on the digest) and load those. If an instance could never have been used, we avoid loading its interface file entirely. This doesn't appear to help too much for type families, where we have to load all of the instances anyway in order to check for consistency. A choice to make: Should we record just the class, or also the types involved? It would be best if we could quickly conclude that there are no more instances to load, but this may be difficult if matching against types as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 01:47:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 01:47:05 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.7163af110a7949676716ad09d46709c6@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255 | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) Comment: This is an excellent change, but if it is to be newbie-friendly (which I ideally and egoistically define as "telling the user enough ''not'' to make yet another confused post on Stackoverflow"), maybe it could use a more explanatory error message than "Warning: Tab character"? Something like Tab characters aren't displayed portably. They can cause code to look correctly indented when it isn't, or vice versa, wildly varying dependent on the setup of the editor/browser/web site etc. used to view it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 08:06:58 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 08:06:58 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do Message-ID: <046.5eef205a104808a079ad54238c650906@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- At the moment the `TidyPgm` pass is forced to predict, accurately but unpleasantly, some aspects of what `CorePrep` and `Core2Stg` will do. Reason: * Each `Id` in the interface file records (among other things) the '''arity''' of the `Id`, and whether it has '''CAF references''' * We really only know these two things for sure after `CorePrep`. The conversion from Core to STG makes no structural changes. * However the result of `TidyPgm` (which preceded `CorePrep`) is used to generate the interface file. So it has to predict the arity and CAF-ref status of each `Id`. * This is not good. It restricts what `CorePrep` can do (notably, it must not change the arity of a top-level `Id`), and it leads to unsavoury code (e.g. look at the call to `CorePrep.cvtLitInteger` in `TidyPgm.cafRefsL`. It's also dangerous: an inconsistency could lead to a crash. This is a long-standing problem. My current thought for how to unravel it is this: * `TidyPgm` does not attach arity or CAF-ref info. * Instead, run `CorePrep` after `TidyPgm`, and generate accurate arity and CAF-ref info * Then use that auxiliary mapping during the conversion from tidied program to `ModIface`. I don't think this would be hard. It would mean that the tidied program and the core-prep'd program would have to exist in memory at the same time. An alternative would be to generate the `ModIface` from the tidied program ''sans'' arity and CAF-ref info, and then, after `CorePrep` run over it to add arity and CAF-ref info. (You'd have to do this before generating the fingerprints.) The advantage of this is that the `ModIface` can be a lot smaller than the code for the entire module. A long-standing wart which needs some careful attention. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 08:44:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 08:44:23 -0000 Subject: [GHC] #9719: Improve `mkInteger` interface Message-ID: <042.84328c1dba8cb713d97fde4fbf0592a8@haskell.org> #9719: Improve `mkInteger` interface -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: Keywords: Integer | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `mkInteger` is the current operation provided by the `Integer` libraries to construct (large) integer values. The current type-signature is {{{#!hs mkInteger :: Bool -- sign-bit -> [Int] -- absolute value in 31 bit chunks, least significant first -> Integer }}} A somewhat pathological example of why this representation is not so nice is the following simple CAF {{{#!hs c :: Integer c = 0xf000000000000000 }}} that (this is for a 64bit arch!) gets compiled into the following STG: {{{ ==================== STG syntax: ==================== sat_sJQ :: GHC.Types.Int [LclId, Str=DmdType] = NO_CCS GHC.Types.I#! [3]; sat_sJR :: [GHC.Types.Int] [LclId, Str=DmdType] = NO_CCS :! [sat_sJQ GHC.Types.[]]; sat_sJP :: GHC.Types.Int [LclId, Str=DmdType] = NO_CCS GHC.Types.I#! [1610612736]; sat_sJS :: [GHC.Types.Int] [LclId, Str=DmdType] = NO_CCS :! [sat_sJP sat_sJR]; sat_sJO :: GHC.Types.Int [LclId, Str=DmdType] = NO_CCS GHC.Types.I#! [0]; sat_sJT :: [GHC.Types.Int] [LclId, Str=DmdType] = NO_CCS :! [sat_sJO sat_sJS]; Foo.c :: GHC.Integer.Type.Integer [GblId, Str=DmdType] = \u srt:SRT:[0Y :-> GHC.Integer.Type.mkInteger, sJT :-> sat_sJT] [] GHC.Integer.Type.mkInteger GHC.Types.True sat_sJT; }}} Instead a more "natural" `mkInteger` would be desirable, possibly in the style of `unpackCString#`, in terms of a packed/unboxed vector of machine- word-sized chunks. A better `mkInteger` could then take a `ByteArray#` or a `Addr#` + length instead, e.g. {{{#!hs mkInteger :: Int# -- signum(n) = sign of encoded Integer -- abs(n) = number of machine-word sized chunks -> Addr# -- pointer to start of machine-word sized chunks, -- least-significant chunk first -> Integer }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 08:48:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 08:48:28 -0000 Subject: [GHC] #9719: Improve `mkInteger` interface In-Reply-To: <042.84328c1dba8cb713d97fde4fbf0592a8@haskell.org> References: <042.84328c1dba8cb713d97fde4fbf0592a8@haskell.org> Message-ID: <057.40c13f88d3a2604f8280351943787119@haskell.org> #9719: Improve `mkInteger` interface -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Integer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > `mkInteger` is the current operation provided by the `Integer` libraries > to construct (large) integer values. The current type-signature is > > {{{#!hs > mkInteger :: Bool -- sign-bit > -> [Int] -- absolute value in 31 bit chunks, least significant > first > -> Integer > }}} > > A somewhat pathological example of why this representation is not so nice > is the following simple CAF > > {{{#!hs > c :: Integer > c = 0xf000000000000000 > }}} > > that (this is for a 64bit arch!) gets compiled into the following STG: > > {{{ > ==================== STG syntax: ==================== > sat_sJQ :: GHC.Types.Int > [LclId, Str=DmdType] = > NO_CCS GHC.Types.I#! [3]; > sat_sJR :: [GHC.Types.Int] > [LclId, Str=DmdType] = > NO_CCS :! [sat_sJQ GHC.Types.[]]; > sat_sJP :: GHC.Types.Int > [LclId, Str=DmdType] = > NO_CCS GHC.Types.I#! [1610612736]; > sat_sJS :: [GHC.Types.Int] > [LclId, Str=DmdType] = > NO_CCS :! [sat_sJP sat_sJR]; > sat_sJO :: GHC.Types.Int > [LclId, Str=DmdType] = > NO_CCS GHC.Types.I#! [0]; > sat_sJT :: [GHC.Types.Int] > [LclId, Str=DmdType] = > NO_CCS :! [sat_sJO sat_sJS]; > Foo.c :: GHC.Integer.Type.Integer > [GblId, Str=DmdType] = > \u srt:SRT:[0Y :-> GHC.Integer.Type.mkInteger, sJT :-> sat_sJT] [] > GHC.Integer.Type.mkInteger GHC.Types.True sat_sJT; > }}} > > > Instead a more "natural" `mkInteger` would be desirable, possibly in the > style of `unpackCString#`, in terms of a packed/unboxed vector of > machine-word-sized chunks. A better `mkInteger` could then take a > `ByteArray#` or a `Addr#` + length instead, e.g. > > {{{#!hs > mkInteger :: Int# -- signum(n) = sign of encoded Integer > -- abs(n) = number of machine-word sized chunks > -> Addr# -- pointer to start of machine-word sized chunks, > -- least-significant chunk first > -> Integer > }}} New description: `mkInteger` is the current operation provided by the `Integer` libraries to construct (large) integer values. The current type-signature is {{{#!hs mkInteger :: Bool -- sign-bit -> [Int] -- absolute value in 31 bit chunks, least significant first -> Integer }}} A somewhat pathological example of why this representation is not so nice is the following simple CAF {{{#!hs c :: Integer c = 0xf000000000000000 }}} that (this is for a 64bit arch!) gets compiled into the following STG: {{{ ==================== STG syntax: ==================== sat_sJQ :: GHC.Types.Int [LclId, Str=DmdType] = NO_CCS GHC.Types.I#! [3]; sat_sJR :: [GHC.Types.Int] [LclId, Str=DmdType] = NO_CCS :! [sat_sJQ GHC.Types.[]]; sat_sJP :: GHC.Types.Int [LclId, Str=DmdType] = NO_CCS GHC.Types.I#! [1610612736]; sat_sJS :: [GHC.Types.Int] [LclId, Str=DmdType] = NO_CCS :! [sat_sJP sat_sJR]; sat_sJO :: GHC.Types.Int [LclId, Str=DmdType] = NO_CCS GHC.Types.I#! [0]; sat_sJT :: [GHC.Types.Int] [LclId, Str=DmdType] = NO_CCS :! [sat_sJO sat_sJS]; Foo.c :: GHC.Integer.Type.Integer [GblId, Str=DmdType] = \u srt:SRT:[0Y :-> GHC.Integer.Type.mkInteger, sJT :-> sat_sJT] [] GHC.Integer.Type.mkInteger GHC.Types.True sat_sJT; }}} Moreover, determining how much space to allocate for the resulting `Integer` is a bit work as it for one, you need to traverse the list twice, and then you can't simply derive the exact allocation amount by the list-length alone due to the odd 31-bit chunks. Instead a more "natural" `mkInteger` would be desirable, possibly in the style of `unpackCString#`, in terms of a packed/unboxed vector of machine- word-sized chunks. A better `mkInteger` could then take a `ByteArray#` or a `Addr#` + length instead, e.g. {{{#!hs mkInteger :: Int# -- signum(n) = sign of encoded Integer -- abs(n) = number of machine-word sized chunks -> Addr# -- pointer to start of machine-word sized chunks, -- least-significant chunk first -> Integer }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 09:43:59 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 09:43:59 -0000 Subject: [GHC] #9720: libffi compilation does not use bundled g++ on Windows Message-ID: <045.bf722a023618f6ec3164b6d2ecf1b967@haskell.org> #9720: libffi compilation does not use bundled g++ on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Building GHC fails on Windows (at least on mingw32) if there is no host g++ compiler available. The cause seems to be that configure script looks for a C++ compiler and fails to find one. Here's the invocation of the libffi configure script from the main build: cd libffi && \ \ cd build && \ CC=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/inplace/mingw/bin/gcc.exe \ LD=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/inplace/mingw/bin/ld.exe \ AR=/usr/bin/ar \ NM=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/inplace/mingw/bin/nm.exe \ RANLIB=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/inplace/mingw/bin/ranlib.exe \ CFLAGS=" -U__i686 -march=i686 -fno-stack-protector -w" \ LDFLAGS=" -w" \ "/bin/sh" ./configure \ --prefix=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/libffi/build/inst \ --libdir=C:/Users/Gintas/Downloads/msys32/home/Gintas/ghc/libffi/build/inst/lib \ --enable-static=yes \ --enable-shared=no \ --host=i386-unknown-mingw32 Note that CC is overridden, but CXX is not. The configure script then looks for a C++ compiler and finds KCC, which is not even a compiler but a kerberos tool: checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl.exe... no checking for FCC... no checking for KCC... KCC checking whether we are using the GNU C++ compiler... no checking whether KCC accepts -g... no checking dependency style of KCC... none This causes the configure script to fail later on. g++ is not actually used in the build (looks like it's only needed for one test case), passing in gcc for CXX seems to work fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 09:45:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 09:45:32 -0000 Subject: [GHC] #9720: libffi compilation does not use bundled g++ on Windows In-Reply-To: <045.bf722a023618f6ec3164b6d2ecf1b967@haskell.org> References: <045.bf722a023618f6ec3164b6d2ecf1b967@haskell.org> Message-ID: <060.813706dfddd2b77d0b4aefcaacf33126@haskell.org> #9720: libffi compilation does not use bundled g++ on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D370 | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => patch * differential: => Phab:D370 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 15:19:28 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 15:19:28 -0000 Subject: [GHC] #7378: Identical alts/bad divInt# code In-Reply-To: <056.22cc8de2dae750ab03e1570e152919d7@haskell.org> References: <056.22cc8de2dae750ab03e1570e152919d7@haskell.org> Message-ID: <071.2dd86e36e6657e910c66150430e1cf02@haskell.org> #7378: Identical alts/bad divInt# code -------------------------------------+------------------------------------- Reporter: | Owner: daniel.is.fischer | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: 7360 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by TomSchrijvers): * cc: tom.schrijvers@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 15:20:12 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 15:20:12 -0000 Subject: [GHC] #2132: Optimise nested comparisons In-Reply-To: <046.ba0b25228872b80f2daed8d0d0f8352f@haskell.org> References: <046.ba0b25228872b80f2daed8d0d0f8352f@haskell.org> Message-ID: <061.b3708ca770a8722ca6b0ed411e40617f@haskell.org> #2132: Optimise nested comparisons -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by TomSchrijvers): * cc: tom.schrijvers@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 15:33:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 15:33:05 -0000 Subject: [GHC] #9721: RecordWildCards panic Message-ID: <050.e5e3caba02351eeadc72b707a2f9ddab@haskell.org> #9721: RecordWildCards panic -------------------------------------+------------------------------------- Reporter: jorgemendes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- GHC 7.4.1 (Debian 7.7 and Ubuntu 12.04.5 LTS) panics with: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for i386-unknown-linux): compiler/rename/RnPat.lhs:535:39-79: Irrefutable pattern failed for pattern gres@(gre : _) }}} I found a minimal test case to exemplify this issue: {{{#!hs module Foo where import Bar (Bar (Bar)) foo :: Bar -> () foo Bar {..} = () }}} {{{#!hs module Bar where data Bar = Bar { barA :: Int, barB :: Int } }}} A workaround is to import all data fields in module Foo: {{{#!hs import Bar (Bar (..)) }}} I also tried this with GHC 7.6.3 (Mac OS X), with no warnings nor errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 15:45:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 15:45:22 -0000 Subject: [GHC] #9721: RecordWildCards panic In-Reply-To: <050.e5e3caba02351eeadc72b707a2f9ddab@haskell.org> References: <050.e5e3caba02351eeadc72b707a2f9ddab@haskell.org> Message-ID: <065.d66caec2d124c8aae46c300bb89f5fa6@haskell.org> #9721: RecordWildCards panic ---------------------------------------------+--------------------------- Reporter: jorgemendes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------------+--------------------------- Comment (by Yuras): Looks similar to #5892 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 16:33:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 16:33:22 -0000 Subject: [GHC] #9721: RecordWildCards panic In-Reply-To: <050.e5e3caba02351eeadc72b707a2f9ddab@haskell.org> References: <050.e5e3caba02351eeadc72b707a2f9ddab@haskell.org> Message-ID: <065.7e43052ab99154886722038556198d30@haskell.org> #9721: RecordWildCards panic ---------------------------------------------+--------------------------- Reporter: jorgemendes | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------------+--------------------------- Changes (by simonpj): * status: new => closed * resolution: => wontfix Comment: Yes, it's ok in 7.6 and 7.8. We aren't going to fix 7.4 I'm afraid. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 18:54:38 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 18:54:38 -0000 Subject: [GHC] #8100: Standalone deriving using template haskell In-Reply-To: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> References: <044.0add0211f14c3e1d8f3c2c4a3d5c37d4@haskell.org> Message-ID: <059.90c3b536f08c432a0b60f3a67b01f334@haskell.org> #8100: Standalone deriving using template haskell -------------------------------------+------------------------------------- Reporter: acube | Owner: goldfire Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): See [wiki:Design/TemplateHaskellGADTs] for a related change to the `Dec` type I'd like feedback on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 18:54:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 18:54:55 -0000 Subject: [GHC] #9527: Add Generic instances for Language.Haskell.TH In-Reply-To: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> References: <042.dfd174000f78899025cbeb254e3635a2@haskell.org> Message-ID: <057.cc17178c26a25a3476fefa9dbe6b0862@haskell.org> #9527: Add Generic instances for Language.Haskell.TH -------------------------------------+------------------------------------- Reporter: nh2 | Owner: goldfire Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Moderate (less Operating System: | than a day) Unknown/Multiple | Blocked By: 9526 Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): See [wiki:Design/TemplateHaskellGADTs] for a related change to the `Dec` type I'd like feedback on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 18:55:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 18:55:14 -0000 Subject: [GHC] #9064: Support default class method signatures in Template Haskell In-Reply-To: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> References: <047.e88ba6dee52425f96ee400d414e6b173@haskell.org> Message-ID: <062.98200087441d267ed9b2c744732a6815@haskell.org> #9064: Support default class method signatures in Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): See [wiki:Design/TemplateHaskellGADTs] for a related change to the `Dec` type I'd like feedback on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 21:26:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 21:26:40 -0000 Subject: [GHC] #9574: GHC Panic: No Skolem Info In-Reply-To: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> References: <045.a8d5c4a0e8ebaca5dabb9fd5e04d534e@haskell.org> Message-ID: <060.7dc1d2977ba11c72f9d5da984befbaf9@haskell.org> #9574: GHC Panic: No Skolem Info -------------------------------------+------------------------------------- Reporter: ian_mi | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.9 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: | -------------------------------------+------------------------------------- Comment (by monoidal): Bumping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 22:38:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 22:38:33 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor Message-ID: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | crash Related Tickets: | Test Case: ghcirun004 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I was recently repeatedly running the validate test suite and got this test to fail: {{{ Actual stderr output differs from expected: --- /dev/null 2014-02-15 17:35:19.578872448 -0800 +++ ./ghci/should_run/ghcirun004.run.stderr 2014-10-24 14:46:15.289211100 -0700 @@ -0,0 +1 @@ +ghc: ioManagerWakeup: write: Bad file descriptor *** unexpected failure for ghcirun004(ghci) }}} Might be related to #5443. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 23:25:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 23:25:00 -0000 Subject: [GHC] #9296: Acquire all_tasks_mutex in forkProcess In-Reply-To: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> References: <044.ae97a3ce059e8213fe20f693f6d103a4@haskell.org> Message-ID: <059.083bc1894d3b390fdf103ddeaa8a6f7d@haskell.org> #9296: Acquire all_tasks_mutex in forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): Fixed in 16403f0d182d2d3d0b1fbe5ad778ead4bfcb7e16. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 24 23:47:50 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Oct 2014 23:47:50 -0000 Subject: [GHC] #9252: Generalize hs-boot files to be more like module signatures In-Reply-To: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> References: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> Message-ID: <060.db243b1764fe09cecbc19f1250a82c6b@haskell.org> #9252: Generalize hs-boot files to be more like module signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: backpack Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D130 | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"aa4799534225e3fc6bbde0d5e5eeab8868cc3111/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="aa4799534225e3fc6bbde0d5e5eeab8868cc3111" Implementation of hsig (module signatures), per #9252 Summary: Module signatures, like hs-boot files, are Haskell modules which omit value definitions and contain only signatures. This patchset implements one particular aspect of module signature, namely compiling them against a concrete implementation. It works like this: when we compile an hsig file, we must be told (via the -sig-of flag) what module this signature is implementing. The signature is compiled into an interface file which reexports precisely the entities mentioned in the signature file. We also verify that the interface is compatible with the implementation. This feature is useful in a few situations: 1. Like explicit import lists, signatures can be used to reduce sensitivity to upstream changes. However, a signature can be defined once and then reused by many modules. 2. Signatures can be used to quickly check if a new upstream version is compatible, by typechecking just the signatures and not the actual modules. 3. A signature can be used to mediate separate modular development, where the signature is used as a placeholder for functionality which is loaded in later. (This is only half useful at the moment, since typechecking against signatures without implementations is not implemented in this patchset.) Unlike hs-boot files, hsig files impose no performance overhead. This patchset punts on the type class instances (and type families) problem: instances simply leak from the implementation to the signature. You can explicitly specify what instances you expect to have, and those will be checked, but you may get more instances than you asked for. Our eventual plan is to allow hiding instances, but to consider all transitively reachable instances when considering overlap and soundness. ToDo: signature merging: when a module is provided by multiple signatures for the same base implementation, we should not consider this ambiguous. ToDo: at the moment, signatures do not constitute use-sites, so if you write a signature for a deprecated function, you won't get a warning when you compile the signature. Future work: The ability to feed in shaping information so that we can take advantage of more type equalities than might be immediately evident. Signed-off-by: Edward Z. Yang Test Plan: validate and new tests Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, ezyang, carter, goldfire Differential Revision: https://phabricator.haskell.org/D130 GHC Trac Issues: #9252 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 00:27:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 00:27:04 -0000 Subject: [GHC] #9720: libffi compilation does not use bundled g++ on Windows In-Reply-To: <045.bf722a023618f6ec3164b6d2ecf1b967@haskell.org> References: <045.bf722a023618f6ec3164b6d2ecf1b967@haskell.org> Message-ID: <060.0148dd0c2d556d973d55842eeb67e38e@haskell.org> #9720: libffi compilation does not use bundled g++ on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D370 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"0855b249aba370e285c866d04ce7e4c1183311b9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0855b249aba370e285c866d04ce7e4c1183311b9" Pass in CXX to libffi's configure script. Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D370 GHC Trac Issues: #9720 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 07:13:40 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 07:13:40 -0000 Subject: [GHC] #9345: Data.List.inits is extremely slow In-Reply-To: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> References: <045.8c8d33c1ac31f0ad81573670a0018873@haskell.org> Message-ID: <060.9c3ecde180c4c31e2d75a82cbf313efc@haskell.org> #9345: Data.List.inits is extremely slow -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: merge Priority: high | Milestone: 7.8.4 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D329 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: closed => merge * milestone: 7.10.1 => 7.8.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 08:23:35 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 08:23:35 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.15500e71cebf0a721e6de03dbdf8af5c@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): I've created a self contained single module repro, attached as the GadtVsData.hs file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 09:20:16 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 09:20:16 -0000 Subject: [GHC] #5966: getAppUserDataDirectory does not respect XDG specification In-Reply-To: <047.bc37781e7713df0d1b7455991f78caf3@haskell.org> References: <047.bc37781e7713df0d1b7455991f78caf3@haskell.org> Message-ID: <062.32401f3a3643e30f4503a92775473012@haskell.org> #5966: getAppUserDataDirectory does not respect XDG specification -------------------------------------+------------------------------------- Reporter: ordcoder | Owner: ekmett Type: bug | Status: upstream Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.4.1 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: 6077 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) * status: new => upstream Comment: Filed this upstream as https://github.com/haskell/directory/issues/6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 11:16:03 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 11:16:03 -0000 Subject: [GHC] #9703: Add missing calling conventions to Template Haskell In-Reply-To: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> References: <044.66b2f8ad99eea15ad1544e4f8b52a5c2@haskell.org> Message-ID: <059.48dff4c6c8ef6f19dc85f96e70503826@haskell.org> #9703: Add missing calling conventions to Template Haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: ekmett Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.9 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D353 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 11:19:01 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 11:19:01 -0000 Subject: [GHC] #9723: Give Tab warning only once per file Message-ID: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> #9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Currently, when compiling a tabbed file, GHC spits out a huge number of warnings: {{{ Main.hs:1:1: Warning: Tab character [..] Main.hs:89:1: Warning: Tab character Main.hs:90:1: Warning: Tab character Main.hs:91:1: Warning: Tab character Main.hs:92:1: Warning: Tab character Main.hs:99:4: Warning: Tab character Main.hs:100:4: Warning: Tab character Main.hs:101:4: Warning: Tab character }}} This is annoying and not very nice to our users. I suggest to replace it by {{{ This file contains tabs (e.g. line n column m); please use spaces instead }}} or (to be nice to tools that parse this output) {{{ Main.hs:1:1: Tab found here, and in n further locations. Please use spaces instead. }}} (This is clearly a low priority request, but also possibly some low- hanging fruit for new contributors.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 11:20:37 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 11:20:37 -0000 Subject: [GHC] #9262: Allow free variables in reifyInstances In-Reply-To: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> References: <047.749a75076140dfc26b9c87d7bfbdeb74@haskell.org> Message-ID: <062.dcd98ac1992e6f6c0333acdb6479200c@haskell.org> #9262: Allow free variables in reifyInstances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: feature | Status: patch request | Milestone: Priority: normal | Version: 7.8.2 Component: Template | Keywords: Haskell | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D359 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 11:25:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 11:25:21 -0000 Subject: [GHC] #9710: Clean up Trac versions In-Reply-To: <047.e9e7ccfe79be5260af9a1e1e7a3f431d@haskell.org> References: <047.e9e7ccfe79be5260af9a1e1e7a3f431d@haskell.org> Message-ID: <062.5b6ce0c5c3962e8ecd9f3c312680ef01@haskell.org> #9710: Clean up Trac versions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.3 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): * owner: => hvr * component: Build System => Trac & Git -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 11:34:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 11:34:04 -0000 Subject: [GHC] #9549: deriveConstants fails on OpenBSD In-Reply-To: <045.280f1382fe569e58794f97c954f259a6@haskell.org> References: <045.280f1382fe569e58794f97c954f259a6@haskell.org> Message-ID: <060.54f02a5866a4318a3153b76884c5bc79@haskell.org> #9549: deriveConstants fails on OpenBSD -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: OpenBSD | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D332 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 11:36:21 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 11:36:21 -0000 Subject: [GHC] #9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform In-Reply-To: <047.b513f6d5b7f08c66f27c72ad328610e0@haskell.org> References: <047.b513f6d5b7f08c66f27c72ad328610e0@haskell.org> Message-ID: <062.0acbd7944d858fe131dbae32e43553f8@haskell.org> #9593: Edit New issue Building current ghc HEAD fails with globalRegMaybe not defined for this platform -------------------------------------+------------------------------------- Reporter: angerman | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (LLVM) | Keywords: Resolution: fixed | Architecture: arm Operating System: MacOS X | Difficulty: Easy (less than 1 Type of failure: Building | hour) GHC failed | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D208 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 11:47:04 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 11:47:04 -0000 Subject: [GHC] #9710: Clean up Trac versions In-Reply-To: <047.e9e7ccfe79be5260af9a1e1e7a3f431d@haskell.org> References: <047.e9e7ccfe79be5260af9a1e1e7a3f431d@haskell.org> Message-ID: <062.e32fa6cbfcf418cbdc586d74c50f068d@haskell.org> #9710: Clean up Trac versions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by hvr): The problem with the ordering is that Trac orders the versions by its associated release-date. However, not all versions have a release-date set (it's a bit of work to find out all historic release dates so I haven't filled in everything yet), in which case non-released versions are put in front. (Note also that `version` in Trac can be any string, i.e. not necessarily a dotted integer) Also, I'm afraid deleting old versions from the version table will render the remaining historic Ticket meta-data inconsistent or to the very least, destroy historic information. Ideally, the version field is used to denote the first version a bug/issue is known to exist in (regardless whether that version is "supported" or not). The milestone is used for declaring the version where the ticket is planned to be or was fixed. So that allows you to see the "life-span" of a bug quite easily right from the ticket-meta data. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 11:57:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 11:57:07 -0000 Subject: [GHC] #9713: Update comment about C helper for dynamic exports. In-Reply-To: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> References: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> Message-ID: <059.af76a613bd810dd0b6bb43f4981bb1b7@haskell.org> #9713: Update comment about C helper for dynamic exports. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by thomie): No knowing anything about this code, I have the following questions/remarks, mostly about the commit message: * Please mention the Trac number. * Patch does more than update a comment, needs better title. * What does it mean that f_helper is a helper in C "approximately"? * In which commit did the RTS API change? * Are there other calls to rts_evalIO anywhere that need updating? * Why did this not get caught by a test? Should one be added? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 13:04:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 13:04:49 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.9f0833ecadc198ee160719d8bdeac330@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255 | -------------------------------------+------------------------------------- Comment (by thomie): I don't think this patch as is stands is Python3 compabible. Please see my inline comments in https://phabricator.haskell.org/rGHC972ba1210d1bb535c41526ce396c0f086d30b59a -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 13:07:41 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 13:07:41 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.6692f2bf904fd9c9907f0471e26f8fbd@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: infoneeded request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 13:16:52 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 13:16:52 -0000 Subject: [GHC] #9720: libffi compilation does not use bundled g++ on Windows In-Reply-To: <045.bf722a023618f6ec3164b6d2ecf1b967@haskell.org> References: <045.bf722a023618f6ec3164b6d2ecf1b967@haskell.org> Message-ID: <060.399e1a172f3cea0465e288ed04c585d6@haskell.org> #9720: libffi compilation does not use bundled g++ on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.8.3 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D370 | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 14:17:17 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 14:17:17 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.c2f01ec43a1da3f9162e64e91e34f0bd@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: D349 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => D349 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 14:17:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 14:17:46 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.5bf28557f040bd51d0a2f69b05fa527b@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Changes (by thomie): * differential: D349 => Phab:D349 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 17:53:06 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 17:53:06 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.25da17b1ff3089048b48fb923684a3ef@haskell.org> #9160: Panic: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: #4524 Test Case: | indexed_types/should_fail/T9160 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by mjo): * status: closed => new * resolution: fixed => Comment: I'm seeing the same symptoms with 7.8.3: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.3 }}} Only with -O2 set, again. {{{ $ cd singletons-1.0/ $ runghc Setup.hs configure --user -O2 Configuring singletons-1.0... $ runghc Setup.hs build ... [39 of 45] Compiling Data.Singletons.Prelude.List ( src/Data/Singletons/Prelude/List.hs, dist/build/Data/Singletons/Prelude/List.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): Template variable unbound in rewrite rule }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 18:09:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 18:09:49 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.51ad4e87e4eb8e3770126e2257799d78@haskell.org> #9160: Panic: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: x86_64 (amd64) Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: #4524 Test Case: | indexed_types/should_fail/T9160 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mjo): I should also mention that the test cases passes, i.e. fails: {{{ $ ghc T9160.hs [1 of 1] Compiling T9160 ( T9160.hs, T9160.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. T9160.hs:18:8: Type indexes must match class instance head Found ?* -> *? but expected ?*? In the type instance declaration for ?F? In the instance declaration for ?C (a :: *)? }}} Same thing happens with -O2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 18:42:53 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 18:42:53 -0000 Subject: [GHC] #9724: reexport IsList class from a trustworthy module Message-ID: <044.b4b824d4864a7071bef003961687614b@haskell.org> #9724: reexport IsList class from a trustworthy module -------------------------------------+------------------------------------- Reporter: int-e | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: -------------------------------------+------------------------------------- ==== Motivation GHC's Safe Haskell extension relies to a large extent on inferring safety of modules automatically. As a concrete example, [[http://hackage.haskell.org/package/data-default|data-default]] used to be inferred safe. This is no longer the case, because [[http://hackage.haskell.org/package/dlist-0.7.1|dlist-0.7.1]] added an {{{IsList}}} instance for difference lists. The only way to do that currently is to import the relevant parts of {{{GHC.Exts}}}, and that module is not safe. Of course the resulting non-safety of the {{{Data.DList}}} module can be fixed by adding a {{{TrustWorthy}}} pragma to the module and trusting the {{{dlist}}} package. But that is unsatisfactory, because there is nothing unsafe about providing an instance for the {{{IsList}}} class. This issue is bound to pop up in other packages as well. ==== Proposed Solution (this is one of many possibilities) Add a {{{GHC.Exts.Safe}}} module that is marked {{{TrustWorthy}}} and reexports the {{{IsList}}} class, and possibly other things from {{{GHC.Exts}}} that are safe to use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 20:58:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 20:58:49 -0000 Subject: [GHC] #9725: Constraint deduction failure Message-ID: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I get a strange error message like this {{{ [1 of 1] Compiling Main ( 08-10.hs, interpreted ) 08-10.hs:254:33: Could not deduce (KnownLoc (ent par1 a)) arising from a use of ?Hidden'? from the context (List ConfFamily ts) bound by the type signature for locAware :: List ConfFamily ts => (forall (i :: k). KnownLoc (ent par i) => ConfFamily (Facility (ent par i)) ts) -> Con ConfFamily (On ent par) at 08-10.hs:251:13-160 or from (ent par a ~ 'Monitor par1 mp, KnownLoc ('Monitor par1 mp)) bound by a pattern with constructor MonitorF :: forall (par :: Entity) (mp :: MonitorPoint). KnownLoc ('Monitor par mp) => String -> String -> Observer -> Bool -> Facility ('Monitor par mp), in an equation for ?h? at 08-10.hs:254:19-28 In the expression: Hidden' (d f) In an equation for ?h?: h (Hide f@(MonitorF {})) = Hidden' (d f) In an equation for ?locAware?: locAware descr = Abstr h where h :: (ent `On` par) -> ConfFamily (ent `On` par) ts h (Hide f@(MonitorF {})) = Hidden' (d f) d :: KnownLoc (ent par i) => Facility (ent par i) -> ConfFamily (Facility (ent par i)) ts d _ = descr Failed, modules loaded: none. }}} I have many language extensions active, such as, `DataKinds`, `ScopedTypeVariables`, etc. If somebody says this indeed looks like a bug, then I'll try to post a minimal reproduction case. ** My reasoning goes like this ** Here are the relevant facts that GHC figured out from a GADT pattern match: `(ent par a ~ 'Monitor par1 mp, KnownLoc ('Monitor par1 mp))` From this I discover these equalities: {{{ ent === 'Monitor (*) par === par1 (**) a === mp (***) }}} Substituring `(*)`^-1^ and `(***)`^-1^ into the given `KnownLoc ('Monitor par1 mp)` results in the desired `KnownLoc (ent par1 a)` Looks like a bug, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 21:21:34 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 21:21:34 -0000 Subject: [GHC] #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 Message-ID: <045.27c764f1bc949f892e614a3885cf6189@haskell.org> #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- swprintf has different signatures in mingw32, where it does not include the buffer size, and in mingw-w64, where it does. That of course breaks the code as mingw-w64 treats the pointer to the format string as a size_t. Bummer: C:/.../inplace/mingw/i686-w64-mingw32/include/swprintf.inl:30:5: note: expected 'size_t' but argument is of type 'short unsigned int *' int swprintf (wchar_t *__stream, size_t __count, const wchar_t *__format, ...) ^ rts\Linker.c:1986:12: warning: passing argument 2 of 'swprintf' makes integer from pointer without a cast [enabled by default] swprintf(buf, L"lib%s.DLL", dll_name); I have a fix pending to use snwprintf instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 22:05:15 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 22:05:15 -0000 Subject: [GHC] #7320: GHC crashes when building on 32-bit Linux in a Linode In-Reply-To: <043.0168db82b571fa620930b74d5d40cf16@haskell.org> References: <043.0168db82b571fa620930b74d5d40cf16@haskell.org> Message-ID: <058.abcff5873e65498308bab1bcd03a2f41@haskell.org> #7320: GHC crashes when building on 32-bit Linux in a Linode ---------------------------------------------+---------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------------+---------------------------- Changes (by gintas): * cc: gintas, simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 22:14:47 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 22:14:47 -0000 Subject: [GHC] #9727: -Werror=unused-but-set-variable causes validation error on Windows Message-ID: <045.46cb8c51f4cb0e085fad55ca8cdfc48e@haskell.org> #9727: -Werror=unused-but-set-variable causes validation error on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- After upgrading the inplace mingw to gcc 4.8.3, validate.sh fails with the following error: cc1.exe: error: -Werror=unused-but-set-variable: No option -Wunused-but- set-variable The cause is in mk/validate-settings.mk: ifeq "$(GccLT46)" "NO" SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined SRC_CC_WARNING_OPTS += -Wno-error=inline endif This checks the version of the inplace mingw, but the actual command line that fails is not using the inplace mingw (4.8.3), but the host ghc's mingw (4.5.3, in /usr/local/mingw). Command line: C:/Users/Gintas/Downloads/msys32/usr/local/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1.exe -quiet -v -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -Icompiler/stage1/build/autogen -IC:\Users\Gintas\Downloads\msys32\home\Gintas\ghc\inplace/lib/include/ -iprefix c:\users\gintas\downloads\msys32\usr\local\mingw\bin\../lib/gcc/mingw32/4.5.2/ -isystem C:/Users/Gintas/Downloads/msys32/usr/local/mingw/bin/../lib/gcc/mingw32/4.5.2/include -isystem C:/Users/Gintas/Downloads/msys32/usr/local/mingw/bin/../lib/gcc/mingw32/4.5.2 /include-fixed -U__i686 -Di386_HOST_ARCH=1 -Dmingw32_HOST_OS=1 -D__GLASGOW_HASKELL__=708 -U__i686 -isystemC:\Users\Gintas\Downloads\msys32\usr\local\lib\process-1.2.0.0\include -isystemC:\Users\Gintas\Downloads\msys32\usr\local\lib\directory-1.2.1.0\include -isystemC:\Users\Gintas\Downloads\msys32\usr\local\lib\time-1.4.2\include -isystemC:\Users\Gintas\Downloads\msys32\usr\local\lib\Win32-2.3.0.2\include -isystemC:\Users\Gintas\Downloads\msys32\usr\local\lib\bytestring-0.10.4.0\include -isystemC:\Users\Gintas\Downloads\msys32\usr\local\lib\base-4.7.0.1\include -isystemC:\Users\Gintas\Downloads\msys32\usr\local\lib\integer- gmp-0.5.1.0\include -isystemC:\Users\Gintas\Downloads\msys32\usr\local\lib/include -include compiler/stage1/build/autogen/cabal_macros.h compiler/stage1/build/Fingerprint_hsc_make.c -quiet -dumpbase Fingerprint_hsc_make.c -march=i686 -march=i686 -auxbase-strip compiler/stage1/build/Fingerprint_hsc_make.o -Werror -Wall -Werror=unused- but-set-variable -Wno-error=inline -version -fno-stack-protector -o C:\Users\Gintas\Downloads\msys32\tmp\ccvafaLk.s -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 22:24:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 22:24:39 -0000 Subject: [GHC] #9727: -Werror=unused-but-set-variable causes validation error on Windows In-Reply-To: <045.46cb8c51f4cb0e085fad55ca8cdfc48e@haskell.org> References: <045.46cb8c51f4cb0e085fad55ca8cdfc48e@haskell.org> Message-ID: <060.01c8975db00f0a763ad87ae545d512e5@haskell.org> #9727: -Werror=unused-but-set-variable causes validation error on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D373 | -------------------------------------+------------------------------------- Changes (by gintas): * differential: => Phab:D373 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 22:49:23 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 22:49:23 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.570237496a0e3ed764a911611b976e8c@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): The thread starting at http://www.haskell.org/pipermail/glasgow-haskell- users/2013-December/024466.html may be relevant. In short, GHC does not decompose `f x ~ g y` into `f ~ g, x ~ y` unless it knows already that `f` and `g` (or equivalently `x` and `y`) have the same kind. It seems to me that GHC should be able to ''conclude'' from `f x ~ g y` that `f` and `g` have the same kind, but maybe it has no way to represent this? I think there is a related Trac ticket also, but I couldn't find it. Maybe adding kind annotations for some of the type variables involved would help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 25 23:47:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Oct 2014 23:47:49 -0000 Subject: [GHC] #9715: The most minimal Gloss project causes the profiler to fail silently. In-Reply-To: <044.6ce93f62a8ca3e7527c71ce3cdf48228@haskell.org> References: <044.6ce93f62a8ca3e7527c71ce3cdf48228@haskell.org> Message-ID: <059.ec4fa451dcb593f60ce9824c95163980@haskell.org> #9715: The most minimal Gloss project causes the profiler to fail silently. -------------------------------------+------------------------------------- Reporter: Yxven | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): My guess is that gloss or a C library it uses is exiting abruptly and not giving the GHC RTS a chance to shut down and write out the profiling information. For example if I build with `-debug` instead of profiling and run with `+RTS -Ds` the output ends with {{{ ... 7f1da4134740: freeing capability 0 7f1da4134740: task exiting }}} whereas a Hello, World program prints {{{ ... 7f198b4fd700: freeing capability 0 7f198dbf5740: shutting down capability 0, attempt 1598 7f198dbf5740: task exiting 7f198dbf5740: freeing task manager, 0 tasks still running 7f198dbf5740: removed cap 0 from capset 0 7f198dbf5740: removed cap 0 from capset 1 7f198dbf5740: cap 0: shutting down 7f198dbf5740: deleted capset 0 7f198dbf5740: deleted capset 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 03:54:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 03:54:32 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.2494ceab1060d5e608d9c82f230a5d65@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 rwbarton]: > It seems to me that GHC should be able to ''conclude'' from `f x ~ g y` that `f` and `g` have the same kind, but maybe it has no way to represent this? > > I think there is a related Trac ticket also, but I couldn't find it. > > Maybe adding kind annotations for some of the type variables involved would help? I don't know what you're doing, but if I understand what you're getting at, I don't think it's true in general. Consider {{{#!hs {-# LANGUAGE TypeFamilies, TypeOperators, KindSignatures #-} module ConstraintEq where type family Id a :: * where Id x = x type family YaKnow a :: * where YaKnow x = x Int }}} Here `Id Int ~ YaKnow Id`, but `Id` and `YaKnow` have different kinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 03:57:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 03:57:59 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.3186577a5de3c117d582a28a17e21297@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rwbarton): `f` and `g` here are understood to vary over type constructors, not type synonyms or type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 04:02:38 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 04:02:38 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.2fe40a9a7ab7321d7e13574412624c74@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 rwbarton]: > `f` and `g` here are understood to vary over type constructors, not type synonyms or type families. Oh, I see. That puts a different spin on things. -- Ticket URL: GHC The Glasgow Haskell Compiler From kyrab at mail.ru Sun Oct 26 06:36:53 2014 From: kyrab at mail.ru (kyra) Date: Sun, 26 Oct 2014 09:36:53 +0300 Subject: [GHC] #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 In-Reply-To: <045.27c764f1bc949f892e614a3885cf6189@haskell.org> References: <045.27c764f1bc949f892e614a3885cf6189@haskell.org> Message-ID: <544C9685.8090207@mail.ru> Another variant is to #define _CRT_NON_CONFORMING_SWPRINTFS for this (I use it). Cheers, Kyra On 10/26/2014 1:21 AM, GHC wrote: > #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 > -------------------------------------+------------------------------------- > Reporter: gintas | Owner: gintas > Type: bug | Status: new > Priority: normal | Milestone: > Component: Runtime System | Version: 7.9 > Keywords: | Operating System: Windows > Architecture: Unknown/Multiple | Type of failure: > Difficulty: Unknown | None/Unknown > Blocked By: | Test Case: > Related Tickets: | Blocking: > | Differential Revisions: > -------------------------------------+------------------------------------- > swprintf has different signatures in mingw32, where it does not include > the > buffer size, and in mingw-w64, where it does. That of course breaks the > code > as mingw-w64 treats the pointer to the format string as a size_t. Bummer: > > > C:/.../inplace/mingw/i686-w64-mingw32/include/swprintf.inl:30:5: note: > expected 'size_t' but argument is of type 'short unsigned int *' > int swprintf (wchar_t *__stream, size_t __count, const wchar_t *__format, > ...) > ^ > > rts\Linker.c:1986:12: > warning: passing argument 2 of 'swprintf' makes integer from pointer > without a cast [enabled by default] > swprintf(buf, L"lib%s.DLL", dll_name); > > I have a fix pending to use snwprintf instead. > > -- > Ticket URL: > GHC > The Glasgow Haskell Compiler > _______________________________________________ > ghc-tickets mailing list > ghc-tickets at haskell.org > http://www.haskell.org/mailman/listinfo/ghc-tickets > From ghc-devs at haskell.org Sun Oct 26 06:41:39 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 06:41:39 -0000 Subject: [GHC] #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 In-Reply-To: <045.27c764f1bc949f892e614a3885cf6189@haskell.org> References: <045.27c764f1bc949f892e614a3885cf6189@haskell.org> Message-ID: <060.483a1f15c0f3d17abaf04539f1f3e189@haskell.org> #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by awson): {{{#define _CRT_NON_CONFORMING_SWPRINTFS}}} also solves the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 08:45:46 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 08:45:46 -0000 Subject: [GHC] #9682: Implement "Add bifunctor related classes to base"-Proposal In-Reply-To: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> References: <042.4dafee5ba2643aa862277abc448bd81a@haskell.org> Message-ID: <057.be7c8452703bccc4d605862d05dbd115@haskell.org> #9682: Implement "Add bifunctor related classes to base"-Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D336 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"0a290ca0ad599e40ca15a60cc988640f1cfcb4c2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0a290ca0ad599e40ca15a60cc988640f1cfcb4c2" Add new `Data.Bifunctor` module (re #9682) This adds the module `Data.Bifunctor` providing the `Bifunctor(bimap,first,second)` class and a couple of instances This module and the class were previously exported by the `bifunctors` package. In contrast to the original module all `INLINE` pragmas have been removed. Reviewed By: ekmett, austin, dolio Differential Revision: https://phabricator.haskell.org/D336 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 09:08:20 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 09:08:20 -0000 Subject: [GHC] #4440: time004 fails depending on the date In-Reply-To: <056.7cae293d5c5c202bca7e240bc720a730@haskell.org> References: <056.7cae293d5c5c202bca7e240bc720a730@haskell.org> Message-ID: <071.ec2c138de51a5272e590068759dd9712@haskell.org> #4440: time004 fails depending on the date -------------------------------------+------------------------------------- Reporter: | Owner: daniel.is.fischer | Status: new Type: bug | Milestone: 7.10.1 Priority: low | Version: 7.1 Component: Test Suite | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * difficulty: => Unknown Comment: fyi, it's that time of the year again... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 10:30:24 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 10:30:24 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.e64e0fa09b39b549df7db010836b9e2b@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:1 rwbarton]: > ... > > Maybe adding kind annotations for some of the type variables involved would help? I tried that. These are the most generic kinds: {{{ ent :: Entity -> k -> Entity Monitor :: Entity -> Bool -> Entity par :: Entity mp :: Bool }}} It looks like the equation `(*)` does not seem to establish the kind-level equality `Entity -> k -> Entity === Entity -> Bool -> Entity` and thus `k === Bool`. So yes, your analysis is correct, that kind variables mess up the decomposition. When changing `ent` to `Monitor`, everything works, probably because the kind variable `k` is eliminated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 16:41:05 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 16:41:05 -0000 Subject: [GHC] #9728: ghci: internal error: ASSERTION FAILED: file rts/Interpreter.c, line 773 Message-ID: <045.ebf64d7a8e540c9c1c277bb0fdb153d0@haskell.org> #9728: ghci: internal error: ASSERTION FAILED: file rts/Interpreter.c, line 773 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | crash Related Tickets: | Test Case: ghcirun002 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It's a ghc-HEAD on amd64 ./configure --enable-unregisterised. One of faulty tests is a: {{{ ghc-unreg/testsuite/tests/ghci/should_run $ '/home/slyfox/dev/git/ghc- unreg/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno- debug-output -no-user-package-db -rtsopts -optc-fno-builtin -fno-warn-tabs -fno-ghci-history ghcirun002.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS *Main> main (: internal error: ASSERTION FAILED: file rts/Interpreter.c, line 773 (GHC version 7.9.20141020 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} The assertion failure is triggered by stack overflow check when handling ... stack overflow! {{{ // Stack check if (Sp - INTERP_STACK_CHECK_THRESH < SpLim) { Sp -= 2; Sp[1] = (W_)obj; Sp[0] = (W_)&stg_apply_interp_info; // placeholder, really /* 773 */ RETURN_TO_SCHEDULER(ThreadInterpret, StackOverflow); } /* ... RETURN_TO_SCHEDULER decl: */ #define RETURN_TO_SCHEDULER(todo,retcode) \ /* this triggers assert */ SAVE_STACK_POINTERS; \ cap->r.rCurrentTSO->what_next = (todo); \ threadPaused(cap,cap->r.rCurrentTSO); \ cap->r.rRet = (retcode); \ return cap; /* ... SAVE_STACK_POINTERS decl: */ #define SAVE_STACK_POINTERS \ ASSERT(Sp > SpLim); \ cap->r.rCurrentTSO->stackobj->sp = Sp }}} In our case '''Sp == SpLim'''. That means we have written one word out-of-stack-bounds, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 16:53:32 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 16:53:32 -0000 Subject: [GHC] #9729: GHCi accepts invalid programs when recompiling Message-ID: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> #9729: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | 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: GHC Blocked By: | accepts invalid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Here's what's happening: Module A imports module B. Module B contains a function with constraints that are '''required''' to compile module B. If I load module A in GHCi, I can remove some (required) constraints on the function in module B and GHCi will successfully reload module B. My example uses the [https://hackage.haskell.org/package/syntactic syntactic] library. I attempted to recreate the situation I just described without syntactic, but I was unsuccessful. Module A.hs: {{{ #!haskell module A where import B import Data.Syntactic.Sugar.BindingT () main = print "hello" }}} Module B.hs: {{{ #!haskell {-# LANGUAGE GADTs, TypeOperators, FlexibleContexts #-} module B where import Data.Syntactic data Let x where Let :: Let (a :-> (a -> b) :-> Full b) share :: (Let :<: sup, sup ~ Domain b, sup ~ Domain a, Internal (a -> b) ~ (Internal a -> Internal b), -- remove me Syntactic a, Syntactic b, Syntactic (a -> b), SyntacticN (a -> (a -> b) -> b) (ASTF sup (Internal a) -> ASTF sup (Internal (a -> b)) -> ASTF sup (Internal b))) => a -> (a -> b) -> b share = sugarSym Let }}} Here's a terminal transcript: {{{ $ ghci A [1 of 2] Compiling B ( testsuite/B.hs, interpreted ) [2 of 2] Compiling A ( testsuite/A.hs, interpreted ) Ok, modules loaded: A, B. > (Now remove the constraint from B and save. This *should* break module B) > :r [1 of 2] Compiling B ( testsuite/B.hs, interpreted ) Ok, modules loaded: A, B. > :q $ ghci B [1 of 2] Compiling B ( testsuite/B.hs, interpreted ) testsuite/B.hs:21:9: Could not deduce (Internal (a -> b) ~ (Internal a -> Internal b)) }}} If I had to guess what's going on, it's that GHCi is remembering the instance that A imports from BindingT: {{{ instance (...) => Syntactic (a -> b) where type Internal (a -> b) = Internal a -> Internal b }}} This instance implies the constraint that module B needs, however it should never be visible to module B. GHCi seems to be ignoring that and using the instance to recompile module B. When compiling from scratch, module B is compiled first, so of course the instance (and therefore the constraint) are not visible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 17:29:54 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 17:29:54 -0000 Subject: [GHC] #9729: GHCi accepts invalid programs when recompiling In-Reply-To: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> References: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> Message-ID: <062.d3c1bb5000f28d4237fd42cc56aa0d9e@haskell.org> #9729: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): I should have mentioned that following the same procedure with non- interactive GHC ("ghc A", then change B, then "ghc A" again) does detect the error in module B. So this problem appears to only affect GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 20:30:07 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 20:30:07 -0000 Subject: [GHC] #9705: Panic on a pattern synonym in a class In-Reply-To: <047.614ec39c173b8238a9064e76b118d842@haskell.org> References: <047.614ec39c173b8238a9064e76b118d842@haskell.org> Message-ID: <062.e71b3216a6efd9bcfce683ea4a855fb0@haskell.org> #9705: Panic on a pattern synonym in a class -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by monoidal): The patch looks good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 21:30:13 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 21:30:13 -0000 Subject: [GHC] #9729: GHCi accepts invalid programs when recompiling In-Reply-To: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> References: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> Message-ID: <062.052b07f259c4222d189d7a0c584c318a@haskell.org> #9729: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ezyang (added) Comment: I think your hypothesis is likely right. It's a long-standing deficiency in GHCi that it doesn't make instance declarations scope correctly, or (words) predictably. Edward Yang is thinking about ways to fix this. Can you just be more explicit about what module `B` looks like after the edit? What, precisely, does "remove the constraint" mean? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 21:31:59 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 21:31:59 -0000 Subject: [GHC] #9728: ghci: internal error: ASSERTION FAILED: file rts/Interpreter.c, line 773 In-Reply-To: <045.ebf64d7a8e540c9c1c277bb0fdb153d0@haskell.org> References: <045.ebf64d7a8e540c9c1c277bb0fdb153d0@haskell.org> Message-ID: <060.20e89e97893a36c5089f0c4152660837@haskell.org> #9728: ghci: internal error: ASSERTION FAILED: file rts/Interpreter.c, line 773 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: ghcirun002 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I saw this on `ghcirun004`, but only on my `wip/new-flatten-skolems-Aug14` branch. It's reassuring (in the sense that it's not specific to my branch) that it is happening elsewhere too. I'd love a fix. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 21:34:55 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 21:34:55 -0000 Subject: [GHC] #9729: GHCi accepts invalid programs when recompiling In-Reply-To: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> References: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> Message-ID: <062.23b58fad91f97c89538c05a5e8a7cf41@haskell.org> #9729: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): By "remove the constraint", I mean comment that single line `Internal (a -> b) ~ (Internal a -> Internal b)` in the constraints for `share`. After the edit, module B is: {{{ #!haskell {-# LANGUAGE GADTs, TypeOperators, FlexibleContexts #-} module B where import Data.Syntactic data Let x where Let :: Let (a :-> (a -> b) :-> Full b) share :: (Let :<: sup, sup ~ Domain b, sup ~ Domain a, --Internal (a -> b) ~ (Internal a -> Internal b), -- remove me Syntactic a, Syntactic b, Syntactic (a -> b), SyntacticN (a -> (a -> b) -> b) (ASTF sup (Internal a) -> ASTF sup (Internal (a -> b)) -> ASTF sup (Internal b))) => a -> (a -> b) -> b share = sugarSym Let }}} The example is as minimal as I could make it. In particular, GHCi *does* detect the change to module B if I do not import BindingT in module A. This supports my hypothesis because the instance is never in scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 23:20:49 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 23:20:49 -0000 Subject: [GHC] #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 In-Reply-To: <045.27c764f1bc949f892e614a3885cf6189@haskell.org> References: <045.27c764f1bc949f892e614a3885cf6189@haskell.org> Message-ID: <060.3b9c46073e74813f281ada8c49043f31@haskell.org> #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D372 | -------------------------------------+------------------------------------- Changes (by gintas): * differential: => Phab:D372 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 26 23:39:45 2014 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Oct 2014 23:39:45 -0000 Subject: [GHC] #9540: words is not a good producer; unwords is not a good consumer (was: unwords is not a good producer) In-Reply-To: <045.cf07c524c3885055d6c8e1249648041f@haskell.org> References: <045.cf07c524c3885055d6c8e1249648041f@haskell.org> Message-ID: <060.564d542c938160a08a7b70d08bece89b@haskell.org> #9540: words is not a good producer; unwords is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: fusion Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Runtime | hour) performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: D375 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => D375 * milestone: => 7.10.1 Comment: I've changed my mind; I think it probably (but not necessarily) makes more sense to make `unwords` be a good consumer and `words` a good producer, so they can play nice with each other. If I could make `unwords` both, that'd be the ideal, but we can at least go one way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 00:33:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 00:33:47 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly In-Reply-To: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> References: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> Message-ID: <064.71df54175a1408ded690235e7d34dae7@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by agibiansky): Does anyone know whether this bug has been looked at, or whether it will be fixed for GHC 7.10? I would be very interested in getting it fixed by 7.10, but I do not know how to get started fixing it, or whether it has already been fixed... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 00:42:31 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 00:42:31 -0000 Subject: [GHC] #9716: The list modules need a bit of post-BBP shaking In-Reply-To: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> References: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> Message-ID: <060.15234be5f58776b752452c7799a579e8@haskell.org> #9716: The list modules need a bit of post-BBP shaking -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: lists Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D380 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => D380 Comment: I've uploaded a CR to get this started. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 00:42:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 00:42:55 -0000 Subject: [GHC] #9716: The list modules need a bit of post-BBP shaking In-Reply-To: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> References: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> Message-ID: <060.821a71f64a1fcc2a9712f9238dd7df84@haskell.org> #9716: The list modules need a bit of post-BBP shaking -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: lists Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D380 | -------------------------------------+------------------------------------- Changes (by dfeuer): * differential: D380 => Phab:D380 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 00:43:26 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 00:43:26 -0000 Subject: [GHC] #9510: Prelude.!! is not a good consumer In-Reply-To: <045.ea9dba32ca908a61e9807eddb78f8a5a@haskell.org> References: <045.ea9dba32ca908a61e9807eddb78f8a5a@haskell.org> Message-ID: <060.4b100b177ef8cac1736d307a79111478@haskell.org> #9510: Prelude.!! is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: Component: Core | Version: 7.8.3 Libraries | Keywords: fusion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D380 | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * status: new => patch * differential: => Phab:D380 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 03:48:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 03:48:55 -0000 Subject: [GHC] #9031: ghc panic: RegAlloc.Liveness.computeLivenss In-Reply-To: <045.282178438a787f7ffeeca849ab71135d@haskell.org> References: <045.282178438a787f7ffeeca849ab71135d@haskell.org> Message-ID: <060.78ff015ecce9c01d3bf3a9eeee192161@haskell.org> #9031: ghc panic: RegAlloc.Liveness.computeLivenss -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jwlato): I can no longer reproduce this with ghc-7.8.3, so I think this can be closed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 06:49:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 06:49:06 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly In-Reply-To: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> References: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> Message-ID: <064.0663496c30993e11703cbb27d7a2b505@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by trommler): Could you check if the patch (Phab:D349) for #8935 fixes the issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 08:32:28 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 08:32:28 -0000 Subject: [GHC] #9031: ghc panic: RegAlloc.Liveness.computeLivenss In-Reply-To: <045.282178438a787f7ffeeca849ab71135d@haskell.org> References: <045.282178438a787f7ffeeca849ab71135d@haskell.org> Message-ID: <060.2d4396f0788989250cdc328e6992818d@haskell.org> #9031: ghc panic: RegAlloc.Liveness.computeLivenss -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: worksforme | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Closing by original reporter's suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 08:45:34 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 08:45:34 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.0dcb84f2f585faa0b59d1d86fecf9e08@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: Phab:D339 | -------------------------------------+------------------------------------- Comment (by awson): Here I propose my patchset for `rts/Linker.c` (against current HEAD). It intersects with Gintas' one, but does a bit more (`COMDAT` support for gcc 4.9.x) and does some things in a more straightforward manner -- mostly in handling name decoration things. What's going on with name decoration? Well, original code have some crufty and ad-hocish paths related mostly to very old mingw gcc/binutils/runtime combinations. Now mingw-w64 offers pretty uniform and MS-compatible decoration scheme across its tools and runtime. The scheme is pretty straightforward: on 32 bit objects symbols are exported with underscore prepended (and `@` + stack size suffix appended for `stdcall` functions), on 64 bits no underscore is prepended and no suffix is appended because we have no `stdcall` convention on 64 bits. On top of that `__imp_` prefix is further prepended for `dllimport`ed symbols. Mingw-w64 runtime is conformant to MS declaring all win32 symbols `dllimport`ed, while old mingw is not and this is why 32-bit cases differs so much. I commented on this extensively in #7097 and #2283. My patch reflects these considerations and also unifies a bunch of RTS imports between 32 and 64 bit cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 09:27:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 09:27:06 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.e6b63e8caf0ae7dfc0f448cb0dff218e@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.3 Libraries | Keywords: IORef Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"9e2cb00e5af9d86546f82a74c3d0382e65704d56/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9e2cb00e5af9d86546f82a74c3d0382e65704d56" Optimise atomicModifyIORef' implementation (#8345) This forces the new value before installing it in the IORef. This optimisation was originally suggested by Patrick Palka and "exhibits a speedup of 1.7x (vanilla RTS) / 1.4x (threaded RTS)" according to #8345 Reviewed By: austin, simonmar Differential Revision: https://phabricator.haskell.org/D315 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 09:29:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 09:29:49 -0000 Subject: [GHC] #8345: A more efficient atomicModifyIORef' In-Reply-To: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> References: <044.baf7da7be36865925e6009a83d69ed56@haskell.org> Message-ID: <059.f9ee664728d317ae0081ab2ab6a50e31@haskell.org> #8345: A more efficient atomicModifyIORef' -------------------------------------+------------------------------------- Reporter: parcs | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.6.1 Libraries | Keywords: IORef Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Moderate (less Unknown/Multiple | than a day) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: #5926 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) * status: patch => closed * version: 7.6.3 => 7.6.1 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 09:55:18 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 09:55:18 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.f6b6fb25c2e9a16bdd48f009c5c95305@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: Phab:D339 | -------------------------------------+------------------------------------- Comment (by gintas): awson, thanks for the patch! I'll get to testing it right away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 10:07:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 10:07:10 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.c8c2e7eeb19aaeb9ae7439e1f0403fb7@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: Phab:D339 | -------------------------------------+------------------------------------- Comment (by awson): Perhaps I should mention this patch solves `swprintf` problem a bit differently from your approach (I've already [https://ghc.haskell.org/trac/ghc/ticket/9726#comment:1 commented on this]). Also I didn't test it on 32 bits for quite a long time (several months or so). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 10:18:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 10:18:50 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.da5b0f0503751cced167c082c493e9b3@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: Phab:D339 | -------------------------------------+------------------------------------- Comment (by gintas): Yep, I'm aware of _CRT_NON_CONFORMING_SWPRINTFS. I'll try testing on 32-bit, will let you know how that goes. Thanks again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 12:42:55 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 12:42:55 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.8b00c3ff797ff93e776e18cfa74b865e@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Fyi (& hoping you may give it a look) somewhat related to this ticket is Phab:D377 which is about removing `-XOverlappingInstances` from `Data.Typeable.*` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 13:58:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 13:58:58 -0000 Subject: [GHC] #9724: reexport IsList class from a trustworthy module In-Reply-To: <044.b4b824d4864a7071bef003961687614b@haskell.org> References: <044.b4b824d4864a7071bef003961687614b@haskell.org> Message-ID: <059.5c929625da91e605b3510afc23bd31dc@haskell.org> #9724: reexport IsList class from a trustworthy module -------------------------------------+------------------------------------- Reporter: int-e | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: eir@? (added) Comment: I agree that this deserves some attention. I always feel dirty importing `GHC.Exts`, and the non-dirty things from there should have other places to be pulled from. I'm specifically thinking of `Constraint`, but I'm sure there are things other than just `IsList` and `Constraint` that should find new homes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 15:01:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 15:01:16 -0000 Subject: [GHC] #9218: Upgrade the version of MinGW shipped with GHC In-Reply-To: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> References: <047.dd7762c6a468e59baf096987bc6ae487@haskell.org> Message-ID: <062.b3b0a25299af61b8d56130f76cd314df@haskell.org> #9218: Upgrade the version of MinGW shipped with GHC -------------------------------------+------------------------------------- Reporter: komadori | Owner: gintas Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Build | Version: 7.8.2 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #3390 Test Case: | Blocking: | Differential Revisions: Phab:D339 | -------------------------------------+------------------------------------- Comment (by gintas): I've run validate.sh on Windows with x86_64 and i686 toolchains, both are looking reasonable with kyra's patch. There are some failures, but most of them are also there with the baseline. I think the only remaining blocker is the mirror location for mingw-w64 packages on download.haskell.org in case the files on sourceforge are removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 15:51:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 15:51:38 -0000 Subject: [GHC] #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions In-Reply-To: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> References: <042.09a9d3f5faa12c7fffbc47f1a0b508fe@haskell.org> Message-ID: <057.910b774cd18ec46bb3163cf644785be6@haskell.org> #9281: Rewrite `integer-gmp` to use only non-allocating GMP functions -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: integer-gmp Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: #8647 None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D82 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"0e1f0f7d1682d77c5dbb1d2b36f57037113cf7b4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0e1f0f7d1682d77c5dbb1d2b36f57037113cf7b4" Un-wire `Integer` type (re #9714) Integer is currently a wired-in type for integer-gmp. This requires replicating its inner structure in `TysWiredIn`, which makes it much harder to change Integer to a more complex representation (as e.g. needed for implementing #9281) This commit stops `Integer` being a wired-in type, and makes it known-key type instead, thereby simplifying code notably. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D351 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 15:51:38 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 15:51:38 -0000 Subject: [GHC] #9714: Un-`wire` Integer type In-Reply-To: <042.d9e6c84c3f736b36a268197d3ac72a0d@haskell.org> References: <042.d9e6c84c3f736b36a268197d3ac72a0d@haskell.org> Message-ID: <057.2a2a7ce3abafd02f7ad345f8a4b2ce7b@haskell.org> #9714: Un-`wire` Integer type -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Resolution: | Keywords: Integer Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Moderate (less Type of failure: | than a day) None/Unknown | Blocked By: Test Case: | Related Tickets: #9281 Blocking: | Differential Revisions: Phab:D351 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"0e1f0f7d1682d77c5dbb1d2b36f57037113cf7b4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0e1f0f7d1682d77c5dbb1d2b36f57037113cf7b4" Un-wire `Integer` type (re #9714) Integer is currently a wired-in type for integer-gmp. This requires replicating its inner structure in `TysWiredIn`, which makes it much harder to change Integer to a more complex representation (as e.g. needed for implementing #9281) This commit stops `Integer` being a wired-in type, and makes it known-key type instead, thereby simplifying code notably. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D351 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 15:55:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 15:55:33 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly In-Reply-To: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> References: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> Message-ID: <064.582e375d196f0a3b3cd631c7d27161ff@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:D349 Comment: Replying to [comment:7 trommler]: > Could you check if the patch (Phab:D349) for #8935 fixes the issue? I back ported Phab:D349 to ghc 7.8.3 and there is no segfault in the test snippet above anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 15:57:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 15:57:46 -0000 Subject: [GHC] #9480: Segfault in GHC API code using Shelly In-Reply-To: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> References: <049.0677aa1db4b4385b2175404d6ded322c@haskell.org> Message-ID: <064.ee8ce3e6b1b212ee1f284797c7702104@haskell.org> #9480: Segfault in GHC API code using Shelly -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: #8935 Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Changes (by trommler): * milestone: => 7.10.1 Comment: Milestone for #8935 is 7.10.1 so setting it here too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 16:01:16 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 16:01:16 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.b454c93aac9c64a330a9fb8a954f6214@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 (LLVM) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: 9268 | Differential Revisions: Phab:D150 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 16:05:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 16:05:47 -0000 Subject: [GHC] #9435: x86 sse4.2 popCnt16# needs to zero-extend its result In-Reply-To: <047.2d22c842edc6d517b7f7713b23c8ad16@haskell.org> References: <047.2d22c842edc6d517b7f7713b23c8ad16@haskell.org> Message-ID: <062.8a83518c4c141c077148dfe9bc83254f@haskell.org> #9435: x86 sse4.2 popCnt16# needs to zero-extend its result -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 (NCG) | Keywords: Resolution: fixed | Architecture: x86_64 (amd64) Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: Phab:D147 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.8.4 Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 16:06:02 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 16:06:02 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale In-Reply-To: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> References: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> Message-ID: <060.f327207706db22555562ae57feb17feb@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D185 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.8.4 Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 16:06:57 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 16:06:57 -0000 Subject: [GHC] #9186: GHC panic when compiling compdata In-Reply-To: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> References: <047.bd93976605e2ee52c8ffb09a3a838441@haskell.org> Message-ID: <062.3b5b664a47f904d0c35e6c0085d3526c@haskell.org> #9186: GHC panic when compiling compdata -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #8935 Test Case: | Blocking: | Differential Revisions: Phab:D349 | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:27 thomie]: I think before we close this ticket we should have a regression test. The first attempt at #8935 passed the testsuite with no errors. I don't know enough about the earlier phases of GHC to come up with such a test case but I could help explaining what is going on in the backend and especially with dynamic linking and loading. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 16:07:21 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 16:07:21 -0000 Subject: [GHC] #9006: GHC accepts import of private data constructor if it has the same name as the type In-Reply-To: <046.f4fcc91a133451d6f840223341c96eb9@haskell.org> References: <046.f4fcc91a133451d6f840223341c96eb9@haskell.org> Message-ID: <061.b79e3338602ea03dd384dea0c15a646f@haskell.org> #9006: GHC accepts import of private data constructor if it has the same name as the type -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | rename/should_fail/T9006 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * milestone: => 7.8.4 Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 16:07:41 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 16:07:41 -0000 Subject: [GHC] #9417: Pattern synonyms across modules broken in Haddock In-Reply-To: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> References: <047.b6ac7a5cd3eafafe3f496e209d04da27@haskell.org> Message-ID: <062.20a47a39b10303b08bddc40f6d3684f8@haskell.org> #9417: Pattern synonyms across modules broken in Haddock -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: pattern synonyms 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 thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.8.4 Comment: Merged to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 17:05:58 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 17:05:58 -0000 Subject: [GHC] #9384: setNumCapabilities call breaks eventlog events In-Reply-To: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> References: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> Message-ID: <060.f094fd5c5bd1a00de91ce1fec64d4fca@haskell.org> #9384: setNumCapabilities call breaks eventlog events -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Incorrect | Difficulty: Unknown result at runtime | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * priority: normal => high * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 17:40:59 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 17:40:59 -0000 Subject: [GHC] #9713: Update comment about C helper for dynamic exports. In-Reply-To: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> References: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> Message-ID: <059.147b4baf412d4de5ce6864d744998b6c@haskell.org> #9713: Update comment about C helper for dynamic exports. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:2 thomie]: * I prepared the patch before writing the ticket, but I've updated the commit message to include the Trac number and a reference to the original patch (from 2011). * The patch only updates comments (note that it is changing a latex style .lhs file), so there's nothing to test. * "approximately" - in reality, the code has to extract the result of the call, and the details of that depend on whether LLVM is used or not, and I'm not sure I understand all of them. Since the emphasis of the comment is the creation of adjustors, I think it's ok to gloss over that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 17:55:23 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 17:55:23 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale In-Reply-To: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> References: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> Message-ID: <060.401dca75cd769cf0b8a895ceaf6759e0@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D185 | -------------------------------------+------------------------------------- Comment (by refold): @dcoutts thinks that we should use `LANGUAGE=C` instead of `en` because there's no guarantee that the `en` locale is available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 18:04:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 18:04:42 -0000 Subject: [GHC] #9727: -Werror=unused-but-set-variable causes validation error on Windows In-Reply-To: <045.46cb8c51f4cb0e085fad55ca8cdfc48e@haskell.org> References: <045.46cb8c51f4cb0e085fad55ca8cdfc48e@haskell.org> Message-ID: <060.eaeb1878138c41d868e9d52682c0b72c@haskell.org> #9727: -Werror=unused-but-set-variable causes validation error on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: patch Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D373 | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 18:05:32 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 18:05:32 -0000 Subject: [GHC] #9727: -Werror=unused-but-set-variable causes validation error on Windows In-Reply-To: <045.46cb8c51f4cb0e085fad55ca8cdfc48e@haskell.org> References: <045.46cb8c51f4cb0e085fad55ca8cdfc48e@haskell.org> Message-ID: <060.5a5d89b81199f4436e2184e4d9e7b1b1@haskell.org> #9727: -Werror=unused-but-set-variable causes validation error on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D373 | -------------------------------------+------------------------------------- Changes (by gintas): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 18:07:47 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 18:07:47 -0000 Subject: [GHC] #9713: Update comment about C helper for dynamic exports. In-Reply-To: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> References: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> Message-ID: <059.c498287ceaef9069f2a80165956a12fc@haskell.org> #9713: Update comment about C helper for dynamic exports. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by int-e): In fact there were two relevant API changes, 03a9ff01812afc81eb5236fd3063cbec44cf469e and 8b75acd3ca25165536f18976c8d80cb62ad613e4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 18:16:07 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 18:16:07 -0000 Subject: [GHC] #9663: Windows build process should give better message if you forgot to clone tarballs In-Reply-To: <045.1da0869ddf56108fdfa02fd69e07ae82@haskell.org> References: <045.1da0869ddf56108fdfa02fd69e07ae82@haskell.org> Message-ID: <060.e36a43f6cdc899405e3610f8f9ea8406@haskell.org> #9663: Windows build process should give better message if you forgot to clone tarballs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #9218 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * related: => #9218 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 18:19:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 18:19:03 -0000 Subject: [GHC] #8890: segfault on Windows 7 i386 In-Reply-To: <045.ef91946d4291bd999be2fb92692f63b8@haskell.org> References: <045.ef91946d4291bd999be2fb92692f63b8@haskell.org> Message-ID: <060.5cdf683c63ad18dd2f35c36106108b70@haskell.org> #8890: segfault on Windows 7 i386 ---------------------------------------------+----------------------------- Reporter: ganesh | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------------+----------------------------- Changes (by gintas): * status: new => closed * resolution: => wontfix Comment: Looks like this is obsolete, I could not reproduce the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 18:23:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 18:23:50 -0000 Subject: [GHC] #9730: Polymorphism and type classes Message-ID: <046.310e1397bb5747d9bd08033446e752bc@haskell.org> #9730: Polymorphism and type classes -------------------------------------+------------------------------------- Reporter: mjaskel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: Typeclass, | Unknown/Multiple Polymorphism, ImpredicativeTypes | Type of failure: GHC Architecture: Unknown/Multiple | rejects valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Let us define some typeclasses {{{#!hs class A a where class B b where class C c where }}} I often use `RankNTypes` and write a type `forall a. A a => a` to mean that only the members of type class `A` have been used to construct its elements. If I have a function that converts programs written only with members of `A` into a programs written only with members of `B`, and an analogous one to convert from `B` to `C`, I would expect to be able to compose them {{{#!hs a2b :: (forall a. A a => a) -> (forall b. B b => b) a2b = undefined b2c :: (forall b. B b => b) -> (forall c. C c => c) b2c = undefined a2c :: (forall a. A a => a) -> (forall c. C c => c) a2c = b2c . a2b }}} However, I get many types error of the form: {{{ Cannot instantiate unification variable ?b0? with a type involving foralls: forall b. B b => b Perhaps you want ImpredicativeTypes }}} Every `forall` is under a function type, but I enable `ImpredicativeTypes` anyway, and I get the following error: {{{ Could not deduce (B (forall b. B b => b)) arising from a use of ?a2b? from the context (C c) bound by the type signature for a2c :: C c => (forall a. A a => a) -> c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 18:25:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 18:25:10 -0000 Subject: [GHC] #9297: Packages linked against certain Windows .dll files give warnings at runtime In-Reply-To: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> References: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> Message-ID: <065.b0fdd7a2aff1da4b577778ffb01492e7@haskell.org> #9297: Packages linked against certain Windows .dll files give warnings at runtime -------------------------------------+------------------------------------- Reporter: | Owner: simonmar RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Runtime | Keywords: System | Architecture: x86_64 (amd64) Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: #2283, #9218 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * related: #2283 => #2283, #9218 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 19:11:10 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 19:11:10 -0000 Subject: [GHC] #9367: :list does not underline expression correctly in WinGHCi for files with Windows-style newlines In-Reply-To: <044.22597e1155087b2ec7457131835e824e@haskell.org> References: <044.22597e1155087b2ec7457131835e824e@haskell.org> Message-ID: <059.ebb1c67f60bac1b33d91072caef65866@haskell.org> #9367: :list does not underline expression correctly in WinGHCi for files with Windows-style newlines ---------------------------------------+---------------------------------- Reporter: kraai | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Changes (by gintas): * owner: => gintas Comment: I could reproduce the bug on winghci 1.0.6 bundled with Haskell Platform 2014.2.0.0 (ghc 7.8.3). The problem does not appear when running ghc from an msys terminal or a Windows command shell. However, I looked into it more closely and it looks like ghci is indeed at fault. There is some funny business going on with line endings. In the part that is the source listing, newlines are not , but . That's probably what's confusing WinGHCI. My guess is that something is not stripping the from the source properly and then tries to append on its own. To illustrate, the additional s show up as ^M: a :: Int = 8 left :: [Int] = _ right :: [Int] = _ [C:\users\gintas\temp\qsort.hs:2:16-47] *Main> 1 qsort [] = []^M 2 qsort (a:as) = qsort left ++ [a] ++ qsort right^M ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 3 where (left,right) = (filter (<=a) as, filter (>a) as)^M [C:\users\gintas\temp\qsort.hs:2:16-47] *Main> Leaving GHCi. Produced using: echo -e ':l qsort.hs \n:b 2\n:main\n:list' | TERM=dumb /tmp/ghc/bin/ghc.exe --interactive > /tmp/out The issue is still there in ghc HEAD. Let me take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 20:17:37 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 20:17:37 -0000 Subject: [GHC] #9367: :list does not underline expression correctly in WinGHCi for files with Windows-style newlines In-Reply-To: <044.22597e1155087b2ec7457131835e824e@haskell.org> References: <044.22597e1155087b2ec7457131835e824e@haskell.org> Message-ID: <059.afb16eb82d49deee76880f60bdcad204@haskell.org> #9367: :list does not underline expression correctly in WinGHCi for files with Windows-style newlines ---------------------------------------+---------------------------------- Reporter: kraai | Owner: gintas Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D382 | ---------------------------------------+---------------------------------- Changes (by gintas): * status: new => patch * differential: => Phab:D382 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 20:36:49 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 20:36:49 -0000 Subject: [GHC] #2104: Add Labels In-Reply-To: <045.8e0dd3d5e2a0d3899747780f8d7a3947@haskell.org> References: <045.8e0dd3d5e2a0d3899747780f8d7a3947@haskell.org> Message-ID: <060.8b9366c883bffe1ed61dde55de32af7e@haskell.org> #2104: Add Labels -------------------------------------+------------------------------------- Reporter: barney | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: lowest | Version: 6.8.2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by barney): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: I set this as fixed, because it's completely subsumed by Symbol. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 20:46:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 20:46:33 -0000 Subject: [GHC] #8825: ghc can't determine gcc version on ru_RU locale In-Reply-To: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> References: <045.43d22cc06e6058e3e2bc2637c7a5c8b1@haskell.org> Message-ID: <060.9a9e7387a900fdea2250ab355ccdf47a@haskell.org> #8825: ghc can't determine gcc version on ru_RU locale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: D185 | -------------------------------------+------------------------------------- Comment (by slyfox): On my system if I pass LANGUAGE=something-incorrect it fallbacks to 'en' messages anyways. Looks like it's explicitely documented behaviour: https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE- variable.html But I dont have strong preference over 'C'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 21:08:33 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 21:08:33 -0000 Subject: [GHC] #9731: Inductive type definitions on Nat Message-ID: <045.ee757b86fa097a15d7c9fc18dbdaf548@haskell.org> #9731: Inductive type definitions on Nat -------------------------------------+------------------------------------- Reporter: barney | 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: -------------------------------------+------------------------------------- If you define your own type-level natural numbers by promoting {{{#!hs data Nat = Zero | Successor Nat }}} you can then define both data and type families inductively, for example {{{#!hs data family Vector1 :: Nat -> * -> * data instance Vector1 Zero a = EmptyVector data instance Vector1 (Successor n) a = MkVector a (Vector1 n a) }}} Using the built-in Nat, there is no way to define inductive data families, and inductive type families such as {{{#!hs type family Vector2 :: Nat -> * -> * where Vector2 0 a = () Vector2 n a = (a, (Vector2 (n-1) a)) }}} require UndecidableInstances (and must be closed). This proposal is to add (n+k) patterns for Nat, so that the built-in naturals can be used in the same way that the user defined naturals can, to define type and data families inductively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 21:15:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 21:15:06 -0000 Subject: [GHC] #9676: Data.List.isSuffixOf can be very inefficient In-Reply-To: <045.eeef3e586222f9b3ebd00734e3d3ae2c@haskell.org> References: <045.eeef3e586222f9b3ebd00734e3d3ae2c@haskell.org> Message-ID: <060.c7fe184231703120b1c9a94ac94af3e7@haskell.org> #9676: Data.List.isSuffixOf can be very inefficient -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D330 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"49b05d6935b6677443a970a45138def66c6f8cee/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="49b05d6935b6677443a970a45138def66c6f8cee" Improve performance of isSuffixOf (#9676) The new implementation avoids reversing the "haystack" list, which can be very expensive. Reviewed By: ekmett Differential Revision: https://phabricator.haskell.org/D330 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 21:15:43 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 21:15:43 -0000 Subject: [GHC] #9676: Data.List.isSuffixOf can be very inefficient In-Reply-To: <045.eeef3e586222f9b3ebd00734e3d3ae2c@haskell.org> References: <045.eeef3e586222f9b3ebd00734e3d3ae2c@haskell.org> Message-ID: <060.ff3b80fcc5c8416212958bf173d69295@haskell.org> #9676: Data.List.isSuffixOf can be very inefficient -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D330 | -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 21:16:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 21:16:11 -0000 Subject: [GHC] #9367: GHCI :list uses malformed line endings () on Windows (was: :list does not underline expression correctly in WinGHCi for files with Windows-style newlines) In-Reply-To: <044.22597e1155087b2ec7457131835e824e@haskell.org> References: <044.22597e1155087b2ec7457131835e824e@haskell.org> Message-ID: <059.f66cce0191fa75c74e13beeb4151f4d2@haskell.org> #9367: GHCI :list uses malformed line endings () on Windows ---------------------------------------+---------------------------------- Reporter: kraai | Owner: gintas Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D382 | ---------------------------------------+---------------------------------- Comment (by gintas): I've confirmed that the patch addresses the issue in WinGhci too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 21:17:12 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 21:17:12 -0000 Subject: [GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link In-Reply-To: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> References: <055.52caeb288dc7ec39f4857ef2699cf6c8@haskell.org> Message-ID: <070.9d201894a27c287864ab29fe9dbcba29@haskell.org> #9215: GHC 7.8.2 mingw-w64: symbol not found in link -------------------------------------+------------------------------------- Reporter: | Owner: stuartallenmills | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: x86_64 (amd64) Operating System: Windows | Difficulty: Unknown Type of failure: Other | Blocked By: Test Case: | Related Tickets: #9218 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * related: => #9218 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 21:18:46 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 21:18:46 -0000 Subject: [GHC] #8671: Rebindable syntax creates bogus warning In-Reply-To: <050.07c801a7681cbd433cc4bd9ae7655ac2@haskell.org> References: <050.07c801a7681cbd433cc4bd9ae7655ac2@haskell.org> Message-ID: <065.209ff028c2d1c3754960e972ac6141e4@haskell.org> #8671: Rebindable syntax creates bogus warning -------------------------------------+------------------------------------- Reporter: | Owner: thomaseding | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: warning at compile-time | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * os: Windows => Unknown/Multiple Comment: This doesn't look Windows-specific. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 21:23:48 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 21:23:48 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values Message-ID: <047.98d7de74203e4f381291a803ad282f11@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | 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: Compile- Blocked By: | time crash Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It's possible to declare a toplevel unboxed value with a pattern synonym, which causes a panic: {{{ {-# LANGUAGE PatternSynonyms, MagicHash #-} pattern P = 0# }}} (compare with error on `x = 0#`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 21:24:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 21:24:56 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.77080fca70a27932eca8eea4689e5adb@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by monoidal: Old description: > It's possible to declare a toplevel unboxed value with a pattern synonym, > which causes a panic: > > {{{ > {-# LANGUAGE PatternSynonyms, MagicHash #-} > pattern P = 0# > }}} > > (compare with error on `x = 0#`). New description: It's possible to declare a toplevel unboxed value with a pattern synonym, which causes a panic: {{{ {-# LANGUAGE PatternSynonyms, MagicHash #-} pattern P = 0# }}} (compare with error on `x = 0#`). `pattern P <- 0#` seems to work fine. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 21:47:11 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 21:47:11 -0000 Subject: [GHC] #7191: hsc2hs can't treat absolute path correctly on Windows. In-Reply-To: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> References: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> Message-ID: <062.2c015d42b8e20ba0d36fa6802215518a@haskell.org> #7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => infoneeded Comment: Can someone confirm? I just tried to reproduce the bug on 2014.2.0.0 but did not run into any problems. Absolute paths worked fine both from cmd.exe and from msys2 bash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 21:47:22 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 21:47:22 -0000 Subject: [GHC] #5305: crash after writing around 40 gigabytes to stdout In-Reply-To: <043.48fee4d3a7f28cbdbb3c32eded172ce9@haskell.org> References: <043.48fee4d3a7f28cbdbb3c32eded172ce9@haskell.org> Message-ID: <058.294f1a59247118cec16065799df23672@haskell.org> #5305: crash after writing around 40 gigabytes to stdout -------------------------------------+------------------------------------- Reporter: lava | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Runtime | Difficulty: Unknown crash | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => infoneeded * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 21:52:03 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 21:52:03 -0000 Subject: [GHC] #2628: hIsTerminalDevice returns True for /dev/null (aka NUL) on Windows In-Reply-To: <044.c1bd1c3ac0471340a6fae29b24f965a3@haskell.org> References: <044.c1bd1c3ac0471340a6fae29b24f965a3@haskell.org> Message-ID: <059.45267cbdfe728bf3b6ac58358ba2ca56@haskell.org> #2628: hIsTerminalDevice returns True for /dev/null (aka NUL) on Windows -----------------------------------------+--------------------------- Reporter: igloo | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: ? Component: Core Libraries | Version: 6.8.3 Resolution: wontfix | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: 2228 | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------- Changes (by gintas): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => wontfix Comment: The test passes here in an msys2 window, which is the new official ghc build environment. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 22:00:56 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 22:00:56 -0000 Subject: [GHC] #9101: Need option to use system gcc and binutils on Windows/msys2 (was: Build 7.8.2 from sources on Windows/msys2) In-Reply-To: <047.9aaf79de73007bb10bd989466d9c86e1@haskell.org> References: <047.9aaf79de73007bb10bd989466d9c86e1@haskell.org> Message-ID: <062.d7bf2d962ba672a2f7c833ae783e277d@haskell.org> #9101: Need option to use system gcc and binutils on Windows/msys2 -------------------------------------+------------------------------------- Reporter: cchantep | Owner: gintas Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Build | Keywords: System | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: Windows | Blocked By: Type of failure: | Related Tickets: #9218 None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * type: bug => feature request * component: Compiler => Build System * related: => #9218 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 22:01:53 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 22:01:53 -0000 Subject: [GHC] #8830: internal error: Misaligned section: 18206e5b on Windows In-Reply-To: <047.c72974f625aa2960800193f6a0ae2799@haskell.org> References: <047.c72974f625aa2960800193f6a0ae2799@haskell.org> Message-ID: <062.7c36ee0ad4e8baa0c5e63a84cf162291@haskell.org> #8830: internal error: Misaligned section: 18206e5b on Windows -------------------------------------+------------------------------ Reporter: joeyhess | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------ Changes (by gintas): * status: new => infoneeded Comment: Could you provide more detailed instructions to reproduce the issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 22:05:17 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 22:05:17 -0000 Subject: [GHC] #110: Cygwin binaries In-Reply-To: <046.e27078d66dc3ce56ae08f6163d6a3403@haskell.org> References: <046.e27078d66dc3ce56ae08f6163d6a3403@haskell.org> Message-ID: <061.cd87ee688c9005c29a995b88952dee46@haskell.org> #110: Cygwin binaries -------------------------------------+------------------------------------- Reporter: fizzgig | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: None Component: None | Keywords: Resolution: None | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): Are we sure we still want this? Mingw binaries are generally preferred on Windows, and the current ghc Windows build is quite usable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 22:21:50 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 22:21:50 -0000 Subject: [GHC] #8229: Linking in Windows is slow In-Reply-To: <045.f2fe9210b16252447cedd8c4a7748b17@haskell.org> References: <045.f2fe9210b16252447cedd8c4a7748b17@haskell.org> Message-ID: <060.74a6c4007a918d64a62ea8e338855aca@haskell.org> #8229: Linking in Windows is slow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Compile- | Difficulty: Unknown time performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): I'd like to try this with the newer mingw-w64 / gcc 4.8.3. What do I need to do to build a dynamic GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 22:30:06 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 22:30:06 -0000 Subject: [GHC] #989: Build GHC on Windows using Microsoft toolchain (was: Windows "native" port) In-Reply-To: <047.96e16f269cc7176052a090de33c91146@haskell.org> References: <047.96e16f269cc7176052a090de33c91146@haskell.org> Message-ID: <062.cbfdc5f6f9290f62831bf64de26dbfa8@haskell.org> #989: Build GHC on Windows using Microsoft toolchain -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: feature | Status: new request | Milestone: ? Priority: normal | Version: Component: Build | Keywords: System | Architecture: x86 Resolution: | Difficulty: Project (more Operating System: Windows | than a week) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: N/A | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * difficulty: Difficult (2-5 days) => Project (more than a week) * type: task => feature request * component: Compiler => Build System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 22:34:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 22:34:42 -0000 Subject: [GHC] #2465: View + Pattern Match not fused sufficiently In-Reply-To: <044.d33f6438c82e85b6cd4f00a3e01e2de0@haskell.org> References: <044.d33f6438c82e85b6cd4f00a3e01e2de0@haskell.org> Message-ID: <059.15a42fcb704f40059ac4e0b1e914ff01@haskell.org> #2465: View + Pattern Match not fused sufficiently -------------------------------------+------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Operating System: | Architecture: x86 Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by gintas): * os: Windows => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 22:44:51 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 22:44:51 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.1d9d83aea3fc9639619a46fb38bab450@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => cactus -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 27 23:24:42 2014 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Oct 2014 23:24:42 -0000 Subject: [GHC] #9713: Update comment about C helper for dynamic exports. In-Reply-To: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> References: <044.083f4fc80ef23a774f83bde7913d8490@haskell.org> Message-ID: <059.0b60a82243764976bac9beac27ee143a@haskell.org> #9713: Update comment about C helper for dynamic exports. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by thomie): > note that it is changing a latex style .lhs file Thanks, I missed that. Patch LGTM now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 01:20:11 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 01:20:11 -0000 Subject: [GHC] #9733: Strange errors when using type families as parameters Message-ID: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> #9733: Strange errors when using type families as parameters -------------------------------------+------------------------------------- Reporter: crockeea | 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: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I seem to have found a dark corner of GHC. In the process of finding a minimal example, I found a few different ways to trigger a bug. I'm assuming they are all related. == Example 1 == I started off with a GADT parameterized by a type list: {{{#!haskell {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} module Foo where type TList = '[Float, Double] type family PrevElt (xs :: [*]) (a :: *) :: * where PrevElt (b ': a ': xs) a = b PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a data FooList :: ([*] -> * -> *) where Bar :: FooList prevrp ((PrevElt prevrp rp) -> rp) test1 :: FooList TList ((PrevElt TList rp) -> rp) test1 = Bar }}} which compiles as expected. If I make a syntactic change and parameterize the GADT with the type family rather than the type list: {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} module Foo where type TList = '[Float, Double] type family PrevElt (xs :: [*]) (a :: *) :: * where PrevElt (b ': a ': xs) a = b PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a data FooTF :: ((* -> *) -> * -> *) where Bar :: FooTF prevrp ((prevrp rp) -> rp) test2 :: FooTF (PrevElt TList) ((PrevElt TList rp) -> rp) test2 = Bar }}} I get a non-sensical error: {{{ Foo.hs:15:9: Couldn't match type `PrevElt TList rp' with `PrevElt TList rp' NB: `PrevElt' is a type function, and may not be injective Expected type: FooTF (PrevElt TList) (PrevElt TList rp -> rp) Actual type: FooTF (PrevElt TList) (PrevElt TList rp -> rp) Relevant bindings include test2 :: FooTF (PrevElt TList) (PrevElt TList rp -> rp) (bound at testsuite\Foo.hs:15:1) In the expression: Bar In an equation for `test2': test2 = Bar }}} As far as I know, this should compile. == Example 2 == Another simple example uses [https://hackage.haskell.org/package/syntactic syntactic], along with the type-family-parameterized GADT: {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} module Foo where import Data.Syntactic type family PrevElt (xs :: [*]) (a :: *) :: * where PrevElt (b ': a ': xs) a = b PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a data FooTF :: ((* -> *) -> * -> *) where Const :: FooTF prevrp (Full rp) Bar :: FooTF prevrp ((prevrp rp) :-> Full rp) type T1 = Double type T2 = Float type Dom = FooTF (PrevElt '[T1, T2]) leaf = inj (Const :: Dom (Full T1)) :: ASTF Dom T1 t1 = inj (Bar :: Dom (T1 :-> Full T2)) :$ leaf :: ASTF Dom T2 }}} By only changing the types `T1` and `T2`: {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} module Foo where import Data.Syntactic type family PrevElt (xs :: [*]) (a :: *) :: * where PrevElt (b ': a ': xs) a = b PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a data FooTF :: ((* -> *) -> * -> *) where Const :: FooTF prevrp (Full rp) Bar :: FooTF prevrp ((prevrp rp) :-> Full rp) data T type T1 = T Double type T2 = T Float type Dom = FooTF (PrevElt '[T1, T2]) leaf = inj (Const :: Dom (Full T1)) :: ASTF Dom T1 t1 = inj (Bar :: Dom (T1 :-> Full T2)) :$ leaf :: ASTF Dom T2 }}} GHC complains: {{{ Foo.hs:21:11: Couldn't match type ?Double? with ?T Float? Expected type: Dom (T1 :-> Full T2) Actual type: FooTF T (T Double :-> Full Double) In the first argument of ?inj?, namely ?(Bar :: Dom (T1 :-> Full T2))? In the first argument of ?(:$)?, namely ?inj (Bar :: Dom (T1 :-> Full T2))? Failed, modules loaded: none. }}} == Example 3 == I've also attached a larger example (also using [https://hackage.haskell.org/package/syntactic syntactic]) that has [more, different] errors, which I believe to be related to this problem. Errors for the attached file are: {{{ Foo.hs:32:6: Couldn't match type `NextElt TList (PrevElt ((':) * (T' Float) ('[] *)) Double)' with `Double' Expected type: Double Actual type: NextElt TList (PrevElt TList Double) In the first argument of `(:$)', namely `inj' Bar' In the expression: inj' Bar :$ leaf In an equation for `t1': t1 = inj' Bar :$ leaf Foo.hs:32:11: Couldn't match type `PrevElt TList' with T' Expected type: Dom (Foo (T' Double) T1 :-> Full (Foo Double T1)) Actual type: FooTF T' (Foo (T' Double) T1 :-> Full (Foo Double T1)) In the first argument of inj', namely `Bar' In the first argument of `(:$)', namely `inj' Bar' }}} In the first error, the `Actual type: NextElt TList (PrevElt TList Double)` is strange because `Double` only occurs as a parameter to `T'`, and never as a naked type that could be applied to type family. In the second error, GHC seems to be confusing two types of kind `(* -> *)`: `T'` and `PrevElt TList`. Changing the GADT from type-family-indexed to type-list-index (like in the first example) makes the attached code compile. I minimized the attached example as much as possible: any changes I made to simplify the code resulted in different errors, which may also be helpful for finding this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 02:42:06 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 02:42:06 -0000 Subject: [GHC] #9733: Strange errors when using type families as parameters In-Reply-To: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> References: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> Message-ID: <062.376ba00fc2c58a15e740191445aadcf4@haskell.org> #9733: Strange errors when using type families as parameters -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I believe that these are all variations on #9433, which is fixed in HEAD. Each example (save the first) uses an under-saturated type family. If you concur, please close as duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 02:56:31 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 02:56:31 -0000 Subject: [GHC] #9733: Strange errors when using type families as parameters In-Reply-To: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> References: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> Message-ID: <062.e3139ba0295a964409161013d5e7951b@haskell.org> #9733: Strange errors when using type families as parameters -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): My errors do look very similar to those in #9433. Can someone verify that HEAD handles the cases above appropriately? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 03:18:20 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 03:18:20 -0000 Subject: [GHC] #9733: Strange errors when using type families as parameters In-Reply-To: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> References: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> Message-ID: <062.0a771653a4cf0a5e81cfb0efebe1766c@haskell.org> #9733: Strange errors when using type families as parameters -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): Example 1 result: {{{ [1 of 1] Compiling Foo ( t1.hs, t1.o ) t1.hs:14:10: Type family ?PrevElt? should have 2 arguments, but has been given 1 In the type signature for ?test2?: test2 :: FooTF (PrevElt TList) ((PrevElt TList rp) -> rp) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 07:16:46 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 07:16:46 -0000 Subject: [GHC] #9664: Add identity functor to base In-Reply-To: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> References: <042.d93212f5c77e3a86c1eb4895b4ba2ebb@haskell.org> Message-ID: <057.2242c182a29b3a3c222451303b9af8fd@haskell.org> #9664: Add identity functor to base -------------------------------------+------------------------------------- Reporter: hvr | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D313 | -------------------------------------+------------------------------------- Comment (by hvr): @ross, any comments to my last comment? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 09:21:10 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 09:21:10 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.8d278a91379aa02952ead7acfefc8c08@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): `pattern P <- 0#` doesn't completely work either: {{{ {-# LANGUAGE PatternSynonyms, MagicHash #-} pattern PAT <- 0# f PAT = 42# g 0# = 42# }}} This results in an `f` function that always fails the pattern match: {{{ Main.f :: GHC.Prim.Int# -> GHC.Prim.Int# [GblId, Arity=1, Str=DmdType] Main.f = \ _ [Occ=Dead] -> break<4>() Control.Exception.Base.patError @ GHC.Prim.Int# "T9732.hs:6:1-11|function f"# }}} Contrast this with {{{ Main.g :: GHC.Prim.Int# -> GHC.Prim.Int# [GblId, Arity=1, Str=DmdType] Main.g = \ (ds_dL5 :: GHC.Prim.Int#) -> break<1>() case ds_dL5 of _ [Occ=Dead] { __DEFAULT -> Control.Exception.Base.patError @ GHC.Prim.Int# "T9732.hs:7:1-10|function g"#; 0 -> break<0>() 42 } }}} Interestingly, if `f` returns a lifted `Int`, it all works out as expected: {{{ f PAT = (42 :: Int) }}} results in {{{ Main.f :: GHC.Prim.Int# -> GHC.Types.Int [GblId, Arity=1, Str=DmdType] Main.f = \ (ds_dLU :: GHC.Prim.Int#) -> break<4>() let { cont_aLE :: GHC.Types.Int [LclId, Str=DmdType] cont_aLE = break<3>() GHC.Types.I# 42 } in let { fail_aLF :: GHC.Types.Int [LclId, Str=DmdType] fail_aLF = Control.Exception.Base.patError @ GHC.Types.Int "T9732.hs:6:1-19|function f"# } in break<2>(fail_aLF,cont_aLE) case ds_dLU of _ [Occ=Dead] { __DEFAULT -> fail_aLF; 0 -> cont_aLE } }}} Is it a good idea to just disallow pattern synonyms of unlifted types? Or should `pattern P <- 0#` work at least? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 11:43:07 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 11:43:07 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.4db9dfea4291e8c5b1b957d6843ad691@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): I would think that pattern synonyms for unlifted types ''should'' work, but with the same restrictions as normal patterns for unlifted types. That is, you can't use these patterns to define a global variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 11:45:04 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 11:45:04 -0000 Subject: [GHC] #9733: Strange errors when using type families as parameters In-Reply-To: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> References: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> Message-ID: <062.1831894eeccc2a32c4cb2bfc033c0079@haskell.org> #9733: Strange errors when using type families as parameters -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Yep -- that's #9433 talking. Closing. Sorry that crockeea seemingly put time into crafting a nice bug report for a duplicate! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 11:58:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 11:58:02 -0000 Subject: [GHC] #9433: Partially applied type family allowed but unusable In-Reply-To: <048.32c0a789e233f979db2cb332186dcb22@haskell.org> References: <048.32c0a789e233f979db2cb332186dcb22@haskell.org> Message-ID: <063.2e8342242c2ca3d846e81120997e62f9@haskell.org> #9433: Partially applied type family allowed but unusable -------------------------------------+------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.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: indexed- | types/should_fail/T9433 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by rodlogic): Related ticket was closed as a duplicate: #9733 (may contain additional information that is relevant here). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 13:13:45 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 13:13:45 -0000 Subject: [GHC] #9733: Strange errors when using type families as parameters In-Reply-To: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> References: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> Message-ID: <062.33eb3e9bff6db88f81eb5f1e39c658c9@haskell.org> #9733: Strange errors when using type families as parameters -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > I seem to have found a dark corner of GHC. In the process of finding a > minimal example, I found a few different ways to trigger a bug. I'm > assuming they are all related. > > == Example 1 == > I started off with a GADT parameterized by a type list: > > {{{#!haskell > {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} > > module Foo where > > type TList = '[Float, Double] > > type family PrevElt (xs :: [*]) (a :: *) :: * where > PrevElt (b ': a ': xs) a = b > PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a > > data FooList :: ([*] -> * -> *) where > Bar :: FooList prevrp ((PrevElt prevrp rp) -> rp) > > test1 :: FooList TList ((PrevElt TList rp) -> rp) > test1 = Bar > }}} > which compiles as expected. > > If I make a syntactic change and parameterize the GADT with the type > family rather than the type list: > > {{{#!hs > {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} > > module Foo where > > type TList = '[Float, Double] > > type family PrevElt (xs :: [*]) (a :: *) :: * where > PrevElt (b ': a ': xs) a = b > PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a > > data FooTF :: ((* -> *) -> * -> *) where > Bar :: FooTF prevrp ((prevrp rp) -> rp) > > test2 :: FooTF (PrevElt TList) ((PrevElt TList rp) -> rp) > test2 = Bar > }}} > I get a non-sensical error: > {{{ > Foo.hs:15:9: > Couldn't match type `PrevElt TList rp' with `PrevElt TList rp' > NB: `PrevElt' is a type function, and may not be injective > Expected type: FooTF (PrevElt TList) (PrevElt TList rp -> rp) > Actual type: FooTF (PrevElt TList) (PrevElt TList rp -> rp) > Relevant bindings include > test2 :: FooTF (PrevElt TList) (PrevElt TList rp -> rp) > (bound at testsuite\Foo.hs:15:1) > In the expression: Bar > In an equation for `test2': test2 = Bar > }}} > As far as I know, this should compile. > > == Example 2 == > Another simple example uses > [https://hackage.haskell.org/package/syntactic syntactic], along with the > type-family-parameterized GADT: > {{{#!hs > {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} > > module Foo where > > import Data.Syntactic > > type family PrevElt (xs :: [*]) (a :: *) :: * where > PrevElt (b ': a ': xs) a = b > PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a > > data FooTF :: ((* -> *) -> * -> *) where > Const :: FooTF prevrp (Full rp) > Bar :: FooTF prevrp ((prevrp rp) :-> Full rp) > > type T1 = Double > type T2 = Float > type Dom = FooTF (PrevElt '[T1, T2]) > > leaf = inj (Const :: Dom (Full T1)) :: ASTF Dom T1 > t1 = inj (Bar :: Dom (T1 :-> Full T2)) :$ leaf :: ASTF Dom T2 > }}} > > By only changing the types `T1` and `T2`: > {{{#!hs > {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} > > module Foo where > > import Data.Syntactic > > type family PrevElt (xs :: [*]) (a :: *) :: * where > PrevElt (b ': a ': xs) a = b > PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a > > data FooTF :: ((* -> *) -> * -> *) where > Const :: FooTF prevrp (Full rp) > Bar :: FooTF prevrp ((prevrp rp) :-> Full rp) > > data T > type T1 = T Double > type T2 = T Float > type Dom = FooTF (PrevElt '[T1, T2]) > > leaf = inj (Const :: Dom (Full T1)) :: ASTF Dom T1 > t1 = inj (Bar :: Dom (T1 :-> Full T2)) :$ leaf :: ASTF Dom T2 > }}} > > GHC complains: > > {{{ > Foo.hs:21:11: > Couldn't match type ?Double? with ?T Float? > Expected type: Dom (T1 :-> Full T2) > Actual type: FooTF T (T Double :-> Full Double) > In the first argument of ?inj?, namely > ?(Bar :: Dom (T1 :-> Full T2))? > In the first argument of ?(:$)?, namely > ?inj (Bar :: Dom (T1 :-> Full T2))? > Failed, modules loaded: none. > }}} > > == Example 3 == > I've also attached a larger example (also using > [https://hackage.haskell.org/package/syntactic syntactic]) that has > [more, different] errors, which I believe to be related to this problem. > Errors for the attached file are: > > {{{ > Foo.hs:32:6: > Couldn't match type `NextElt TList (PrevElt ((':) * (T' Float) ('[] > *)) Double)' > with `Double' > Expected type: Double > Actual type: NextElt TList (PrevElt TList Double) > In the first argument of `(:$)', namely `inj' Bar' > In the expression: inj' Bar :$ leaf > In an equation for `t1': t1 = inj' Bar :$ leaf > > Foo.hs:32:11: > Couldn't match type `PrevElt TList' with T' > Expected type: Dom (Foo (T' Double) T1 :-> Full (Foo Double T1)) > Actual type: FooTF > T' (Foo (T' Double) T1 :-> Full (Foo Double T1)) > In the first argument of inj', namely `Bar' > In the first argument of `(:$)', namely `inj' Bar' > }}} > > In the first error, the `Actual type: NextElt TList (PrevElt TList > Double)` is strange because `Double` only occurs as a parameter to `T'`, > and never as a naked type that could be applied to type family. > > In the second error, GHC seems to be confusing two types of kind `(* -> > *)`: `T'` and `PrevElt TList`. > > Changing the GADT from type-family-indexed to type-list-index (like in > the first example) makes the attached code compile. I minimized the > attached example as much as possible: any changes I made to simplify the > code resulted in different errors, which may also be helpful for finding > this bug. New description: I seem to have found a dark corner of GHC. In the process of finding a minimal example, I found a few different ways to trigger a bug. I'm assuming they are all related. == Example 1 == I started off with a GADT parameterized by a type list: {{{#!haskell {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} module Foo where type TList = '[Float, Double] type family PrevElt (xs :: [*]) (a :: *) :: * where PrevElt (b ': a ': xs) a = b PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a data FooList :: ([*] -> * -> *) where Bar :: FooList prevrp ((PrevElt prevrp rp) -> rp) test1 :: FooList TList ((PrevElt TList rp) -> rp) test1 = Bar }}} which compiles as expected. If I make a syntactic change and parameterize the GADT with the type family rather than the type list: {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} module Foo where type TList = '[Float, Double] type family PrevElt (xs :: [*]) (a :: *) :: * where PrevElt (b ': a ': xs) a = b PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a data FooTF :: ((* -> *) -> * -> *) where Bar :: FooTF prevrp ((prevrp rp) -> rp) test2 :: FooTF (PrevElt TList) ((PrevElt TList rp) -> rp) test2 = Bar }}} I get a non-sensical error: {{{ Foo.hs:15:9: Couldn't match type `PrevElt TList rp' with `PrevElt TList rp' NB: `PrevElt' is a type function, and may not be injective Expected type: FooTF (PrevElt TList) (PrevElt TList rp -> rp) Actual type: FooTF (PrevElt TList) (PrevElt TList rp -> rp) Relevant bindings include test2 :: FooTF (PrevElt TList) (PrevElt TList rp -> rp) (bound at testsuite\Foo.hs:15:1) In the expression: Bar In an equation for `test2': test2 = Bar }}} As far as I know, this should compile. == Example 2 == Another simple example uses [https://hackage.haskell.org/package/syntactic syntactic], along with the type-family-parameterized GADT: {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} module Foo where import Data.Syntactic type family PrevElt (xs :: [*]) (a :: *) :: * where PrevElt (b ': a ': xs) a = b PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a data FooTF :: ((* -> *) -> * -> *) where Const :: FooTF prevrp (Full rp) Bar :: FooTF prevrp ((prevrp rp) :-> Full rp) type T1 = Double type T2 = Float type Dom = FooTF (PrevElt '[T1, T2]) leaf = inj (Const :: Dom (Full T1)) :: ASTF Dom T1 t1 = inj (Bar :: Dom (T1 :-> Full T2)) :$ leaf :: ASTF Dom T2 }}} By only changing the types `T1` and `T2`: {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, DataKinds, TypeOperators #-} module Foo where import Data.Syntactic type family PrevElt (xs :: [*]) (a :: *) :: * where PrevElt (b ': a ': xs) a = b PrevElt (b ': c ': xs) a = PrevElt (c ': xs) a data FooTF :: ((* -> *) -> * -> *) where Const :: FooTF prevrp (Full rp) Bar :: FooTF prevrp ((prevrp rp) :-> Full rp) data T a type T1 = T Double type T2 = T Float type Dom = FooTF (PrevElt '[T1, T2]) leaf = inj (Const :: Dom (Full T1)) :: ASTF Dom T1 t1 = inj (Bar :: Dom (T1 :-> Full T2)) :$ leaf :: ASTF Dom T2 }}} GHC complains: {{{ Foo.hs:21:11: Couldn't match type ?Double? with ?T Float? Expected type: Dom (T1 :-> Full T2) Actual type: FooTF T (T Double :-> Full Double) In the first argument of ?inj?, namely ?(Bar :: Dom (T1 :-> Full T2))? In the first argument of ?(:$)?, namely ?inj (Bar :: Dom (T1 :-> Full T2))? Failed, modules loaded: none. }}} == Example 3 == I've also attached a larger example (also using [https://hackage.haskell.org/package/syntactic syntactic]) that has [more, different] errors, which I believe to be related to this problem. Errors for the attached file are: {{{ Foo.hs:32:6: Couldn't match type `NextElt TList (PrevElt ((':) * (T' Float) ('[] *)) Double)' with `Double' Expected type: Double Actual type: NextElt TList (PrevElt TList Double) In the first argument of `(:$)', namely `inj' Bar' In the expression: inj' Bar :$ leaf In an equation for `t1': t1 = inj' Bar :$ leaf Foo.hs:32:11: Couldn't match type `PrevElt TList' with T' Expected type: Dom (Foo (T' Double) T1 :-> Full (Foo Double T1)) Actual type: FooTF T' (Foo (T' Double) T1 :-> Full (Foo Double T1)) In the first argument of inj', namely `Bar' In the first argument of `(:$)', namely `inj' Bar' }}} In the first error, the `Actual type: NextElt TList (PrevElt TList Double)` is strange because `Double` only occurs as a parameter to `T'`, and never as a naked type that could be applied to type family. In the second error, GHC seems to be confusing two types of kind `(* -> *)`: `T'` and `PrevElt TList`. Changing the GADT from type-family-indexed to type-list-index (like in the first example) makes the attached code compile. I minimized the attached example as much as possible: any changes I made to simplify the code resulted in different errors, which may also be helpful for finding this bug. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 13:15:01 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 13:15:01 -0000 Subject: [GHC] #9733: Strange errors when using type families as parameters In-Reply-To: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> References: <047.de323f518f5460efee6e4c422bc0b4b2@haskell.org> Message-ID: <062.7569bfa4b501afdccc78a0974fd2c4d7@haskell.org> #9733: Strange errors when using type families as parameters -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by crockeea): I verified that all of the snippets above behave reasonably with HEAD, so this is indeed a duplicate. Mostly that means that I get an error about partially applied type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 14:31:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 14:31:16 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.1916b88dff686e825ff79794d2cf325e@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Right. If it works when the pattern synonym is expanded, it should work un-expanded Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 14:36:42 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 14:36:42 -0000 Subject: [GHC] #9716: The list modules need a bit of post-BBP shaking In-Reply-To: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> References: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> Message-ID: <060.4a63001f71c38392b6fe3b81277b3bd5@haskell.org> #9716: The list modules need a bit of post-BBP shaking -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: lists Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D380 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"75979f3661ff16ec44528a23005ac1be2b9683fe/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="75979f3661ff16ec44528a23005ac1be2b9683fe" base: Refactor/clean-up *List modules This gets rid of all hand-unboxing in `GHC.List` and moves `Foldable` requirements from `Data.OldList` into `GHC.List` (preparatory work for addressing #9716). Specifically, this moves the definition of `maximum`, `minimum`, `foldl'`, `foldl1`, `foldl1'`, `sum`, and `product` into `GHC.List` (which now needs to import `GHC.Num`) Make `take`, `drop`, `length`, and `!!` generally saner (see also #9510) Performance overall seems minimally affected. Some things go up; some things go down; nothing moves horribly much. The code is much easier to read. Differential Revision: https://phabricator.haskell.org/D380 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 14:36:43 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 14:36:43 -0000 Subject: [GHC] #9510: Prelude.!! is not a good consumer In-Reply-To: <045.ea9dba32ca908a61e9807eddb78f8a5a@haskell.org> References: <045.ea9dba32ca908a61e9807eddb78f8a5a@haskell.org> Message-ID: <060.aa0e1a715e0e70ef39bd49a02baf4afb@haskell.org> #9510: Prelude.!! is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: Component: Core | Version: 7.8.3 Libraries | Keywords: fusion Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D380 | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"75979f3661ff16ec44528a23005ac1be2b9683fe/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="75979f3661ff16ec44528a23005ac1be2b9683fe" base: Refactor/clean-up *List modules This gets rid of all hand-unboxing in `GHC.List` and moves `Foldable` requirements from `Data.OldList` into `GHC.List` (preparatory work for addressing #9716). Specifically, this moves the definition of `maximum`, `minimum`, `foldl'`, `foldl1`, `foldl1'`, `sum`, and `product` into `GHC.List` (which now needs to import `GHC.Num`) Make `take`, `drop`, `length`, and `!!` generally saner (see also #9510) Performance overall seems minimally affected. Some things go up; some things go down; nothing moves horribly much. The code is much easier to read. Differential Revision: https://phabricator.haskell.org/D380 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 14:47:09 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 14:47:09 -0000 Subject: [GHC] #9510: Prelude.!! is not a good consumer In-Reply-To: <045.ea9dba32ca908a61e9807eddb78f8a5a@haskell.org> References: <045.ea9dba32ca908a61e9807eddb78f8a5a@haskell.org> Message-ID: <060.37eaf749b2c0bf3c749d4267fd57e9dd@haskell.org> #9510: Prelude.!! is not a good consumer -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: fusion Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: performance bug | Test Case: | Blocking: | Differential Revisions: Phab:D380 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 14:49:00 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 14:49:00 -0000 Subject: [GHC] #9716: The list modules need a bit of post-BBP shaking In-Reply-To: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> References: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> Message-ID: <060.4465b9c3b1c40e40a35824a003777a32@haskell.org> #9716: The list modules need a bit of post-BBP shaking -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: lists Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D380 | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: ekmett => * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 14:56:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 14:56:55 -0000 Subject: [GHC] #9734: Provide macro __GLASGOW_HASKELL_TH__ Message-ID: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> #9734: Provide macro __GLASGOW_HASKELL_TH__ -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 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: -------------------------------------+------------------------------------- The Debian packaging added a few hacks to create a CPP macro that can be used to distinguish compilers with Template Haskell support from those that don?t have that support. We need this to compiler some code on non- TH architectures. It works, but we found that we cannot upstream such patches, which is a shame. I propose that among the GHC-defined macros listed at https://www.haskell.org/ghc/docs/latest/html/users_guide/options- phases.html#c-pre-processor there is also `__GLASGOW_HASKELL_TH__=YES`, which is available if the compiler supports splices, or ``__GLASGOW_HASKELL_TH__=NO` if not. (I propose a two-valued comparison so that library authors can decide themselves what the default should be if this symbol is not defined, some might want to use TH on older compilers, some not.) I hope this can be part of 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 14:57:35 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 14:57:35 -0000 Subject: [GHC] #9734: Provide macro __GLASGOW_HASKELL_TH__ In-Reply-To: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> References: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> Message-ID: <061.f1cae33a845baa3cf5d4feb63bcee080@haskell.org> #9734: Provide macro __GLASGOW_HASKELL_TH__ -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by nomeata: Old description: > The Debian packaging added a few hacks to create a CPP macro that can be > used to distinguish compilers with Template Haskell support from those > that don?t have that support. We need this to compiler some code on non- > TH architectures. > > It works, but we found that we cannot upstream such patches, which is a > shame. > > I propose that among the GHC-defined macros listed at > https://www.haskell.org/ghc/docs/latest/html/users_guide/options- > phases.html#c-pre-processor there is also `__GLASGOW_HASKELL_TH__=YES`, > which is available if the compiler supports splices, or > ``__GLASGOW_HASKELL_TH__=NO` if not. > > (I propose a two-valued comparison so that library authors can decide > themselves what the default should be if this symbol is not defined, some > might want to use TH on older compilers, some not.) > > I hope this can be part of 7.10. New description: The Debian packaging added a few hacks to create a CPP macro that can be used to distinguish compilers with Template Haskell support from those that don?t have that support. We need this to compiler some code on non- TH architectures. It works, but we found that we cannot upstream such patches, which is a shame. I propose that among the GHC-defined macros listed at https://www.haskell.org/ghc/docs/latest/html/users_guide/options- phases.html#c-pre-processor there is also `__GLASGOW_HASKELL_TH__=YES`, which is available if the compiler supports splices, or `__GLASGOW_HASKELL_TH__=NO` if not. (I propose a two-valued comparison so that library authors can decide themselves what the default should be if this symbol is not defined, some might want to use TH on older compilers, some not.) I hope this can be part of 7.10. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 15:02:29 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 15:02:29 -0000 Subject: [GHC] #9716: The list modules need a bit of post-BBP shaking In-Reply-To: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> References: <045.9e2c5f46e95f06cf5cb5b0c85cab6d33@haskell.org> Message-ID: <060.512437f3e5db367b92a5b862fb2ee1bf@haskell.org> #9716: The list modules need a bit of post-BBP shaking -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: lists Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D380 | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: => ekmett -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 15:08:54 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 15:08:54 -0000 Subject: [GHC] #9734: Provide macro __GLASGOW_HASKELL_TH__ In-Reply-To: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> References: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> Message-ID: <061.abd764c644b7ceac5166bf52e4552c70@haskell.org> #9734: Provide macro __GLASGOW_HASKELL_TH__ -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D386 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D386 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 15:18:02 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 15:18:02 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.8b65ceb1c655a5b47c5454298f03ce11@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.9 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D387 | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D387 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 15:27:55 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 15:27:55 -0000 Subject: [GHC] #9735: Template Haskell for cross compilers (port from GHCJS) Message-ID: <044.571ab421ac035967d7e54249bed99e9a@haskell.org> #9735: Template Haskell for cross compilers (port from GHCJS) -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 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: -------------------------------------+------------------------------------- GHCJS supports Template Haskell by running it outside the compiler's process, with a different implementation of the Quasi type class. This can be done for other cross compilers too, if GHC gets an option to serialize Template Haskell requests and pass them to an external process. Someone started the work on this, but I think he stopped. I still have a document with a step by step plan to build an iOS cross compiler, with pointers to the relevant GHC and GHCJS code. https://github.com/ghcjs/ghcjs/wiki/Porting-GHCJS-Template-Haskell-to-GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 15:34:56 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 15:34:56 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC In-Reply-To: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> References: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> Message-ID: <058.fdf3c8e0c1727d3eeb292eedd0e56c10@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => infoneeded Comment: I can't reproduce this problem. When I load your original files (that is, with `newName`, not `mkName`), I get this: {{{ Duplicate exact Name ?X? Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but bound it multiple times If that's it, then -ddump-splices might be useful }}} The error seems reasonable to me: the name is bound both as a type and as a data constructor. I'm also on GHC 7.8.3 on a Mac. Can you try again to reproduce the problem? Maybe your GHCi state had something else going on... perhaps a `ghci.conf` file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 15:35:59 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 15:35:59 -0000 Subject: [GHC] #9736: Constant folding rules are wrong for GHCJS Message-ID: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> #9736: Constant folding rules are wrong for GHCJS -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: bug | Status: new Priority: normal | Milestone: 7.10.1 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: -------------------------------------+------------------------------------- GHCJS currently has a complete copy of PrelRules to work around some issues where the rules depend on the build environment instead of the target. - shiftRightLogical - removeOp32 I'd like to get rid of the copy for 7.10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 15:36:27 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 15:36:27 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.6bf0bf5b6ab44042af6bab99dd387fd9@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------- Reporter: tulcod | Owner: archblob Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm doing a bunch of TH bugfixes. @archblob, you still working on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 16:32:03 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 16:32:03 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.0cfcf07f8fdd43d6460b488c4a83bd9f@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: Phab:D343 | -------------------------------------+------------------------------------- Comment (by jstolarek): Status update: [https://github.com/jstolarek/ghc/blob/T8326-heap-checks-alternative- plan/compiler/codeGen/StgCmmExpr.hs#L398 I tried knot-tying] but it doesn't work - `cgAlts` is strict in `gc_plan` and changing that doesn't look trivial. The only alternative I see at the moment is to: a) compile the alternatives without heap checks; b) examine heap usage of compiled alternatives c) create a GC plan d) add heap checks to compiled alternatives, if necessary That sounds simple but I have no idea how to leverage FCode monadery to add heap checks to compiled `CmmAGraph`. Am I right to think that currently there is no plumbing for compiling more code on top of already existing `CmmAGraph`? So far I was only able to came up with a prototype that [https://github.com/jstolarek/ghc/commit/266b1295abfc807f6aab2d6b3578f8d52e9295c9 #diff-6f97a583ff892976f6b49509aec5ab28R403 implements point a-c above but instead of d) it re-compiles the alternatives from scratch]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 16:51:47 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 16:51:47 -0000 Subject: [GHC] #9737: List ANN in pragmas chapter of user manual Message-ID: <047.d95ed21ed5b0c0a2ce03e4a2154ae9c7@haskell.org> #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: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 16:54:16 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 16:54:16 -0000 Subject: [GHC] #9738: Handle ANN pragmas in declaration splices Message-ID: <047.9007fbb41f2b3d6c8fece070225de54d@haskell.org> #9738: Handle ANN pragmas in declaration splices -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template Haskell | 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: -------------------------------------+------------------------------------- If I say {{{ $( do decs <- [d| data T = MkT {-# ANN type T "hi!" #-} |] runIO $ putStrLn $ pprint decs return decs ) }}} I get {{{ data T_0 = MkT_1 }}} No `ANN`. :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 17:03:05 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 17:03:05 -0000 Subject: [GHC] #9209: Template haskell panic In-Reply-To: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> References: <045.d647771768adeb307823d972c7c2dc2f@haskell.org> Message-ID: <060.6156521858812ebb8a510e03556a97ee@haskell.org> #9209: Template haskell panic -------------------------------------+------------------------------------- Reporter: tulcod | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 archblob): * owner: archblob => Comment: No, you can take ownership. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 17:24:24 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 17:24:24 -0000 Subject: [GHC] #9084: Template Haskell should warn when it encounters an unencodable pragma In-Reply-To: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> References: <047.5f052e5338f2346c8cf2671e4bbc517e@haskell.org> Message-ID: <062.4338f5ef7a5214a3c019024607671f1e@haskell.org> #9084: Template Haskell should warn when it encounters an unencodable pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.2 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D388 | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D388 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 18:15:21 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 18:15:21 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.514bc2d7514e1ff99c13d1d31cb41a54@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: Phab:D343 | -------------------------------------+------------------------------------- Comment (by jstolarek): BTW. I think it would be a Good Thing to make `FCode` monad an instance of `MonadFix` and replace `StgCmmMonad.fixC` with `mfix`. I think this would make code easier to read. People know what `mfix` is, while implementation of `fixC` might not be immediately obvious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 28 19:21:22 2014 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Oct 2014 19:21:22 -0000 Subject: [GHC] #9738: Handle ANN pragmas in declaration splices In-Reply-To: <047.9007fbb41f2b3d6c8fece070225de54d@haskell.org> References: <047.9007fbb41f2b3d6c8fece070225de54d@haskell.org> Message-ID: <062.d8eb4ced58ac671ff930cf26a8653ba5@haskell.org> #9738: Handle ANN pragmas in declaration splices -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Template | Version: 7.8.3 Haskell | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D389 | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D389 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 00:27:59 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 00:27:59 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes Message-ID: <046.2587334b1f81281802988a39c910928f@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Type checking this makes GHC 7.8.3 loop: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} module Foo where class Class3 a => Class1 a where class Class2 t a where class2 :: (Class3 t) => a -> m class (Class1 t, Class2 t t) => Class3 t where }}} Does not happen in 7.6.3. I think it's something to do with the `Class3` constraint appearing in `class2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 00:31:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 00:31:51 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.9905c208d340befb8e75e2c6e4c0b5a5@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by ezyang): * version: 7.8.3 => 7.9 Comment: Confirmed to loop on GHC HEAD 75979f3661ff16ec44528a23005ac1be2b9683fe -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 00:35:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 00:35:43 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.67d70e2dcbda605f52ecdfbefcde40f6@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * failure: None/Unknown => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 00:36:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 00:36:34 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.8becd592baebd05d5ad03b41978dd193@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bitonic): Actually, you don't need `MultiParamTypeClasses`: {{{#!hs module Foo where class Class3 a => Class1 a where class Class2 a where class2 :: (Class3 a) => b class (Class1 a, Class2 a) => Class3 a where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 00:38:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 00:38:56 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.8d89d000bc116d1312ab291e053b0468@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by bitonic): Aaaand with only two classes: {{{!#hs module Foo where class Class2 a => Class1 a where class3 :: (Class2 a) => b class (Class1 a) => Class2 a where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 00:41:27 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 00:41:27 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.6611a5190221971ab293e9b573dd6ca5@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 00:46:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 00:46:08 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.4fe88a6cec64bfa8c189eb95cad5d30a@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:4 bitonic]: > Aaaand with only two classes: > > {{{#!hs > module Foo where > > class Class2 a => Class1 a where > class3 :: (Class2 a) => b > > class (Class1 a) => Class2 a where > }}} The two-class version doesn't loop in 7.9; it just gets an error as it should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 01:24:37 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 01:24:37 -0000 Subject: [GHC] #9740: D380 caused fft2 regressions Message-ID: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> #9740: D380 caused fft2 regressions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D390 -------------------------------------+------------------------------------- When I got rid of the hand-unboxing in GHC.List, I missed the fact that a `take` helper function took an unboxed value and was therefore strict. When I changed that to a regular function, I didn't make it strict, and this caused a regression in fft2 and (I believe) also a test suite perf test. The function is properly strictified in D390. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 01:25:50 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 01:25:50 -0000 Subject: [GHC] #9740: D380 caused fft2 regressions In-Reply-To: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> References: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> Message-ID: <060.5d1a0fd185c49ecb4b7c1157029cc48c@haskell.org> #9740: D380 caused fft2 regressions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Easy (less than 1 Type of failure: Runtime | hour) performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D390 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 01:26:26 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 01:26:26 -0000 Subject: [GHC] #9740: D380 caused fft2 regressions In-Reply-To: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> References: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> Message-ID: <060.83f8b506c3b8a75418dec9b4ef798265@haskell.org> #9740: D380 caused fft2 regressions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D390 | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: core-libraries-committee@? (added) * component: Compiler => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 03:52:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 03:52:45 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.ba8f9bf061b3e259e56e0268713a3970@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): The problem with `pattern P = 0#` is that the wrapper it yields is `$WP = 0#` which is a top-level binding at an unboxed type. If `P` had any arguments, then `$WP` would be a function instead of a variable, and so it would be valid. So we could say that unboxed pattern synonyms are only allowed if they are either unidirectional or have arguments. But doesn't that sound a bit arbitrary? Side question: is it even possible to change the definition of `P` to have an argument but still be unboxed? Something like `pattern P x = (# 0#, x #)` doesn't work, because unboxed tuples are not allowed in patterns. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 04:04:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 04:04:31 -0000 Subject: [GHC] #9353: prefetch primops are not currently useful In-Reply-To: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> References: <050.df9431cf6a5e94b42f1021289c874b34@haskell.org> Message-ID: <065.ff83e63d533546478c7c5da09c1a7f62@haskell.org> #9353: prefetch primops are not currently useful -------------------------------------+------------------------------------- Reporter: | Owner: carter MikeIzbicki | Status: new Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D350 | -------------------------------------+------------------------------------- Comment (by carter): David pointed me to #5129 and #2273 which touch on related semantic concerns in the context of seq. I'm not sure if those same problems apply there though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 07:20:52 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 07:20:52 -0000 Subject: [GHC] #9740: D380 caused fft2 regressions In-Reply-To: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> References: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> Message-ID: <060.8f80c8dfe7261feee9f8a8dd56fd8df5@haskell.org> #9740: D380 caused fft2 regressions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D390 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"5f69c8efd94862261bc6730f8dd80c2b67b430ad/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5f69c8efd94862261bc6730f8dd80c2b67b430ad" Reorder GHC.List; fix performance regressions Rearrange some oddly placed code. Modify `take` to make the fold unconditionally strict in the passed `Int`. This clears up the `fft2` regression. This fixes #9740. Differential Revision: https://phabricator.haskell.org/D390 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 07:51:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 07:51:20 -0000 Subject: [GHC] #9740: D380 caused fft2 regressions In-Reply-To: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> References: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> Message-ID: <060.b9724e296156fb42863de497e1147e73@haskell.org> #9740: D380 caused fft2 regressions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D390 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 08:13:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 08:13:03 -0000 Subject: [GHC] #9740: D380 caused fft2 regressions In-Reply-To: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> References: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> Message-ID: <060.f0a1684433a952036da6bcbf658eeb2d@haskell.org> #9740: D380 caused fft2 regressions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D390 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => new * resolution: fixed => Comment: It fixed the regression in T7257: http://ghcspeed- nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=tests%2Falloc%2FT7257&env=1&revs=50&equid=on but not the one in fft2: http://ghcspeed- nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=nofib%2Fallocs%2Ffft2&env=1&revs=50&equid=on Do your measurements disagree, or were you just expecting this to fix it. Could you have a second look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 09:25:16 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 09:25:16 -0000 Subject: [GHC] #9736: Constant folding rules are wrong for GHCJS In-Reply-To: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> References: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> Message-ID: <059.6bf007377212e67edeec135349771ef6@haskell.org> #9736: Constant folding rules are wrong for GHCJS -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you be more specific? Why are these "optimisations" wrong for GHCJS? Could they be wrong for other architectures? Concretely, what change do you propose? Built-in rules (like those in `PrelRules` have access to `DynFlags`. If necessary you could make the rule conditional on the `GHCJS` flag (whatever that is). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 10:13:39 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 10:13:39 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.a40ff81807fa71f0c8b68ab5a817073f@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard, why do you think this is a bug? Looking at the simplified reproduction test case, we see {{{ -- Restricted kind signature: --test :: forall (ent :: Bool -> En) . (forall i . Kn (ent i) => Fm (Fac (ent i))) -> Co Fm (O ent) test :: forall ent. (forall i . Kn (ent i) => Fm (Fac (ent i))) -> Co Fm (O ent) }}} The program typechecks fine with "restricted kind signature" (agreed?), with GHC 7.8.2 or HEAD. So decomposition of type applications is working fine (i.e. comment:1 is not right; although in previous versions of GHC Reid was correct). The actual problem is that the type signature (the one not in comments) kind-checks like this: {{{ test :: forall k. forall (ent :: k -> En). (forall (i::k). Kn (ent i) => Fm (Fac (ent i))) -> Co Fm (O ent) }}} The pattern-match on `Mb` indeed yields the given equality `ent::k ~ M::Bool`. But we can't ''use'' that unless we know that `k~Bool` and, until Richard implements kind-level equalities, we don't know that. The "restricted kind signature" de-polymorphises" it, which is all you need to make it work. Richard: you should add this to your test suite for kind-level equalities! Is there a wiki page for this? Is it [wiki:DependentHaskell]? I suspect not. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 10:35:46 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 10:35:46 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.50c20c28bb9069ac7a232a5965b13c11@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:6 simonpj]: ... snip ... > The pattern-match on `Mb` indeed yields the given equality `ent::k ~ M::Bool`. But we can't ''use'' that unless we know that `k~Bool` and, until Richard implements kind-level equalities, we don't know that. But isn't this just plain ''kind inference'' as we have it today? > > The "restricted kind signature" de-polymorphises" it, which is all you need to make it work. Right, that's what I figured. But in my ''actual'' code I have {{{ data En = M Bool | Ind Nat -- etc. data Fac :: En -> * where Mo :: Kn (M b) => Fac (M b) Odu :: Kn (Ind n) => Fac (Ind n) -- etc. }}} And the pattern match in `h` goes over these, so I *need* the poly- kindedness. It would let me consolidate a bunch of otherwise identical functions (modulo constructor names). > > Richard: you should add this to your test suite for kind-level equalities! Is there a wiki page for this? Is it [wiki:DependentHaskell]? I suspect not. > > Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 11:11:20 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 11:11:20 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.1b1e74bb9a8c32de6c4359d1fd64605d@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): No it's not just kind inference. Do you want that poly-kinded type for `test`? Sounds as if the answer is "yes". Well, then `k` is a skolem variable, and if it is is locally known to be equal to `Bool`, that's a local kind equality (a la GADTs). From what you say, in some branches of `h`, you have a local equality `k ~ Bool` and in others you have `k ~ Nat`. This is just what Richard is working on! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 11:54:58 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 11:54:58 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.4d1cb7bbf0c33a6da521fa05aa321b72@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:8 simonpj]: > No it's not just kind inference. Do you want that poly-kinded type for `test`? Sounds as if the answer is "yes". Well, then `k` is a skolem variable, and if it is is locally known to be equal to `Bool`, that's a local kind equality (a la GADTs). > While I suspected that this could be the answer, I am still happy I asked! Thanks for explaining. > From what you say, in some branches of `h`, you have a local equality `k ~ Bool` and in others you have `k ~ Nat`. Exactly. `k` will be instantiated to different kinds in the pattern matching process. > > This is just what Richard is working on! Good to hear. Is there an ETA for this work? Is there a chance to have a stripped-down version of that feature as a preview, that handles just such plain equations, without the full bells&whistles goodness? Would a plain mortal like me be in a position to make the former happen? > > Simon Thanks again, Gabor -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 12:24:10 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 12:24:10 -0000 Subject: [GHC] #9740: D380 caused fft2 regressions In-Reply-To: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> References: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> Message-ID: <060.8af62919a1002f6c28bf816354b0f92a@haskell.org> #9740: D380 caused fft2 regressions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D390 | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:5 nomeata]: > It fixed the regression in T7257: > http://ghcspeed- nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=tests%2Falloc%2FT7257&env=1&revs=50&equid=on > but not the one in fft2: > http://ghcspeed- nomeata.rhcloud.com/timeline/?exe=2&base=2%2B68&ben=nofib%2Fallocs%2Ffft2&env=1&revs=50&equid=on > > Do your measurements disagree, or were you just expecting this to fix it. Could you have a second look? That's most peculiar. I had not measured T7257, but I ''definitely'' saw an improvement in fft2, unless I read something all wrong. I'm running nofib now and will review the numbers again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 12:41:02 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 12:41:02 -0000 Subject: [GHC] #9736: Constant folding rules are wrong for GHCJS In-Reply-To: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> References: <044.c4363bb1f8d5a0787e880ae23c6d91e8@haskell.org> Message-ID: <059.2dfdc8fc9bef4934c41e1d6665054c30@haskell.org> #9736: Constant folding rules are wrong for GHCJS -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 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: | -------------------------------------+------------------------------------- Comment (by luite): Ah my intention was just to verify that the changes in GHCJS, which are based on 7.8, are still correct in the latest HEAD and then attach the patch here. One issue likely affects other cross compilers: `shiftRightLogical` truncates the value to `Word`size, which is wrong if the host word size is different from the target. https://github.com/ghc/ghc/blob/f1090855d9b8d33b3194364dcca0683d89049f03/compiler/prelude/PrelRules.lhs#L373 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 13:21:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 13:21:56 -0000 Subject: [GHC] #9740: D380 caused fft2 regressions In-Reply-To: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> References: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> Message-ID: <060.3d928cc7c4cc9d2896f3297638c52b45@haskell.org> #9740: D380 caused fft2 regressions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D390 | -------------------------------------+------------------------------------- Comment (by dfeuer): I think I found the problem. I accidentally had an unrestricted `INLINE` on `take`. I'm trying again now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 13:54:31 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 13:54:31 -0000 Subject: [GHC] #9741: Interpreter stack checks are not quite right Message-ID: <046.3063371461063dd3b4b1c60903b205f1@haskell.org> #9741: Interpreter stack checks are not quite right -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- In my experimental branch, I'm getting this failure on `tests/ghci/should_run/ghcirun002`: {{{ : internal error: ASSERTION FAILED: file rts/Interpreter.c, line 778 (GHC version 7.9.20141029 for x86_64_unknown_linux) }}} The ASSERTION failure means that I must have `-DDEBUG` in my RTS; I have no idea why. My `validate.mk` looks like this: {{{ GhcStage1HcOpts += -ticky -DDEBUG GhcStage2HcOpts += -ticky GhcLibHcOpts += -Wwarn -ticky SplitObjs = YES }}} That is mysterious but not the main point. Somehow we are getting a stack overflow in the interpreter. So I added this line to `Interpreter` on line 772: {{{ debugBelch ( "Interpreter Sp=%p SpLim=%p headroom = %ld\n\n", Sp, SpLim, Sp-SpLim ) ; }}} Sure enough, when running test `ghcirun002` on HEAD, I get this output {{{ Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0238 SpLim=0x7f42649d00c0 headroom = 47 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0228 SpLim=0x7f42649d00c0 headroom = 45 Interpreter Sp=0x7f42649d0210 SpLim=0x7f42649d00c0 headroom = 42 Interpreter Sp=0x7f4264b40230 SpLim=0x7f4264b400c0 headroom = 46 Interpreter Sp=0x7f42649e1230 SpLim=0x7f42649e10c0 headroom = 46 Interpreter Sp=0x7f42649d9230 SpLim=0x7f42649d90c0 headroom = 46 Interpreter Sp=0x7f4264182230 SpLim=0x7f42641820c0 headroom = 46 Interpreter Sp=0x7f426417a230 SpLim=0x7f426417a0c0 headroom = 46 Interpreter Sp=0x7f4264172230 SpLim=0x7f42641720c0 headroom = 46 Interpreter Sp=0x7f426416a230 SpLim=0x7f426416a0c0 headroom = 46 Interpreter Sp=0x7f4264162230 SpLim=0x7f42641620c0 headroom = 46 Interpreter Sp=0x7f426415a230 SpLim=0x7f426415a0c0 headroom = 46 Interpreter Sp=0x7f4264152230 SpLim=0x7f42641520c0 headroom = 46 Interpreter Sp=0x7f426414a230 SpLim=0x7f426414a0c0 headroom = 46 Interpreter Sp=0x7f4264142230 SpLim=0x7f42641420c0 headroom = 46 Interpreter Sp=0x7f426413a230 SpLim=0x7f426413a0c0 headroom = 46 Interpreter Sp=0x7f4264132230 SpLim=0x7f42641320c0 headroom = 46 Interpreter Sp=0x7f42649d0238 SpLim=0x7f42649d00c0 headroom = 47 Interpreter Sp=0x7f4264a1e238 SpLim=0x7f4264a1e0c0 headroom = 47 Interpreter Sp=0x7f4264a16238 SpLim=0x7f4264a160c0 headroom = 47 Interpreter Sp=0x7f4264a0e238 SpLim=0x7f4264a0e0c0 headroom = 47 Interpreter Sp=0x7f4264a06238 SpLim=0x7f4264a060c0 headroom = 47 Interpreter Sp=0x7f4257ff8238 SpLim=0x7f4257ff80c0 headroom = 47 Interpreter Sp=0x7f4257ff0238 SpLim=0x7f4257ff00c0 headroom = 47 Interpreter Sp=0x7f4257fe8238 SpLim=0x7f4257fe80c0 headroom = 47 Interpreter Sp=0x7f4257fe0238 SpLim=0x7f4257fe00c0 headroom = 47 Interpreter Sp=0x7f4257fd8238 SpLim=0x7f4257fd80c0 headroom = 47 Interpreter Sp=0x7f4257fd0238 SpLim=0x7f4257fd00c0 headroom = 47 Interpreter Sp=0x7f4257fc8238 SpLim=0x7f4257fc80c0 headroom = 47 Interpreter Sp=0x7f4257fc0238 SpLim=0x7f4257fc00c0 headroom = 47 Interpreter Sp=0x7f4257fb8238 SpLim=0x7f4257fb80c0 headroom = 47 Interpreter Sp=0x7f4257fb0238 SpLim=0x7f4257fb00c0 headroom = 47 Interpreter Sp=0x7f42641f8238 SpLim=0x7f42641f80c0 headroom = 47 Interpreter Sp=0x7f42641f0238 SpLim=0x7f42641f00c0 headroom = 47 Interpreter Sp=0x7f42644f8238 SpLim=0x7f42644f80c0 headroom = 47 Interpreter Sp=0x7f42644ef238 SpLim=0x7f42644ef0c0 headroom = 47 Interpreter Sp=0x7f42644e7238 SpLim=0x7f42644e70c0 headroom = 47 Interpreter Sp=0x7f42644de238 SpLim=0x7f42644de0c0 headroom = 47 Interpreter Sp=0x7f42644d6238 SpLim=0x7f42644d60c0 headroom = 47 Interpreter Sp=0x7f42644ce238 SpLim=0x7f42644ce0c0 headroom = 47 Interpreter Sp=0x7f42644c5238 SpLim=0x7f42644c50c0 headroom = 47 Interpreter Sp=0x7f42644bd238 SpLim=0x7f42644bd0c0 headroom = 47 Interpreter Sp=0x7f42644b4238 SpLim=0x7f42644b40c0 headroom = 47 Interpreter Sp=0x7f42644ac238 SpLim=0x7f42644ac0c0 headroom = 47 Interpreter Sp=0x7f42644a4238 SpLim=0x7f42644a40c0 headroom = 47 Interpreter Sp=0x7f426449b238 SpLim=0x7f426449b0c0 headroom = 47 Interpreter Sp=0x7f4264493238 SpLim=0x7f42644930c0 headroom = 47 Interpreter Sp=0x7f426448a238 SpLim=0x7f426448a0c0 headroom = 47 Interpreter Sp=0x7f4264482238 SpLim=0x7f42644820c0 headroom = 47 Interpreter Sp=0x7f426447a238 SpLim=0x7f426447a0c0 headroom = 47 Interpreter Sp=0x7f426454e238 SpLim=0x7f426454e0c0 headroom = 47 Interpreter Sp=0x7f42641e8238 SpLim=0x7f42641e80c0 headroom = 47 Interpreter Sp=0x7f426417c238 SpLim=0x7f426417c0c0 headroom = 47 Interpreter Sp=0x7f4264174238 SpLim=0x7f42641740c0 headroom = 47 Interpreter Sp=0x7f426416c238 SpLim=0x7f426416c0c0 headroom = 47 Interpreter Sp=0x7f4264164238 SpLim=0x7f42641640c0 headroom = 47 Interpreter Sp=0x7f426415c238 SpLim=0x7f426415c0c0 headroom = 47 Interpreter Sp=0x7f4264154238 SpLim=0x7f42641540c0 headroom = 47 Interpreter Sp=0x7f426414c238 SpLim=0x7f426414c0c0 headroom = 47 Interpreter Sp=0x7f42643e0238 SpLim=0x7f42643e00c0 headroom = 47 Interpreter Sp=0x7f42643d8238 SpLim=0x7f42643d80c0 headroom = 47 Interpreter Sp=0x7f42643d0238 SpLim=0x7f42643d00c0 headroom = 47 Interpreter Sp=0x7f42643c8238 SpLim=0x7f42643c80c0 headroom = 47 Interpreter Sp=0x7f42643c0238 SpLim=0x7f42643c00c0 headroom = 47 Interpreter Sp=0x7f42643b8238 SpLim=0x7f42643b80c0 headroom = 47 Interpreter Sp=0x7f42643e0238 SpLim=0x7f42643e00c0 headroom = 47 Interpreter Sp=0x7f4264154138 SpLim=0x7f42641540c0 headroom = 15 Interpreter Sp=0x7f42641541d0 SpLim=0x7f42641540c0 headroom = 34 Interpreter Sp=0x7f426415c230 SpLim=0x7f426415c0c0 headroom = 46 Interpreter Sp=0x7f4264164130 SpLim=0x7f42641640c0 headroom = 14 Interpreter Sp=0x7f42641641c8 SpLim=0x7f42641640c0 headroom = 33 Interpreter Sp=0x7f426447a0e0 SpLim=0x7f426447a0c0 headroom = 4 Interpreter Sp=0x7f426447a178 SpLim=0x7f426447a0c0 headroom = 23 Interpreter Sp=0x7f426447a210 SpLim=0x7f426447a0c0 headroom = 42 Interpreter Sp=0x7f4264482138 SpLim=0x7f42644820c0 headroom = 15 Interpreter Sp=0x7f42644821d0 SpLim=0x7f42644820c0 headroom = 34 Interpreter Sp=0x7f426448a228 SpLim=0x7f426448a0c0 headroom = 45 Interpreter Sp=0x7f4264493238 SpLim=0x7f42644930c0 headroom = 47 Interpreter Sp=0x7f426449b130 SpLim=0x7f426449b0c0 headroom = 14 Interpreter Sp=0x7f426449b1c8 SpLim=0x7f426449b0c0 headroom = 33 Interpreter Sp=0x7f42644ac0d0 SpLim=0x7f42644ac0c0 headroom = 2 Interpreter Sp=0x7f42644ac168 SpLim=0x7f42644ac0c0 headroom = 21 Interpreter Sp=0x7f42644ac200 SpLim=0x7f42644ac0c0 headroom = 40 Interpreter Sp=0x7f42644b4230 SpLim=0x7f42644b40c0 headroom = 46 Interpreter Sp=0x7f42644bd108 SpLim=0x7f42644bd0c0 headroom = 9 Interpreter Sp=0x7f42644bd1a0 SpLim=0x7f42644bd0c0 headroom = 28 Interpreter Sp=0x7f42644bd238 SpLim=0x7f42644bd0c0 headroom = 47 Interpreter Sp=0x7f42644ce140 SpLim=0x7f42644ce0c0 headroom = 16 Interpreter Sp=0x7f42644ce1d8 SpLim=0x7f42644ce0c0 headroom = 35 Interpreter Sp=0x7f42644d6218 SpLim=0x7f42644d60c0 headroom = 43 Interpreter Sp=0x7f42644de0e0 SpLim=0x7f42644de0c0 headroom = 4 Interpreter Sp=0x7f42644de178 SpLim=0x7f42644de0c0 headroom = 23 Interpreter Sp=0x7f42644de210 SpLim=0x7f42644de0c0 headroom = 42 Interpreter Sp=0x7f42644e70c0 SpLim=0x7f42644e70c0 headroom = 0 Interpreter Sp=0x7f42644e7158 SpLim=0x7f42644e70c0 headroom = 19 Interpreter Sp=0x7f42644e71f0 SpLim=0x7f42644e70c0 headroom = 38 Interpreter Sp=0x7f42644ef230 SpLim=0x7f42644ef0c0 headroom = 46 Interpreter Sp=0x7f42644f8190 SpLim=0x7f42644f80c0 headroom = 26 Interpreter Sp=0x7f42644f8228 SpLim=0x7f42644f80c0 headroom = 45 Interpreter Sp=0x7f42641f00d8 SpLim=0x7f42641f00c0 headroom = 3 Interpreter Sp=0x7f42641f0170 SpLim=0x7f42641f00c0 headroom = 22 Interpreter Sp=0x7f42641f0208 SpLim=0x7f42641f00c0 headroom = 41 Interpreter Sp=0x7f4257fb8210 SpLim=0x7f4257fb80c0 headroom = 42 Interpreter Sp=0x7f4257fb80f0 SpLim=0x7f4257fb80c0 headroom = 6 Interpreter Sp=0x7f4257fb8188 SpLim=0x7f4257fb80c0 headroom = 25 Interpreter Sp=0x7f4257fb8220 SpLim=0x7f4257fb80c0 headroom = 44 Interpreter Sp=0x7f4257fc00d0 SpLim=0x7f4257fc00c0 headroom = 2 Interpreter Sp=0x7f4257fc0168 SpLim=0x7f4257fc00c0 headroom = 21 Interpreter Sp=0x7f4257fc0200 SpLim=0x7f4257fc00c0 headroom = 40 Interpreter Sp=0x7f4257fc80b0 SpLim=0x7f4257fc80c0 headroom = -2 <---- NB Interpreter Sp=0x7f4257fc8148 SpLim=0x7f4257fc80c0 headroom = 17 Interpreter Sp=0x7f4257fc81e0 SpLim=0x7f4257fc80c0 headroom = 36 Interpreter Sp=0x7f4257fd0228 SpLim=0x7f4257fd00c0 headroom = 45 Interpreter Sp=0x7f4257fe0228 SpLim=0x7f4257fe00c0 headroom = 45 Interpreter Sp=0x7f4257fe8140 SpLim=0x7f4257fe80c0 headroom = 16 Interpreter Sp=0x7f4257fe81d8 SpLim=0x7f4257fe80c0 headroom = 35 Interpreter Sp=0x7f4257ff0120 SpLim=0x7f4257ff00c0 headroom = 12 Interpreter Sp=0x7f4257ff01b8 SpLim=0x7f4257ff00c0 headroom = 31 Interpreter Sp=0x7f4257ff8100 SpLim=0x7f4257ff80c0 headroom = 8 Interpreter Sp=0x7f4257ff8198 SpLim=0x7f4257ff80c0 headroom = 27 Interpreter Sp=0x7f4257ff8230 SpLim=0x7f4257ff80c0 headroom = 46 Interpreter Sp=0x7f4264a060e0 SpLim=0x7f4264a060c0 headroom = 4 Interpreter Sp=0x7f4264a06178 SpLim=0x7f4264a060c0 headroom = 23 Interpreter Sp=0x7f4264a06210 SpLim=0x7f4264a060c0 headroom = 42 Interpreter Sp=0x7f4264a0e0c0 SpLim=0x7f4264a0e0c0 headroom = 0 Interpreter Sp=0x7f4264a0e158 SpLim=0x7f4264a0e0c0 headroom = 19 Interpreter Sp=0x7f4264a0e1f0 SpLim=0x7f4264a0e0c0 headroom = 38 Interpreter Sp=0x7f4264a16138 SpLim=0x7f4264a160c0 headroom = 15 Interpreter Sp=0x7f4264a161d0 SpLim=0x7f4264a160c0 headroom = 34 Interpreter Sp=0x7f4264a1e118 SpLim=0x7f4264a1e0c0 headroom = 11 }}} So yes, we get into a situation in which we have negative headroom. Presumably if the ASSERT is off, we simply don't notice. But it's clearly wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 13:55:08 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 13:55:08 -0000 Subject: [GHC] #9741: Interpreter stack checks are not quite right In-Reply-To: <046.3063371461063dd3b4b1c60903b205f1@haskell.org> References: <046.3063371461063dd3b4b1c60903b205f1@haskell.org> Message-ID: <061.9d75891c6d90663e2f62b57e697ff2dd@haskell.org> #9741: Interpreter stack checks are not quite right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 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 simonpj): * owner: => simonmar * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 13:55:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 13:55:48 -0000 Subject: [GHC] #9741: Interpreter stack checks are not quite right In-Reply-To: <046.3063371461063dd3b4b1c60903b205f1@haskell.org> References: <046.3063371461063dd3b4b1c60903b205f1@haskell.org> Message-ID: <061.fb93f3d3b846db35a48376fd92f57802@haskell.org> #9741: Interpreter stack checks are not quite right -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 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 simonpj): * priority: normal => highest Comment: I'll mark this as high priority because it looks like a potential seg- fault. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 14:04:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 14:04:51 -0000 Subject: [GHC] #9740: D380 caused fft2 regressions In-Reply-To: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> References: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> Message-ID: <060.22519943f5639c37d72f97605921007c@haskell.org> #9740: D380 caused fft2 regressions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D394 | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: Phab:D390 => Phab:D394 Comment: It looks like I've actually squashed this one now and recovered nomeata's full fft2 improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 14:48:07 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 14:48:07 -0000 Subject: [GHC] #9740: D380 caused fft2 regressions In-Reply-To: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> References: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> Message-ID: <060.aec180288226150fdb857a620b58e464@haskell.org> #9740: D380 caused fft2 regressions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D394 | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"64d0a198be05c7baff36e43ab96928a402f00a19/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="64d0a198be05c7baff36e43ab96928a402f00a19" Really fix fft2 regression. #9740 Rewrite `take` more aggressively for fusion. Add some more explicit strictness to `unsafeTake` and `unsafeDrop` that seems to help code size and allocation just a drop in some nofib tests. They were not previously strict in their numerical arguments, but always called in contexts where those had been forced; it didn't make a difference in simple test cases, but made a small difference for nofib. See #9740. Differential Revision: https://phabricator.haskell.org/D394 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 15:00:21 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 15:00:21 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.0693394df6429f00d8b02a9682ba2dbb@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Look at `WwLib.mkWorkerArgs` which deals with much the same issue. We just add a void argument to the wrapper avoid the top-level unboxed binding. I think we can do the same thing for pattern synonyms, no? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 15:03:34 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 15:03:34 -0000 Subject: [GHC] #9719: Improve `mkInteger` interface In-Reply-To: <042.84328c1dba8cb713d97fde4fbf0592a8@haskell.org> References: <042.84328c1dba8cb713d97fde4fbf0592a8@haskell.org> Message-ID: <057.3814595da3b36058d8a1b6b45535284c@haskell.org> #9719: Improve `mkInteger` interface -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Integer 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 nominolo): * cc: nominolo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 15:16:03 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 15:16:03 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.a4c9414d3ecd23ffb7aeae85bd263f9f@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): This is interesting: the definition of `Class1` is actually ''illegal'' in Haskell 98, because `class3` constrains the type variable `a`. This sort of thing is only supposed to be allowed with `-XConstrainedClassMethods`. In fact, if you enable that flag, suddenly the compiler realizes there's a loop! So it looks likely that someone made the flag enable the extra loop checking required by such methods, but accidentally failed to make it control whether such things are allowed at all! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 15:20:56 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 15:20:56 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.988e926c319e603ea434feb2f5da85d0@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: duncan Type: bug | Status: patch Priority: normal | Milestone: ? Component: Core | Version: 6.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D395 | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * status: new => patch * differential: => Phab:D395 Comment: Library proposal accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 15:33:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 15:33:45 -0000 Subject: [GHC] #9740: D380 caused fft2 regressions In-Reply-To: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> References: <045.4a41385eb1fc2cfd77230caa8df7cf98@haskell.org> Message-ID: <060.e084c00a96109210cdb73f0904a4e2f6@haskell.org> #9740: D380 caused fft2 regressions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D394 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Fix confirmed. The regression had also affected mandel, where performance is recovered as well. Thanks for taking the time to hunt down the issue! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 16:16:54 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 16:16:54 -0000 Subject: [GHC] #9668: Unicode info is out of date In-Reply-To: <045.4162c8318981414b1b75ed9710354b32@haskell.org> References: <045.4162c8318981414b1b75ed9710354b32@haskell.org> Message-ID: <060.570ca5cd6933b834de09878e7cb17bfc@haskell.org> #9668: Unicode info is out of date -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: merge Priority: normal | Milestone: 7.8.4 Component: Core | Version: 7.9 Libraries | Keywords: Unicode Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => merge * milestone: 7.10.1 => 7.8.4 Comment: This is completed by https://phabricator.haskell.org/rGHCd4fd16801bc59034abdc6214e60fcce2b21af9c8 but we probably want to merge to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 16:29:44 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 16:29:44 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.dae97b3cfce280728da31cfda2486fb0@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: duncan Type: bug | Status: patch Priority: normal | Milestone: ? Component: Core | Version: 6.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D395 | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:11 thomie]: > Library proposal accepted. Is there a summary of the library submission? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 16:32:48 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 16:32:48 -0000 Subject: [GHC] #9668: Unicode info is out of date In-Reply-To: <045.4162c8318981414b1b75ed9710354b32@haskell.org> References: <045.4162c8318981414b1b75ed9710354b32@haskell.org> Message-ID: <060.446a18da2cd307f9a544247c17d82153@haskell.org> #9668: Unicode info is out of date -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Unicode Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: merge => closed * resolution: => fixed * milestone: 7.8.4 => 7.10.1 Comment: Er, we should probably have some guidelines written down about what is suitable for merging to a maintenance branch, but I ''really'' don't think this qualifies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 16:35:43 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 16:35:43 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.f368d56f25f78abc5776e14801183752@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: duncan Type: bug | Status: patch Priority: normal | Milestone: ? Component: Core | Version: 6.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D395 | -------------------------------------+------------------------------------- Comment (by ekmett): @hvr See the link from thomie above ~5 weeks ago. Makes sense to me. So is the plan then to depcate the tags now and remove them later? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 17:09:01 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 17:09:01 -0000 Subject: [GHC] #9668: Unicode info is out of date In-Reply-To: <045.4162c8318981414b1b75ed9710354b32@haskell.org> References: <045.4162c8318981414b1b75ed9710354b32@haskell.org> Message-ID: <060.ae258adef38eea0c6bc155cfe9420fb6@haskell.org> #9668: Unicode info is out of date -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Unicode Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:7 rwbarton]: > Er, we should probably have some guidelines written down about what is suitable for merging to a maintenance branch, but I ''really'' don't think this qualifies. I'm reminded of the prayer books my synagogue uses for Rosh Hashanah and Yom Kippur?the holiday date charts in the back were reprinted verbatim from an earlier edition, so they include the dates for the holidays many years ago, but ran out just a few years after the second printing. I personally consider such things as Unicode table update to be part of regular maintenance, rather than new features. Note: if we ''do'' decide to merge to 7.8.4, the tables will have to be generated for that, not copied over from 7.9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 17:19:45 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 17:19:45 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.e215cd175e29b2b5f913eab0ee6b4a82@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): But you don't have to decompose the given equality to get the wanted. We have {{{ [G] e1 :: ent k1 ~ M b [G] e2 :: Kn (M b) [W] e3 :: Kn (ent k1) }}} Solve with {{{ e3 := e2 |> Kn (sym e1) }}} The problem is that GHC tries to decompose the given, fails utterly, and then has no way forward. So, I'd say this shows a completeness bug in the solver. It's one we may not want to address, as I agree my kind equality stuff makes this straightforward and I don't see an easy way of solving this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 17:28:51 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 17:28:51 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.65353c3013ad578f6f79f705598a4124@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Sorry to pester about this, but your example still seems not minimal. I don't think we're looking for a real-world minimal example, just a syntactic one. There seems to be a bunch of things in that file which are not related to this ticket. (All the methods in that class? Strictness annotations?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 17:51:32 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 17:51:32 -0000 Subject: [GHC] #9742: The default definitions of foldl1 and foldr1 are too strict Message-ID: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> #9742: The default definitions of foldl1 and foldr1 are too strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- We currently have {{{#!hs foldr1 :: (a -> a -> a) -> t a -> a foldr1 f xs = fromMaybe (error "foldr1: empty structure") (foldr mf Nothing xs) where mf x Nothing = Just x mf x (Just y) = Just (f x y) }}} This has to traverse the entire list before it can do anything. What we want is {{{#!hs mf x r = Just $ case r of Nothing -> x Just y -> f x y }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 17:57:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 17:57:00 -0000 Subject: [GHC] #9668: Unicode info is out of date In-Reply-To: <045.4162c8318981414b1b75ed9710354b32@haskell.org> References: <045.4162c8318981414b1b75ed9710354b32@haskell.org> Message-ID: <060.be2fa8a63ac9fd9f81256bfab2643996@haskell.org> #9668: Unicode info is out of date -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Unicode Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Incorrect | Related Tickets: result at runtime | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by ekmett): As much as I'd like to fix it in 7.8.4 this probably belongs in 7.10. It is hard for users to detect patch levels and switch behaviors. This is a fairly weak argument, but it's really enough that there **exists** an argument to give pause about changing something in a patch-level release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 17:59:19 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 17:59:19 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.2a6c8af254b521507ef359dc0883470e@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: duncan Type: bug | Status: patch Priority: normal | Milestone: ? Component: Core | Version: 6.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D395 | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:13 ekmett]: > @hvr See the link from thomie above ~5 weeks ago. I saw no summary of the voting/discussing there; I meant a summary in the sense of >> At the end of the discussion period, summarise your understanding of the consensus (or lack thereof), including a link to the thread in the mailing list archives, and send the summary to the maintainer for decision. Here's an example of what I mean: http://www.haskell.org/pipermail/libraries/2014-August/023658.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 18:51:12 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 18:51:12 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.5c7b52605446febe4aec7a5e121ca35b@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: duncan Type: bug | Status: patch Priority: normal | Milestone: ? Component: Core | Version: 6.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D395 | -------------------------------------+------------------------------------- Comment (by thomie): From http://www.haskell.org/pipermail/libraries/2014-October/024033.html: > This proposal is now accepted, with support from Duncan, Herbert and > myself. No objections were raised. > > If all goes well, versionTags will be deprecated in GHC 7.10, and removed > in GHC 7.12. I'll try to write a bit nicer summary next time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 21:24:41 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 21:24:41 -0000 Subject: [GHC] #9742: The default definitions of foldl1 and foldr1 are too strict In-Reply-To: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> References: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> Message-ID: <060.93d98e579aff255fd6eaa7890d5c36f8@haskell.org> #9742: The default definitions of foldl1 and foldr1 are too strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > We currently have > > {{{#!hs > foldr1 :: (a -> a -> a) -> t a -> a > foldr1 f xs = fromMaybe (error "foldr1: empty structure") > (foldr mf Nothing xs) > where > mf x Nothing = Just x > mf x (Just y) = Just (f x y) > }}} > > This has to traverse the entire list before it can do anything. What we > want is > > {{{#!hs > mf x r = Just $ case r of > Nothing -> x > Just y -> f x y > }}} New description: We currently have {{{#!hs foldr1 :: (a -> a -> a) -> t a -> a foldr1 f xs = fromMaybe (error "foldr1: empty structure") (foldr mf Nothing xs) where mf x Nothing = Just x mf x (Just y) = Just (f x y) }}} This has to traverse the entire container before it can do anything. What we want is {{{#!hs mf x r = Just $ case r of Nothing -> x Just y -> f x y }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 21:52:00 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 21:52:00 -0000 Subject: [GHC] #9742: The default definitions of foldl1 and foldr1 are too strict In-Reply-To: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> References: <045.e30bcb7464368b482b2ba698124b59bb@haskell.org> Message-ID: <060.f52026a1dc8a9622080633f3b32d6e99@haskell.org> #9742: The default definitions of foldl1 and foldr1 are too strict -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.9 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I should say "may have to", actually. The current `foldr1` should be okay on snoc lists, say. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 29 23:37:30 2014 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Oct 2014 23:37:30 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.50565bba27a81770184520455783cb53@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah I see. You are right. But this is pretty coincidental. If the wanted was `[W] ent ~ M` we'd be out of luck. And taking account of the coincidence is far from straightforward; it would be a significant complication in the solver, which will be redundant when your stuff lands. So I propose to wait. Sorry Gabor, but Richard's stuff is itself a major increment, and I just don't know what a simple cut-down version might look like. ETA is up to Richard. Meanwhile, `usafeCoerce` may be needed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 00:51:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 00:51:04 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.ef2d19553e1dbf98255c3b7169f2427b@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): ETA on my work is "not 7.10". There are three primary things that my work (for now) addresses: 1) kind equalities in terms, 2) promoted GADTs, and 3) promoted type families. Item (1) feels quite close to start the discussion about merging, maybe a few more weeks. (2) and (3) are in the 2-3 month timeframe, I think. However, I think it's reasonable to consider merging (1) even if (2) and (3) are unfinished. (1) by itself will solve this problem, and the `dynApply` problem highlighted in wiki:Typeable. In any case, my campaign toward merging won't start in earnest until I have something to show that I'm proud of, and that time isn't quite yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 00:52:02 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 00:52:02 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.4a39607cefd0a7c926e91fd9f59b662e@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): Oh -- and I agree with Simon that the fact that this is soluble is a lucky coincidence and not worth fixing right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 02:25:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 02:25:15 -0000 Subject: [GHC] #9706: New block-structured heap organization for 64-bit In-Reply-To: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> References: <045.a63dcd9ee3561b6e809272c4a2e2bc36@haskell.org> Message-ID: <060.f79c34258a1c66a2a6bc4ab9fa9fbdeb@haskell.org> #9706: New block-structured heap organization for 64-bit -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by refold): Replying to [comment:13 simonmar]: > Open questions: > > * Does VirtualAlloc on Windows behave the same way? That is, can we allocate as much address space as we want, without creating page tables and without getting an out of memory error? According to chapter 7 of Russinovich's book (4th ed., which covers XP, 2000 and Server 2003), page tables are allocated lazily. I did some tests on Windows 7 ([https://gist.github.com/23Skidoo/ae5cedb5e4717e96de3d here's my test program]): reserving a terabyte of memory doesn't take any noticeable time; however, the system refuses to reserve more than 1423 GB. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 04:15:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 04:15:30 -0000 Subject: [GHC] #9734: Provide macro __GLASGOW_HASKELL_TH__ In-Reply-To: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> References: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> Message-ID: <061.4f885e381f05c68a3c2cc956bc23bda9@haskell.org> #9734: Provide macro __GLASGOW_HASKELL_TH__ -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D386 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"c211f8e55b8dd1d43854ce3c4554ffbafb0009f9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c211f8e55b8dd1d43854ce3c4554ffbafb0009f9" Add __GLASGOW_HASKELL_TH__=YES/NO to CPP definitions Test Plan: None really. Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D386 GHC Trac Issues: #9734 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 04:15:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 04:15:29 -0000 Subject: [GHC] #9236: hGetContents leads to late/silent failures In-Reply-To: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> References: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> Message-ID: <060.75ac75107381ad3222cdf5e4fd39500f@haskell.org> #9236: hGetContents leads to late/silent failures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #8213 Test Case: | Blocking: | Differential Revisions: Phab:D327 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"257cbec2f605c31d335a6709b43754a88f184d9d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="257cbec2f605c31d335a6709b43754a88f184d9d" Fix #9236 Error on read from closed handle Summary: Fixes #9236. My testing indicates that this does *not* lead to problems with broken pipes and such, but further testing is required. It found a bug in haddock; I've submitted a pull request upstream. Reviewers: ekmett, austin Reviewed By: ekmett, austin Subscribers: rwbarton, thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D327 GHC Trac Issues: #9236 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 04:15:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 04:15:29 -0000 Subject: [GHC] #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 In-Reply-To: <045.27c764f1bc949f892e614a3885cf6189@haskell.org> References: <045.27c764f1bc949f892e614a3885cf6189@haskell.org> Message-ID: <060.a4c7741888271a1caa86752256f9e814@haskell.org> #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D372 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"5ce1266a7d323fd4fe4262f07be908d65e5b5b43/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5ce1266a7d323fd4fe4262f07be908d65e5b5b43" Use snwprintf instead of swprintf in rts/Linker.c. Summary: swprintf has different signatures in mingw32, where it does not include the buffer size, and in mingw-w64, where it does. That of course breaks the code as mingw-w64 treats the pointer to the format string as a size_t. snwprintf is available in both environments and is consistent, so use that instead. Reviewers: simonmar, austin Reviewed By: austin Subscribers: #ghc_windows_task_force, thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D372 GHC Trac Issues: #9726 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 04:15:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 04:15:30 -0000 Subject: [GHC] #9367: GHCI :list uses malformed line endings () on Windows In-Reply-To: <044.22597e1155087b2ec7457131835e824e@haskell.org> References: <044.22597e1155087b2ec7457131835e824e@haskell.org> Message-ID: <059.f2daefdd13c8bbef2c2f388ed1262c81@haskell.org> #9367: GHCI :list uses malformed line endings () on Windows ---------------------------------------+---------------------------------- Reporter: kraai | Owner: gintas Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D382 | ---------------------------------------+---------------------------------- Comment (by Austin Seipp ): In [changeset:"45175e13edad452843207491d01cdbce0bedbbd4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="45175e13edad452843207491d01cdbce0bedbbd4" Extra CRs are now filtered out from the source file for :list. Fixes #9367. Reviewers: austin Reviewed By: austin Subscribers: #ghc_windows_task_force, thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D382 GHC Trac Issues: #9367 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 04:15:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 04:15:29 -0000 Subject: [GHC] #9727: -Werror=unused-but-set-variable causes validation error on Windows In-Reply-To: <045.46cb8c51f4cb0e085fad55ca8cdfc48e@haskell.org> References: <045.46cb8c51f4cb0e085fad55ca8cdfc48e@haskell.org> Message-ID: <060.b61ecd1da3d1c66598fad9b6a2b98832@haskell.org> #9727: -Werror=unused-but-set-variable causes validation error on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: closed Priority: normal | Milestone: Component: Build | Version: 7.9 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D373 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"acb3295c69179159ba8230baff4104414c1db2c2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="acb3295c69179159ba8230baff4104414c1db2c2" Avoid setting -Werror=unused-but-set-variable on Windows. Summary: The option is not needed (it was only intended to override Debian's default) and causes an error if the host ghc's mingw is too old (which the script does not detect). Fixes T9727 Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D373 GHC Trac Issues: #9727 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 06:19:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 06:19:31 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.6ca236674a0609440f3279a05b32073b@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255, | Phab:D399 | -------------------------------------+------------------------------------- Changes (by mlen): * status: infoneeded => patch * differential: Phab:D255 => Phab:D255, Phab:D399 Comment: Proposed patch @ Phab:D399 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 09:23:28 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 09:23:28 -0000 Subject: [GHC] #9734: Provide macro __GLASGOW_HASKELL_TH__ In-Reply-To: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> References: <046.d6e4ba795f6cf95735b1df462cd4424a@haskell.org> Message-ID: <061.75c3c1499c513a5404b80a5d58d2f02e@haskell.org> #9734: Provide macro __GLASGOW_HASKELL_TH__ -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D386 | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 09:34:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 09:34:04 -0000 Subject: [GHC] #9367: GHCI :list uses malformed line endings () on Windows In-Reply-To: <044.22597e1155087b2ec7457131835e824e@haskell.org> References: <044.22597e1155087b2ec7457131835e824e@haskell.org> Message-ID: <059.150cb37e47432759cf99c666e2e60226@haskell.org> #9367: GHCI :list uses malformed line endings () on Windows ---------------------------------------+---------------------------------- Reporter: kraai | Owner: gintas Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: Phab:D382 | ---------------------------------------+---------------------------------- Changes (by gintas): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 09:40:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 09:40:10 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.531bfd877d52c30e1b6e0f4325173761@haskell.org> #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: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:38 dreixel]: > No, not yet, I'm afraid. Is this still possible for GHC 7.10? Do you need help with something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 10:11:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 10:11:13 -0000 Subject: [GHC] #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 In-Reply-To: <045.27c764f1bc949f892e614a3885cf6189@haskell.org> References: <045.27c764f1bc949f892e614a3885cf6189@haskell.org> Message-ID: <060.59f0154fd569b3dbf3bf0e5204adc672@haskell.org> #9726: Linker.c uses of swprintf() fail to compile on gcc 4.8.3 -------------------------------------+------------------------------------- Reporter: gintas | Owner: gintas Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime | Version: 7.9 System | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: Windows | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D372 | -------------------------------------+------------------------------------- Changes (by gintas): * status: new => closed * resolution: => fixed Comment: Thanks. I slightly prefer using swnprintf() to the #define since it's safer and generally seems cleaner... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 10:11:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 10:11:29 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.4fcdf86f188a850394a827456ba3307d@haskell.org> #7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 10:12:14 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 10:12:14 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.dfb9a6cffc904489c0a8bb1784dd9657@haskell.org> #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: | -------------------------------------+------------------------------------- Comment (by dreixel): Oh, I definitely want it in for 7.10. But I thought we were doing a 7.8.4, so 7.10 got pushed back? What's the deadline for feature merge? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 10:51:29 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 10:51:29 -0000 Subject: [GHC] #5462: Deriving clause for arbitrary classes In-Reply-To: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> References: <046.24a58a6ed3a2a300970707da88d918ff@haskell.org> Message-ID: <061.4c84150efda10b462f2f5d06eb5cc728@haskell.org> #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: | -------------------------------------+------------------------------------- Comment (by simonpj): https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 11:24:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 11:24:13 -0000 Subject: [GHC] #9681: Printing of "\n" in error messages is broken In-Reply-To: <045.abc102fa93d2a130d37cc7ab11f8ef8d@haskell.org> References: <045.abc102fa93d2a130d37cc7ab11f8ef8d@haskell.org> Message-ID: <060.d990694582130041010438a4941c102d@haskell.org> #9681: Printing of "\n" in error messages is broken -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: 1+"\n" | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by mlen): According to #4436, the formatting is intended behavior for multiline strings. Maybe that behavior should be only enabled with TH or only non-blank lines. I started to work on the case when single newline character is truncated in the output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 11:52:00 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 11:52:00 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.5e9ba4afb42c1f65503b9b4940a5beda@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): Hmm. `mkWorkerArgs` looks like quite the rabbit hole... does it make sense to figure out the plumbing for that, or is it good enough to just steal the basic idea and implement something similar for pattern synonyms that ensures there's always at least one argument (a synthetic `()` if need be) to pattern synonym wrapper functions returning unboxed values? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 11:59:54 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 11:59:54 -0000 Subject: [GHC] #7170: Foreign.Concurrent finalizer called twice in some cases In-Reply-To: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> References: <048.7b99ed8be2aa8efa30d578d90781f5ff@haskell.org> Message-ID: <063.d9f3bc71ad217b2d6c40f2c1ca221ad7@haskell.org> #7170: Foreign.Concurrent finalizer called twice in some cases -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: ekmett Type: bug | Status: new Priority: high | Milestone: 7.6.1 Component: Core | Version: 7.8.3 Libraries | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: crash | Test Case: | ffi/should_run/7170 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: core-libraries-committee@? (added) * owner: => ekmett * component: libraries/base => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 12:01:30 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 12:01:30 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.dbb35c41730c1c2e3e2ac4ca9136b3cc@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): As for the unidirectional case, I was accidentally looking at the simplified output instead of just the desugared one. So with this code: {{{ {-# LANGUAGE PatternSynonyms, MagicHash #-} pattern PAT <- 0# f PAT = 42# }}} the Core generated for `f` is: {{{ Main.f :: GHC.Prim.Int# -> GHC.Prim.Int# [LclIdX, Str=DmdType] Main.f = \ (ds_dpR :: GHC.Prim.Int#) -> break<2>() case (\ _ [Occ=Dead, OS=OneShot] -> Control.Exception.Base.patError @ GHC.Prim.Int# "T9732.hs:7:1-11|function f"#) GHC.Prim.void# of wild_00 { __DEFAULT -> (case break<1>() 42 of wild_X4 { __DEFAULT -> Main.$mPAT @ GHC.Prim.Int# ds_dpR wild_X4 }) wild_00 } }}} which is close enough: it would be correct if only `wild_00` wasn't floated out... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 12:18:45 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 12:18:45 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.294c0df9f87663fcdfd818df8c6e478d@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: ghcirun004 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm seeing this too, on Linux. Also on test T2589. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 12:30:03 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 12:30:03 -0000 Subject: [GHC] #7191: hsc2hs can't treat absolute path correctly on Windows. In-Reply-To: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> References: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> Message-ID: <062.6f658b958db4d54e1b252bd3f048fe88@haskell.org> #7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by thomie): The problem might be that no new version of hsc2hs has been released in over 2 years [1]. The filepath fix from above has come after the last release. [1] http://hackage.haskell.org/package/hsc2hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 12:41:10 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 12:41:10 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.36af485fce6ffb87042986d088c9e0ed@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:11 simonpj]: > Ah I see. You are right. But this is pretty coincidental. If the wanted was `[W] ent ~ M` we'd be out of luck. And taking account of the coincidence is far from straightforward; it would be a significant complication in the solver, which will be redundant when your stuff lands. > > So I propose to wait. Sorry Gabor, but Richard's stuff is itself a major increment, and I just don't know what a simple cut-down version might look like. ETA is up to Richard. Meanwhile, `unsafeCoerce` may be needed. I am ''trying'' to go the `unsafeCoerce` route. But I have not succeeded to write it yet. I keep getting kind mismatch errors in line 27. So I replaced the call to `d` there with a hole `_`. Then I get this diagnostic: {{{ 9725.hs:27:30: Found hole _ with type: Fac (ent k1) -> Fm (Fac (ent b0)) Where: ent is a rigid type variable bound by the type signature for test :: (forall (i :: k). Kn (ent i) => Fm (Fac (ent i))) -> Co Fm (O ent) at /home/ggreif/ReleaseFeatureMatrix/bachelor/9725.hs:24:16 k1 is a rigid type variable bound by a pattern with constructor Hi :: forall (k :: BOX) (ent :: k -> En) (k :: k). Fac (ent k) -> O ent, in an equation for h at /home/ggreif/ReleaseFeatureMatrix/bachelor/9725.hs:27:14 b0 is an ambiguous type variable Relevant bindings include m :: Fac (ent k1) (bound at /home/ggreif/ReleaseFeatureMatrix/bachelor/9725.hs:27:17) h :: O ent -> Fm (O ent) (bound at /home/ggreif/ReleaseFeatureMatrix/bachelor/9725.hs:27:11) d :: forall (i :: k). Kn (ent i) => Fac (ent i) -> Fm (Fac (ent i)) (bound at /home/ggreif/ReleaseFeatureMatrix/bachelor/9725.hs:29:11) de :: forall (i :: k). Kn (ent i) => Fm (Fac (ent i)) (bound at /home/ggreif/ReleaseFeatureMatrix/bachelor/9725.hs:25:6) test :: (forall (i :: k). Kn (ent i) => Fm (Fac (ent i))) -> Co Fm (O ent) (bound at /home/ggreif/ReleaseFeatureMatrix/bachelor/9725.hs:25:1) In the expression: _ In the first argument of HiF , namely (_ m) In the expression: HiF (_ m) Failed, modules loaded: none. }}} Stangely the type reported for `m` is `Fac (ent k1)` (which comes from the context provided by `Hi` and not from the context provided by `Mo`, which would be `Fac (M b)`. This changes to the expected one with the "restricted" signature. I believe this is the place where the "badness" happens. Does this finding change something w.r.t. the analysis? > > Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 13:09:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 13:09:49 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.9539ad413ead32310f221859f465a5fb@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): Never mind, I've figured out that last bit -- it's because in this case, `$mPAT` is used at type `Int# -> Int# -> Int# -> Int#`, so it's always going to be strict in both the `cont` and the `fail` arguments. I'll change the code generator for matchers so that both `cont` and `fail` takes an extra `()` argument. Another problem, then, will be making the matcher polymorphic enough that its `r` type argument can be either `*` or `#`... So all in all, in this example, currently: {{{ $mPAT :: forall (r :: *). Int# -> r -> r -> r }}} but it should be {{{ $mPAT :: forall (r :: ?). Int# -> (() -> r) -> (() -> r) -> r }}} Does that sound reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 13:10:49 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 13:10:49 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.bb18187dfde3136dd460cdae8a1f1f95@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): (and of course if `$mPAT :: forall (r :: ?)` is not kosher, we can just have two matchers, one `$mPAT :: forall (r :: *)` and one `$mPAT# :: (forall r :: #)`, and just have the extra `()` arguments for `cont`/`fail` for the latter) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 13:16:46 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 13:16:46 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.0cf73b143f91d14271ede003b9331828@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): * `cont` and `fail` should take an extra arg if (but only if) they have no other value args, and the result type is unlifted. This is easy to test. * Don't give them an extra arg of `()`. Rather use `voidPrimId`. This is zero bits wide, and hence takes no instructions to pass. Just like `mkWorkerArgs`. * Yes, it's fine to give the `r` variable an `OpenTypeKind`. Similar to the `errorId` definitions in `MkId`. OK? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 14:07:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 14:07:48 -0000 Subject: [GHC] #5918: hsc2hs forces wordsize (i.e. -m32 or -m64) to be the choice of GHC instead of allowing a different (or no/default choice) In-Reply-To: <043.e6ff42227eb96c2343121f97bbc9654d@haskell.org> References: <043.e6ff42227eb96c2343121f97bbc9654d@haskell.org> Message-ID: <058.14ee81647808c979366cbdc334d1d040@haskell.org> #5918: hsc2hs forces wordsize (i.e. -m32 or -m64) to be the choice of GHC instead of allowing a different (or no/default choice) ------------------------------------------+--------------------------- Reporter: Atze | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.10.1 Component: hsc2hs | Version: 7.4.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86 Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #3681 Differential Revisions: | ------------------------------------------+--------------------------- Changes (by thomie): * related: => #3681 Comment: This seems to be the current hack applied to UHC: https://github.com/UU- ComputerScience/uhc/blob/be2d49c431334aa57659d623d4c0962854a6985e/EHC/ehclib/files2.mk#L364 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 14:22:27 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 14:22:27 -0000 Subject: [GHC] #7984: hsc2hs --cross-compile does not handle negative #enum In-Reply-To: <049.61cc524756b01502c75ea520468c0a78@haskell.org> References: <049.61cc524756b01502c75ea520468c0a78@haskell.org> Message-ID: <064.f476a4ec2106ec60ec3e1e7edeb0586b@haskell.org> #7984: hsc2hs --cross-compile does not handle negative #enum -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: hsc2hs | Version: 7.6.3 Resolution: fixed | 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): * status: patch => closed * resolution: => fixed Comment: Fixed in http://git.haskell.org/hsc2hs.git/commit/10696fe17c9d2b4e3498684c6ffbd9f44eda53c4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 14:33:48 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 14:33:48 -0000 Subject: [GHC] #7735: -fext-core doesn't generate .hcr when .o and .hi files are present In-Reply-To: <044.3479fe7fbe9009d5637f47b82085a48e@haskell.org> References: <044.3479fe7fbe9009d5637f47b82085a48e@haskell.org> Message-ID: <059.c514cfbed74533d331f003620a6aab78@haskell.org> #7735: -fext-core doesn't generate .hcr when .o and .hi files are present -------------------------------------+------------------------------------- Reporter: kmels | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: External | Version: 7.6.2 Core | Keywords: Resolution: wontfix | Architecture: x86_64 (amd64) Operating System: Linux | Difficulty: Unknown Type of failure: GHC | Blocked By: doesn't work at all | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: External has been removed in commit 5bf22f06ef71f61094de7564dee770f136d5481a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 14:38:08 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 14:38:08 -0000 Subject: [GHC] #5844: Panic on generating Core code In-Reply-To: <050.618a99421fb5762b3e8312f4eee15b16@haskell.org> References: <050.618a99421fb5762b3e8312f4eee15b16@haskell.org> Message-ID: <065.4d67772f3bbf5d13af3573594fc05c2f@haskell.org> #5844: Panic on generating Core code -------------------------------------+------------------------------------- Reporter: | Owner: JamesFisher | Status: closed Type: bug | Milestone: 7.10.1 Priority: normal | Version: 7.4.1 Component: External | Keywords: Core | Architecture: Unknown/Multiple Resolution: wontfix | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: Compile- | time crash | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => wontfix Comment: External Core has been removed in commit 5bf22f06ef71f61094de7564dee770f136d5481a. Also see this mailinglist discussion: https://www.haskell.org/pipermail/ghc- devs/2014-April/004791.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 15:05:04 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 15:05:04 -0000 Subject: [GHC] #7191: hsc2hs can't treat absolute path correctly on Windows. In-Reply-To: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> References: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> Message-ID: <062.6df5a91beb779a476a9fef77ffa42a60@haskell.org> #7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): What needs to be done to get it released? Also, any idea why I had problems reproducing the bug? Can anyone else reproduce it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 15:20:52 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 15:20:52 -0000 Subject: [GHC] #7191: hsc2hs can't treat absolute path correctly on Windows. In-Reply-To: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> References: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> Message-ID: <062.c1e5a2ec56e823877eab366e146154d9@haskell.org> #7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) Comment: Replying to [comment:10 gintas]: > What needs to be done to get it released? We can try asking @hvr? > Also, any idea why I had problems reproducing the bug? Can anyone else reproduce it? GHC master does include a more recent version of hsc2hs as a submodule, maybe you were using that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 15:27:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 15:27:36 -0000 Subject: [GHC] #7191: hsc2hs can't treat absolute path correctly on Windows. In-Reply-To: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> References: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> Message-ID: <062.2c49b2b16e4e7f518f3db96b6c2e0352@haskell.org> #7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by gintas): No, I am sure I was using hsc2hs from Haskell Platform 2014.2.0.0. I just retested, it works perfectly fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 15:47:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 15:47:38 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.53c13d70c67dd281295bf1b18c001003@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): Yes, I've found `voidPrimId`/`voidArgId` meanwhile, and I have a working implementation pushed to `wip/T9732` just now. However, I had to split the matcher into two, since otherwise I can't decide when to have the extra arg, since the result type is completely unknown at matcher generation time. So for now, I've went with {{{ Main.$mPAT :: forall r. GHC.Prim.Int# -> r -> r -> r Main.$m#PAT :: forall (r :: #). GHC.Prim.Int# -> (GHC.Prim.Void# -> r) -> (GHC.Prim.Void# -> r) -> r }}} so that takes care of using pattern synonyms when the _result_ type is unlifted: both of these now compile lint-free, and give the expected behaviour: {{{ f PAT = 42# g PAT = (42 :: Int) }}} So the only remaining TODO should be to add this extra `Void#` argument to the generated wrappers when there are no other arguments and the pattern type is unlifted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 15:56:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 15:56:15 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.703615879bdef300e408310a341da2c5@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I see. You don't know if the result is unlifted, but you DO know if `cont` has value args. (Which it does not in this case.) I think you can just have the second of your two matchers, with `forall (r :: ?). ...`, something that is not possible in source Haskell, but which you can do in generated code I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 16:00:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 16:00:23 -0000 Subject: [GHC] #9730: Polymorphism and type classes In-Reply-To: <046.310e1397bb5747d9bd08033446e752bc@haskell.org> References: <046.310e1397bb5747d9bd08033446e752bc@haskell.org> Message-ID: <061.4016053fb27f7de44aa5e2ca7b6913f9@haskell.org> #9730: Polymorphism and type classes -------------------------------------+------------------------------------- Reporter: mjaskel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Typeclass, Resolution: | Polymorphism, ImpredicativeTypes Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: rejects valid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sorry but you really need impredicative polymorphism here, and GHC simply does not support it properly at the moment. (The `ImpredicativeTypes` stuff is badly broken.) However in this case there's an easy workaround {{{ a2c x = b2c (a2b x) }}} Now you don't need impredicativity Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 16:01:50 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 16:01:50 -0000 Subject: [GHC] #9681: Printing of "\n" in error messages is broken In-Reply-To: <045.abc102fa93d2a130d37cc7ab11f8ef8d@haskell.org> References: <045.abc102fa93d2a130d37cc7ab11f8ef8d@haskell.org> Message-ID: <060.052f58e24fb8a8187e8906c6138cc02b@haskell.org> #9681: Printing of "\n" in error messages is broken -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: 1+"\n" | Blocking: | Differential Revisions: Phab:D405 | -------------------------------------+------------------------------------- Changes (by mlen): * cc: simonpj (added) * status: new => infoneeded * differential: => Phab:D405 Comment: The patch is available @ Phab:D405 It covers only the case of missing newline, since I didn't know what to do about the formatting issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 16:09:36 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 16:09:36 -0000 Subject: [GHC] #9732: Pattern synonyms and unboxed values In-Reply-To: <047.98d7de74203e4f381291a803ad282f11@haskell.org> References: <047.98d7de74203e4f381291a803ad282f11@haskell.org> Message-ID: <062.cdc7c83458f4bffbcdad5f278e61eb43@haskell.org> #9732: Pattern synonyms and unboxed values -------------------------------------+------------------------------------- Reporter: monoidal | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by cactus): A single open-kinded matcher works, yes, if we are OK with argument-free `cont`s and all `fail`s taking the extra `Void#` argument. I will redo my implementation for this design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 16:30:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 16:30:32 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.3138a56a7df188676ed35828ecbf91f1@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by goldfire): After some struggle, I came up with a working construction, attached. Bonus points if you can make it prettier and/or bind the scoped type variables without adding proxies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 16:33:55 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 16:33:55 -0000 Subject: [GHC] #9687: Missing Typeable instances for built-in types In-Reply-To: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> References: <047.800a58af8ff1c1e3b5c6e120fd7f1ace@haskell.org> Message-ID: <062.81601d69c01e9304de329ffacce38a21@haskell.org> #9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_fail/T9687 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => deriving/should_fail/T9687 Comment: I'll improve the error message for a hand-written `Typeable` instance anyway. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 16:44:23 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 16:44:23 -0000 Subject: [GHC] #9743: Expose ghc-bin code as a library Message-ID: <044.c26a85473d4052c84c57e6fbda861e37@haskell.org> #9743: Expose ghc-bin code as a library -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 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: -------------------------------------+------------------------------------- We have a few projects, most notably `ghci-ng`, `ghc-mod` and `GHCJS` using significant parts of the GHC front end, doing so by copying the code into their own trees. While the code hasn't been written with use as a library in mind, exposing it can significantly reduce the amount of code to be copied by these projects, in particular if they want to support multiple GHC versions. We could either expose `ghc-bin` directly as a package, adding all modules as `exposed-modules`, or add the modules to the `ghc` package. As far as I could see, `ghc-bin` does not have any dependencies that `ghc` does not already have, so I don't have any strong preference for either. We can use the current version as a starting point and adapt it for the projects using it as needed. I'd submit a few small changes to `Main.hs` that'd let GHCJS use much more of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 16:54:16 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 16:54:16 -0000 Subject: [GHC] #9681: Printing of "\n" in error messages is broken In-Reply-To: <045.abc102fa93d2a130d37cc7ab11f8ef8d@haskell.org> References: <045.abc102fa93d2a130d37cc7ab11f8ef8d@haskell.org> Message-ID: <060.d9b76d41857e22145e6a388f6347c075@haskell.org> #9681: Printing of "\n" in error messages is broken -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: 1+"\n" | Blocking: | Differential Revisions: Phab:D405 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"995ea1c8335631d6e4db1ff4da38251b2f396edb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="995ea1c8335631d6e4db1ff4da38251b2f396edb" Fixed missing trailing newline bug in pretty printer Summary: Pretty printer didn't produce trailing newline in strings in error messages. Reviewers: simonpj, austin Reviewed By: austin Subscribers: thomie, carter, simonmar, mlen Differential Revision: https://phabricator.haskell.org/D405 GHC Trac Issues: #9681 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 16:54:15 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 16:54:15 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.d34e536b63d8d5a6315d8b0d8347ffbd@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: patch request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255, | Phab:D399 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"c6d4ae6f437fb041ea70f3d2b4f7f0d03ff797bf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c6d4ae6f437fb041ea70f3d2b4f7f0d03ff797bf" Fix test driver python3 compatibility issues Summary: Fixes python3 compatibility issues by replacing filter with a list comperhension and a potential issue with python2 when override_flags would be an empty list. Reviewers: austin, thomie Reviewed By: austin, thomie Subscribers: thomie, carter, simonmar, mlen Differential Revision: https://phabricator.haskell.org/D399 GHC Trac Issues: #9230 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 16:54:38 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 16:54:38 -0000 Subject: [GHC] #9230: Make -fwarn-tabs the default In-Reply-To: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> References: <045.44ab9aa6c5c4554ed8d149c327b464d2@haskell.org> Message-ID: <060.fa575a67841c63ed6d5384aa3bc783c3@haskell.org> #9230: Make -fwarn-tabs the default -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mlen Type: feature | Status: closed request | Milestone: 7.10.1 Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D255, | Phab:D399 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 16:55:53 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 16:55:53 -0000 Subject: [GHC] #9681: Printing of "\n" in error messages is broken In-Reply-To: <045.abc102fa93d2a130d37cc7ab11f8ef8d@haskell.org> References: <045.abc102fa93d2a130d37cc7ab11f8ef8d@haskell.org> Message-ID: <060.336f8a3ecce0e9bcb4a1accb0f9dd347@haskell.org> #9681: Printing of "\n" in error messages is broken -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: 1+"\n" | Blocking: | Differential Revisions: Phab:D405 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: infoneeded => closed * resolution: => fixed Comment: Merged, thanks! I think any fixes to formatting long strings can happen later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 17:09:59 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 17:09:59 -0000 Subject: [GHC] #7381: Build failure with BuildFlavour = prof In-Reply-To: <047.aa1b992407c04eb83593ab3d072f1bff@haskell.org> References: <047.aa1b992407c04eb83593ab3d072f1bff@haskell.org> Message-ID: <062.80c69b5da451c667d0edeb9eb8feb392@haskell.org> #7381: Build failure with BuildFlavour = prof -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.7 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: MacOS X | Difficulty: Unknown Type of failure: Building | Blocked By: GHC failed | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nh2): * owner: igloo => * status: closed => new * resolution: fixed => * milestone: => 7.8.4 Comment: This change is undocumented in the 7.6 to 7.8 changelog and breaks existing behaviour. As mentioned by David Terei in March 2013 (https://www.haskell.org/pipermail/ghc-devs/2013-March/000677.html) you now have to write `ghc -M [files] -dep-suffix=''` to get the old `ghc -M [files]` behaviour. This hit me badly since I was using some other `-dep-suffix` flags already, so I didn't get the `"You must specify at least one -dep-suffix"` warning, and the `.o` files were simply missing from my output Makefile. I'm reopening this ticket so that we can mention this change at least in the changelog for 7.8.4 if that's OK. And as David wrote, the user guide should probably also be updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 18:06:41 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 18:06:41 -0000 Subject: [GHC] #9744: Make program name and project version configurable Message-ID: <044.83253224e4144ae46fadcfbf6a5cd378@haskell.org> #9744: Make program name and project version configurable -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | 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: -------------------------------------+------------------------------------- GHC uses `cProjectVersion` in a few places and `ghc` is hardcoded as the program name. This is used for example for determining the location of the user package database (`getAppUserDataDirectory "ghc"`) and the names of dynamic libraries. I've been working around this for GHCJS, but it requires copying quite a bit of code. I have a patch that adds the program name and version to `Settings` that I'll submit once I've tested GHCJS with HEAD. My patch just allows these settings to be changed by GHC API clients. However, we could also make GHC itself read its own values from the `settings` file. This way we could add a version tag to a GHC installation without recompiling, keeping its packages and package databases separate from existing ones. Let me know if there's any interest in this and I'll add it to the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 18:16:24 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 18:16:24 -0000 Subject: [GHC] #9744: Make program name and project version configurable In-Reply-To: <044.83253224e4144ae46fadcfbf6a5cd378@haskell.org> References: <044.83253224e4144ae46fadcfbf6a5cd378@haskell.org> Message-ID: <059.f4f6ceac7de2b9b6a586ff78a4dd37eb@haskell.org> #9744: Make program name and project version configurable -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by luite): Side note: Hardcoded constants are also used for the target platform, while the actual target is configurable through `DynFlags`/`Settings`. Unfortunately properly printing a platform triple appears to be a bit hairy. I don't need this for GHCJS, so I've left it out so far for this reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 18:45:37 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 18:45:37 -0000 Subject: [GHC] #9011: panic - interactiveUI:setBuffering2 In-Reply-To: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> References: <044.3a6f1d7a5582a64701fea17d484c8cf1@haskell.org> Message-ID: <059.ad531b0a1e4886fe479b2a82ca969c3e@haskell.org> #9011: panic - interactiveUI:setBuffering2 -------------------------------------+---------------------------------- Reporter: irneb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+---------------------------------- Comment (by monoidal): irneb: Could you check if the issue still persists in GHC 7.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 20:24:31 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 20:24:31 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.45504966ec33438d8aeda1636f28b568@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by alanz): Status report. Using Phab:D297 applied to head, [https://github.com/alanz/ghc- exactprint/tree/ghc-7.9 ghc-exactprint] is able to fully reproduce the module header and exports of a haskell source file. Working with the annotations feels natural, and it works. Also, there has been no feedback, adverse or otherwise on wether this is the right approach. Given that HaRe will be the primary user initially, I would be happy to go ahead with this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 20:42:33 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 20:42:33 -0000 Subject: [GHC] #9745: qual_pkg panic with template haskell Message-ID: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> #9745: qual_pkg panic with template haskell -------------------------------------+------------------------------------- Reporter: luite | 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: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm updating some things that use Template Haskell to derive lenses to work with GHC HEAD, but I'm getting the following error. My `cabal- install` a fresh build from the master branch of the `cabal` repository. {{{ src/Lib.hs:11:1:ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141029 for x86_64-unknown-linux): qual_pkg lens-4.5.0.0.1 }}} lenstest.cabal {{{ name: lenstest version: 0.1.0.0 license-file: LICENSE author: Luite Stegeman maintainer: stegeman at gmail.com build-type: Simple cabal-version: >=1.10 library build-depends: base >= 4.8 && < 4.9, lens >= 4.5 exposed-modules: Lib default-language: Haskell2010 hs-source-dirs: src }}} src/Lib.hs: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Lib where import Control.Lens data XY = X Int | Y String makeLenses ''XY makePrisms ''XY }}} The `lens` and `free` packages need to be patched to work with the latest GHC, because of a conflict with `Data.Bifunctor`. I've attached updated version that use `PackageImports` to get the module from `bifunctors` as a workaround. Use {{{ cabal install --allow-newer }}} to install, since some dependencies have too restrictive upper bounds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 20:47:40 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 20:47:40 -0000 Subject: [GHC] #9745: qual_pkg panic with template haskell In-Reply-To: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> References: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> Message-ID: <059.9c374c30fcd4fa3e2dbb39d27d11a099@haskell.org> #9745: qual_pkg panic with template haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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: | -------------------------------------+------------------------------------- Comment (by luite): Sorry, the updated lens package couldn't be attached because it's bigger than the 256kB file size limit. Get it here: http://hdiff.luite.com/tmp/lens-4.5.0.0.1.tar.gz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 21:42:44 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 21:42:44 -0000 Subject: [GHC] #9725: Constraint deduction failure In-Reply-To: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> References: <048.ce87721a06dc31147070f2a0751cf107@haskell.org> Message-ID: <063.24e27c94fdeb687a58772d7841afbf68@haskell.org> #9725: Constraint deduction failure -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:15 goldfire]: > After some struggle, I came up with a working construction, attached. Bonus points if you can make it prettier and/or bind the scoped type variables without adding proxies. Thanks, Richard, this is very cool. It will take a while for me to analyse what exactly you are doing. I attached a version based on your workaround that makes the kind `En` a bit more interesting. I believe I can now transfer this into my real code :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 22:01:13 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 22:01:13 -0000 Subject: [GHC] #7191: hsc2hs can't treat absolute path correctly on Windows. In-Reply-To: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> References: <047.3232ebc6fdd91e5298cac108986ac5ca@haskell.org> Message-ID: <062.23fb4227bc41ca0737ff94ae7f18c81b@haskell.org> #7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:10 gintas]: > What needs to be done to get it released? Well, `hsc2hs` was never meant to be released independently from GHC to http://hackage.haskell.org/package/hsc2hs (and GHC's `hsc2hs` hasn't had its version number incremented for ages, because it's only an internal helper of the GHC distribution) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 22:37:32 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 22:37:32 -0000 Subject: [GHC] #9746: tests/ghci/scripts/T8172 is sensitive to drive name on Windows Message-ID: <045.7af0e04e1ed640383fef9f280530ad11@haskell.org> #9746: tests/ghci/scripts/T8172 is sensitive to drive name on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The test fails when the checkout is not on drive C:, like this: --- ./ghci/scripts/T8172.stdout-mingw32 2014-10-28 23:28:12.264410700 +0100 +++ ./ghci/scripts/T8172.run.stdout 2014-10-30 15:20:13.964595800 +0100 @@ -1,11 +1,11 @@ current working directory: - C:\ + K:\ module import search paths: . current working directory: - C:\ + K:\ module import search paths: none current working directory: - C:\ + K:\ module import search paths: / -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 22:38:11 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 22:38:11 -0000 Subject: [GHC] #9746: tests/ghci/scripts/T8172 is sensitive to drive name on Windows In-Reply-To: <045.7af0e04e1ed640383fef9f280530ad11@haskell.org> References: <045.7af0e04e1ed640383fef9f280530ad11@haskell.org> Message-ID: <060.7f6d86f039cacd70a026d5b8d933533f@haskell.org> #9746: tests/ghci/scripts/T8172 is sensitive to drive name on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Description changed by gintas: Old description: > The test fails when the checkout is not on drive C:, like this: > > --- ./ghci/scripts/T8172.stdout-mingw32 2014-10-28 23:28:12.264410700 > +0100 > +++ ./ghci/scripts/T8172.run.stdout 2014-10-30 15:20:13.964595800 > +0100 > @@ -1,11 +1,11 @@ > current working directory: > - C:\ > + K:\ > module import search paths: > . > current working directory: > - C:\ > + K:\ > module import search paths: none > current working directory: > - C:\ > + K:\ > module import search paths: > / New description: The test fails when the checkout is not on drive C:, like this: {{{ --- ./ghci/scripts/T8172.stdout-mingw32 2014-10-28 23:28:12.264410700 +0100 +++ ./ghci/scripts/T8172.run.stdout 2014-10-30 15:20:13.964595800 +0100 @@ -1,11 +1,11 @@ current working directory: - C:\ + K:\ module import search paths: . current working directory: - C:\ + K:\ module import search paths: none current working directory: - C:\ + K:\ module import search paths: / }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 30 22:46:17 2014 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Oct 2014 22:46:17 -0000 Subject: [GHC] #9259: GHCi should list its available command line options In-Reply-To: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> References: <048.fd9cb3ac17eedfc718e7fd061bcfaed1@haskell.org> Message-ID: <063.a6a759e5ade82bf57d53a85c50828adb@haskell.org> #9259: GHCi should list its available command line options -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: kolmodin Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Driver | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: Phab:D337 | -------------------------------------+------------------------------------- Comment (by afleck): Oops, sorry. I didn't realize there was already a patch on Phabricator. I'm new to this... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 00:36:24 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 00:36:24 -0000 Subject: [GHC] #9747: Odd failure to deduce a constraint Message-ID: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> #9747: Odd failure to deduce a constraint -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: TypeFamilies | Operating System: ConstraintKinds | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Using a type family to build a compound constraint that includes several constraints produced by applying another type family results in a type checker error like, {{{ Could not deduce (ConFun l a, ConFun l b) arising from a use of ?bar? from the context (ConFun l a, ConFun l b) bound by the type signature for baz :: (ConFun l a, ConFun l b) => Proxy l -> HList '[a, b] -> () }}} An example program is given at, https://gist.github.com/acowley/a001bd092599b5914bad -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 00:48:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 00:48:49 -0000 Subject: [GHC] #9747: Odd failure to deduce a constraint In-Reply-To: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> References: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> Message-ID: <061.72a0f0095da2d5c743041d427870703d@haskell.org> #9747: Odd failure to deduce a constraint -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: TypeFamilies Operating System: | ConstraintKinds Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => infoneeded Comment: Works for me, on GHC 7.8.3. If you're still seeing this error, try enabling `-fprint-explicit-kinds` -- my guess is that you'll get some helpful information. Can you give more instructions on how to reproduce? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 01:06:49 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 01:06:49 -0000 Subject: [GHC] #9747: Odd failure to deduce a constraint In-Reply-To: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> References: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> Message-ID: <061.8fe30308739988e6d94c2e409db38b95@haskell.org> #9747: Odd failure to deduce a constraint -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: TypeFamilies Operating System: | ConstraintKinds Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by acowley): Sorry I wasn't clear, you need to uncomment the definition of `baz` to see the error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 01:13:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 01:13:20 -0000 Subject: [GHC] #9745: qual_pkg panic with template haskell In-Reply-To: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> References: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> Message-ID: <059.22764ecc45e003dc90e6218b64efd5f8@haskell.org> #9745: qual_pkg panic with template haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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 ezyang): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 01:20:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 01:20:09 -0000 Subject: [GHC] #9745: qual_pkg panic with template haskell In-Reply-To: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> References: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> Message-ID: <059.007763649c3f5a39ce2701c623d675b6@haskell.org> #9745: qual_pkg panic with template haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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: | -------------------------------------+------------------------------------- Comment (by ezyang): `semigroups` doesn't seem to compile for me, what version are you using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 03:46:44 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 03:46:44 -0000 Subject: [GHC] #9745: qual_pkg panic with template haskell In-Reply-To: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> References: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> Message-ID: <059.edcf52c1bad2f7fd48f9d011af4fb037@haskell.org> #9745: qual_pkg panic with template haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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: | -------------------------------------+------------------------------------- Comment (by luite): It's `lens` that generates a name with a package version, not key: https://github.com/ekmett/lens/blob/b28d8658a3abf166d81eeffc8297a934116a97ef/src/Control/Lens/Internal/TH.hs#L92 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 04:14:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 04:14:35 -0000 Subject: [GHC] #9748: Disambiguate IO actions in GHCi with :set +t Message-ID: <051.eb64c51829f1760c379502433f79e297@haskell.org> #9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently GHCi's `:set +t` displays the same type for the following: {{{#!hs % ghci -ignore-dot-ghci GHCi, version 7.8.2: 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> :set +t Prelude> 'a' 'a' it :: Char Prelude> return 'a' 'a' it :: Char Prelude> return 'a' :: IO Char 'a' it :: Char }}} A user at `#haskell-beginners` ran into a problem where they mistook an expression that defaulted to IO for a pure expression (`Id . even <$> pure 5`), `:set +t` was suggested but ended up showing the incorrect type: {{{#!hs ghci> Id . even <$> pure 5 Id False it :: Id Bool }}} This is bad for pedagogical reasons, it would be an improvement to display the following: {{{#!hs Prelude> :set +t Prelude> 'a' 'a' it :: Char Prelude> return 'a' 'a' it :: Char <- return 'a' :: IO Char Prelude> return 'a' :: IO Char 'a' it :: Char <- return 'a' :: IO Char }}} mirroring existing syntax: {{{#!hs Prelude> :set -XScopedTypeVariables Prelude> a :: Char <- return 'a' :: IO Char a :: Char }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 04:15:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 04:15:54 -0000 Subject: [GHC] #9748: Disambiguate IO actions in GHCi with :set +t In-Reply-To: <051.eb64c51829f1760c379502433f79e297@haskell.org> References: <051.eb64c51829f1760c379502433f79e297@haskell.org> Message-ID: <066.9071392858336d34611a867fe5ada479@haskell.org> #9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: low | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): *showing the incorrect type for the given expression, the type of `it` is correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 04:44:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 04:44:22 -0000 Subject: [GHC] #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion In-Reply-To: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> References: <045.7e2f7bf1f77ecf8607cd3966531ffeb1@haskell.org> Message-ID: <060.678479cc90aaa6fc2b9f7410494ec2b8@haskell.org> #8089: Implementation of GHC.Event.Poll.poll is broken due to bad coercion -------------------------------------+------------------------------------- Reporter: merijn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/base | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by merijn): * cc: hvr, ekmett (added) * keywords: patch => * status: closed => new * resolution: fixed => * owner: thoughtpolice => Comment: My "fixed" fix was still wrong, proper fix incoming on Phabricator -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 07:05:22 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 07:05:22 -0000 Subject: [GHC] #9745: qual_pkg panic with template haskell In-Reply-To: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> References: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> Message-ID: <059.d621c25ac17e303e518abc807947cb99@haskell.org> #9745: qual_pkg panic with template haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: invalid | 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 ezyang): * status: new => closed * resolution: => invalid Comment: Ahhh, very nice catch! I grepped for key like things but I must have missed this. So, let's close as not our bug... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 07:46:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 07:46:35 -0000 Subject: [GHC] #9748: Disambiguate IO actions in GHCi with :set +t In-Reply-To: <051.eb64c51829f1760c379502433f79e297@haskell.org> References: <051.eb64c51829f1760c379502433f79e297@haskell.org> Message-ID: <066.83e3a0410ade67d1e12a6e9cadacad7e@haskell.org> #9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: low | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by hvr): I've been wishing something like that myself, however I don't like {{{#!hs it :: Char <- return 'a' :: IO Char }}} as it's too noisy IMO by the redundantly repeated value's type I'd rather like to see something like {{{#!hs it :: {- IO -} Char }}} that doesn't need to repeat the type, and still give an indication about evaluated result stored in `it` having resulted from an `IO`-action -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 08:24:17 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 08:24:17 -0000 Subject: [GHC] #9746: tests/ghci/scripts/T8172 is sensitive to drive name on Windows In-Reply-To: <045.7af0e04e1ed640383fef9f280530ad11@haskell.org> References: <045.7af0e04e1ed640383fef9f280530ad11@haskell.org> Message-ID: <060.6b09d4b6da53f9ceac83500c04c60323@haskell.org> #9746: tests/ghci/scripts/T8172 is sensitive to drive name on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): So, can we just fix the test, so that it is not sensitive in this way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 08:36:14 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 08:36:14 -0000 Subject: [GHC] #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas In-Reply-To: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> References: <046.11c831d7bf4fcb0f838442415009db50@haskell.org> Message-ID: <061.c915fa6746500ccfb26ed9daae9f9b27@haskell.org> #9242: Implement {-# OVERLAPPABLE #-} and {-# INCOHERENT #-} pragmas -------------------------------------+------------------------------------- Reporter: simonpj | Owner: diatchki Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"cbb20ab2c3222da75625bcf41f8ff67a7e9ba5f7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cbb20ab2c3222da75625bcf41f8ff67a7e9ba5f7" Drop deprecated `OverlappingInstances` from base With #9242 the `OverlappingInstances` extension got deprecated, this commit adapts the only two remaining places in `base` where it was still used. Starting with this commit, the `Typeable (s t)` instance (which seemingly was the motivation for using `OverlappingInstances` in the first place when `Typeable` was neither polykinded nor auto-derived-only, see also commit ce3fd0e02826367e6134a3362d8d37aa114236f5 which introduced overlapping instances) does no longer allow overlapping instances, and there doesn't seem to be any good reason to keep allowing overlapping instance now. This also removes redundant `LANGUAGE`/`OPTIONS_GHC` pragmas from `Data.Typeable` and refactors the language pragmas into more uniform single-line pragmas. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D377 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 08:52:39 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 08:52:39 -0000 Subject: [GHC] #9747: Odd failure to deduce a constraint In-Reply-To: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> References: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> Message-ID: <061.c4cec62fccb439a0107e908f2b6e2bef@haskell.org> #9747: Odd failure to deduce a constraint -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: TypeFamilies Operating System: | ConstraintKinds Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: infoneeded => closed * resolution: => fixed Comment: It's a bug in GHC 7.8.3, fixed in upcoming 7.8.4 and HEAD, and not present in 7.8.2. Both say {{{ T9747.hs:35:8: Type family ?ConFun? should have 2 arguments, but has been given 1 In the type signature for ?bar?: bar :: HListAll (ConFun l) ts => Proxy l -> HList ts -> () }}} And that's right! This works though {{{ type family ConFun (t :: *) :: * -> Constraint data Tag type instance ConFun Tag = Group class (Show a, Eq a, Ord a) => Group a bar :: HListAll (ConFun l) ts => Proxy l -> HList ts -> () bar _ _ = () baz :: (ConFun l a, ConFun l b) => Proxy l -> HList [a,b] -> () baz = bar }}} I've eta-reduced `ConFun`, but then I had to give a fresh name to the RHS via the class decl for `Group`. I'll add the working version as a regression test. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 08:53:03 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 08:53:03 -0000 Subject: [GHC] #9747: Odd failure to deduce a constraint In-Reply-To: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> References: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> Message-ID: <061.3d9e1022ac64b82b8183000f33430bbc@haskell.org> #9747: Odd failure to deduce a constraint -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: TypeFamilies Operating System: | ConstraintKinds Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: indexed- | Related Tickets: types/should_compile/T9747 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T9747 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 09:13:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 09:13:45 -0000 Subject: [GHC] #9748: Disambiguate IO actions in GHCi with :set +t In-Reply-To: <051.eb64c51829f1760c379502433f79e297@haskell.org> References: <051.eb64c51829f1760c379502433f79e297@haskell.org> Message-ID: <066.c37f994bc1607f2ea1c985432decd34c@haskell.org> #9748: Disambiguate IO actions in GHCi with :set +t -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.8.2 Priority: low | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Moreover we ''really'' don't want to repeat the expression being evaluated, which might be large! Way too noisy. I quite like Herert's suggestion. Or {{{ Prelude> return 'a' Running IO action... 'a' it :: Char }}} or {{{ Prelude> return 'a' it :: Char -- After running the IO action }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 09:47:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 09:47:45 -0000 Subject: [GHC] #9628: Add Annotations to the AST to simplify source to source conversions In-Reply-To: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> References: <044.285fa4db7fb10488df4811e6070f6acb@haskell.org> Message-ID: <059.df142453f17c4b1abe461ee69cb46517@haskell.org> #9628: Add Annotations to the AST to simplify source to source conversions -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.9 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: D297 | -------------------------------------+------------------------------------- Comment (by simonpj): Fair enough in general. I've added some comments on Phab -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 10:09:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 10:09:33 -0000 Subject: [GHC] #9358: Improve flag description in the user guide In-Reply-To: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> References: <048.91e928ec38c51924ff2b3e0f4aa8883c@haskell.org> Message-ID: <063.d24b41ff3272f37d269e8a8334d5bca6@haskell.org> #9358: Improve flag description in the user guide -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.8.3 Documentation | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: Documentation bug | Related Tickets: #1880 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by jstolarek): `-ddump-simpl-phases` and `-ddump-simpl-phases` look like a no-op. Investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 10:33:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 10:33:01 -0000 Subject: [GHC] #9236: hGetContents leads to late/silent failures In-Reply-To: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> References: <045.fb61a417f1b94d36fb043e0e3c3da5bd@haskell.org> Message-ID: <060.d5e065613b64a7cfab87ce6875bd2680@haskell.org> #9236: hGetContents leads to late/silent failures -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: feature | Status: closed request | Milestone: Priority: normal | Version: 7.8.2 Component: Core | Keywords: Libraries | Architecture: Unknown/Multiple Resolution: fixed | Difficulty: Easy (less than 1 Operating System: | hour) Unknown/Multiple | Blocked By: Type of failure: Other | Related Tickets: #8213 Test Case: | Blocking: | Differential Revisions: Phab:D327 | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 12:26:41 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 12:26:41 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.d66f282d75ffd1a53f92966ad1115ac1@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | typecheck/should_fail/T9739 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T9739 Comment: The 3-class version still loops in HEAD. Reason is this: * `TcTyClsDcls.checkValidClass` is called on each class in turn. * It checks for superclass cycles, and then checks for ambiguity of the method types * The ambiguity check loops if there is a superclass cycle * The superclass cycle check was first, and aborted `checkValidClass` if it failed. * BUT we failed to notice that it would loop if there was a superclass cycle in ''another'' class in the group; and after each class we dust ourselves off and the next one, to get as many validity errors as possible. Solution was simple: make the ambiguity check happen only if there have been no errors so far. Patch coming Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 12:36:20 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 12:36:20 -0000 Subject: [GHC] #9749: ghc -M 7.8 does not add underscores when -dep-suffix is used Message-ID: <042.ec0d8eacc55debae81fec5cb658ef211@haskell.org> #9749: ghc -M 7.8 does not add underscores when -dep-suffix is used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: 7381 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- https://www.haskell.org/ghc/docs/7.8.3/html/users_guide/separate- compilation.html says: ''Make extra dependencies that declare that files with suffix `._` depend on interface files with suffix `._hi`'' but ghc 7.8 doesn't do that any more, it drops the `_` underscore. This undocumented (neither in User Guide nor in Changelog) change was introduced for #7381 in https://git.haskell.org/ghc.git/commitdiff/af072fc35d8dbe7962e62700da052593e999c0ef. Is this a documentation bug or a `ghc -M` bug? How should one write `ghc -M` invocations that work on both 7.6 and 7.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 12:36:45 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 12:36:45 -0000 Subject: [GHC] #9749: ghc -M 7.8 does not add underscores when -dep-suffix is used In-Reply-To: <042.ec0d8eacc55debae81fec5cb658ef211@haskell.org> References: <042.ec0d8eacc55debae81fec5cb658ef211@haskell.org> Message-ID: <057.41ec8f05a45fee507446e7f1017838ac@haskell.org> #9749: ghc -M 7.8 does not add underscores when -dep-suffix is used -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build | Version: 7.8.3 System | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Easy (less than 1 Unknown/Multiple | hour) Type of failure: | Blocked By: None/Unknown | Related Tickets: #7381 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nh2): * related: 7381 => #7381 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 12:49:23 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 12:49:23 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.106cf0c141b523c2823ed66e8f356693@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: Phab:D343 | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sure this is do-able by knot-tying, but it'll need a bit of care. * Each alternative can start by emitting a pure blob of code that is a function of the GC plan * The GC plan is computed from the heap-allocation info from all the alternatives (this is the knot-tied bit) * So it must be possible to run the alternative `FCode` blobs without yet knowing the GC plan. * Currently `cgAlts` is strict in the plan, but I don't think it needs to be. After all, the code we generate for the alternatives does not depend on whether there's a heap check at the beginning. You probably need to allocate a label regardless since that is a monadic operation. So not trivial, but ought to be quite possible. ''Semantically'' the data dependencies are just fine! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 12:52:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 12:52:51 -0000 Subject: [GHC] #7944: GHC goes into an apparently infinite loop at -O2 In-Reply-To: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> References: <042.860ea78ae85c4a928feb9d490c6ef1e4@haskell.org> Message-ID: <057.339e5e3322cbf875f56d1be24a6345b4@haskell.org> #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: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 12:55:01 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 12:55:01 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.827df2a02873ae6fad8095493fd41d3f@haskell.org> #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: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 13:01:02 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 13:01:02 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.e19e6cec690b54964a34fc1b3eb03f57@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: crash | Related Tickets: Test Case: ghcirun004 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): Does anyone have a clue what is going on here? I regularly get a batch of failures {{{ Unexpected failures: ffi/should_run ffi018_ghci [bad stdout or stderr] (ghci) ghci/should_run T2589 [bad stdout or stderr] (ghci) ghci/should_run ghcirun001 [bad stdout or stderr] (ghci) ghci/should_run ghcirun002 [bad exit code] (ghci) ghci/should_run ghcirun003 [bad stdout or stderr] (ghci) ghci/should_run ghcirun004 [bad stdout or stderr] (ghci) }}} all of which are this `ioManagerWakeup:write: Bad file descriptor` thing. What is `ioManagerWakeup`? Who calls it? Why? What does it mean to have a bad file descriptor? It's bad because I can't get a clean validate these days. Incidentally {{{ make TEST=ghcirun001 }}} works fine! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 13:21:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 13:21:09 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.2a459df1b3016a8a649565ee2d4898ba@haskell.org> #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: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 13:33:43 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 13:33:43 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.ef2bac3ed8f126d1ed10a408b5df7aae@haskell.org> #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: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 13:36:00 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 13:36:00 -0000 Subject: [GHC] #9729: GHCi accepts invalid programs when recompiling In-Reply-To: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> References: <047.be9ff38058adb3f22c9154bf2f7b59eb@haskell.org> Message-ID: <062.e9823f47e77955c4e1c5a87377693f73@haskell.org> #9729: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: GHC | Blocked By: accepts invalid program | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): The problem is this. * When compiling A we load up the interface file for `Data.Syntactic.Sugar.BindingT`, since A imports it. It includes an orphan instance declaration for the type family `Internal`. * That populates the `eps_fam_inst_env`, globally across all packages, recording an instance for the type family `Internal`. * Then when recompiling B we see the instance. The solution, I think, is this: * During instance lookup, for type families or classes, if the matched instance is an orphan, then check that the host module for the instance is transitively below the module being compiled. We only need to do this check for orphan instance, because it's guaranteed true for non-orphans. GHC already keeps a list of all the orphan modules transitively below the one being compiled, in the `imp_orphs` field of `tcg_imports`. So the check should be easy to do. That said, a `ModuleSet` would be better than a list, for fast membership checks. Edward is already working on adding more info to the `imp_orphs` field: see Trac #9717. It might be better to combine the two. Edward would you like to comment? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 13:36:09 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 13:36:09 -0000 Subject: [GHC] #9717: More lazy orphan module loading In-Reply-To: <045.9158d61e70fef57bd7cb8f0956c9909d@haskell.org> References: <045.9158d61e70fef57bd7cb8f0956c9909d@haskell.org> Message-ID: <060.5f685defd6109ac8f1361fd996277e7a@haskell.org> #9717: More lazy orphan module loading -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: backpack Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #9729 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 13:50:35 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 13:50:35 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.4d23fc45a949c70f75db076037855566@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: #1498 Test Case: | Blocking: 8317 | Differential Revisions: Phab:D343 | -------------------------------------+------------------------------------- Comment (by jstolarek): Yes, data dependencies are fine. My current patch actually does the things outlined above but without knot-tying. And it's buggy at the moment. I'll try to debug my patch and if that fails I'll try the approach you just described above but I admit I'm not too keen on it. The problem is that making `cgAlts` non-strict in `gc_plan` seems very non-trivial and seems to require *a lot* of changes in the structure of the code. By contrast, my patch is quite well localized and confined to a small area of code. > You probably need to allocate a label regardless since that is a monadic operation. I don't understand that bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 14:15:40 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 14:15:40 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.9c7dbe1ca72de776b734fc02e079bd1a@haskell.org> #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: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 15:24:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 15:24:51 -0000 Subject: [GHC] #9750: Core lint failure with TypeLits Symbol Message-ID: <046.5556b1a5abfec32c491622ee4b789d38@haskell.org> #9750: Core lint failure with TypeLits Symbol -------------------------------------+------------------------------------- Reporter: dreixel | 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: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following module: {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE ScopedTypeVariables #-} module Bug where import GHC.TypeLits ( Symbol, KnownSymbol ) -------------------------------------------------------------------------------- data Meta = MetaCons Symbol data M1 (c :: Meta) = M1 class Generic a where type Rep a :: * from :: a -> Rep a -------------------------------------------------------------------------------- data A = A1 instance Generic A where type Rep A = M1 ('MetaCons "test") from A1 = M1 class GShow' f where gshowsPrec' :: f -> ShowS instance (KnownSymbol c) => GShow' (M1 ('MetaCons c)) instance GShow' A where gshowsPrec' = gshowsPrec' . from }}} fails `-dcore-lint` in HEAD with: {{{ *** Core Lint errors : in result of Desugar (after optimization) *** : Warning: [RHS of $dKnownSymbol_azn :: GHC.TypeLits.KnownSymbol "test"] From-type of Cast differs from type of enclosed expression From-type: GHC.TypeLits.KnownSymbol "test" Type of enclosed expr: [GHC.Types.Char] Actual enclosed expr: GHC.CString.unpackCString# "test"# Coercion used in cast: GHC.TypeLits.NTCo:KnownSymbol[0] <"test">_N ; GHC.TypeLits.NTCo:SSymbol[0] <"test">_P }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 15:46:25 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 15:46:25 -0000 Subject: [GHC] #9739: GHC 7.8 chokes on recursive classes In-Reply-To: <046.2587334b1f81281802988a39c910928f@haskell.org> References: <046.2587334b1f81281802988a39c910928f@haskell.org> Message-ID: <061.0174073d9d1a0e6d481d8743e9ea800a@haskell.org> #9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 (Type checker) | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Compile- | Related Tickets: time crash | Test Case: | typecheck/should_fail/T9739 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dfeuer): I don't understand why such a member signature was even allowed without `-XConstrainedClassMethods`. That's essentially a syntax error! Someone also noticed that `Foldable` members currently have a redundant (but harmless) `Foldable` constraint that I think shouldn't have been allowed (I'll take care of those). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 16:09:52 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 16:09:52 -0000 Subject: [GHC] #9750: Core lint failure with TypeLits Symbol In-Reply-To: <046.5556b1a5abfec32c491622ee4b789d38@haskell.org> References: <046.5556b1a5abfec32c491622ee4b789d38@haskell.org> Message-ID: <061.f0990bbe13c163b39aac5c153d2bdd3e@haskell.org> #9750: Core lint failure with TypeLits Symbol -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 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: | -------------------------------------+------------------------------------- Comment (by simonpj): works on `wip/new-flatten-skolems-Oct14`!! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 17:08:32 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 17:08:32 -0000 Subject: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas In-Reply-To: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> References: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> Message-ID: <059.cc773aff99fca99c1eeff76552b2b897@haskell.org> #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: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 17:29:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 17:29:05 -0000 Subject: [GHC] #9747: Odd failure to deduce a constraint In-Reply-To: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> References: <046.d23256d8231e0e6be0c3d8a217a6bac0@haskell.org> Message-ID: <061.dd4ef3db5f0aca07e10543f5194fd066@haskell.org> #9747: Odd failure to deduce a constraint -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: TypeFamilies Operating System: | ConstraintKinds Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: | Difficulty: Unknown None/Unknown | Blocked By: Test Case: indexed- | Related Tickets: types/should_compile/T9747 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by acowley): Thank you! That is precisely the error I expected to see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 18:04:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 18:04:15 -0000 Subject: [GHC] #2968: Avoid generating C trigraphs (was: add test for C trigraphs) In-Reply-To: <045.2a7f68178978b83c4a4101bfbab4cf22@haskell.org> References: <045.2a7f68178978b83c4a4101bfbab4cf22@haskell.org> Message-ID: <060.84642f03b921fd2154c42be4c97b4ff9@haskell.org> #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: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 18:12:51 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 18:12:51 -0000 Subject: [GHC] #9751: add runMeta Hook or TcM variant of hscCompileCoreExprHook Message-ID: <044.0e39eba5e5bc320ab7bb45f4a7f2c823@haskell.org> #9751: add runMeta Hook or TcM variant of hscCompileCoreExprHook -------------------------------------+------------------------------------- Reporter: luite | Owner: luite Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: GHC API | 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: -------------------------------------+------------------------------------- GHCJS has to jump through hoops to make annotations work and to get the necessary information for linking a TH splice. The main reason is that `hscCompileCoreExprHook` does not expose the `TcM` environment. Easiest fix would be to add {{{#!hs hscCompileCoreExprTcMHook :: HscEnv -> SrcSpan -> CoreExpr -> TcM HValue }}} to `Hooks`, but it'd be better to hook `runMeta` instead. Unfortunately `runMeta` is polymorphic, so it could be more tricky. I'm going to see if I can hook `runMeta` in a reasonable way, and if I run out of time for 7.10.1, send a patch with `hscCompileCoreExprTcMHook` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 19:17:15 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 19:17:15 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.ac5052041c8d0911cc32354168c6a56f@haskell.org> #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: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 19:53:48 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 19:53:48 -0000 Subject: [GHC] #9667: Type inference is weaker for GADT than analogous Data Family In-Reply-To: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> References: <045.0a0cdd9719d44a0f67a0c23e3cebdaa1@haskell.org> Message-ID: <060.034fdb6538b56c0ea5cdfb76461447da@haskell.org> #9667: Type inference is weaker for GADT than analogous Data Family -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.3 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: GHC | rejects valid program | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by carter): ok, i'll strip it down more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 20:40:05 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 20:40:05 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.8b8d0fa20b80c75d7f35e2e153d0f002@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 20:49:33 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 20:49:33 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.d2e4a4b1a297fd26f9475271089bfb2e@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Runtime | Version: 7.7 System | Keywords: IO Manager, Resolution: | System Time Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 20:53:55 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 20:53:55 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.dc09f67a507758cca7751f571a6e3f64@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Compile- | Blocked By: time performance bug | Related Tickets: #910 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by nh2): @simonmar How much do you think is this affected by #8224? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 31 21:14:54 2014 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Oct 2014 21:14:54 -0000 Subject: [GHC] #2773: Documentation mentions deprecated flags In-Reply-To: <044.8fbd9fa5930a794c5be22803687b7d92@haskell.org> References: <044.8fbd9fa5930a794c5be22803687b7d92@haskell.org> Message-ID: <059.9ce54c34aaef3196690960d431ef385a@haskell.org> #2773: Documentation mentions deprecated flags -------------------------------------+--------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Difficulty: Unknown | Test Case: -------------------------------------+--------------------------------- Comment (by Austin Seipp ): In [changeset:"e466ea7a153a1b8d5bcfebf3dddaa33125c14c5d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e466ea7a153a1b8d5bcfebf3dddaa33125c14c5d" Remove legacy support for -optdef flags Summary: -optdef flags were deprecated in or before 2008 Reviewers: austin Reviewed By: austin Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D409 GHC Trac Issues: #2773 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler