From ghc-devs at haskell.org Mon Aug 1 00:54:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Aug 2016 00:54:29 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.f36a23328384ff6027303376e731314a@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgillespie): I'd like to have a look. What is the proposed message? Should we use the original message below? {{{ Foo.hs:2:20 inferred: "Just 5" has type "Maybe a0" expected: second argument of "($)" must have type "Int" in the expression: addThree $ Just 5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 1 08:36:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Aug 2016 08:36:15 -0000 Subject: [GHC] #12176: Failure of bidirectional type inference at the kind level In-Reply-To: <047.cd9ca4aa1f9d2a50e3f65696b41c1e1c@haskell.org> References: <047.cd9ca4aa1f9d2a50e3f65696b41c1e1c@haskell.org> Message-ID: <062.35c791ecfcaea5dc53d0a54b943e70b1@haskell.org> #12176: Failure of bidirectional type inference at the kind level -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"89ae1e858f6eed42cebd9af01b30e239d4543faf/ghc" 89ae1e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="89ae1e858f6eed42cebd9af01b30e239d4543faf" Relevant Bindings no longer reports shadowed bindings (fixes #12176) Summary: Modified the RelevantBindings method in TcErrors.hs to only search over non-shadowed bindings. Test Plan: Wrote 2 simple test cases, verified that it worked with multiple shadowed bindings, and also non-shadowed bindings. Reviewers: austin, bgamari, ezyang Reviewed By: ezyang Subscribers: ezyang, thomie Differential Revision: https://phabricator.haskell.org/D2434 GHC Trac Issues: #12177 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 1 08:36:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Aug 2016 08:36:15 -0000 Subject: [GHC] #12177: Relevant bindings includes shadowed bindings In-Reply-To: <045.0e76a562090c9d87371f445f74b8515d@haskell.org> References: <045.0e76a562090c9d87371f445f74b8515d@haskell.org> Message-ID: <060.586ecf0a93d6b830a09e3072a2de97f4@haskell.org> #12177: Relevant bindings includes shadowed bindings -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2434 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"89ae1e858f6eed42cebd9af01b30e239d4543faf/ghc" 89ae1e8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="89ae1e858f6eed42cebd9af01b30e239d4543faf" Relevant Bindings no longer reports shadowed bindings (fixes #12176) Summary: Modified the RelevantBindings method in TcErrors.hs to only search over non-shadowed bindings. Test Plan: Wrote 2 simple test cases, verified that it worked with multiple shadowed bindings, and also non-shadowed bindings. Reviewers: austin, bgamari, ezyang Reviewed By: ezyang Subscribers: ezyang, thomie Differential Revision: https://phabricator.haskell.org/D2434 GHC Trac Issues: #12177 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 1 09:52:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Aug 2016 09:52:32 -0000 Subject: [GHC] #9173: Better type error messages In-Reply-To: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> References: <046.f8f24aa2ddaa3d579bc40f0b6f04f6b7@haskell.org> Message-ID: <061.e0c6bcf9b8236a6afb28f5202bd5cf9a@haskell.org> #9173: Better type error messages -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chreekat): Replying to [comment:20 sgillespie]: > I'd like to have a look. What is the proposed message? Should we use the original message below? > > {{{ > Foo.hs:2:20 > inferred: "Just 5" has type "Maybe a0" > expected: second argument of "($)" must have type "Int" > in the expression: addThree $ Just 5 > }}} I vote for the simpler wording change rather than whatever acrobatics would be required to overcome the problems listed here: https://mail.haskell.org/pipermail/ghc-devs/2015-August/009559.html I guess that the patch mentioned above makes those bigger changes possible, but still. For the wording change, I think adding "...from context" is universally desired. See my comment:14, and the one following it, for suggested text. Incidentally, I dislike the eldest proposal (quoted in this comment) because it splits the necessary information over a couple lines, which is not so nice for integrating with vim's `:make` command. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 1 10:39:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Aug 2016 10:39:13 -0000 Subject: [GHC] #8473: Generate table of cost-centre numbers with source locations In-Reply-To: <053.95380650abc814621da8b15bb4430f35@haskell.org> References: <053.95380650abc814621da8b15bb4430f35@haskell.org> Message-ID: <068.e46c01085caefb85ad1da023a9704686@haskell.org> #8473: Generate table of cost-centre numbers with source locations -------------------------------------+------------------------------------- Reporter: lars_e_krueger | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Profiling | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7105 | Differential Rev(s): Phab:D2282 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged as 7fc7538fffb9ad4ad2132a8a9ef8cb6543d0b2fc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 1 11:03:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Aug 2016 11:03:10 -0000 Subject: [GHC] #12368: Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation In-Reply-To: <046.2b784c018fc4a62b657688676ee901f3@haskell.org> References: <046.2b784c018fc4a62b657688676ee901f3@haskell.org> Message-ID: <061.87a38c66cf9200aa274ca41ad09ec10f@haskell.org> #12368: Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2392 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Code on Phab and the branch, currently awaiting validation. Didn’t validate, had a minor typo that was hard to track down. But now it is fixed, and ready for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 1 11:59:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Aug 2016 11:59:46 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi In-Reply-To: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> References: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> Message-ID: <059.d1d2253dc42be09f61935316259774a9@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): If we choose to provide access to shadowed identifiers then, in the debugger, our environment gets littered by `Ghci#._result` and `Ghci#._exception`. Is that desirable? I think I have a patch that implements that, but it breaks the debugger tests because of the above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 1 14:20:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Aug 2016 14:20:53 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.fa25fe36f870fb7f911085b5de34c269@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2430 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 Comment: This should go in to 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 1 14:34:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Aug 2016 14:34:43 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.d100c8fbf0e1d70de4344a7c5cca3b14@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2430 Wiki Page: | -------------------------------------+------------------------------------- Comment (by luisgabriel): Replying to [comment:3 simonmar]: > I found one bug, see Phab:D2430. However, even after the patch the threadscope profiles don't look identical. I don't think there is an actual problem, just that the program itself isn't very parallel - if you zoom in, there's lots of time in each thread where no work is being done. The difference in scheduling is due to the way that `forkOS` has to hand- shake with the new thread to get its `ThreadId`. Indeed. This example is not very good. I did not expect the profiles to look identical, but it seemed a bit odd to me having a large number of capabilities in idle. Nevertheless, I'm happy to see you identified a bug in the scheduler. Thank you very much for the quick fix! Feel free to close this ticket when the patch lands. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 05:32:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 05:32:44 -0000 Subject: [GHC] #12450: Option to suppress GHCi output "Failed, modules loaded" Message-ID: <045.33d72cd979536e35cebd0175b09fac32@haskell.org> #12450: Option to suppress GHCi output "Failed, modules loaded" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For projects with lots of modules, the "modules loaded" message can be considerably long. For example: {{{ Failed, modules loaded: Distribution.Client.Check, Distribution.Client.Run, Distribution.Client.Tar, Distribution.Client.Types, Distribution.Client.Win32SelfUpgrade, Distribution.Client.Utils, Paths_cabal_install, Distribution.Client.BuildReports.Types, Distribution.Client.Dependency.Types, Distribution.Client.Init.Types, Distribution.Solver.Types.ConstraintSource, Distribution.Solver.Types.Settings, Distribution.Client.GlobalFlags, Distribution.Client.HttpUtils, Distribution.Client.Security.HTTP, Distribution.Solver.Types.PackageIndex, Distribution.Solver.Types.ComponentDeps, Distribution.Solver.Types.OptionalStanza, Distribution.Solver.Types.PackageFixedDeps, Distribution.Solver.Types.SourcePackage, Distribution.Solver.Types.LabeledPackageConstraint, Distribution.Solver.Types.PackageConstraint, Distribution.Client.World, Distribution.Client.FetchUtils, Distribution.Client.GZipUtils, Distribution.Client.Init.Licenses, Distribution.Client.Init.Heuristics, Distribution.Client.Compat.Process, Distribution.Client.JobControl, Distribution.Client.Compat.ExecutablePath, Distribution.Client.Compat.Semaphore, Distribution.Client.ParseUtils, Distribution.Client.Compat.FilePerms, Distribution.Client.Haddock, Distribution.Client.InstallPlan, Distribution.Client.SolverInstallPlan, Distribution.Client.BuildReports.Anonymous, Distribution.Client.BuildReports.Storage, Distribution.Solver.Types.PkgConfigDb, Distribution.Solver.Types.SolverPackage, Distribution.Solver.Types.SolverId, Distribution.Solver.Types.ResolverPackage, Distribution.Solver.Modular, Distribution.Client.PackageUtils, Distribution.Solver.Types.DependencyResolver, Distribution.Solver.Types.InstalledPreference, Distribution.Solver.Types.PackagePath, Distribution.Solver.Types.PackagePreferences, Distribution.Solver.Types.Progress, Distribution.Solver.Types.Variable, Distribution.Solver.Modular.Assignment, Distribution.Solver.Modular.ConfiguredConversion, Distribution.Solver.Modular.IndexConversion, Distribution.Solver.Modular.Log, Distribution.Solver.Modular.Package, Distribution.Solver.Modular.Solver, Distribution.Solver.Modular.Builder, Distribution.Solver.Modular.Cycles, Distribution.Solver.Modular.Dependency, Distribution.Solver.Modular.Explore, Distribution.Solver.Modular.Index, Distribution.Solver.Modular.Message, Distribution.Solver.Modular.Preference, Distribution.Solver.Modular.Validate, Distribution.Solver.Modular.Linking, Distribution.Solver.Modular.PSQ, Distribution.Solver.Modular.Tree, Distribution.Solver.Modular.Flag, Distribution.Solver.Modular.Version, Distribution.Solver.Modular.ConflictSet, Distribution.Solver.Modular.Var, Distribution.Solver.Modular.Configured, Distribution.Solver.Modular.LabeledGraph, Distribution.Client.ProjectPlanning.Types, Distribution.Client.DistDirLayout, Distribution.Client.PackageHash, Distribution.Client.RebuildMonad, Distribution.Client.Glob, Distribution.Client.FileMonitor, Distribution.Client.Utils.Json. *Distribution.Client.Check> }}} It would be nice if there were a way to suppress this message. If there already is a way, it would be nice if GHCi mentioned this method when the module list gets long. See also https://stackoverflow.com/questions/11509201/how-can-i-suppress- failed-modules-loaded-in-ghci -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 05:45:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 05:45:51 -0000 Subject: [GHC] #12450: Option to suppress GHCi output "Failed, modules loaded" In-Reply-To: <045.33d72cd979536e35cebd0175b09fac32@haskell.org> References: <045.33d72cd979536e35cebd0175b09fac32@haskell.org> Message-ID: <060.af4fb212fbd81e38b6f89ffbd4e3eea4@haskell.org> #12450: Option to suppress GHCi output "Failed, modules loaded" -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): An acceptable workaround is: {{{ ghci Foo.hs | (trap '' SIGINT; sed -e '/Failed, modules loaded.*/d') }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 07:13:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 07:13:42 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.f9533ff63a7f6d58adcfacceea073a1b@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Doesn't it work to have string literals be of type `(# Int#, Addr# #)` (see comment:38)? The unboxed tuple will be passed as two arguments, but in Core you can name the unboxed tuple and pass it around as a single entity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 08:25:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 08:25:25 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.4f5f835504ccda26bea9f47343427548@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): Wouldn't that generate something like {{{unpackCString# (# 3#, "abc"# #)}}} for {{{"abc"}}}? And if I just typed "abc" in ghci, wouldn't it fail as ghci can not handle unboxed tuples? Beside from that, it should work, but then I could also just try to change {{{unpackCString#}}} to have type {{{Addr# -> Int# -> [Char]}}}, avoiding the tuple. This would of course break backwards compatibility, as would an unboxed tuple, and I wanted to see if I could avoid that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 08:32:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 08:32:56 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.baee023b62569818d32207252dd5b40e@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The Unarise pass removes unboxed tuple binders and arguments, so it would be passed as two separate arguments. However, unarise is currently part of SimplStg, so GHCi doesn't get to take advantage of it, I don't know how hard that is to change. Maybe @osa1 or @simonpj would know. Backwards compatibility is a separate issue, we can always introduce new APIs instead of breaking old ones, I doubt there are serious problems here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 08:33:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 08:33:27 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.47e46b5b20829af624bb4769ff45a4b8@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 11:04:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 11:04:13 -0000 Subject: [GHC] #12451: TemplateHaskell and Data.Typeable - tcIfaceGlobal (local): not found Message-ID: <047.1d9361812b982e579fc60f1fc0d6ed94@haskell.org> #12451: TemplateHaskell and Data.Typeable - tcIfaceGlobal (local): not found -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TemplateHaskell, Typeable | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code produces an ghc panic error: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE ScopedTypeVariables #-} module TH where import Language.Haskell.TH import Language.Haskell.TH.Syntax import Data.Typeable usingType :: forall a. Typeable a => a -> Q [Dec] usingType _ = do -- Try to get anything using typeRep. let name = (tyConName $ typeRepTyCon $ typeRep (Proxy :: Proxy a)) `seq` "The name!" -- theF = "The name!" return [FunD (mkName "theF") [Clause [] (NormalB $ LitE $ StringL name ) []]] }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Main where import TH data A = A Int -- Changing the argument to (A 3) does not help. $(usingType (undefined :: A)) main = putStrLn $ theF }}} The error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: $tcA [r5m0 :-> Type constructor ‘A’, r5m3 :-> Data constructor ‘A’, r5m9 :-> Identifier ‘A’] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 11:16:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 11:16:43 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.4685e6cad542dcb42069b588d30443c8@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I didn't follow the whole thread but yeah, if you want to compile string literals to unboxed tuples (`(# len, ptr #)`) it'd be a problem for GHCi as the bytecode interpreter/compiler can't handle unboxed tuple returns. (it has some special cases for handling primops that return state tokens in an unboxed tuple) We had briefly discussed doing bytecode generation after unarise in the mailing list (https://mail.haskell.org/pipermail/ghc- devs/2016-July/012502.html see Simon's response). I don't understand native calling conventions good enough to comment, but maybe we can add one more special case in the bytecode compiler to handle `(# len, ptr #)` returns, like the special cases for returning `(# RealWorld#, a #)` etc. (search for `isUnboxedTupleCon` in `ByteCodeGen.hs`) I'm willing to work on extending unboxed tuple support in the bytecode interpreter, but I don't have any concrete proposals right now -- I need to study native calling conventions for returning tuples first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 11:45:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 11:45:25 -0000 Subject: [GHC] #12452: TemplateHaskell - variables in top level splices and loading modules. Message-ID: <047.4bfcfbe0129fd7dc7c290b050460ebc2@haskell.org> #12452: TemplateHaskell - variables in top level splices and loading modules. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux TemplateHaskell | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code fails when loading Main module: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE ScopedTypeVariables #-} module TH where import Language.Haskell.TH import Language.Haskell.TH.Syntax import Data.Typeable usingType :: a -> Q [Dec] usingType _ = do let name = "The name!" -- theF = "The name!" return [FunD (mkName "theF") [Clause [] (NormalB $ LitE $ StringL name ) []]] }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Main where import TH data A = A Int -- Runs with `usingType (undefined :: A)` instead $(usingType (A 3) ) main = putStrLn $ theF }}} The error: {{{ $ ghc --make Main.hs [1 of 2] Compiling TH ( TH.hs, TH.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) attempting to use module ‘Main’ (Main.hs) which is not loaded }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 14:06:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 14:06:43 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.1431f447908b3d9775b2e5d2992eb123@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): After switching to {{{(# Int#, Addr# #)}}}, I have a sort-of working implementation. The builtin rules seem to work, rewriting string literals from user-code works and has access to the length, but ghci wouldn't even start up. Maybe I can take a look this evening into it, but if I understand unboxed tuples correctly, it should be possible to just flatten them if they appear in an argument position, right? E.g. turn {{{ foo (# a, b, c #) }}} into {{{ foo a b c }}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 14:24:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 14:24:49 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.4922b1597632722b554ff5c582752700@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > E.g. turn foo (# a, b, c #) into foo a b c Yes. That's the easy part (see `RepType.repType`), the problem is returning tuples, it needs support from the code generator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 14:55:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 14:55:31 -0000 Subject: [GHC] #12451: TemplateHaskell and Data.Typeable - tcIfaceGlobal (local): not found In-Reply-To: <047.1d9361812b982e579fc60f1fc0d6ed94@haskell.org> References: <047.1d9361812b982e579fc60f1fc0d6ed94@haskell.org> Message-ID: <062.2421ca81359bb6d5c8e238650b068b83@haskell.org> #12451: TemplateHaskell and Data.Typeable - tcIfaceGlobal (local): not found -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: | TemplateHaskell, Typeable Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell Comment: Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 14:58:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 14:58:36 -0000 Subject: [GHC] #12452: TemplateHaskell - variables in top level splices and loading modules. In-Reply-To: <047.4bfcfbe0129fd7dc7c290b050460ebc2@haskell.org> References: <047.4bfcfbe0129fd7dc7c290b050460ebc2@haskell.org> Message-ID: <062.8a733e173f1790ed9e5219ebaad09ada@haskell.org> #12452: TemplateHaskell - variables in top level splices and loading modules. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: | TemplateHaskell Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 16:47:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 16:47:14 -0000 Subject: [GHC] #10626: Missed opportunity for SpecConstr In-Reply-To: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> References: <046.2ec00fd6c7f1ac3b0945088bcbe8d910@haskell.org> Message-ID: <061.9912e68292fe51cd02933763959bde14@haskell.org> #10626: Missed opportunity for SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: nomeata, bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 16:53:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 16:53:58 -0000 Subject: [GHC] #2333: Emit a warning if an INLINE function is a loop breaker In-Reply-To: <046.23407b4f66367aefddc60efec387ceb9@haskell.org> References: <046.23407b4f66367aefddc60efec387ceb9@haskell.org> Message-ID: <061.a40441dedf7d6eb110a5b7fd502a88d2@haskell.org> #2333: Emit a warning if an INLINE function is a loop breaker -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: We have done this for a very long time now. In fact there are even tickets about these warnings (#9418). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 17:37:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 17:37:07 -0000 Subject: [GHC] #9418: Warnings about "INLINE binder is (non-rule) loop breaker" In-Reply-To: <046.872466a3116fcd1a2415e5a6fb1d5342@haskell.org> References: <046.872466a3116fcd1a2415e5a6fb1d5342@haskell.org> Message-ID: <061.41492f0c46e267cfe8054dd0e067f543@haskell.org> #9418: Warnings about "INLINE binder is (non-rule) loop breaker" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #12137, #3073 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: #12137 => #12137, #3073 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 19:21:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 19:21:02 -0000 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@haskell.org> Message-ID: <059.b445ca71a0137e39e715c609cf88568a@haskell.org> #1475: Adding imports and exports with Template Haskell -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomasjm): Replying to [comment:19 SimonHengel]: > Just because I've been pushing for this in the past, I solved my use case in a different way. > > For me closing this as won't fix would be ok. @SimonHengel, I'd like to do the same use case of generating test imports automatically. Could you describe how you solved the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 21:46:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 21:46:36 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.7a8507a38b7cc5c083a71a57dab3725a@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): It seems to work. I added a pass before generating byte-code which transforms the unboxed tuples and now ghci works again. I am validating right now, but stage2 was working, so this should pass, too. So to let you review my changes, I have to ask: Should I include changes made to submodules or just include the changes to GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 2 22:20:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Aug 2016 22:20:41 -0000 Subject: [GHC] #12088: Promote data family instance constructors In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.dd33d413384e91a2ef3cdccbe1185aef@haskell.org> #12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: Sorry to be slow... I'm on holiday. You give a great example. The key point is that to ''kind-check'' the `data instance F Q r` declaration, we need to have completely processed the `type instance Open Q` declaration. So even instance declarations can have dependencies! I'd like Richard E's opinion on all this; hence cc'ing goldfire. To me your example raises the question of whether it's even ''possible'' to figure out the dependencies. You probably believe that your "add extra edges" does so. But I still don't know exactly what those edges are. Maybe you could take a comment in this ticket to explain your algorithm precisely? Meanwhile, here's a new hypothesis. The only instances we must have in hand to do kind-checking are `type instance`s, because they give rise to implicit nominal type/kind equalities (e.g. `F Int ~ Bool`) that the kind checker must solve. But `data instance`s are different: they do not give rise to implicit nominal type/kind equalities. So in that way they behave more like data type declarations. Indeed, I think that the only way that type/class declaration T can depend on a `data instance` declaration D is if T mentions one of D's promoted data constructors. This will be sorted out by the ordinary SCC analysis. So perhaps this small modification to my algorithm will work: in the step "Partition the `InstDecl` nodes from the `TyClDecl` nodes", instead partition the `type instance` decls from the `TyClDecl` and `data instance` decls. Then your example will work just fine, because the `type instance Open Q` will be dealt with as soon as `data Q` is done. The worry in my mind is whether you could have two `type instance` declarations, D1 and D2, where it was essential to process D1 before D2, or vice versa. I can't come up with an example, but neither can I see how to prove that there is no such example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 04:01:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 04:01:11 -0000 Subject: [GHC] #12088: Promote data family instance constructors In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.a6ad6012f86ac71fd0b93a7cde6fba0a@haskell.org> #12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexvieth): > I'd like Richard E's opinion on all this Me too. We also need to think about how a solution for this ticket would hold up under an implementation of #11962. > To me your example raises the question of whether it's even possible to figure out the dependencies. You probably believe that your "add extra edges" does so. But I still don't know exactly what those edges are. Maybe you could take a comment in this ticket to explain your algorithm precisely? After a bit of thought I came up with a simple change to my last example: {{{#!hs -- A.hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeInType #-} module A where import Data.Kind type family Open (t :: Type) :: Type data family F (t :: Type) :: Open t -> Type }}} {{{#!hs -- B.hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE GADTs #-} module B where import Data.Kind import A data Q type instance Open Q = Bool data instance F Q r where F0 :: F Q 'True }}} The difference is that the data family is defined in `A.hs` and the family `Closed` is no longer necessary, as the data family is enough to obscure the `Open` dependency. `B.hs` as given above will not pass with my approach, but swap the two instance declarations and it's fine. > So perhaps this small modification to my algorithm will work ... The modification sounds good, but I share your worry and I think we're actually in for a bit more thinking. {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UndecidableInstances #-} module A2 where import Data.Kind type family Open1 (t :: Type) :: Type type family Open2 (t :: Type) (q :: Open1 t) :: Type }}} {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE GADTs #-} module B where import Data.Kind import A2 type instance Open1 () = Bool type instance Open2 () 'True = Char }}} The instance `Open1 ()` needs to come before `Open2 () 'True` to get that `Open1 () ~ Bool`, but how are we to know this? Maybe we always check smaller instances (fewer parameters) before bigger ones? > Sorry to be slow... I'm on holiday. No problem, enjoy it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 07:07:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 07:07:49 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.36824480c446f61848c17bab5f904568@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2430 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"988ad8ba8e709eff3cea59728e481bb269fa6185/ghc" 988ad8ba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="988ad8ba8e709eff3cea59728e481bb269fa6185" Fix to thread migration Summary: If we had 2 threads on the run queue, say [A,B], and B is bound to the current Task, then we would fail to migrate any threads. This fixes it so that we would migrate A in that case. This will help parallelism a bit in programs that have lots of bound threads. Test Plan: Test program in #12419, which is actually not a great program but it does behave a bit better after this change. Reviewers: ezyang, niteria, bgamari, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2430 GHC Trac Issues: #12419 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 07:10:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 07:10:45 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.13a08d2295c4b3d8f572cc938bc14292@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2430 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge Comment: This also depends on https://phabricator.haskell.org/rGHC55f5aed756cd5d464942dddcb33e0bd19b05f2a4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 07:19:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 07:19:03 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.95e19ec5965aafb7f38216ebdb6a624e@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): We'll need to think about how we want to do this for GHCi. I presume we can't do unarise on Core because it can't generate type-correct Core, right @osa1? It seems like a lot of trouble to have a whole pass just for strings in GHCi, especially since it overlaps with what unarise does. Perhaps it could be handled in the byte code generator directly? Anyway, feel free to put your patch up on Phabricator for review. If it depends on submodule changes, I believe the right way to handle those is to fork the submodule on github and make the `.gitmodule` file point to your fork, at least while the patch is in review, and then when pushing, revert the `.gitmodules` changes and push to the upstream submodules first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 08:16:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 08:16:49 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.63c5c61b9507a5e3387215d017fd1e97@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I believe pre-unboxed-sums unarise pass could be made type-safe (I actually had a patch that moved unarise pass to Core and I don't recall any type safety issues), but now that we have sums moving unarise to Core means adding `unsafeCoerce#`s everywhere. One of my initial unboxed sums patches was doing that, but no one liked it (SPJ reviewed it on Phab) because of `unsafeCoerce#`s in Core. So yeah unarise can't be made type safe without `unsafeCoerce#`s at the moment, it needs to stay as a STG pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 09:19:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 09:19:59 -0000 Subject: [GHC] #5972: option to suppress (Monomorphic) record selector functions In-Reply-To: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> References: <043.27a8993b6ebd13b3ba62e973b8e38730@haskell.org> Message-ID: <058.3f04fd9c491e671df7b7976f2a780acc@haskell.org> #5972: option to suppress (Monomorphic) record selector functions -------------------------------------+------------------------------------- Reporter: AntC | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: records Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 09:24:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 09:24:52 -0000 Subject: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper In-Reply-To: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> References: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> Message-ID: <059.f88af0800978ad0a2eb4f539bf6c0521@haskell.org> #5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 10:14:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 10:14:55 -0000 Subject: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper In-Reply-To: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> References: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> Message-ID: <059.f9be2425f3ef787fd8231669dfe08e7c@haskell.org> #5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 11:04:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 11:04:16 -0000 Subject: [GHC] #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm In-Reply-To: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> References: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> Message-ID: <059.d34fb273add1d8ea8340bac9dd126faa@haskell.org> #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): On my Debian system, the symbol `__udivti3` seems to be provided by `/lib/x86_64-linux-gnu/libgcc_s.so.1` Easiest way to trigger the problem is to build with `BuildFlavour = perf- llvm` and then run: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20160802: http://www.haskell.org/ghc/ :? for help ghc-stage2: /home/erikd/Git/ghc-upstream/libraries/ghc-prim/dist- install/build/HSghc-prim-0.5.0.0.o: unknown symbol `__udivti3' ghc-stage2: unable to load package `ghc-prim-0.5.0.0' }}} Not sure how to add this to the build system, but I was able to hack something together to test using the following steps. * Full build with `BuildFlavour = perf-llvm`. * Edit `ghc/stage2/package-data.mk` and add `gcc_s` to the `ghc_stage2_DEP_EXTRA_LIBS` line. * Edit `mk/build.mk` and uncomment `stage=2` so we only build the stage 2 compiler. * `touch compiler/main/GHC.hs` to force a rebuild. * Run `make`. Now when I run `inplace/bin/ghc-stage2 --interactive` it works correctly. @thomie Any idea on how this could be fixed in the build system? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 11:15:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 11:15:11 -0000 Subject: [GHC] #12453: Remove setUnfoldingInfoLazily Message-ID: <049.1cffcb49ca141ffeffcdf735b038e5ed@haskell.org> #12453: Remove setUnfoldingInfoLazily -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The definition of `setUnfoldingInfoLazily` is exactly the same as `setUnfoldingInfo` and is only used in one place, `TcInterface`. They were made equivalent in 2010 in 2ff2497dc374175b8ed81446258baf208d1f3e6e with the commit message. {{{ commit 2ff2497dc374175b8ed81446258baf208d1f3e6e Author: Ian Lynagh Wed Oct 20 15:37:10 2010 Committer: Ian Lynagh Wed Oct 20 15:37:10 2010 Original File: compiler/basicTypes/IdInfo.lhs Don't seq unfoldings We generate intermediate unfoldings which are just thrown away, so evaluating them is a waste of time. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:30:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:30:27 -0000 Subject: [GHC] #4960: Better inlining test in CoreUnfold In-Reply-To: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> References: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> Message-ID: <061.35ffdd0b37c545471898db991c6182fa@haskell.org> #4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer Comment: Seems well specified and unimplemented currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:31:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:31:39 -0000 Subject: [GHC] #3781: Improve inlining for local functions In-Reply-To: <046.7e7e45262f788675411974bac0244395@haskell.org> References: <046.7e7e45262f788675411974bac0244395@haskell.org> Message-ID: <061.9c80bec8affe46d1091dd42372be2eed@haskell.org> #3781: Improve inlining for local functions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:31:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:31:44 -0000 Subject: [GHC] #3755: Improve join point inlining In-Reply-To: <046.29f65772931b3d82df31cb86d07a2ef5@haskell.org> References: <046.29f65772931b3d82df31cb86d07a2ef5@haskell.org> Message-ID: <061.6eeb59e42f2377bf17da74b400203735@haskell.org> #3755: Improve join point inlining -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.12.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:31:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:31:56 -0000 Subject: [GHC] #7511: Room for GHC runtime improvement >~5%, inlining related In-Reply-To: <046.27ace21e269a814078afb7c9e46089a8@haskell.org> References: <046.27ace21e269a814078afb7c9e46089a8@haskell.org> Message-ID: <061.b44f7a97756ed9bd456f8a30c7404551@haskell.org> #7511: Room for GHC runtime improvement >~5%, inlining related -------------------------------------+------------------------------------- Reporter: danielv | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:32:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:32:23 -0000 Subject: [GHC] #3073: Avoid reconstructing dictionaries in recursive instance methods In-Reply-To: <046.cb32dbba432b9228a1ce1c087df10ff6@haskell.org> References: <046.cb32dbba432b9228a1ce1c087df10ff6@haskell.org> Message-ID: <061.2671133d57622ccc84c91564be9644bd@haskell.org> #3073: Avoid reconstructing dictionaries in recursive instance methods -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:33:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:33:54 -0000 Subject: [GHC] #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) In-Reply-To: <044.a125e44de5957e50d259dfbe1a2d51e0@haskell.org> References: <044.a125e44de5957e50d259dfbe1a2d51e0@haskell.org> Message-ID: <059.c082b1f58d9ff3ac01605cfb9fe79a8e@haskell.org> #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => invalid Comment: I'm going to close this as it isn't exactly clear what the suggestion is. Currently recursive definitions can be inlined but loop breakers are not inlined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:34:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:34:10 -0000 Subject: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper In-Reply-To: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> References: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> Message-ID: <059.621ba3d609dd5e55723b4bf13296346a@haskell.org> #5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:35:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:35:35 -0000 Subject: [GHC] #4960: Better inlining test in CoreUnfold In-Reply-To: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> References: <046.cec683217356c2475640d9dd14bf88ce@haskell.org> Message-ID: <061.d84254dcfe2fa685e4e3bdf9dfa40413@haskell.org> #4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: newcomer => newcomer, Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:49:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:49:11 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.2c0cb790a20dea74b2c3c3371689d44f@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:50:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:50:18 -0000 Subject: [GHC] #12274: GHC panic: simplifier ticks exhausted In-Reply-To: <045.2b6954bdf1af859f773f3b4e8826a3f4@haskell.org> References: <045.2b6954bdf1af859f773f3b4e8826a3f4@haskell.org> Message-ID: <060.b57c74ec726a1e9c9828918075ff5075@haskell.org> #12274: GHC panic: simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:55:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:55:22 -0000 Subject: [GHC] #11791: Remove the `isInlinePragma prag` test In-Reply-To: <046.e1b8da45884d1bb5e6fabdc8ea65e302@haskell.org> References: <046.e1b8da45884d1bb5e6fabdc8ea65e302@haskell.org> Message-ID: <061.c36e3db5c65f1e8e7429a4cb08c054b1@haskell.org> #11791: Remove the `isInlinePragma prag` test -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11781, #5928 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer, Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:55:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:55:28 -0000 Subject: [GHC] #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) In-Reply-To: <044.a125e44de5957e50d259dfbe1a2d51e0@haskell.org> References: <044.a125e44de5957e50d259dfbe1a2d51e0@haskell.org> Message-ID: <059.43b350366afa24ff58a692c4c13673c4@haskell.org> #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.11 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -19,1 +19,1 @@ - More details, examples, and an informal spec: wiki:Inlining + More details, examples, and an informal spec: wiki:OldInlining New description: Inlining refers to the unfolding of definitions, ie replacing uses of identifiers with the definitions bound to them. Doing this at compile time can expose potential for other optimizations. As described in the User Guide, this is currently limited to non-recursive definitions, to avoid non-terminating recursion in the inliner. Unfolding Recursions Since many definitions in non-trivial programs are either recursive themselves or are built from recursion combinators, leaving recursion out of inlining alltogether is a serious limitation, especially in view of the encoding of loops via tail recursion. In conventional languages, loop transformations such as loop unrolling are at the heart of optimizing high performance code (for a useful overview, see Compiler Transformations for High-Performance Computing, ACM Computing Surveys, 1994). As a consequence, many performance-critical Haskell programs contain hand- unrolled and hand-peeled recursions, which is error-prone and obscures declarative contents. More details, examples, and an informal spec: wiki:OldInlining -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:56:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:56:57 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.8d01656f090d1c19430ea4704782c7a7@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1900 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:57:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:57:56 -0000 Subject: [GHC] #7109: Inlining depends on datatype size, even with INLINE pragmas In-Reply-To: <046.d7688d63b8d11652e4d6ca8d86579926@haskell.org> References: <046.d7688d63b8d11652e4d6ca8d86579926@haskell.org> Message-ID: <061.2e0b15d0846ac7765c492039859a34b5@haskell.org> #7109: Inlining depends on datatype size, even with INLINE pragmas -------------------------------------+------------------------------------- Reporter: dreixel | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 13:58:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 13:58:27 -0000 Subject: [GHC] #7114: Cannot recover (good) inlining behaviour from 7.0.2 in 7.4.1 In-Reply-To: <046.fae9ca2bbb58d7bf9387efb9e72b692a@haskell.org> References: <046.fae9ca2bbb58d7bf9387efb9e72b692a@haskell.org> Message-ID: <061.8a130d0be13e457b33e87236013c55c5@haskell.org> #7114: Cannot recover (good) inlining behaviour from 7.0.2 in 7.4.1 -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 14:01:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 14:01:25 -0000 Subject: [GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 In-Reply-To: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> References: <048.40c26b7b4284fbfbecf1a612dcab9f75@haskell.org> Message-ID: <063.79155a1844fa2d4e2c9695b88262fa90@haskell.org> #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10527 #5539 | Differential Rev(s): #8319 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 14:02:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 14:02:24 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.73a7cb238f3c584395db3fb4ade377b3@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 14:04:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 14:04:32 -0000 Subject: [GHC] #11068: Make Generic/Generic1 methods inlinable In-Reply-To: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> References: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> Message-ID: <059.c10d0edea0f6d01291b928c8ceab26cd@haskell.org> #11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Generics, | newcomer, Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: Generics => Generics, newcomer, Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 14:07:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 14:07:28 -0000 Subject: [GHC] #11068: Make Generic/Generic1 methods inlinable In-Reply-To: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> References: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> Message-ID: <059.977be795dd6ea2181149c550cc80919d@haskell.org> #11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Generics, | newcomer, Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1447 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): mpickering, you marked this as newcomer, but I'm not sure how easy this is to get right. glguy already tried to fix this with https://phabricator.haskell.org/D1447, but we remarked in comment:5 that he "was struggling to reproduce that the change fixed anything". glguy, what exactly did you mean by this? I think some clarification on what the challenge here is would be needed before someone tries to dive in on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 14:56:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 14:56:05 -0000 Subject: [GHC] #12454: Cross-module specialisation of recursive functions Message-ID: <049.c024fa407a83e5fa89afe16591ed10e0@haskell.org> #12454: Cross-module specialisation of recursive functions -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Inlining | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #5928 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is common for library authors to write overloaded functions but in doing so they cause a performance penalty for their consumers as GHC refuses the specialise such functions across modules. For example, {{{#!hs {-# language FlexibleContexts #-} module M where import Control.Monad.IO.Class import Control.Monad.Reader hello :: (MonadIO m, MonadReader Int m) => Int -> m () hello n = do m <- ask case m `mod` n == 0 of True -> liftIO $ print "helloo" False -> hello (n-1) }}} Using `hello` in a client module, we would like to optimise away the explicit dictionary passing once we specialise `hello` to a specific monad stack. {{{#!hs import M import Control.Monad.Reader import M (hello) main :: IO () main = runReaderT (hello 128) 42 }}} However, as `hello` is recursive its unfolding was not included in the interface file. As a result, the specialisation can't take place which leaves us with less efficient code. The solution to this is mark `hello` as `INLINABLE`. Once we do this the unfolding of `hello` is included in the interface file even though `hello` will never be inlined as it is self-recursive and hence the loop-breaker. Once included in the interface file, GHC can properly specialise `hello` and produce optimal code. An aside, it is quite strange to mark such a recursive definition as `INLINABLE` to get this behaviour as you know it will never be inlined. It would perhaps be better to have a better named pragma which ensured unfoldings were placed in interface files. This ticket is to track the behaviour of these types of definitions which are very common in the wild. A proposed solution on #5928 was to add a flag to always mark overloaded functions as inlinable to make sure these specialisations can take place. This is something which I am planning to implement in order to see what the consequences are in terms of performance and interface file sizes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 14:56:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 14:56:39 -0000 Subject: [GHC] #12454: Cross-module specialisation of recursive functions In-Reply-To: <049.c024fa407a83e5fa89afe16591ed10e0@haskell.org> References: <049.c024fa407a83e5fa89afe16591ed10e0@haskell.org> Message-ID: <064.197b88828f14f3f2bd344c2d7a6cf194@haskell.org> #12454: Cross-module specialisation of recursive functions -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5928 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * Attachment "opt.txt" added. Core when marking hello as inlinable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 14:56:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 14:56:58 -0000 Subject: [GHC] #12454: Cross-module specialisation of recursive functions In-Reply-To: <049.c024fa407a83e5fa89afe16591ed10e0@haskell.org> References: <049.c024fa407a83e5fa89afe16591ed10e0@haskell.org> Message-ID: <064.067eb066f57be05a041c67140d5e6b42@haskell.org> #12454: Cross-module specialisation of recursive functions -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5928 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * Attachment "unopt.txt" added. Core when not marking hello as inlinable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 14:58:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 14:58:19 -0000 Subject: [GHC] #12454: Cross-module specialisation of recursive functions In-Reply-To: <049.c024fa407a83e5fa89afe16591ed10e0@haskell.org> References: <049.c024fa407a83e5fa89afe16591ed10e0@haskell.org> Message-ID: <064.d336f9771b8a94a314bd73b8fda2c5a1@haskell.org> #12454: Cross-module specialisation of recursive functions -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5928 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mpickering: @@ -52,0 +52,7 @@ + The two attached files contain the core for these two programs. They were + compiled with + + {{{ + ghc-8.0.1 -fforce-recomp -ddump-simpl -O2 mtl-stack.hs + }}} + New description: It is common for library authors to write overloaded functions but in doing so they cause a performance penalty for their consumers as GHC refuses the specialise such functions across modules. For example, {{{#!hs {-# language FlexibleContexts #-} module M where import Control.Monad.IO.Class import Control.Monad.Reader hello :: (MonadIO m, MonadReader Int m) => Int -> m () hello n = do m <- ask case m `mod` n == 0 of True -> liftIO $ print "helloo" False -> hello (n-1) }}} Using `hello` in a client module, we would like to optimise away the explicit dictionary passing once we specialise `hello` to a specific monad stack. {{{#!hs import M import Control.Monad.Reader import M (hello) main :: IO () main = runReaderT (hello 128) 42 }}} However, as `hello` is recursive its unfolding was not included in the interface file. As a result, the specialisation can't take place which leaves us with less efficient code. The solution to this is mark `hello` as `INLINABLE`. Once we do this the unfolding of `hello` is included in the interface file even though `hello` will never be inlined as it is self-recursive and hence the loop-breaker. Once included in the interface file, GHC can properly specialise `hello` and produce optimal code. An aside, it is quite strange to mark such a recursive definition as `INLINABLE` to get this behaviour as you know it will never be inlined. It would perhaps be better to have a better named pragma which ensured unfoldings were placed in interface files. The two attached files contain the core for these two programs. They were compiled with {{{ ghc-8.0.1 -fforce-recomp -ddump-simpl -O2 mtl-stack.hs }}} This ticket is to track the behaviour of these types of definitions which are very common in the wild. A proposed solution on #5928 was to add a flag to always mark overloaded functions as inlinable to make sure these specialisations can take place. This is something which I am planning to implement in order to see what the consequences are in terms of performance and interface file sizes. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 15:00:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 15:00:06 -0000 Subject: [GHC] #12453: Remove setUnfoldingInfoLazily In-Reply-To: <049.1cffcb49ca141ffeffcdf735b038e5ed@haskell.org> References: <049.1cffcb49ca141ffeffcdf735b038e5ed@haskell.org> Message-ID: <064.015002f620314c58eddd2812c154642d@haskell.org> #12453: Remove setUnfoldingInfoLazily -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"7a8ef01920731f0afa45f3589fcb4a89d5eb125c/ghc" 7a8ef01/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7a8ef01920731f0afa45f3589fcb4a89d5eb125c" Remove `setUnfoldingInfoLazily` The definition of `setUnfoldingInfoLazily` is exactly the same as `setUnfoldingInfo` and is only used in one place, `TcIface`. They were made equivalent in 2010 in 2ff2497dc374175b8ed81446258baf208d1f3e6e with the commit message. {{{ commit 2ff2497dc374175b8ed81446258baf208d1f3e6e Author: Ian Lynagh Wed Oct 20 15:37:10 2010 Committer: Ian Lynagh Wed Oct 20 15:37:10 2010 Original File: compiler/basicTypes/IdInfo.lhs Don't seq unfoldings We generate intermediate unfoldings which are just thrown away, so evaluating them is a waste of time. }}} Closes #12453 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 15:00:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 15:00:33 -0000 Subject: [GHC] #12453: Remove setUnfoldingInfoLazily In-Reply-To: <049.1cffcb49ca141ffeffcdf735b038e5ed@haskell.org> References: <049.1cffcb49ca141ffeffcdf735b038e5ed@haskell.org> Message-ID: <064.3733d5b35f14db8357794b39e02f33f2@haskell.org> #12453: Remove setUnfoldingInfoLazily -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 15:21:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 15:21:24 -0000 Subject: [GHC] #12073: Missing instance of MonadFix for Q In-Reply-To: <046.40bbc19dbb6e691647fd4beba8f8097c@haskell.org> References: <046.40bbc19dbb6e691647fd4beba8f8097c@haskell.org> Message-ID: <061.44d33ad3ee6596557d2d0ad9ea8acba1@haskell.org> #12073: Missing instance of MonadFix for Q -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I have no knowledge of whether this implementation is correct, although it certainly looks plausible. As the TH czar, I'm happy to accept this instance from a design point of view. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 15:23:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 15:23:46 -0000 Subject: [GHC] #12178: Allow inline pragmas on pattern synonyms In-Reply-To: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> References: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> Message-ID: <064.4e7af634554443f800693defa5638973@haskell.org> #12178: Allow inline pragmas on pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 15:32:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 15:32:45 -0000 Subject: [GHC] #12178: Allow inline pragmas on pattern synonyms In-Reply-To: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> References: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> Message-ID: <064.8344e562c9af493a4234b4451ad9ad7d@haskell.org> #12178: Allow inline pragmas on pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * cc: bgamari (added) Comment: Bumping the importance of this since you really should be able to use pattern synonyms in a manner without compromising performance. I agree that a simple `INLINE P` pragma should inline both the matcher and the builder. Indeed we could expose `INLINE_MATCHER` and `INLINE_BUILDER` variants as well, although I am doubtful that they would pull their weight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 15:40:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 15:40:49 -0000 Subject: [GHC] #12178: Allow inline pragmas on pattern synonyms In-Reply-To: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> References: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> Message-ID: <064.a37ef26cbf1c1c0870151df3bfa51ad4@haskell.org> #12178: Allow inline pragmas on pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I hate to say it, but I feel confident someone will want the finer control here. But I suppose there would be no barrier to implementing the finer control later and so we should start with the simpler version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 16:05:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 16:05:04 -0000 Subject: [GHC] #12455: Compact Regions Message-ID: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> #12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm going to use this task to keep track of what we still need to do around compact regions before 8.2.1, and so I have somewhere to hang diffs. Here's the current ToDo list: * compaction should be interruptible by GC, otherwise we block a multithreaded program while compacting (I know how to do this and have a prototype, just need to finish it). * Make it work with profiling * We should have an API that doesn't require specifying a size, just `compact :: NFData a => a -> IO (Compact a)` * libraries/compact/tests failures with `EXTRA_HC_OPTS="-debug -with- rtsopts=-DS"` * Do we need both `totalW` and `totalDataW`? It looks like one of them is redundant to me. * What happens if we try to compact something that refers to a large block? One larger than a megablock? * Improve comments -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 16:18:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 16:18:32 -0000 Subject: [GHC] #12455: Compact Regions In-Reply-To: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> References: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> Message-ID: <062.66a48e17c1da7a0a5719730653260d36@haskell.org> #12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonmar: @@ -14,1 +14,1 @@ - rtsopts=-DS"` + rtsopts=-DS"` (I think this is the static object problem, see below) @@ -19,1 +19,7 @@ - * Improve comments + * Static Objects: currently compaction copies static objects into the + compact. This violates some invariants (_STATIC objects should not be on + the heap), but is important because we would otherwise have pointers from + compacts to static objects that would need to be followed during GC, in + order to find CAFs. I don't like this at all. + + And in general, improve the comments. New description: I'm going to use this task to keep track of what we still need to do around compact regions before 8.2.1, and so I have somewhere to hang diffs. Here's the current ToDo list: * compaction should be interruptible by GC, otherwise we block a multithreaded program while compacting (I know how to do this and have a prototype, just need to finish it). * Make it work with profiling * We should have an API that doesn't require specifying a size, just `compact :: NFData a => a -> IO (Compact a)` * libraries/compact/tests failures with `EXTRA_HC_OPTS="-debug -with- rtsopts=-DS"` (I think this is the static object problem, see below) * Do we need both `totalW` and `totalDataW`? It looks like one of them is redundant to me. * What happens if we try to compact something that refers to a large block? One larger than a megablock? * Static Objects: currently compaction copies static objects into the compact. This violates some invariants (_STATIC objects should not be on the heap), but is important because we would otherwise have pointers from compacts to static objects that would need to be followed during GC, in order to find CAFs. I don't like this at all. And in general, improve the comments. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 16:30:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 16:30:49 -0000 Subject: [GHC] #10766: user manual: INLINE's interaction with optimization levels is not clear In-Reply-To: <043.95e7d1c8fa07ad8573df841b0fc2eccf@haskell.org> References: <043.95e7d1c8fa07ad8573df841b0fc2eccf@haskell.org> Message-ID: <058.555778f206e83648fe1162f108a576be@haskell.org> #10766: user manual: INLINE's interaction with optimization levels is not clear -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 16:32:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 16:32:01 -0000 Subject: [GHC] #10710: More self-explanatory pragmas for inlining phase control In-Reply-To: <046.f56ee656c180387739bfbd9da62ea521@haskell.org> References: <046.f56ee656c180387739bfbd9da62ea521@haskell.org> Message-ID: <061.4ecf0f5a1769f86f020102901266865d@haskell.org> #10710: More self-explanatory pragmas for inlining phase control -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 16:33:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 16:33:58 -0000 Subject: [GHC] #10421: exponential blowup in inlining (without INLINE pragmas) In-Reply-To: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> References: <047.3eae2ebffed9a4a3ca74833c7f8bcec3@haskell.org> Message-ID: <062.da25c4a4dae577002c35d592b7c8ac40@haskell.org> #10421: exponential blowup in inlining (without INLINE pragmas) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 16:35:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 16:35:22 -0000 Subject: [GHC] #10371: GHC fails to inline and specialize a function In-Reply-To: <050.00603e7cdfd7583d3908a8e6d41ce4f9@haskell.org> References: <050.00603e7cdfd7583d3908a8e6d41ce4f9@haskell.org> Message-ID: <065.2f125cd358ab66df842b4d41fa64ec73@haskell.org> #10371: GHC fails to inline and specialize a function -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8668 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 16:37:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 16:37:08 -0000 Subject: [GHC] #9798: Frustrating behaviour of the INLINE pragma In-Reply-To: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> References: <047.03fcc8543b545bdba8b772bab7be3a3b@haskell.org> Message-ID: <062.b0601a4448f7052604db1db3a3d2b790@haskell.org> #9798: Frustrating behaviour of the INLINE pragma -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 16:38:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 16:38:08 -0000 Subject: [GHC] #9701: GADTs not specialized properly In-Reply-To: <045.92cfd361991e24d797a63e834e046545@haskell.org> References: <045.92cfd361991e24d797a63e834e046545@haskell.org> Message-ID: <060.678f07cecd450f33bf596369c9bca276@haskell.org> #9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: GADTs, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: GADTs => GADTs, Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 16:38:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 16:38:59 -0000 Subject: [GHC] #9418: Warnings about "INLINE binder is (non-rule) loop breaker" In-Reply-To: <046.872466a3116fcd1a2415e5a6fb1d5342@haskell.org> References: <046.872466a3116fcd1a2415e5a6fb1d5342@haskell.org> Message-ID: <061.57065f7e384908f6b2e28286934bf88f@haskell.org> #9418: Warnings about "INLINE binder is (non-rule) loop breaker" -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #12137, #3073 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 16:41:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 16:41:24 -0000 Subject: [GHC] #9320: Inlining regression/strangeness in 7.8 In-Reply-To: <044.93d9094a260d4e54544e3180a10496bb@haskell.org> References: <044.93d9094a260d4e54544e3180a10496bb@haskell.org> Message-ID: <059.15be23cfc5d993455a99784d955f15bb@haskell.org> #9320: Inlining regression/strangeness in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 16:53:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 16:53:20 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.b7ee8f2991966b5175ae6dfa2c4ff798@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @osa1: this is still failing, any chance you could take a look plesae? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 17:13:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 17:13:45 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.8756f48f2c1643600a189d5bb0370653@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Yes, I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 18:07:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 18:07:37 -0000 Subject: [GHC] #12073: Missing instance of MonadFix for Q In-Reply-To: <046.40bbc19dbb6e691647fd4beba8f8097c@haskell.org> References: <046.40bbc19dbb6e691647fd4beba8f8097c@haskell.org> Message-ID: <061.2b02132d0e007a3d8d86ddad12f053cc@haskell.org> #12073: Missing instance of MonadFix for Q -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): This looks reasonable to me. It acts like IO. I suppose any manually constructed infinite terms it might allow are entirely on the user's head anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 19:09:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 19:09:13 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.7ee7e1dc7e421771433c2051cbe36d7c@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I build 714bebf ("Implement unboxed sums") and it's parent commit. Here's the difference: {{{ - Parser allocates the same amount - Renamer/typechecker allocates +0.281 mb - Desugar allocates -0.006 mb - Simplifier allocates +0.093 mb - CoreTidy allocates +0.010 mb - CorePrep allocates +0.001 mb - CodeGen allocates -0.647 mb }}} overall it should allocate less, and we can see it in the RTS output. This is the output from the parent: ("bytes allocated", "786881504") This is from "implement unboxed sums": ("bytes allocated", "786256984") This is 624,520 less. But max_bytes_used is increased: ("max_bytes_used", "16536648") to ("max_bytes_used", "17697744") Difference: +1,161,096 So it seems like allocation-wise this is better but maybe GC is running at different times, and causing residence to increase? I'm not sure how to interpret this. Allocation is reduced so maybe this is a good thing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 19:31:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 19:31:34 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.6ad867cf62b8ad3efa93f72becba5b8c@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I also compared "Implement unboxed sums" with a13fda7 (current HEAD, "Clarify comment on makeCorePair"). `bytes_allocated` is even lower now: ("bytes allocated", "786255456") to ("bytes allocated", "786244136") Difference: -11,320 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 19:38:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 19:38:08 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.7f51caf943db5cc2c4950717814d5ea3@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): See Note [residency] for how to measure max_bytes_used more accurately: https://phabricator.haskell.org/diffusion/GHC/browse/master/testsuite/tests/perf/compiler/all.T;a13fda71b02cdaa840f8040b392777272a0d7794$11 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 23:16:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 23:16:20 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.85d59fb5560471e47c2973c9ab7f83ef@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): After reading the ghc-devs discussion that decided to rename `builtin` to `bespoke`, I have a question. Is it still the case that using any other deriving strategy than `bespoke` for a class that supports `bespoke` requires using this new extension? The summary of the new system in the mailing list discussion seemed to imply not in some cases, but that could be just my misunderstanding. If not, then that could lead to confusing errors, like accidentally deriving `Functor` with anyclass because `DeriveAnyClass` is enabled but `DeriveFunctor` has been forgotten, and would probably warrant some more warnings. On the other hand, I think GND would give equivalent result to `bespoke` for many classes, so it might be convenient ''not'' to warn in those cases. E.g. when someone wants to derive `Functor`, `Applicative` and `Monad` for their monad stack newtype, it seems almost reasonable that only GND needs to be enabled, and not `DeriveFunctor`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 23:23:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 23:23:46 -0000 Subject: [GHC] #12456: Panics when making a quotation as pattern synonym Message-ID: <051.e005d068b395051143f7da213f6d0769@haskell.org> #12456: Panics when making a quotation as pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -XPatternSynonyms -XViewPatterns -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :m + Language.Haskell.TH Prelude Language.Haskell.TH> pattern A :: ExpQ; pattern A <- (undefined -> ()) where A = undefined ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): nameModule system $dIP_a4HS Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude Language.Haskell.TH> }}} should we be able to use quotations that are pattern synonyms? I have no use for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 23:36:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 23:36:18 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.a6f790c3a87244650655b20255eb3ac5@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:40 oerjan]: > Is it still the case that using any other deriving strategy than `bespoke` for a class that supports `bespoke` requires using this new extension? The short answer is: yes. The longer, more nuanced answer is that GHC sometimes picks to derive certain "standard" classes using GND when they would produce the same instance (see "The deriving strategy resolution algorithm" section of [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies this wiki page] for more info). For example, `newtype Foo = Foo Int deriving Eq` actually uses GND to derive the `Eq` instance, not the bespoke instance you'd normally get for `Eq`. Most of the time, though, if you derive a standard class without a keyword, it'll default to the `bespoke` strategy. > If not, then that could lead to confusing errors, like accidentally deriving `Functor` with anyclass because `DeriveAnyClass` is enabled but `DeriveFunctor` has been forgotten, and would probably warrant some more warnings. This is a valid concern, but luckily that doesn't happen, even with the current GHC. Currently, GHC's outlook is that `DeriveAnyClass` should //never// kick in for standard classes. As a result, if you try compiling this program: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} newtype T a = T (Maybe a) deriving Functor }}} it will error with: {{{ Can't make a derived instance of ‘Functor T’: You need DeriveFunctor to derive an instance for this class Try GeneralizedNewtypeDeriving for GHC's newtype-deriving extension In the newtype declaration for ‘T’ }}} whereas for nonstandard classes, `DeriveAnyClass` kicks in. Since none of the standard classes use `DefaultSignatures`, I think this special case is probably acceptable (and if you //really// want to derive your `Functor` instance using `DeriveAnyClass` for some bizarre reason, you'll be able to with `DerivingStrategies`). > On the other hand, I think GND would give equivalent result to `bespoke` for many classes, so it might be convenient ''not'' to warn in those cases. E.g. when someone wants to derive `Functor`, `Applicative` and `Monad` for their monad stack newtype, it seems almost reasonable that only GND needs to be enabled, and not `DeriveFunctor`. It is indeed reasonable, and GHC does sometimes choose to pick `GeneralizedNewtypeDeriving` over the `DeriveFunctor` algorithm when the last type variable can be eta-reduced (again, see [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DerivingStrategies this wiki page] for the full story). Emphatically, Phab:D2280 will not change any of this existing behavior. The only things it does are (1) fix the bug reported in the original comment and (2) give you the ability to choose explicitly which strategy to use, and hence bypass the confusing algorithm GHC uses to choose a strategy implicitly in the absence of a strategy keyword. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 3 23:37:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Aug 2016 23:37:59 -0000 Subject: [GHC] #12088: Promote data family instance constructors In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.a7fbed51c2010bc4025838f06204f704@haskell.org> #12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Excellent example! It seems clear that there is going to be no reasonable "always-right" solution to this. Moreover, here is another horrible example {{{ data T1 = MkT1 (...something requiring IA...) data T2 = MkT2 (...something requiring IB...) type instance F1 Int = ...T2... -- IA type instance F2 Int = ...T1... -- IB }}} Here F1 and F2 are supposed to be like Open1 and Open2 in your example; they must be processed in the right order. But T1 and T2 appear to be entirely independent of each other, so SCC analysis will put them in some arbitray order; and that order in turn determines which of IA and IB can be processed because IA mentions T2 and IB mentions T1. So only one ordering of the apparently un-ordered T1, T2 will work. Can you turn that sketch into a concrete example? It's even more horrible than yours because the invisible ordering of instances seems to force an equally-invisible ordering of the data declarations too. Sigh. I'm not sure what to do. The only simple, predictable thing I can think of is this: * Perform SCC analysis on each group of data/type/class/data-instance decls that lie between successive `type instance` decls. * Otherwise process the file in the order writtten, from top to bottom. That is, divide the file into segments, delimited by `type instance` decls. Process the file top-to-bottom, one segment at a time, processing the `type instance` decls in the order they are written. That's simple, easy to specify, and easy to implement. Where there are no `type instance` decls, we get full SCC analysis across the entire module. The big disadvantage is that where you have a forward reference, kind checking will just fail: {{{ data T = MkT S -- Forward reference type instance F Int = Bool data S = MkS Int }}} That is pretty bad. Can you think of an alternative rule? The goal is NOT to be as clever as possible. THe goal is to be as stupid, straightforward, and predictable as possible, even if that might mean a little manual labour on the part of the programmer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 02:40:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 02:40:24 -0000 Subject: [GHC] #12029: Notify user to import * from Data.Kind with TypeInType on In-Reply-To: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> References: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> Message-ID: <066.d455c393b940f382fbcdb743fd35dd1d@haskell.org> #12029: Notify user to import * from Data.Kind with TypeInType on -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): The "NB" was added in this patch: https://phabricator.haskell.org/D1610 I don't see a corresponding trac ticket. It seems there was some doubt as to whether this was the best course. There are actually a number of inconsistent behaviors with `*` and `★` which could be addressed. For one thing if you import `*` from Data.Kind you don't get `★` also which might be confusing since one is supposed to be the Unicode version of the other, but maybe this is okay. Another is that you do `:set -fprint-unicode-syntax` then `:k` displays kinds as `★` whereas `:i` displays kinds as `*`. The NB for `*` (it works the same way for `★`) only shows up if you have no other definition for `*` in the kind namespace. So for example if you define (with `TypeOperators`) {{{ data (f * g) e = Inl1 (f e) | Inr1 (g e) data (f ★ g) e = Inl2 (f e) | Inr2 (g e) }}} you will now get {{{ ghci> :k (*) (*) ∷ ∀ {k}. (k → ★) → (k → ★) → k → ★ ghci> :k (★) (★) ∷ ∀ {k}. (k → ★) → (k → ★) → k → ★ }}} with no mention of the missing kind `*` or `★`. If you next import them you'll get an error for an ambiguous occurrence. I suppose the NB was added to handle a very specific case in which a naive user doing nothing sophisticated was trying to find the kind of `*` and was surprised it didn't exist. Perhaps it would be equally surprising to find it not showing up with `:i`, but as this is more of a search over all uses I'd be inclined not to bother adding this special note. In addition I'd recommend dropping the NB change in 8.2 to make the behaviors consistent, since the requirement to import `*` from Data.Kind is clearly documented and people will have had time to absorb the change by then. However I'm happy to hear other opinions about either of these proposals. Finally, since `*` and `★` are both deprecated should we not be using `Type` from 8.2 onward? As in {{{ ghci> :k (*) (*) ∷ Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 02:47:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 02:47:38 -0000 Subject: [GHC] #12029: Notify user to import * from Data.Kind with TypeInType on In-Reply-To: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> References: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> Message-ID: <066.ddd099d20338ddb6f54d8b4ad5865a3b@haskell.org> #12029: Notify user to import * from Data.Kind with TypeInType on -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:1 johnleo]: > Finally, since `*` and `★` are both deprecated should we not be using `Type` from 8.2 onward? As in > {{{ > ghci> :k (*) > (*) ∷ Type > }}} That is brought up in #12030 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 02:51:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 02:51:59 -0000 Subject: [GHC] #12030: GHCi Proposal: Display (Data.Kind.)Type instead of * In-Reply-To: <051.b7378bd56fec6afa8a8403e249c2a583@haskell.org> References: <051.b7378bd56fec6afa8a8403e249c2a583@haskell.org> Message-ID: <066.647969af9a8f940460b7204bbb7d3fe0@haskell.org> #12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -16,2 +16,2 @@ - `*` throws students off and makes it seem scarier than it is. Symbols are - harder to search for in general and to understand without documentation, + `*` throws students off in my experience, makes it seem scarier than it + is. Symbols are harder to search for and understand without documentation, @@ -20,1 +20,1 @@ - There are valid arguments against displaying `Type`: + There are arguments against: @@ -22,5 +22,4 @@ - 1. It's a recent feature subject to change. - 2. Although symbols are more difficult to search for, `*` is established - in educational materials, logs, blogs and questions. - 3. By default `Type` is not in scope so a user cannot ask for information - in GHCi. + 1. It's a recent feature that is subject to change. + 2. `*` is established in questions online, educational material, logs and + blogs. + 3. `Type` is not in scope by default: user cannot query GHCi. New description: This is premature but what the darn, {{{ >>> :kind Maybe Maybe :: Type -> Type >>> :kind StateT StateT :: Type -> (Type -> Type) -> Type -> Type >>> :kind Eq Eq :: Type -> Constraint >>> :info Functor class Functor (f :: Type -> Type) where ... }}} `*` throws students off in my experience, makes it seem scarier than it is. Symbols are harder to search for and understand without documentation, `Type` on the other hand is descriptive. There are arguments against: 1. It's a recent feature that is subject to change. 2. `*` is established in questions online, educational material, logs and blogs. 3. `Type` is not in scope by default: user cannot query GHCi. `*` is established and searching for “Haskell asterisk” yields a lot resources but [https://support.google.com/websearch/answer/2466433?hl=en ‘*’ is also a wildcard] in Google and ignored by GitHub. With time `Type` would be a good search term but currently it's chicken-and-the-egg. Previous versions of GHCi error on `:kind *` and `:info *` only shows multiplication so that wouldn't be a huge difference but we can qualify by default: {{{ >>> :kind Maybe Maybe :: Data.Kind.Type -> Data.Kind.Type >>> :kind StateT StateT :: Data.Kind.Type -> (Data.Kind.Type -> Data.Kind.Type) -> Data.Kind.Type -> Data.Kind.Type >>> :kind Eq Eq :: Data.Kind.Type -> Constraint >>> :info Functor class Functor (f :: Data.Kind.Type -> Data.Kind.Type) where ... }}} or display `*` normally and only when `TypeInType` is set do we display `Type`. I don't love it (and love `GHC.Types.Type` slightly less) but there is a precedent for unqualified names, browsing the Prelude for example: {{{#!hs ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b undefined :: forall (r :: GHC.Types.RuntimeRep) (a :: TYPE r). GHC.Stack.Types.HasCallStack => a }}} __If__ the consensus is that this will happen sometime down the line consider that each passing release means many more books and blog posts get written using `*`. I wasn't planning on resulting to scare tactics but [https://www.peoria.com/spaw/spawimages/members/member60763/shoot_this_dog.jpg here we are]... ---- If needed a migration plan can be drafted like the Semigroup/FTP/AMP/BBP/MonadFail/expanding Float/... proposals, possibly culminating in `Type` fully replacing `*` and being imported by default. I'm sure there are some further reaching consequences to this and better arguments against. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 03:02:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 03:02:56 -0000 Subject: [GHC] #12029: Notify user to import * from Data.Kind with TypeInType on In-Reply-To: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> References: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> Message-ID: <066.e049ffa44324157a3fa6df4c9b3b6572@haskell.org> #12029: Notify user to import * from Data.Kind with TypeInType on -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): Replying to [comment:2 Iceland_jack]: > Replying to [comment:1 johnleo]: > That is brought up in #12030 Ah, very good! I certainly agree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 03:18:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 03:18:31 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.27952cc64e2df76426770be2c103296c@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): Hm. Commenting on that wiki algorithm: * Might it be simpler to treat the bespoke -> newtype optimization as a post-step, independent of the rest? Or is it ever important ''not'' to apply it? Even for step 1. * Is 2(a) missing `Enum`? * Why is `Traversable` in 2(b)? I would have thought that the bespoke -> newtype optimization would apply to it. I guess there's some technical difference. * All the examples in 2(c) are listed in a or b, leaving the strange impression that it can never be triggered. Although I assume `Functor` and `Foldable` belong there. (Which also tells me the last paragraph in my previous comment has been taken care of). * The phrase "can be successfully used with GeneralizedNewtypeDeriving" is needed in 2(c) as well. Should 2(d) apply or not if that check falls? If it does then sometimes standard classes ''could'' get anyclassed. If it does ''not'', then should the classes fall back to bespoke, at least if their extensions are enabled? * It seems that `Functor` and `Foldable` never get newtype derived if that extension is not enabled, even when it would be safe to do so. I think the algorithm can be simplified a bit: remove point 2(c) entirely, and say explicitly in point 2(d) that it ''doesn't'' apply to standard derivable classes. Lastly, while thinking about this, I made a table of the (currently four- way) classification of the "standard/bespoke" classes: ||= GND equivalence =||||= No extension =||||= Extension =|| ||= Always =|| 2(a) || `Eq` `Ord` `Enum` `Ix` `Bounded` |||| || ||= Requires check =|||| || 2(c) || `Functor` `Foldable` || ||= Never =|| 2(b) || `Read` `Show` || 2(b) || `Data` `Generic` `Generic1` `Typeable` `Traversable`(?) `Lift` || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 04:19:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 04:19:21 -0000 Subject: [GHC] #11385: Unify named wildcards in different type applications In-Reply-To: <051.0076b412916fb4cfc0823d8e3d44b32d@haskell.org> References: <051.0076b412916fb4cfc0823d8e3d44b32d@haskell.org> Message-ID: <066.3fc401405a53475e64a94a2bdbdafac3@haskell.org> #11385: Unify named wildcards in different type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | NamedWildCards TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Trying to wrap the [https://hackage.haskell.org/package/reflection reflection] API without `Proxy`, is there a way to implement this without visible type abstraction? This is `reflect` {{{#!hs reflect_ :: forall (s :: *) a. Reifies s a => a reflect_ = reflect @s Proxy reify_ :: a -> (forall (s :: *). Reifies s a => r) -> r reify_ a f = reify a (\(Proxy :: Proxy s) -> f @s) }}} Would this allow {{{#!hs reify 10 $ \p -> reflect p + reflect p }}} to be written as `↓`? {{{#!hs reify_ 10 $ \ @p -> reflect_ @p + reflect_ @p }}} ---- Minimal `reflection` API: {{{#!hs {-# Language RankNTypes, TypeApplications, KindSignatures, MultiParamTypeClasses, FunctionalDependencies, ScopedTypeVariables, AllowAmbiguousTypes #-} import Unsafe.Coerce data Proxy k = Proxy class Reifies s a | s -> a where reflect :: proxy s -> a newtype Magic a r = Magic (forall (s :: *). Reifies s a => Proxy s -> r) reify :: forall a r. a -> (forall (s :: *). Reifies s a => Proxy s -> r) -> r reify a k = unsafeCoerce (Magic k :: Magic a r) (const a) Proxy {-# INLINE reify #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 04:20:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 04:20:10 -0000 Subject: [GHC] #11385: Unify named wildcards in different type applications In-Reply-To: <051.0076b412916fb4cfc0823d8e3d44b32d@haskell.org> References: <051.0076b412916fb4cfc0823d8e3d44b32d@haskell.org> Message-ID: <066.4c9325bb47945a16b8f9d17d02089380@haskell.org> #11385: Unify named wildcards in different type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | NamedWildCards TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11350 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #11350 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 04:20:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 04:20:31 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.359e4b4bd7082bb914e3dfb09c532b7f@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11385 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #11385 Comment: An additional comment on -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:20:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:20:55 -0000 Subject: [GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods Message-ID: <049.722143f91b930762e66d90cff1b491ea@haskell.org> #12457: Deriving should be (more closely) integrated with other metaprogramming methods -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is unfortunate that if we want to (efficiently) derive a new type class then we have to bake the derivation logic into GHC itself. It seems desirable to be able to implement new deriving methods in libraries in some manner. Ryan Scott says: > I think this would be a wonderful thing to have. Matthew Pickering > (cc'd) has expressed a desire to have all the logic for the `bespoke` > deriving strategies compartmentalized into a library that could easily > be expanded on in the future to support more typeclasses in base. > (Bifunctor, anyone?) > > Unfortunately, each of the major players in today's Haskell > metaprogramming scene that I'm aware of have some downfalls that make > them unsuitable as `deriving` replacements: > > * Template Haskell: Not portable. Staging issues make it hard to use as a drop-in replacement for the `deriving` keyword > * GHC generics: Can't express all the optimizations that the bespoke `deriving` algorithms perform. Unperformant. > * Haskell preprocessors: Difficult to integrate in a typical GHC workflow. Probably wouldn't have all the metadata you'd need to be feature-complete with what `deriving` does today. > > The way I see it, the whole `deriving` business as it currently stands > today is a somewhat-grotesque-but-darn-useful hack that gets around > the lack of a truly nice metaprogramming facility in Haskell. I'm > holding out hope that the work in > https://github.com/shayan-najd/NativeMetaprogramming makes things > nicer soon, and then we can revisit this idea. Until then, > -XDerivingStrategies provides a way to contain some of the madness of > `deriving` after having many features tacked onto it in recent GHC > releases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:22:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:22:06 -0000 Subject: [GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods In-Reply-To: <049.722143f91b930762e66d90cff1b491ea@haskell.org> References: <049.722143f91b930762e66d90cff1b491ea@haskell.org> Message-ID: <064.aabe84ec448499d80af95a91cfe0d66e@haskell.org> #12457: Deriving should be (more closely) integrated with other metaprogramming methods -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Richard comments: >> * Template Haskell: Not portable. Staging issues make it hard to use >> as a drop-in replacement for the `deriving` keyword > >I do not understand "not portable" here. Do you mean that some architectures don't support TH? > >What staging issues? > >I'm imagining here having `deriving Blah` be surface syntax that desugars into some TH splice. You keep the nice user-facing syntax, but make the deriving mechanism itself specified in TH code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:24:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:24:06 -0000 Subject: [GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods In-Reply-To: <049.722143f91b930762e66d90cff1b491ea@haskell.org> References: <049.722143f91b930762e66d90cff1b491ea@haskell.org> Message-ID: <064.e2aadb8b8c8bfb4a0f9ead216d5f7ea0@haskell.org> #12457: Deriving should be (more closely) integrated with other metaprogramming methods -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: RyanGlScott, goldfire (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:28:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:28:50 -0000 Subject: [GHC] #11068: Make Generic/Generic1 methods inlinable In-Reply-To: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> References: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> Message-ID: <059.f7533795e739341dd7f123ddcf995403@haskell.org> #11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Generics, | newcomer, Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1447 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): There is at least some investigative work to be done. It seems no one has checked whether the unfoldings of `from`, `to`, `from1` , `to1` were ever making it into the interface files. If they are, then adding an inlinable pragma won't achieve anything but if they aren't then it is probably worth adding the pragma as Pedro suggested. Feel free to remove the tag if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:36:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:36:35 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.420b05df8e042a0e4a79a08457314712@haskell.org> #9020: Massive blowup of code size on trivial program -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T9020 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D851 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:38:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:38:58 -0000 Subject: [GHC] #8901: (very) bad inline heuristics In-Reply-To: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> References: <048.b4dd5c7e62c55ef9ac6aee5f6863fb3f@haskell.org> Message-ID: <063.4d7d4fce3e9bf1fa90d68ea768596e61@haskell.org> #8901: (very) bad inline heuristics -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: infoneeded => closed * resolution: => invalid Comment: Please reopen if you plan on reinvestigating, it doesn't seem like any more progress is going to be made. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:43:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:43:53 -0000 Subject: [GHC] #8814: 7.8 optimizes attoparsec improperly In-Reply-To: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> References: <047.0e40742dc2d72c1ed5dd771ed77163f7@haskell.org> Message-ID: <062.6c56bafa92aa0cc9bcb6f9bdaf087c91@haskell.org> #8814: 7.8 optimizes attoparsec improperly -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:45:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:45:09 -0000 Subject: [GHC] #8774: Transitivity of Auto-Specialization In-Reply-To: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> References: <047.d2bfa5049b5dc992e463b15a7c2f6ed3@haskell.org> Message-ID: <062.df6da9c56fa57ac1b63bec90a9c795c5@haskell.org> #8774: Transitivity of Auto-Specialization -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8668, | Differential Rev(s): #8099 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:49:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:49:46 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.b9eee6043e81f14141379e2abbeed923@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:50:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:50:30 -0000 Subject: [GHC] #8662: GHC does not inline cheap inner loop when used in two places In-Reply-To: <042.69b3bccc171bc071ffddab8e8b0c335c@haskell.org> References: <042.69b3bccc171bc071ffddab8e8b0c335c@haskell.org> Message-ID: <057.df0e46edb2594eae1dccc7518c939f4d@haskell.org> #8662: GHC does not inline cheap inner loop when used in two places -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:54:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:54:07 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.23e29befd72c04f525dd8e094b341318@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: newcomers => newcomer, Inlining Comment: Any progress on this ticket Richard? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:58:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:58:39 -0000 Subject: [GHC] #12454: Cross-module specialisation of recursive functions In-Reply-To: <049.c024fa407a83e5fa89afe16591ed10e0@haskell.org> References: <049.c024fa407a83e5fa89afe16591ed10e0@haskell.org> Message-ID: <064.60e2e4f353e0a86e2bffa677a5fa28aa@haskell.org> #12454: Cross-module specialisation of recursive functions -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5928, #8589 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: #5928 => #5928, #8589 Comment: #8589 also provides some discussion about adding inlinable pragmas to recursive functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 08:58:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 08:58:48 -0000 Subject: [GHC] #8589: Bad choice of loop breaker with INLINABLE/INLINE In-Reply-To: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> References: <052.029d6667ad632c5148f8f98b3c4c0bd3@haskell.org> Message-ID: <067.ca8237df072dbf19d3fbd8c41bc3c9b7@haskell.org> #8589: Bad choice of loop breaker with INLINABLE/INLINE -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 09:01:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 09:01:06 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.c3af3a9d94d4e11c373c3dc10329257e@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: xnyhps Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer Comment: This seems well-specified for an newcomer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 09:03:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 09:03:27 -0000 Subject: [GHC] #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining In-Reply-To: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> References: <048.1fce5dd08fe08fe19b78be2cb1ec14d9@haskell.org> Message-ID: <063.e4c1c5b39a44c3c830126502721caecb@haskell.org> #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 09:06:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 09:06:37 -0000 Subject: [GHC] #7829: make better/more robust loopbreaker choices In-Reply-To: <046.9eddc93cb0dd6a39eb599a809a81416d@haskell.org> References: <046.9eddc93cb0dd6a39eb599a809a81416d@haskell.org> Message-ID: <061.b22def312d1958ce7b2ae6f1c7965c5f@haskell.org> #7829: make better/more robust loopbreaker choices -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 09:07:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 09:07:37 -0000 Subject: [GHC] #7803: Superclass methods are left unspecialized In-Reply-To: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> References: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> Message-ID: <058.d7f4430b565c5ad261afffa1c4efc2e9@haskell.org> #7803: Superclass methods are left unspecialized -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 09:09:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 09:09:06 -0000 Subject: [GHC] #7283: Specialise INLINE functions In-Reply-To: <041.8c285d32d13a99c93957573ddf0f099f@haskell.org> References: <041.8c285d32d13a99c93957573ddf0f099f@haskell.org> Message-ID: <056.9cf810c3e4edd5984738fd595a0d4b7a@haskell.org> #7283: Specialise INLINE functions -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 09:13:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 09:13:05 -0000 Subject: [GHC] #5834: Allow both INLINE and INLINABLE for the same function In-Reply-To: <041.9dc4c9ae5d423bac79723696e9524f18@haskell.org> References: <041.9dc4c9ae5d423bac79723696e9524f18@haskell.org> Message-ID: <056.fcc093f44a3f6adad5a3396f40b4bd1c@haskell.org> #5834: Allow both INLINE and INLINABLE for the same function -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => invalid Comment: I think there is some confusion here. From my understanding the `INLINABLE` pragma causes the unfolding to be added to the interface file and in addition `INLINE` makes the cost very cheap to encourage the actual inlining. If this is wrong then someone please open the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 10:13:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 10:13:03 -0000 Subject: [GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods In-Reply-To: <049.722143f91b930762e66d90cff1b491ea@haskell.org> References: <049.722143f91b930762e66d90cff1b491ea@haskell.org> Message-ID: <064.baa370cb65ffac80113d817187330c71@haskell.org> #12457: Deriving should be (more closely) integrated with other metaprogramming methods -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 11:47:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 11:47:29 -0000 Subject: [GHC] #12458: Segfault in GHCi runtime type reconstruction Message-ID: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> #12458: Segfault in GHCi runtime type reconstruction -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> data D a = D Prelude> d = D Prelude> :print d d = (_t1::D a) Prelude> d `seq` () () Segmentation fault (core dumped) }}} This is unrelated to #12449 because we're evaluating `d` which has a proper type and not `_t1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 11:47:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 11:47:57 -0000 Subject: [GHC] #12458: Segfault in GHCi runtime type reconstruction In-Reply-To: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> References: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> Message-ID: <059.51470b3b1f257ec9e4a156eccf8ba1fb@haskell.org> #12458: Segfault in GHCi runtime type reconstruction -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * owner: => mniip -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 12:30:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 12:30:53 -0000 Subject: [GHC] #12458: Segfault in GHCi runtime type reconstruction In-Reply-To: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> References: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> Message-ID: <059.5c12280e95a5d827a2ea8866072825a5@haskell.org> #12458: Segfault in GHCi runtime type reconstruction -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2439 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2439 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 12:30:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 12:30:59 -0000 Subject: [GHC] #12458: Segfault in GHCi runtime type reconstruction In-Reply-To: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> References: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> Message-ID: <059.2ad21c0b0f0ccf23bd88b9378fda9921@haskell.org> #12458: Segfault in GHCi runtime type reconstruction -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2439 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 13:08:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 13:08:45 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse Message-ID: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: orf | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://gist.githubusercontent.com/PkmX/bfb2c5af4317c96282795f8c588fda1c/raw/4e388fae1b87e16dc215613531e54b036736b34c/NamedTuple.hs This] works (removing spaces) {{{#!hs -- user = ( #login := "themoritz", #id := 3522732 ) user :: User user = (#login := "themoritz", #id := 3522732) }}} but it doesn't when `UnboxedTuples` are enabled: {{{#!hs -- tWKw.hs:63:46: error: parse error on input ‘)’ user = (#login := "themoritz", #id := 3522732) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 13:09:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 13:09:02 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse In-Reply-To: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> References: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> Message-ID: <066.d907190561bfc21f63baf29334ea4bc0@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: orf Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "NamedTuple.hs" added. From https://www.reddit.com/r/haskell/comments/4w1jcr/using_typelevel_naturals_overloaded_strings_and/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 13:12:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 13:12:18 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse In-Reply-To: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> References: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> Message-ID: <066.9aaa64f4344c9030813c353fcb68319f@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: orf Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This forces users to add a space in the ^rare^ case of mixing `UnboxedTuples` and overloaded labels. {{{#!hs main = do print $ #url mentioned print $ #login ( #user mentioned []) print $ ( #id . #user ) mentioned }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 13:46:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 13:46:12 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.f1cfd1153a9de7b00f8d95c5a3f816b0@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): oerjan, hopefully this answers all of your questions: Replying to [comment:42 oerjan]: > * Might it be simpler to treat the bespoke -> newtype optimization as a post-step, independent of the rest? Or is it ever important ''not'' to apply it? Even for step 1. Yes, there are cases where you don't want to replace the `bespoke` strategy with the `newtype` one. Consider the following example: {{{#!hs newtype Foo a = Foo (Maybe a) }}} What would happen if you tried implementing a `Traversable` instance for `Foo`? As it turns out, trying to define `traverse = coerce` is impossible at the moment: {{{ • Couldn't match representation of type ‘f (Maybe b)’ with that of ‘f (Foo b)’ arising from the coercion of the method ‘traverse’ from type ‘forall (f :: * -> *) a b. Applicative f => (a -> f b) -> Maybe a -> f (Maybe b)’ to type ‘forall (f :: * -> *) a b. Applicative f => (a -> f b) -> Foo a -> f (Foo b)’ NB: We cannot know what roles the parameters to ‘f’ have; we must assume that the role is nominal • When deriving the instance for (Traversable Foo) }}} This is because the type signature of `traverse` leads to an ill-roled coercion (see [https://ghc.haskell.org/trac/ghc/wiki/Roles#RolesandTraversable here] for the full story). Until #9123 is fixed, GHC will refuse to apply the `newtype` strategy to derived `Traversable` instances (unless you explicitly ask for it). BTW, the full list of classes that GHC avoids using the `newtype` strategy for can be found [http://git.haskell.org/ghc.git/blob/8ecac2512aed557b4f59fd697eabd3ef9ddfd6e9:/compiler/typecheck/TcDeriv.hs#l1562 here]. > * Is 2(a) missing `Enum`? No. The full list of "standard" classes for which `newtype` kicks in by default (without the presence of `-XGeneralizedNewtypeDeriving`) can be found [http://git.haskell.org/ghc.git/blob/8ecac2512aed557b4f59fd697eabd3ef9ddfd6e9:/compiler/typecheck/TcDeriv.hs#l1552 here]. As the comments there indicate, `Enum` isn't in that list because by default, deriving `Enum` for a newtype would fail since it checks for a datatype with all nullary constructors. Therefore, you have to enable `-XGeneralizedNewtypeDeriving` (or use the `newtype` keyword) to derive `Enum` for a newtype. > * Why is `Traversable` in 2(b)? I would have thought that the bespoke -> newtype optimization would apply to it. I guess there's some technical difference. See my answer above. > * All the examples in 2(c) are listed in a or b, leaving the strange impression that it can never be triggered. Although I assume `Functor` and `Foldable` belong there. (Which also tells me the last paragraph in my previous comment has been taken care of). Sorry, I should have explicitly enumerated the remaining classes not listed in 2(a) or 2(b). They are `Functor`, `Foldable`, and `Enum`. > * The phrase "can be successfully used with GeneralizedNewtypeDeriving" is needed in 2(c) as well. Should 2(d) apply or not if that check falls? If it does then sometimes standard classes ''could'' get anyclassed. If it does ''not'', then should the classes fall back to bespoke, at least if their extensions are enabled? Yes, I should use that phrase, thank you for noticing that omission. I certainly don't want standard classes to be derived with the `anyclass` strategy. > * It seems that `Functor` and `Foldable` never get newtype derived if that extension is not enabled, even when it would be safe to do so. You have to explicitly enable `-XGeneralizedNewtypeDeriving` to derive `Functor` or `Foldable` that way because, by default, deriving them is guarded behind `-XDeriveFunctor` and `-XDeriveFoldable`. You can't just say `newtype Foo a = Foo (Maybe a) deriving Functor` and expect it to work without extensions, unlike `Eq`, `Ord`, `Ix`, and `Bounded`. > I think the algorithm can be simplified a bit: remove point 2(c) entirely, and say explicitly in point 2(d) that it ''doesn't'' apply to standard derivable classes. I disagree. 2(a), (b), and (c) are all special cases for standard derivable classes, each with enough nuances that trying to cram one of them into 2(d) would make it even more confusing (than it already is). > Lastly, while thinking about this, I made a table of the (currently four-way) classification of the "standard/bespoke" classes: Thank you, this is fantastic! I've updated the wiki page with the corrections above and incorporating your table (with some slight corrections). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 14:58:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 14:58:46 -0000 Subject: [GHC] #12460: Solaris linker does not recognize option --gc-sections Message-ID: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> #12460: Solaris linker does not recognize option --gc-sections ------------------------------------------+---------------------------- Reporter: herzen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Linking) | Version: 8.0.1 Keywords: | Operating System: Solaris Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------------------+---------------------------- Linking helloworld.hs fails with the error ld: fatal: unrecognized option '--' If gcc is called by hand to link with "-Wl,--gc-sections" removed, the link succeeds. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 $ uname -a SunOS diotima 5.11 11.3 i86pc i386 i86pc $ gcc --version gcc (GCC) 4.9.3 $ cat helloworld.hs main = putStrLn "hello, world" $ ghc -c helloworld.hs $ ghc -v -keep-tmp-files -o helloworld helloworld.o Glasgow Haskell Compiler, Version 8.0.1, stage 2 booted by GHC version 7.10.1 Using binary package database: /usr/lib/ghc-8.0.1/package.conf.d/package.cache loading package database /usr/lib/ghc-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Created temporary directory: /tmp/ghc5103_0 *** C Compiler: gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc5103_0/ghc_1.c -o /tmp/ghc5103_0/ghc_2.o -I/usr/lib/ghc-8.0.1/include *** Linker: gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -o helloworld -Wl ,--gc-sections helloworld.o -L/usr/lib/ghc-8.0.1/base-4.9.0.0 -L/usr/lib/ghc-8.0.1/integer-gmp-1.0.0.1 -L/usr/lib/ -L/usr/lib/ghc-8.0.1 /ghc-prim-0.5.0.0 -L/usr/lib/ghc-8.0.1/rts /tmp/ghc5103_0/ghc_2.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.9.0.0 -lHSinteger-gmp-1.0.0.1 -lHSghc-prim-0.5.0.0 -lHSrts -lCffi -lgmp -lm -lrt -ldl ld: fatal: unrecognized option '--' ld: fatal: use the '-z help' option for usage information collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) $ gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -o helloworld helloworld.o -L/usr/lib/ghc-8.0.1/base-4.9.0.0 -L/usr/lib/ghc-8.0.1 /integer-gmp-1.0.0.1 -L/usr/lib/ -L/usr/lib/ghc-8.0.1/ghc-prim-0.5.0.0 -L/usr/lib/ghc-8.0.1/rts /tmp/ghc5103_0/ghc_2.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.9.0.0 -lHSinteger-gmp-1.0.0.1 -lHSghc-prim-0.5.0.0 -lHSrts -lCffi -lgmp -lm -lrt -ldl $ ./helloworld hello, world -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 15:18:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 15:18:20 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.aa6405b95a95c56519202c21270e488d@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Phab:D2430,Phab:2441 -------------------------------------+------------------------------------- Changes (by simonmar): * status: merge => new * differential: Phab:D2430 => Phab:D2430,Phab:2441 Comment: Please don't merge this yet, there's another fix incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 15:18:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 15:18:36 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.51ee170a7792880e7d5f26512eced5ee@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2430, Wiki Page: | Phab:2441 -------------------------------------+------------------------------------- Changes (by simonmar): * differential: Phab:D2430,Phab:2441 => Phab:D2430, Phab:2441 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 15:18:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 15:18:50 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.bda266246fe2a0326f489d85838958e2@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2430, Wiki Page: | Phab:D2441 -------------------------------------+------------------------------------- Changes (by simonmar): * differential: Phab:D2430, Phab:2441 => Phab:D2430, Phab:D2441 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 18:09:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 18:09:59 -0000 Subject: [GHC] #12461: Document -O3 Message-ID: <047.3f32e602233425465e11e52a3692f683@haskell.org> #12461: Document -O3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC accepts the flag -O3, but I can't find any documentation on it. What does it do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 18:13:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 18:13:59 -0000 Subject: [GHC] #12461: Document -O3 In-Reply-To: <047.3f32e602233425465e11e52a3692f683@haskell.org> References: <047.3f32e602233425465e11e52a3692f683@haskell.org> Message-ID: <062.a79a13d7ef85fa3bcd8cee499b62d495@haskell.org> #12461: Document -O3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I doesn't do anything. Anything higher than 2 is set to 2. The relevant function is `DynFlags.updOptLevel`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 19:32:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 19:32:49 -0000 Subject: [GHC] #12462: Cannot add directories with colon to include path Message-ID: <045.be6f241171d14f87cec920186dcadded@haskell.org> #12462: Cannot add directories with colon to include path -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ ezyang at sabre:~$ ls f:g A.hi A.hs A.o ezyang at sabre:~$ ghc-8.0 --make A -if:g : error: module ‘A’ is a package module ezyang at sabre:~$ ghc-8.0 --make A -if\:g : error: module ‘A’ is a package module ezyang at sabre:~$ ghc-8.0 --make A -if\\:g : error: module ‘A’ is a package module }}} The problem is that the colon is interpreted as a path separator.\ Of course, colons break everything forever, so you shouldn't use them. But it is still a bit unsatisfactory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 21:16:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 21:16:46 -0000 Subject: [GHC] #12088: Promote data family instance constructors In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.33cc12218fc2c0a36df307ddd532f775@haskell.org> #12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Some thoughts, after discussion with my son Michael. * This entire problem arises only because of ''open'' type families; I think closed type families are fine. We could simply ban the use of open type families in the kind signature of an open type family. Or possibly all type families, I'm not sure. * Another idea: when we have a group of `type instance` decls, suppose we kind check them, but do not yet solve the kind equalities that arise; but add them to the instance environment anyway. Now solve all the kind equalities. In our example, we'd add both instances for `Open1` and `Open2` before trying to solve their kind equalities. Seems a bit scary somehow. * Question: how do dependently typed languages deal with this? For example, what if typechecking the defintion of a function `f` requires the type checker to evaluate calls to `f`? In Haskell-land you could imagine {{{ type family Id (a :: *) :: Id * }}} We reject this at the moment, but the idea is to get into a situation where, before having typechecked `f` we need to evaluate `f`. That's rather like the situation with `Open1/2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 21:33:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 21:33:56 -0000 Subject: [GHC] #5834: Allow both INLINE and INLINABLE for the same function In-Reply-To: <041.9dc4c9ae5d423bac79723696e9524f18@haskell.org> References: <041.9dc4c9ae5d423bac79723696e9524f18@haskell.org> Message-ID: <056.0b5d93d0073db8ccdcbccd37ee65b735@haskell.org> #5834: Allow both INLINE and INLINABLE for the same function -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * status: closed => new * resolution: invalid => Comment: Mpickering, I think bgamari's ask/clarification edit of the ticket : namely the ability to inline saturated applications and specialize unsaturated use sites. And that we currently can't quite express that? I may be interpreting this incorrectly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 4 22:24:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Aug 2016 22:24:57 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.d83e4c8a44ba1891161f0d18bdf7fc10@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by richardfung): Not really sadly.. I've been just trying to understand all the code. I started looking from where --make starts, trying to go down to where the ModInfo is actually generated. I see that mkIface_ generates the [IfaceDecl] that gets passed to addFingerprints which eventually returns the ModIface which we save and I believe reuse, but that's the farthest I've gotten; I still don't know where IfaceIdInfo is set to NoInfo. At least.. I think that's what's happening? Given the fact I haven't even started looking at the second part of this problem, checking when to inline, I'm beginning to wonder if I'm in over my head! Any advice would certainly be appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 04:01:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 04:01:06 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.c838b529bf0110de061bb3a335aa622e@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:43 RyanGlScott]: > oerjan, hopefully this answers all of your questions: I'm afraid not quite, also now I have some new ones :) > Replying to [comment:42 oerjan]: > > * Might it be simpler to treat the bespoke -> newtype optimization as a post-step, independent of the rest? Or is it ever important ''not'' to apply it? Even for step 1. > > Yes, there are cases where you don't want to replace the `bespoke` strategy with the `newtype` one. Consider the following example: Although that answered my later question about `Traversable`, what I meant here was whether to treat it as a common post-step for the classes that ''can'' be newtype derived. In particular `Functor` and `Foldable`, see below. > What would happen if you tried implementing a `Traversable` instance for `Foo`? As it turns out, trying to define `traverse = coerce` is impossible at the moment: Ah, similar to that "`Monad` not getting `join` as a method" situation. > Until #9123 is fixed, GHC will refuse to apply the `newtype` strategy to derived `Traversable` instances (unless you explicitly ask for it). Surely with the role situation, it will always fail even if you ask for it? Also, I noticed in the code you linked a comment that it wouldn't be equivalent in any case for law-breaking `Applicatives`. > `Enum` isn't in that list because by default, deriving `Enum` for a newtype would fail since it checks for a datatype with all nullary constructors. Ah, I misremembered what types can derive `Enum`. > Sorry, I should have explicitly enumerated the remaining classes not listed in 2(a) or 2(b). They are `Functor`, `Foldable`, and `Enum`. By what you said otherwise, shouldn't `Enum` be in 2(b)? > > * The phrase "can be successfully used with GeneralizedNewtypeDeriving" is needed in 2(c) as well. Should 2(d) apply or not if that check falls? If it does then sometimes standard classes ''could'' get anyclassed. If it does ''not'', then should the classes fall back to bespoke, at least if their extensions are enabled? > > Yes, I should use that phrase, thank you for noticing that omission. I certainly don't want standard classes to be derived with the `anyclass` strategy. My point in the rest of that comment was that even adding that phrase isn't ''enough'', because the wording and fallthrough still implies that anyclass would be used in this case: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving, DeriveAnyClass #-} newtype F x = F ([x], Maybe x) deriving Functor }}} In fact, even assuming anyclass is not used, that example is a bit worrisome: What exactly does GHC do in this case? Does it succeed in deriving `Functor`? (I assume No.) If it fails, does it give an error message that doesn't confuse the user about why it fails? > > * It seems that `Functor` and `Foldable` never get newtype derived if that extension is not enabled, even when it would be safe to do so. > > You have to explicitly enable `-XGeneralizedNewtypeDeriving` to derive `Functor` or `Foldable` that way because, by default, deriving them is guarded behind `-XDeriveFunctor` and `-XDeriveFoldable`. You can't just say `newtype Foo a = Foo (Maybe a) deriving Functor` and expect it to work without extensions, unlike `Eq`, `Ord`, `Ix`, and `Bounded`. What I meant here, relevant to my post-step question, is that unlike with e.g. `Eq` and `Ord`, the algorithm description implies that the newtype deriving optimization is not automatic: it's not applied when deriving `Functor` or `Foldable` with `DeriveFunctor`/`DeriveFoldable` but not GND enabled. > > Lastly, while thinking about this, I made a table of the (currently four-way) classification of the "standard/bespoke" classes: > > Thank you, this is fantastic! I've updated the wiki page with the corrections above and incorporating your table (with some slight corrections). You're welcome, although the table was meant to summarize ''all'' the data for what determines automatic strategy selection, not just whether GND can be used. (I'm a bit unsure whether it was a good idea to separate the first two rows.) In particular, "Requires -XGeneralizedNewtypeDeriving" only applies to the middle right cell, not the whole column, since only the first two rows even allow GND to be automatically selected. I tried rewriting the description from a more class/table-centric perspective. (In the process, I seem to have changed "standard derivable class" into "class which has a bespoke strategy".) 1. Look for a deriving strategy. If one is present, use that. 2. If deriving a class which has a bespoke strategy: (a) If deriving `Eq`, `Ord`, `Ix`, or `Bounded` for a newtype, use the `GeneralizedNewtypeDeriving` strategy (even if the language extension isn't enabled). (b) If deriving `Functor`, `Foldable`, or `Enum`(?) for a newtype, the datatype can be successfully used with `GeneralizedNewtypeDeriving`, and `-XGeneralizedNewtypeDeriving` has been enabled, use the `GeneralizedNewtypeDeriving` strategy. (c) Otherwise, if deriving a class which has a bespoke strategy, and the corresponding language extension is enabled (if necessary), use the bespoke strategy. If the language extension is not enabled, throw an error. 3. If deriving a class without a bespoke strategy: (a) If deriving an instance for a newtype and both `-XGeneralizedNewtypeDeriving` and `-XDeriveAnyClass` are enabled, default to `DeriveAnyClass`, but emit a warning stating the ambiguity. (b) Otherwise, if `-XDeriveAnyClass` is enabled, use `DeriveAnyClass`. (c) Otherwise, if deriving an instance for a newtype, the datatype and typeclass can be successfully used with `GeneralizedNewtypeDeriving`, and `-XGeneralizedNewtypeDeriving` is enabled, do so. (d) Otherwise, throw an error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 08:40:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 08:40:58 -0000 Subject: [GHC] #12062: Parallel make with -j0 and hs-boot leads to floating point exception In-Reply-To: <045.f05741a711c24d381cb39c4a23db2a0e@haskell.org> References: <045.f05741a711c24d381cb39c4a23db2a0e@haskell.org> Message-ID: <060.fbe8826d75ae64b19f53b0d6bcec0d2a@haskell.org> #12062: Parallel make with -j0 and hs-boot leads to floating point exception -------------------------------------+------------------------------------- Reporter: ezyang | Owner: petercommand Type: bug | Status: patch Priority: low | Milestone: Component: Runtime System | Version: 8.0.1-rc2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2415 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f09d65474ed042360999cb88221d65b07bfb4b5f/ghc" f09d6547/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f09d65474ed042360999cb88221d65b07bfb4b5f" check that the number of parallel build is greater than 0 Fixes #12062. Reviewers: bgamari, thomie, austin, simonmar Reviewed By: bgamari, thomie, simonmar Subscribers: simonmar, thomie Differential Revision: https://phabricator.haskell.org/D2415 GHC Trac Issues: #12062 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 08:40:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 08:40:58 -0000 Subject: [GHC] #12405: Add expansions of abbreviated type names in documentation In-Reply-To: <042.6d8da388c6808774e666636ec49e3173@haskell.org> References: <042.6d8da388c6808774e666636ec49e3173@haskell.org> Message-ID: <057.aca6a5fe7f874fd0536c43e684120f10@haskell.org> #12405: Add expansions of abbreviated type names in documentation -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2406 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ca7e1ad346362ba68b430550110e74421b19193f/ghc" ca7e1ad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ca7e1ad346362ba68b430550110e74421b19193f" Expanded abbreviations in Haddock documentation This adds notes to the Haddock documentation for various core datatypes expanding abbreviations. Reviewers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D2406 GHC Trac Issues: #12405 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 08:49:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 08:49:58 -0000 Subject: [GHC] #12405: Add expansions of abbreviated type names in documentation In-Reply-To: <042.6d8da388c6808774e666636ec49e3173@haskell.org> References: <042.6d8da388c6808774e666636ec49e3173@haskell.org> Message-ID: <057.667b94b6d7f667c271506c4e9a079cc5@haskell.org> #12405: Add expansions of abbreviated type names in documentation -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: task | Status: closed Priority: lowest | Milestone: Component: GHC API | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2406 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Thanks syd! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 08:52:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 08:52:39 -0000 Subject: [GHC] #11758: Drop x86_64 binutils <2.17 hack In-Reply-To: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> References: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> Message-ID: <061.687ce352eb7988af8c56baf1499f80da@haskell.org> #11758: Drop x86_64 binutils <2.17 hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: avd Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 8.0.1-rc2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12433 | Differential Rev(s): Phab:D2426 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged in e3e2e49a8f6952e1c8a19321c729c17b294d8c92. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 08:53:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 08:53:16 -0000 Subject: [GHC] #12062: Parallel make with -j0 and hs-boot leads to floating point exception In-Reply-To: <045.f05741a711c24d381cb39c4a23db2a0e@haskell.org> References: <045.f05741a711c24d381cb39c4a23db2a0e@haskell.org> Message-ID: <060.1a8617f057c6f1f8fbaf29a2fbe4f7ca@haskell.org> #12062: Parallel make with -j0 and hs-boot leads to floating point exception -------------------------------------+------------------------------------- Reporter: ezyang | Owner: petercommand Type: bug | Status: merge Priority: low | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1-rc2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2415 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 09:12:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 09:12:45 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.2d416cde4d6d20ab76fbe5b934e5c88f@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ping! Validate has been broken for 2 weeks due to this. That's really ungood :( If you're sure that the regression is not due to your patch (after checking the instructions in Note [residency]) then please update the thresholds for the test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 09:13:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 09:13:45 -0000 Subject: [GHC] #10860: setnumcapabilities001: internal error: ASSERTION FAILED: file rts/Schedule.c, line 400 In-Reply-To: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> References: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> Message-ID: <060.1415466beb71a3da58ca71cf87dc6689@haskell.org> #10860: setnumcapabilities001: internal error: ASSERTION FAILED: file rts/Schedule.c, line 400 -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"ce13a9a9f57d61170837532948fed8bc1924a7ab/ghc" ce13a9a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ce13a9a9f57d61170837532948fed8bc1924a7ab" Fix an assertion that could randomly fail Summary: ASSERT_THREADED_CAPABILITY_INVARIANTS was testing properties of the returning_tasks queue, but that requires cap->lock to access safely. This assertion would randomly fail if stressed enough. Instead I've removed it from the catch-all ASSERT_PARTIAL_CAPABILITIY_INVARIANTS and made it a separate assertion only called under cap->lock. Test Plan: ``` cd testsuite/tests/concurrent/should_run make TEST=setnumcapabilities001 WAY=threaded1 EXTRA_HC_OPTS=-with- rtsopts=-DS CLEANUP=0 while true; do ./setnumcapabilities001.run/setnumcapabilities001 4 9 2000 || break; done ``` Reviewers: niteria, bgamari, ezyang, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2440 GHC Trac Issues: #10860 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 09:13:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 09:13:45 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.a2d18b566f2117d3149cb19648f07dc7@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2430, Wiki Page: | Phab:D2441 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"89fa4e968f47cfb42d0dc33fc3bfffdce31d850e/ghc" 89fa4e9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="89fa4e968f47cfb42d0dc33fc3bfffdce31d850e" Another try to get thread migration right Summary: This is surprisingly tricky. There were linked list bugs in the previous version (D2430) that showed up as a test failure in setnumcapabilities001 (that's a great stress test!). This new version uses a different strategy that doesn't suffer from the problem that @ezyang pointed out in D2430. We now pre-calculate how many threads to keep for this capability, and then migrate any surplus threads off the front of the queue, taking care to account for threads that can't be migrated. Test Plan: 1. setnumcapabilities001 stress test with sanity checking (+RTS -DS) turned on: ``` cd testsuite/tests/concurrent/should_run make TEST=setnumcapabilities001 WAY=threaded1 EXTRA_HC_OPTS=-with- rtsopts=-DS CLEANUP=0 while true; do ./setnumcapabilities001.run/setnumcapabilities001 4 9 2000 || break; done ``` 2. The test case from #12419 Reviewers: niteria, ezyang, rwbarton, austin, bgamari, erikd Subscribers: thomie, ezyang Differential Revision: https://phabricator.haskell.org/D2441 GHC Trac Issues: #12419 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 09:20:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 09:20:42 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.fc6815ea484c3de20fdac4deb7992e99@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2430, Wiki Page: | Phab:D2441 -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 10:25:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 10:25:35 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.8719ce63f7c85da80445c0ddfd866563@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Regression is due to my patch, but I'm not sure what the solution is here. Do you want me to bump the threshold, because with the patch allocation is actually reduced? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 13:29:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 13:29:33 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.1104f4e1a8f2f57e2aefe7ed2187aa92@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I like your algorithm much better, since it has no jumps/gotos. I've updated the wiki page to use it. I've also updated the table to use more accurate labels. Thank you for the peer editing! As for your other questions: > Surely with the role situation, it will always fail even if you ask for it? Also, I noticed in the code you linked a comment that it wouldn't be equivalent in any case for law-breaking `Applicatives`. Yes, it will always fail. But that's the point of `-XDerivingStrategies`—by explicitly using the `newtype` keyword, you take on the burden of ensuring that your typeclass can actually be derived, and you must accept the consequences if you try something which won't work. > My point in the rest of that comment was that even adding that phrase isn't ''enough'', because the wording and fallthrough still implies that anyclass would be used in this case: > > {{{#!hs > {-# LANGUAGE GeneralizedNewtypeDeriving, DeriveAnyClass #-} > > newtype F x = F ([x], Maybe x) deriving Functor > }}} > > In fact, even assuming anyclass is not used, that example is a bit worrisome: What exactly does GHC do in this case? Does it succeed in deriving `Functor`? (I assume No.) If it fails, does it give an error message that doesn't confuse the user about why it fails? That is a very good point, and one which your refactored table takes into account, so now the table reflects the reality that `-XDeriveAnyClass` does //not// fall through in this case. In case you're curious, here's the error message that GHC gives for that example: {{{ • Can't make a derived instance of ‘Functor F’ (even with cunning GeneralizedNewtypeDeriving): You need DeriveFunctor to derive an instance for this class • In the newtype declaration for ‘F’ }}} That seems like a sensible error to me. I'll add a test case for this in Phab:2280 to be safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 14:12:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 14:12:07 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? Message-ID: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> #12463: SPECIALIZABLE pragma? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Inlining | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently it is common practice for library authors to use the `INLINEABLE` pragma to make it more likely that a polymorphic function should get an unfolding in the module's interface file to ensure that GHC is able to specialize. While in practice this works reasonably well, it's not really saying what we often mean: we don't want to inline, we really just want GHC to behave like each use-site's module has a `SPECIALISE` pragma for each concrete type that the function is used at. For instance, consider, {{{#!hs module ALibrary where aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} module SomeUser where import ALibrary aUser :: Int -> Int aUser = {- some large expression involving aLibraryFunction -} }}} Ideally, we would want GHC to take and produce one specialized version of `aLibraryFunction` for every concrete type which it is used at. However, without an `INLINEABLE` function, GHC won't even consider producing an unfolding for `aLibraryFunction` due to its size. If we include an `INLINEABLE` pragma (as most performance-aware authors would do) then we can convince GHC to produce an unfolding, but only at the expense of lowering its inlining cost as well. This is unfortunate since we never wanted GHC to inline; merely to specialize. This is issue especially prevalent in code using MTL-style effects, where we have ubiquitous overloading of very frequently-used functions (e.g. bind). Really what we want in this case is a way of indicating to GHC that a function shouldn't be inlined (use-sites replaced with the body of the function), but rather that GHC should try hard to specialize away particular type variables. This might look like, {{{#!hs aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALIZE forall a. LibraryFunction a #-} }}} This would request that GHC would keep an inlining around and produce a specialized version of `aLibraryFunction` every time it saw a concrete instantiation of `a`. Moreover, it would try to minim -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 14:19:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 14:19:29 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.7fb51c903f68ddfbda1568fe429aeb0d@haskell.org> #12463: SPECIALIZABLE pragma? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 14:22:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 14:22:02 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.6d434f5e6c79827b040a5f2ce97f1ad0@haskell.org> #12463: SPECIALIZABLE pragma? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -42,1 +42,1 @@ - {-# SPECIALIZE forall a. LibraryFunction a #-} + {-# SPECIALISE(a) forall a. aLibraryFunction :: a -> a #-} @@ -44,0 +44,2 @@ + The list of type binders after `SPECIALISE` is the set of binders which + GHC would attempt to specialize. @@ -47,1 +49,12 @@ - instantiation of `a`. Moreover, it would try to minim + instantiation of `a`. Moreover, the produced symbols could be declared as + weak, allowing the linker to cull duplication code when possible. + + Moreover, a variant of this might be, + {{{#!hs + aLibraryFunction :: AClass a => a -> a + aLibraryFunction = {- some large expression involving methods of AClass -} + {-# SPECIALISE_RECURSIVE(a) forall a. aLibraryFunction :: a -> a #-} + }}} + Which would ensure that polymorphic use-sites of `aLibraryFunction` would + themselves be marked as `SPECIALISE_RECURSIVE`, shielding users from the + need to know about a library's expectations of the simplifier. New description: Currently it is common practice for library authors to use the `INLINEABLE` pragma to make it more likely that a polymorphic function should get an unfolding in the module's interface file to ensure that GHC is able to specialize. While in practice this works reasonably well, it's not really saying what we often mean: we don't want to inline, we really just want GHC to behave like each use-site's module has a `SPECIALISE` pragma for each concrete type that the function is used at. For instance, consider, {{{#!hs module ALibrary where aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} module SomeUser where import ALibrary aUser :: Int -> Int aUser = {- some large expression involving aLibraryFunction -} }}} Ideally, we would want GHC to take and produce one specialized version of `aLibraryFunction` for every concrete type which it is used at. However, without an `INLINEABLE` function, GHC won't even consider producing an unfolding for `aLibraryFunction` due to its size. If we include an `INLINEABLE` pragma (as most performance-aware authors would do) then we can convince GHC to produce an unfolding, but only at the expense of lowering its inlining cost as well. This is unfortunate since we never wanted GHC to inline; merely to specialize. This is issue especially prevalent in code using MTL-style effects, where we have ubiquitous overloading of very frequently-used functions (e.g. bind). Really what we want in this case is a way of indicating to GHC that a function shouldn't be inlined (use-sites replaced with the body of the function), but rather that GHC should try hard to specialize away particular type variables. This might look like, {{{#!hs aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALISE(a) forall a. aLibraryFunction :: a -> a #-} }}} The list of type binders after `SPECIALISE` is the set of binders which GHC would attempt to specialize. This would request that GHC would keep an inlining around and produce a specialized version of `aLibraryFunction` every time it saw a concrete instantiation of `a`. Moreover, the produced symbols could be declared as weak, allowing the linker to cull duplication code when possible. Moreover, a variant of this might be, {{{#!hs aLibraryFunction :: AClass a => a -> a aLibraryFunction = {- some large expression involving methods of AClass -} {-# SPECIALISE_RECURSIVE(a) forall a. aLibraryFunction :: a -> a #-} }}} Which would ensure that polymorphic use-sites of `aLibraryFunction` would themselves be marked as `SPECIALISE_RECURSIVE`, shielding users from the need to know about a library's expectations of the simplifier. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 14:26:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 14:26:40 -0000 Subject: [GHC] #11385: Unify named wildcards in different type applications In-Reply-To: <051.0076b412916fb4cfc0823d8e3d44b32d@haskell.org> References: <051.0076b412916fb4cfc0823d8e3d44b32d@haskell.org> Message-ID: <066.b30810674621e9f83bf16da5819d8535@haskell.org> #11385: Unify named wildcards in different type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | NamedWildCards TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11350 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Your `reify_` in comment:7 certainly seems plausible. I would expect that to work with visible type abstraction. Is there any difference now between this ticket and #11350? It seems not. Perhaps we should merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 14:29:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 14:29:59 -0000 Subject: [GHC] #12457: Deriving should be (more closely) integrated with other metaprogramming methods In-Reply-To: <049.722143f91b930762e66d90cff1b491ea@haskell.org> References: <049.722143f91b930762e66d90cff1b491ea@haskell.org> Message-ID: <064.7481bfcadd6bcf51d35efd2505e5c3fe@haskell.org> #12457: Deriving should be (more closely) integrated with other metaprogramming methods -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'll also add: I think we'll need a better way of dealing with types than TH has now. But it's possible that clever `reify`s plus the new `addModFinalizer` behavior of #11832 will be enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 15:11:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 15:11:08 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.c9e2de7aa5f8f277627f36dae6758c94@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I suggest: bump the threshold now to unbreak validate, and keep this ticket open to fix the regression before 8.2. Performance is a big focus for this release, so we'd like to keep on top of regressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 15:20:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 15:20:01 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.be7794ede9ad34f376c834c037f415f9@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I'm experimenting with some changes to fix this without bumping any numbers, so I may leave this unfixed for a little bit more if that's OK? Otherwise let me know and I'll bump the number. (Unfortunately even if I fix this, in a few commits it'll be broken again, this time because of `peak_megabytes_allocated`. Apparently it has been increasing for a long time and now we have 1MB left before it needs bumping again.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 15:29:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 15:29:26 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.0b1f6c3f685f783987a818d45a15e26e@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"253fc3888dc170feb8adcd05067020a2ee1ea53e/ghc" 253fc38/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="253fc3888dc170feb8adcd05067020a2ee1ea53e" Temporarily mark T1969 perf test as broken (#12437) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 15:34:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 15:34:51 -0000 Subject: [GHC] #12088: Promote data family instance constructors In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.b49b31640f338a7117462cf5c880b1bd@haskell.org> #12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I have a very different way of thinking about all of this that may shed some light on the matter. (Before we get any further, if you'd like my input, do email directly. It's only dumb luck that I happened to catch up on this ticket so soon after requesting my feedback.) Most declarations declare actually ''two'' things: a type and a definition. For `data T = MkT Int`, we have the type `T :: Type` and the definition, consisting of `MkT`. For `type family F a where F Bool = Int`, we get the type `F :: Type -> Type` and the definition `F Bool = Int`. What's odd about open families is that the type and definition are separated, quite clearly in the code. But when we think about the fact that closed definitions are declaring two things at once, perhaps it's the ''closed'' definitions that are odd and the open ones are more natural. (Indeed, at the term level, we make the type and body separate top-level declarations.) So, perhaps that's the answer: treat closed declarations as two separate pieces, each with its own node in the dependency graph. Now, any declaration (where "declaration" means either a type declaration or a definition declaration, but not both wrapped together) can depend on any other (also separated) declarations. (Let's hold off a moment on worrying about how to implement this. I'll get to that later. The goal here is simply to describe what programs are accepted.) Let's review the examples from above: ------------------------------------ '''From the original description:''' {{{ data family T a data instance T Int = MkT data Proxy (a :: k) data S = MkS (Proxy 'MkT) }}} Here are the dependencies, where I list a declaration and the things it depends on (not using transitivity): * `T` (type only): nothing * `T Int` (defn only): type of `T` * type of `Proxy`: nothing * defn of `Proxy`: type of `Proxy` * type of `S`: nothing * defn of `S`: type of `MkT` (= defn of `T Int`) In the last bullet, we see that the type of a data constructor is considered in the same declaration as the definition of the parent tycon. The definition of a constructor is also in this same declaration. (This suggests further opportunities for splitting, though. Could one constructor mention another constructor, promoted, from the same type? I think so.) These bullets also show that all definitions automatically depend on their own types. No surprise there. -------------------------------------- '''From comment:10:''' {{{ -- module A type family Open (t :: Type) :: Type data family F (t :: Type) :: Open t -> Type }}} {{{ -- module B import A data Q type instance Open Q = Bool data instance F Q r where F0 :: F Q 'True }}} * `Open` (type only): nothing * `F` (type only): type of `Open` * type of `Q`: nothing * defn of `Q`: type of `Q` * `Open Q` (defn only): type of `Open`, type of `Q` * `F Q r` (defn only): type of `F`, type of `Q`, defn of `Open` The last bullet above reveals something new: when the type of `A` depends on the type of `B`, then the definition of `A` depends on the definition of `B`. In this case, the type of `F` depends on the type of `Open`, and thus the definition of `F` (that is, `instance F Q r`) depends on the definition of `Open`. We now have a small conundrum: what on earth is the definition of `Open`, an open type family? The only possible answer: all instances that are in scope. These instances are considered as an inseparable clump. Any attempt to break them up by bizarre mutual dependencies is met with failure. I do think there is room to be cleverer here, but I think we'd be too clever by half if we tried. In this example, it means that we check the `Open Q` instance before the `F Q r` instance. -------------------------------------------- '''Also from comment:10:''' {{{ -- module A2 type family Open1 (t :: Type) :: Type type family Open2 (t :: Type) (q :: Open1 t) :: Type }}} {{{ -- module B2 import A2 type instance Open1 () = Bool type instance Open2 () 'True = Char }}} * `Open1` (type only): nothing * `Open2` (type only): type of `Open1` * `Open1 ()` (defn only): type of `Open1` * `Open2 ()` (defn only): type of `Open2`, defn of `Open1` It's now clear that we must check the instance for `Open1` before that of `Open2`. No difficulty here. ------------------------------------------- '''From comment:11:''' {{{ data T1 = MkT1 (...something requiring IA...) data T2 = MkT2 (...something requiring IB...) type instance F1 Int = ...T2... -- IA type instance F2 Int = ...T1... -- IB }}} * type of `T1`: nothing * defn of `T1`: defn of `F1` * type of `T2`: nothing * defn of `T2`: defn of `F2` * `F1 Int` (defn only): type of `F1`, type of `T2` * `F2 Int` (defn only): type of `F2`, type of `T1` No problem here either. Go in this order: type of `T1`, type of `T2`, type of `F1`, type of `F2`, `F1 Int`, `F2 Int`, defn of `T1`, defn of `T2`. The reason there is no problem is that we have separated types from definitions. ---------------------------------------------- '''Reactions to comment:12:''' * It's hard to bad open type families from appearing somewhere, because we'd have to make the ban transitive. We'd thus have two classes of closed type families: those that mention open families somewhere (transitively) and those that don't. This would be awful. * Your "another idea" might be something like what I've proposed here. * In answer to your "question": I think only Agda handles this. It's induction recursion. And I think it's rather like what I've sketched here. ----------------------------------------------- '''Implementation notes''' Checking types and definitions separately is a bit of a bother for datatypes, because the datacons and the tycons mutually depend on each other. But I think it's possible -- just a little knotty. Let's assume that the dependency analysis succeeds and that there is a dependency ordering with no (perhaps transitive) self-dependency. 1. At the beginning of the "type-checking" (ahem, desugaring) pass in !TcTyClsDecls, go through the declarations in reverse order and create a knot for each definition (with the list of datacons knot-tied) and each type (with the tycon knot-tied). 2. Then check the declarations in order. a. When a type declaration is processed, close out the tycon's knot. You will now have a tycon usable in every way except to access its datacons. b. When a definition declaration is processed, close out its knot. The datacons will now be untied and usable. '''Proposition.''' If the dependency analysis is correct, the above algorithm accesses nothing that is knot-tied. I propose naming this algorithm the "Celestial Dance of the Black Holes". It's as dangerous as it sounds. But I believe it's implementable. Perhaps not by humans. :) The alternative to the Celestial Dance is to create intermediate structures with mutable references and such and then zonk them to get the desired outcome. The zonker will have to be creative about knot-tying, but that's much simpler. Indeed this may be the better approach, perhaps leaning more heavily on the rather new `TcTyCon` than we have been. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 15:50:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 15:50:08 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.1651c416f6ddb996d8ec0e64dd58b7a3@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by angerman: @@ -14,1 +14,1 @@ - try to reduce #3. + try to reduce 3. New description: Builds using GHC's LLVM backend are currently substantially slower than GHC's own native code generator. There are a few possible reasons for this, 1. the cost of forking processes and serializing/parsing LLVM's intermediate representation 2. the cost of the more powerful optimizations responsible for LLVM's (hopefully) better code generation 3. the cost of redundant optimizations overlapping effort already expended by GHC Given that some architecture (e.g. ARM) are only supported by LLVM and therefore suffer considerably at the hand of our slow builds, we should try to reduce 3. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 15:50:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 15:50:54 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.b17e745ed62dc14012cc659dfeb6b675@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 15:52:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 15:52:05 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.1ddf0e60c3fcfbfc265ed4492ce1d1a2@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 15:53:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 15:53:13 -0000 Subject: [GHC] #5567: LLVM: Improve alias analysis / performance In-Reply-To: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> References: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> Message-ID: <060.e7a8a2d37a5df8e11069b35051ff9b23@haskell.org> #5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 17:12:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 17:12:04 -0000 Subject: [GHC] #12464: Add `instance Semigroup a => Semigroup (IO a)` Message-ID: <051.7ee4c9180a44c202fe41bb3ce898bbc0@haskell.org> #12464: Add `instance Semigroup a => Semigroup (IO a)` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- What the title says -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 18:40:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 18:40:50 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.24a7d5a0259d12c16a4a109438f18d3c@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Edward Kmett notes [https://mail.haskell.org/pipermail/ghc- devs/2016-August/012537.html on the ghc-devs mailing list] that making `-XTypeOperators` allow the use of `(~)` is not a good idea, since it means that other compilers who wish to implement `-XTypeOperators` must now implement all of the ideas in the OutsideIn(X) paper, which is a big ask. It might be better to introduce a new pragma (`-XTypeEqualities`?) for this purpose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 18:54:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 18:54:15 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.a2293fa9c19c5788eb46e63c13b448f3@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): Still a few comments: * I ''really'' don't think `Enum` belongs in 2(b), which is why I put a question mark on it in the first place. I think it should also be moved to the bottom left cell in the table. * Even though it's explained below, I have a hunch the phrase "bespoke typeclass instance" could be misinterpreted as referring to the selected strategy. It's a little longer, but "instance for a bespoke typeclass" feels less ambiguous. * The paragraph starting "Step 2.(b) deserves some explanation." doesn't make sense with the new algorithm, since the issue no longer applies with the new control flow. (After all, one of the things simplifying it is that step 2 doesn't need to consider anyclass any more, and step 3 doesn't need to consider bespoke.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 19:08:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 19:08:42 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.e19d848ec3619a4d6f42ce625f3fe949@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:46 oerjan]: > * I ''really'' don't think `Enum` belongs in 2(b), which is why I put a question mark on it in the first place. I think it should also be moved to the bottom left cell in the table. I don't follow. Why should it be in the "never" category? As noted above, there are scenarios when GHC will derive `Enum` for newtypes, and they are perfectly captured in 2(b). > * Even though it's explained below, I have a hunch the phrase "bespoke typeclass instance" could be misinterpreted as referring to the selected strategy. It's a little longer, but "instance for a bespoke typeclass" feels less ambiguous. This is why I hate choosing syntax :) I'm going strictly by the dictionary definition of "bespoke" here, which means "tailor-made" or "custom-fit". That means the phrase "bespoke typeclass" doesn't make sense, since "bespoke" is a property of the instance, not the typeclass. > * The paragraph starting "Step 2.(b) deserves some explanation." doesn't make sense with the new algorithm, since the issue no longer applies with the new control flow. (After all, one of the things simplifying it is that step 2 doesn't need to consider anyclass any more, and step 3 doesn't need to consider bespoke.) I've reworded it to make it a little clearer, hopefully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 20:37:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 20:37:43 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.02014e09b26c680c2022c80d6d57cf2d@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #10059 => #10059, #10431 Comment: And as it turns out, `-XEqualityConstraints` has been proposed before. See #10431. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 21:08:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 21:08:40 -0000 Subject: [GHC] #12465: Evil idea: Allow empty record field update syntax for types. Message-ID: <051.24b812ed598c409441e148e921dac8f9@haskell.org> #12465: Evil idea: Allow empty record field update syntax for types. -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Use case: Visible type application. I often work with constructors with many arguments, then I want to instantiate type variables with them: {{{#!hs show @(Vector _ _) :: Show a => Vector n a -> String -- Type arguments reversed, see https://github.com/ekmett/distributive/pull/18 cotraverse @_ @(Vector _) :: (NATTY n, Functor f) => (f a -> b) -> (f (Vector n a) -> Vector n a') fmap @(Bazaar _ _ _) :: (t -> t') -> (Bazaar p a b t -> Bazaar p a b t') show @(Magma _ _ _ _) :: (Show a, Show i) => Magma i t b a -> String }}} This makes no sense since types have nothing to do with record or updates thereof but that syntax is often used to avoid parentheses and unneeded wildcard arguments: {{{#!hs isBar (Bar _ _ _ _ _) = True -- ===> isBar Bar{} = True }}} This also means you don't need to worry about the kind of your constructor wrt the type (class) variable it instantiates. ---- Thus the proposal is to allow: {{{#!hs show @Vector{} :: Show a => Vector n a -> String cotraverse @_ @Vector{} :: (NATTY n, Functor f) => (f a -> b) -> (f (Vector n a) -> Vector n a') fmap @Bazaar{} :: (t -> t') -> (Bazaar p a b t -> Bazaar p a b t') show @Magma{} :: (Show a, Show i) => Magma i t b a -> String }}} ---- This would save quite a few keystrokes in my daily coding but more importantly it saves cognitive load but I expect skepticism, especially since GHC would have to determine whether to interpret `show @Vector{}` to `show @Vector`, `show @(Vector _n)` or `show @(Vector _n _a)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 21:09:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 21:09:05 -0000 Subject: [GHC] #12465: Evil idea: Allow empty record field update syntax for types. In-Reply-To: <051.24b812ed598c409441e148e921dac8f9@haskell.org> References: <051.24b812ed598c409441e148e921dac8f9@haskell.org> Message-ID: <066.1b72c9c8724da0b666862f7a5758bee1@haskell.org> #12465: Evil idea: Allow empty record field update syntax for types. -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -3,2 +3,2 @@ - I often work with constructors with many arguments, then I want to - instantiate type variables with them: + I often work with constructors with many arguments that I want to + instantiate type variables with: New description: Use case: Visible type application. I often work with constructors with many arguments that I want to instantiate type variables with: {{{#!hs show @(Vector _ _) :: Show a => Vector n a -> String -- Type arguments reversed, see https://github.com/ekmett/distributive/pull/18 cotraverse @_ @(Vector _) :: (NATTY n, Functor f) => (f a -> b) -> (f (Vector n a) -> Vector n a') fmap @(Bazaar _ _ _) :: (t -> t') -> (Bazaar p a b t -> Bazaar p a b t') show @(Magma _ _ _ _) :: (Show a, Show i) => Magma i t b a -> String }}} This makes no sense since types have nothing to do with record or updates thereof but that syntax is often used to avoid parentheses and unneeded wildcard arguments: {{{#!hs isBar (Bar _ _ _ _ _) = True -- ===> isBar Bar{} = True }}} This also means you don't need to worry about the kind of your constructor wrt the type (class) variable it instantiates. ---- Thus the proposal is to allow: {{{#!hs show @Vector{} :: Show a => Vector n a -> String cotraverse @_ @Vector{} :: (NATTY n, Functor f) => (f a -> b) -> (f (Vector n a) -> Vector n a') fmap @Bazaar{} :: (t -> t') -> (Bazaar p a b t -> Bazaar p a b t') show @Magma{} :: (Show a, Show i) => Magma i t b a -> String }}} ---- This would save quite a few keystrokes in my daily coding but more importantly it saves cognitive load but I expect skepticism, especially since GHC would have to determine whether to interpret `show @Vector{}` to `show @Vector`, `show @(Vector _n)` or `show @(Vector _n _a)`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 21:18:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 21:18:09 -0000 Subject: [GHC] #12465: Evil idea: Allow empty record field update syntax for types. In-Reply-To: <051.24b812ed598c409441e148e921dac8f9@haskell.org> References: <051.24b812ed598c409441e148e921dac8f9@haskell.org> Message-ID: <066.fe906217f860122ffef6611cda0a94e7@haskell.org> #12465: Evil idea: Allow empty record field update syntax for types. -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -58,3 +58,4 @@ - importantly it saves cognitive load but I expect skepticism, especially - since GHC would have to determine whether to interpret `show @Vector{}` to - `show @Vector`, `show @(Vector _n)` or `show @(Vector _n _a)`. + importantly it saves cognitive load but I expect raised eyebrows + (especially since GHC would have to determine whether to interpret `show + @Vector{}` to `show @Vector`, `show @(Vector _n)` or `show @(Vector _n + _a)`). New description: Use case: Visible type application. I often work with constructors with many arguments that I want to instantiate type variables with: {{{#!hs show @(Vector _ _) :: Show a => Vector n a -> String -- Type arguments reversed, see https://github.com/ekmett/distributive/pull/18 cotraverse @_ @(Vector _) :: (NATTY n, Functor f) => (f a -> b) -> (f (Vector n a) -> Vector n a') fmap @(Bazaar _ _ _) :: (t -> t') -> (Bazaar p a b t -> Bazaar p a b t') show @(Magma _ _ _ _) :: (Show a, Show i) => Magma i t b a -> String }}} This makes no sense since types have nothing to do with record or updates thereof but that syntax is often used to avoid parentheses and unneeded wildcard arguments: {{{#!hs isBar (Bar _ _ _ _ _) = True -- ===> isBar Bar{} = True }}} This also means you don't need to worry about the kind of your constructor wrt the type (class) variable it instantiates. ---- Thus the proposal is to allow: {{{#!hs show @Vector{} :: Show a => Vector n a -> String cotraverse @_ @Vector{} :: (NATTY n, Functor f) => (f a -> b) -> (f (Vector n a) -> Vector n a') fmap @Bazaar{} :: (t -> t') -> (Bazaar p a b t -> Bazaar p a b t') show @Magma{} :: (Show a, Show i) => Magma i t b a -> String }}} ---- This would save quite a few keystrokes in my daily coding but more importantly it saves cognitive load but I expect raised eyebrows (especially since GHC would have to determine whether to interpret `show @Vector{}` to `show @Vector`, `show @(Vector _n)` or `show @(Vector _n _a)`). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 21:23:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 21:23:56 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context Message-ID: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following compiles with GHC 7.10.3 and earlier, but not with GHC HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where class Foo a where foo :: (a ~ Int => Int) -> a -> a foo _ a2 = a2 instance Foo Char }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:10: error: • Couldn't match type ‘Char’ with ‘Int’ Inaccessible code in a type expected by the context: Char ~ Int => Int • In the expression: Bug.$dmfoo @Char In an equation for ‘foo’: foo = Bug.$dmfoo @Char In the instance declaration for ‘Foo Char’ }}} This causes `lens-4.14` to [https://github.com/ekmett/lens/issues/667 fail to build] with GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 21:35:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 21:35:55 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.ea084b6ec3e309d6acfe630866a5130d@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: @@ -1,1 +1,1 @@ - The following compiles with GHC 7.10.3 and earlier, but not with GHC HEAD: + The following compiles with GHC 8.0.1 and earlier, but not with GHC HEAD: New description: The following compiles with GHC 8.0.1 and earlier, but not with GHC HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where class Foo a where foo :: (a ~ Int => Int) -> a -> a foo _ a2 = a2 instance Foo Char }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:10: error: • Couldn't match type ‘Char’ with ‘Int’ Inaccessible code in a type expected by the context: Char ~ Int => Int • In the expression: Bug.$dmfoo @Char In an equation for ‘foo’: foo = Bug.$dmfoo @Char In the instance declaration for ‘Foo Char’ }}} This causes `lens-4.14` to [https://github.com/ekmett/lens/issues/667 fail to build] with GHC HEAD. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 22:43:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 22:43:33 -0000 Subject: [GHC] #10431: EqualityConstraints extension? In-Reply-To: <049.f083101907b8bce0e20c55864639c7df@haskell.org> References: <049.f083101907b8bce0e20c55864639c7df@haskell.org> Message-ID: <064.282b2e01c59f7982bb708a55eb59d3c6@haskell.org> #10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 22:59:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 22:59:16 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.2e69d4cb8eadf4f154d4d1924b646f4f@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:29 RyanGlScott]: > And as it turns out, `-XEqualityConstraints` has been proposed before. See #10431. I'm compelled to ask whether there is more than one equality constraints in light of [https://youtu.be/hIZxTQP1ifo?t=2764 these] [https://www.reddit.com/r/haskell/comments/4w1jcr/using_typelevel_naturals_overloaded_strings_and/d63hgvk comments] by Edward and if `EqualityConstraint` were more apt (unless `~~`, `~#`, `~R#`, `~P#`, `Coercible` count) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 5 23:39:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Aug 2016 23:39:13 -0000 Subject: [GHC] #12467: distclean does not clean 'compact' library Message-ID: <043.0965dcc9cbc3831b757e34a906f52bd0@haskell.org> #12467: distclean does not clean 'compact' library -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ > ghc_2 git:(master) make distclean 2>&1 | grep compact > ghc_2 git:(master) }}} I think we should see something like {{{ "rm" -rf libraries/compact/dist-install }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 00:25:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 00:25:49 -0000 Subject: [GHC] #12088: Promote data family instance constructors In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.20aeafcbb8cfbb5927abab1483311c14@haskell.org> #12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't really understand your suggestion Richard. Firstly, we often infer the kind of a data type, so it's hard to separate dependence on its kind from dependendence on its definition. I din't undersand the precise dependency analysis that you informally propose. Secondly, I think that open type families are indeed the odd one out, as you acknowledge in the "odd conundrum". I don't see what's gained by separating types from defns even if we could. Thirdly, you suggest kind-checking all equations for a type family together as a single group. But you can't do that if they mention data types that have not yet been defined. Yet we can't delay too long ... getting those instances into play early is the whole point. Fourth, the dependence may be indirect. In the example, Open2 mentions Open1 directly. But it could instead mention F directly, where F is an open family that has an equation like `type instance F [t] = Open1 t`. Now the dependence on Open1 is hidden. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 01:02:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 01:02:13 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.291ac8dbce0f27d1f86f04769833bca6@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [[ticket:10598#comment:47|RyanGlScott]]: > I don't follow. Why should it be in the "never" category? As noted above, there are scenarios when GHC will derive `Enum` for newtypes, and they are perfectly captured in 2(b). Oh, I'd missed that. I guess removing the question mark was fine, then. However, that means `Enum` alone ''doesn't'' fit properly into my intended table scheme, since it's sort of a hybrid between lower left and middle right (actually, ''upper'' right, since there's no check needed on the shape of the newtype). Which means the current table indeed only describes when to do GND. Possibly, it could fit in the middle ''left'' if the table is slightly relabeled, so that the rows tell what to do about GND and the columns tell about general use. Like so: |||| ||= No extension required =||||= Requires language extension to use =|| ||= GND when possible =|| 2(a) || `Eq`, `Ord`, `Ix`, `Bounded` |||| || ||= GND with extension =|| 2(b) || `Enum` || 2(b) || `Functor`, `Foldable` || ||= Never select GND =|| 2(c) || `Read`, `Show` || 2(c) || `Data`, `Generic`, `Generic1`, `Typeable`, `Traversable`, `Lift` || Which reminds me, I think maybe the word "silly" in step 1 should be "impossible", since after all some very silly things ''are'' allowed, like using anyclass on a class that doesn't support it. > > > * Even though it's explained below, I have a hunch the phrase "bespoke typeclass instance" could be misinterpreted as referring to the selected strategy. It's a little longer, but "instance for a bespoke typeclass" feels less ambiguous. > > This is why I hate choosing syntax :) > > I'm going strictly by the dictionary definition of "bespoke" here, which means "tailor-made" or "custom-fit". That means the phrase "bespoke typeclass" doesn't make sense, since "bespoke" is a property of the instance, not the typeclass. Right. (I have no prior relationship with that word myself.) Anyway my point is that at this point in the algorithm, you ''don't'' want to branch on the (not yet) selected instance, but only on the class. This means you might not want to use a syntax ("bespoke typeclass instance") that could imply that "bespoke" is a property of ''that'' instance. > I've reworded it to make it a little clearer, hopefully. My quibbling mind says that "when it would otherwise derive a `bespoke` instance" should be something like "when it supports `bespoke` instances", otherwise there are still corner cases that aren't obviously caught, such as deriving `Foldable` for a newtype with GND, deriving `Enum` for a newtype, or even (when interpreted intuitively) deriving an instance for which bespoke is selected, but the derivation fails for some other reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 01:21:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 01:21:26 -0000 Subject: [GHC] #12468: GADTs don't refine hole types Message-ID: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> #12468: GADTs don't refine hole types -------------------------------------+------------------------------------- Reporter: | Owner: benjamin.hodgson | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Apologies if this is a dupe. I did look! {{{ #!haskell {-# LANGUAGE GADTs #-} data T a where I :: T Int f :: T a -> a f I = _ }}} This gives the type error: {{{ • Found hole: _ :: a Where: ‘a’ is a rigid type variable bound by the type signature for: f :: forall a. T a -> a at test.hs:6:6 • In the expression: _ In an equation for ‘f’: f I = _ • Relevant bindings include f :: T a -> a (bound at test.hs:7:1) }}} It should say something about `a` being `Int` in this branch. I'm using GHC 8.0.1 on OSX El Capitan. I think this may be a regression; I have a vague memory of it working with GHC 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 01:21:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 01:21:50 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.63102663147b357d0b03280085d34516@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:48 oerjan]: > Possibly, it could fit in the middle ''left'' if the table is slightly relabeled, so that the rows tell what to do about GND and the columns tell about general use. Like so: > > |||| ||= No extension required =||||= Requires language extension to use =|| > ||= GND when possible =|| 2(a) || `Eq`, `Ord`, `Ix`, `Bounded` |||| || > ||= GND with extension =|| 2(b) || `Enum` || 2(b) || `Functor`, `Foldable` || > ||= Never select GND =|| 2(c) || `Read`, `Show` || 2(c) || `Data`, `Generic`, `Generic1`, `Typeable`, `Traversable`, `Lift` || > > Which reminds me, I think maybe the word "silly" in step 1 should be "impossible", since after all some very silly things ''are'' allowed, like using anyclass on a class that doesn't support it. Sounds good to me. Updated with both suggestions. > Right. (I have no prior relationship with that word myself.) Anyway my point is that at this point in the algorithm, you ''don't'' want to branch on the (not yet) selected instance, but only on the class. This means you might not want to use a syntax ("bespoke typeclass instance") that could imply that "bespoke" is a property of ''that'' instance. > > My quibbling mind says that "when it would otherwise derive a `bespoke` instance" should be something like "when it supports `bespoke` instances", otherwise there are still corner cases that aren't obviously caught, such as deriving `Foldable` for a newtype with GND, deriving `Enum` for a newtype, or even (when interpreted intuitively) deriving an instance for which bespoke is selected, but the derivation fails for some other reason. I think I can live with the phrase "when deriving a class which supports bespoke instances". I've updated the wiki to use it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 01:31:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 01:31:28 -0000 Subject: [GHC] #12088: Promote data family instance constructors In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.58c1faeae7ba33bdec390d3ee46b988e@haskell.org> #12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:14 simonpj]: > I don't really understand your suggestion Richard. > > Firstly, we often infer the kind of a data type, so it's hard to separate dependence on its kind from dependendence on its definition. I din't undersand the precise dependency analysis that you informally propose. Yes, of course. But I think this is easily dispatched: if we are inferring the kind, then use this rule: * If a datatype's definition depends on the definition of `X`, then its type depends on the type of `X`. I haven't dwelt on this very long, but that seems to capture the nature of types that can be inferred. Here is something toward a specification of my idea: 1. In a datatype definition for `T`: a. Let `X` be a tycon mentioned in `T`'s kind signature or in kind signatures of type variables to `T`. Then `T`'s type depends on `X`'s type and `T`'s definition depends on `X`'s definition. b. Let `K` be a datacon mentioned in `T`'s kind signature or in kind signatures of type variables to `T`. Let `S` be the tycon containing `K`. (`S` might be a data family ''instance'' tycon, too.) Then `T`'s type depends on the definition of `S`. c. Let `X` be a tycon mentioned in the type signature of a datacon in `T`. Then the definition of `T` depends on the type of `X`. In addition, if `T` does not have CUSK, then the type of `T` depends on the type of `X`. d. Let `K` be a datacon (belonging to tycon `S`) mentioned in the type signature of a datacon in `T`. Then the definition of `T` depends on the definition of `S`. In addition, if `T` does not have a CUSK, then the type of `T` depends on the type of `S`. (If `S` is a data family instance tycon, then this last sentence refers to the family for `S`, not the instance tycon, which has no type declaration to depend on.) 2. In a closed type family definition for `C`: a. Let `X` be a tycon mentioned in any kind signature in the head of `C`. Then `C`'s type depends on `X`'s type and `C`'s definition depends on `X`'s definition. b. Let `K` be a datacon (belonging to tycon `S`) mentioned in any kind signature in the head of `C`. Then `C`'s type depends on `X`'s definition. c. Let `X` be a tycon mentioned in any equation for `C`. Then `C`'s definition depends on `X`'s type. In addition, if `C` does not have a CUSK, then `C`'s type depends on `X`s type. d. Let `K` be a datacon (belonging to tycon `S`) mentioned in any equation for `C`. Then `C`'s definition depends on `S`'s definition. In addition, if `C` does not have a CUSK, then `C`'s type depends on `S`'s type. (Or `S`'s family's type, as above.) 3. In the declaration of an open type family `F`: a. Let `X` be a tycon mentioned in any kind signature in the declaration for `F`. Then `F`'s type depends on `X`'s type and `F`'s instance block depends on `X`'s definition. b. Let `K` be a datacon (belonging to tycon `S`) mentioned in the declaration for `F`. then `F`'s type depends on `S`'s type and `F`'s instance block depends on `S`'s definition. 4. In a type family instance for `F`: a. Let `X` by a tycon mentioned in the instance. Then `F`'s instance block depends on `X`'s type. b. Let `K` be a datacon (belonging to tycon `S`) mentioned in the instance. Then `F`'s instance block depends on `S`'s definition. 5. In the declaration of an open data family `D`: a. Let `X` be a tycon mentioned in any kind signature in the declaration for `D`. Then `D`'s type depends on `X`'s type. b. Let `K` be a datacon (belonging to tycon `S`) mentioned in the declaration for `D`. then `D`'s type depends on `S`'s type. 6. In the declaration of a data instance: as for a regular datatype, where the kind signatures are inherited from the data family declaration. Left for another time: classes. Question raised: Data families always have a CUSK because a data family is always open. But might a data family instance ''not'' have a CUSK? What happens then? Perhaps we need to have CUSK analysis on data family instances, too. > > Secondly, I think that open type families are indeed the odd one out, as you acknowledge in the "odd conundrum". I don't see what's gained by separating types from defns even if we could. We gain induction recursion, #11962. Even before this whole discussion, I had the general idea of this separation. See [wiki:DependentHaskell/Internal#Separatingtypesignaturesfromdefinitions this wiki page], written some time ago, on this idea. > > Thirdly, you suggest kind-checking all equations for a type family together as a single group. But you can't do that if they mention data types that have not yet been defined. Yet we can't delay too long ... getting those instances into play early is the whole point. It's true that my approach will sometimes fail when a finer-grained approach would succeed. But I don't think we're trying to get ''every'' use case. We're trying to get a predictable approach that works just about all the time. Here is an example that would fail: {{{ type family F a = r | r -> a data T :: F a -> Type where MkT :: T False type instance F Int = Bool type instance F Char = Proxy MkT }}} The definition of `T` depends on the first instance while the second instance depends on the definition of `T`. I'm not bothered rejecting this. > > Fourth, the dependence may be indirect. In the example, Open2 mentions Open1 directly. But it could instead mention F directly, where F is an open family that has an equation like `type instance F [t] = Open1 t`. Now the dependence on Open1 is hidden. > Isn't this just transitivity? Depending on the "definition" of a type family means dependency on the block of instances -- all of them. So anything an instance depends on is transitively reachable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 01:45:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 01:45:15 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.f4323078f96e56b87545f0cbf7d64a4b@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): According to current practice of making inaccessible code an error, I think the new behavior is more correct than the old one. I think the fix for this is #11066. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 02:11:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 02:11:54 -0000 Subject: [GHC] #12029: Notify user to import * from Data.Kind with TypeInType on In-Reply-To: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> References: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> Message-ID: <066.2af245ec143c27a625c5ff8fbf6c5237@haskell.org> #12029: Notify user to import * from Data.Kind with TypeInType on -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks, John, for looking into this. * `*` is not (yet) deprecated. While I did work with the larger community to come up with the name `Type`, I don't recall getting specific support for deprecating `*`. I do think this is a good direction of travel, but I don't think we should do this without more of a community mandate. * There are no kind synonyms in GHC 7.10 or below. Thus, according to the [https://prime.haskell.org/wiki/Libraries/3-Release-Policy three-release policy] (which isn't a formal operating policy of GHC, I don't think) we should wait until 8.4 before starting to deprecate `*`. * If the community agrees on moving away from `*`, we could add warnings about `*` to `-Wcompat`. * If the community agrees on moving away from `*`, we could also start changing the pretty-printer to use `Type` instead of `*`. This is not to be done lightly, however. There are several issues here: - Blogs, textbooks, etc., have used `*` for a long time. Furthermore, kinds are hard for newcomers to understand. Changing GHC's output will make this harder. - Until 8.4 comes out, it will be hard for a library author to discover that `*` is the right way to spell `Type` that is compatible with three releases. - The use of `*` as a kind is enshrined in the Haskell Reports. These Reports do not specify the error/warning behavior of a compiler, and so this change is not exactly a deviation from a standard. But it continues to make GHC seem as if it's drifting away from the standard with little remorse. * I personally think we should wait at least 5-6 years before formally disposing of `*`. * `-fprint-unicode-syntax` should use the unicode star for as long as we use `*` in regular output. This should be regardless of context. * I like the `NB`. It's for naive users as John suggests. But it also frequently reminds ''me'' to import `Data.Kind`. Frankly, that's why I added it! Please keep it for several releases. See note about blog posts and textbooks, above. * `*` and the unicode star are just ordinary importable symbols with `-XTypeInType`. Nothing more, nothing less. There is no compiler-aware relationship between the two, other than the fact that both are synonyms for `Type`. * Iceland Jack: You started this ticket. Did you come by the reported infelicity (confusing behavior from `:i *`) "honestly"? By this, I mean were you actually confused by GHC's behavior such that you needed different output to make you not confused? Or did you just notice an inconsistency which is, well, infelicitous? I ask because the treatment of `*` in GHC 8 is very much a dirty hack. I think fixing this bug will make it dirtier. If GHC is truly being confusing, then perhaps this is worth it. But I'm not convinced that fixing this is worth it if we're just doing it for the sake of consistency. (Note: I'm not arguing that the current behavior is the best possible behavior!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 03:14:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 03:14:31 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM Message-ID: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> #12469: Memory fence on writeIORef missing on ARM ------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: memory model | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------------+------------------------------------- The memory model question has been debated now and again. his thread from ten years back (https://mail.haskell.org/pipermail/haskell-prime/2006-April/001237.html) lays out the basic situation with thunk update, writeIORef, and memory fences. But we recently began experimenting with GHC on ARM platforms, and it seems to lack a memory fence that the participants in the cited thread expect it to have. Here's an attempt to construct a program which writes fields of a data structure, and then writes the pointer to that structure to an IORef, without the proper fence inbetween: ```Haskell import Data.IORef import Control.Concurrent data Foo = Foo Int deriving Show {-# NOINLINE mkfoo #-} mkfoo x = Foo x {-# NOINLINE dowrite #-} dowrite r n = writeIORef r $! mkfoo n main = do r <- newIORef (Foo 3) forkIO (dowrite r 4) x <- readIORef r print x ``` Here's the relevant bits of the CMM that results when compiled on an ARM 64 machine: ```C mkfoo_rn1_entry() // [] { [] } {offset c40i: P64[MainCapability+872] = P64[MainCapability+872] + 16; if (P64[MainCapability+872] > I64[MainCapability+880]) goto c40m; else goto c40l; c40m: I64[MainCapability+928] = 16; P64[MainCapability+24] = mkfoo_rn1_closure; call (I64[MainCapability+16])(R1) args: 16, res: 0, upd: 8; c40l: I64[P64[MainCapability+872] - 8] = Foo_con_info; P64[P64[MainCapability+872]] = P64[I64[MainCapability+856]]; P64[MainCapability+24] = P64[MainCapability+872] - 7; I64[MainCapability+856] = I64[MainCapability+856] + 8; call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8; } } ``` ```C dowrite_entry() // [] { [] } {offset c44j: call a_r3Dy_entry() args: 24, res: 0, upd: 8; } } a_r3Dy_entry() // [R1] { [] } {offset c41D: if (I64[MainCapability+856] - 16 < I64[MainCapability+864]) goto c41H; else goto c41I; c41H: P64[MainCapability+24] = a_r3Dy_closure; call (I64[MainCapability+16])(R1) args: 24, res: 0, upd: 8; c41I: I64[I64[MainCapability+856] - 8] = block_c41B_info; P64[I64[MainCapability+856] - 16] = P64[I64[MainCapability+856] + 8]; I64[MainCapability+856] = I64[MainCapability+856] - 16; call mkfoo_rn1_entry() args: 16, res: 8, upd: 8; } } block_c41B_entry() // [R1] { [] } {offset c41B: _s3Ep::P64 = P64[I64[MainCapability+856] + 8]; I64[I64[MainCapability+856] + 8] = block_c41G_info; _s3Es::P64 = P64[MainCapability+24]; P64[MainCapability+24] = _s3Ep::P64; P64[I64[MainCapability+856] + 16] = _s3Es::P64; I64[MainCapability+856] = I64[MainCapability+856] + 8; if (P64[MainCapability+24] & 7 != 0) goto u41S; else goto c41K; u41S: call block_c41G_entry(R1) args: 0, res: 0, upd: 0; c41K: call (I64[I64[P64[MainCapability+24]]])(R1) args: 8, res: 8, upd: 8; } } block_c41G_entry() // [R1] { [] } {offset c41G: _s3Ev::P64 = P64[P64[MainCapability+24] + 7]; P64[_s3Ev::P64 + 8] = P64[I64[MainCapability+856] + 8]; call "ccall" arg hints: [PtrHint, PtrHint] result hints: [] dirty_MUT_VAR(MainCapability+24, _s3Ev::P64); P64[MainCapability+24] = ()_closure+1; I64[MainCapability+856] = I64[MainCapability+856] + 16; call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8; } } ``` The fence should happen before the write of the pointer into the IORef. I can't find the fence, and can't find a codepath in the compiler that would insert it (i.e. with MO_WriteBarrier). `dirty_MUT_VAR` is actually too late to perform the fence, but it doesn't either: ```C void dirty_MUT_VAR(StgRegTable *reg, StgClosure *p) { Capability *cap = regTableToCapability(reg); if (p->header.info == &stg_MUT_VAR_CLEAN_info) { p->header.info = &stg_MUT_VAR_DIRTY_info; recordClosureMutated(cap,p); } } ``` (Neither does `recordClosureMutated`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 03:17:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 03:17:08 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.133047d01d548e0366e1808bd67b3039@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------ Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------ Description changed by rrnewton: @@ -1,1 +1,1 @@ - The memory model question has been debated now and again. his + The memory model question has been debated now and again. This @@ -15,1 +15,2 @@ - ```Haskell + {{{ + #!haskell @@ -32,1 +33,1 @@ - ``` + }}} @@ -37,1 +38,2 @@ - ```C + {{{ + #!C @@ -59,1 +61,0 @@ - ``` @@ -61,1 +62,0 @@ - ```C @@ -126,1 +126,1 @@ - ``` + }}} @@ -135,1 +135,2 @@ - ```C + {{{ + #!C @@ -145,1 +146,1 @@ - ``` + }}} New description: The memory model question has been debated now and again. This thread from ten years back (https://mail.haskell.org/pipermail/haskell-prime/2006-April/001237.html) lays out the basic situation with thunk update, writeIORef, and memory fences. But we recently began experimenting with GHC on ARM platforms, and it seems to lack a memory fence that the participants in the cited thread expect it to have. Here's an attempt to construct a program which writes fields of a data structure, and then writes the pointer to that structure to an IORef, without the proper fence inbetween: {{{ #!haskell import Data.IORef import Control.Concurrent data Foo = Foo Int deriving Show {-# NOINLINE mkfoo #-} mkfoo x = Foo x {-# NOINLINE dowrite #-} dowrite r n = writeIORef r $! mkfoo n main = do r <- newIORef (Foo 3) forkIO (dowrite r 4) x <- readIORef r print x }}} Here's the relevant bits of the CMM that results when compiled on an ARM 64 machine: {{{ #!C mkfoo_rn1_entry() // [] { [] } {offset c40i: P64[MainCapability+872] = P64[MainCapability+872] + 16; if (P64[MainCapability+872] > I64[MainCapability+880]) goto c40m; else goto c40l; c40m: I64[MainCapability+928] = 16; P64[MainCapability+24] = mkfoo_rn1_closure; call (I64[MainCapability+16])(R1) args: 16, res: 0, upd: 8; c40l: I64[P64[MainCapability+872] - 8] = Foo_con_info; P64[P64[MainCapability+872]] = P64[I64[MainCapability+856]]; P64[MainCapability+24] = P64[MainCapability+872] - 7; I64[MainCapability+856] = I64[MainCapability+856] + 8; call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8; } } dowrite_entry() // [] { [] } {offset c44j: call a_r3Dy_entry() args: 24, res: 0, upd: 8; } } a_r3Dy_entry() // [R1] { [] } {offset c41D: if (I64[MainCapability+856] - 16 < I64[MainCapability+864]) goto c41H; else goto c41I; c41H: P64[MainCapability+24] = a_r3Dy_closure; call (I64[MainCapability+16])(R1) args: 24, res: 0, upd: 8; c41I: I64[I64[MainCapability+856] - 8] = block_c41B_info; P64[I64[MainCapability+856] - 16] = P64[I64[MainCapability+856] + 8]; I64[MainCapability+856] = I64[MainCapability+856] - 16; call mkfoo_rn1_entry() args: 16, res: 8, upd: 8; } } block_c41B_entry() // [R1] { [] } {offset c41B: _s3Ep::P64 = P64[I64[MainCapability+856] + 8]; I64[I64[MainCapability+856] + 8] = block_c41G_info; _s3Es::P64 = P64[MainCapability+24]; P64[MainCapability+24] = _s3Ep::P64; P64[I64[MainCapability+856] + 16] = _s3Es::P64; I64[MainCapability+856] = I64[MainCapability+856] + 8; if (P64[MainCapability+24] & 7 != 0) goto u41S; else goto c41K; u41S: call block_c41G_entry(R1) args: 0, res: 0, upd: 0; c41K: call (I64[I64[P64[MainCapability+24]]])(R1) args: 8, res: 8, upd: 8; } } block_c41G_entry() // [R1] { [] } {offset c41G: _s3Ev::P64 = P64[P64[MainCapability+24] + 7]; P64[_s3Ev::P64 + 8] = P64[I64[MainCapability+856] + 8]; call "ccall" arg hints: [PtrHint, PtrHint] result hints: [] dirty_MUT_VAR(MainCapability+24, _s3Ev::P64); P64[MainCapability+24] = ()_closure+1; I64[MainCapability+856] = I64[MainCapability+856] + 16; call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8; } } }}} The fence should happen before the write of the pointer into the IORef. I can't find the fence, and can't find a codepath in the compiler that would insert it (i.e. with MO_WriteBarrier). `dirty_MUT_VAR` is actually too late to perform the fence, but it doesn't either: {{{ #!C void dirty_MUT_VAR(StgRegTable *reg, StgClosure *p) { Capability *cap = regTableToCapability(reg); if (p->header.info == &stg_MUT_VAR_CLEAN_info) { p->header.info = &stg_MUT_VAR_DIRTY_info; recordClosureMutated(cap,p); } } }}} (Neither does `recordClosureMutated`.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 03:17:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 03:17:46 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.8ead14df92ced221869cb8d106085a41@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------ Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------ Description changed by rrnewton: @@ -35,1 +35,1 @@ - Here's the relevant bits of the CMM that results when compiled on an + Here are the relevant bits of the CMM that results when compiled on an New description: The memory model question has been debated now and again. This thread from ten years back (https://mail.haskell.org/pipermail/haskell-prime/2006-April/001237.html) lays out the basic situation with thunk update, writeIORef, and memory fences. But we recently began experimenting with GHC on ARM platforms, and it seems to lack a memory fence that the participants in the cited thread expect it to have. Here's an attempt to construct a program which writes fields of a data structure, and then writes the pointer to that structure to an IORef, without the proper fence inbetween: {{{ #!haskell import Data.IORef import Control.Concurrent data Foo = Foo Int deriving Show {-# NOINLINE mkfoo #-} mkfoo x = Foo x {-# NOINLINE dowrite #-} dowrite r n = writeIORef r $! mkfoo n main = do r <- newIORef (Foo 3) forkIO (dowrite r 4) x <- readIORef r print x }}} Here are the relevant bits of the CMM that results when compiled on an ARM 64 machine: {{{ #!C mkfoo_rn1_entry() // [] { [] } {offset c40i: P64[MainCapability+872] = P64[MainCapability+872] + 16; if (P64[MainCapability+872] > I64[MainCapability+880]) goto c40m; else goto c40l; c40m: I64[MainCapability+928] = 16; P64[MainCapability+24] = mkfoo_rn1_closure; call (I64[MainCapability+16])(R1) args: 16, res: 0, upd: 8; c40l: I64[P64[MainCapability+872] - 8] = Foo_con_info; P64[P64[MainCapability+872]] = P64[I64[MainCapability+856]]; P64[MainCapability+24] = P64[MainCapability+872] - 7; I64[MainCapability+856] = I64[MainCapability+856] + 8; call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8; } } dowrite_entry() // [] { [] } {offset c44j: call a_r3Dy_entry() args: 24, res: 0, upd: 8; } } a_r3Dy_entry() // [R1] { [] } {offset c41D: if (I64[MainCapability+856] - 16 < I64[MainCapability+864]) goto c41H; else goto c41I; c41H: P64[MainCapability+24] = a_r3Dy_closure; call (I64[MainCapability+16])(R1) args: 24, res: 0, upd: 8; c41I: I64[I64[MainCapability+856] - 8] = block_c41B_info; P64[I64[MainCapability+856] - 16] = P64[I64[MainCapability+856] + 8]; I64[MainCapability+856] = I64[MainCapability+856] - 16; call mkfoo_rn1_entry() args: 16, res: 8, upd: 8; } } block_c41B_entry() // [R1] { [] } {offset c41B: _s3Ep::P64 = P64[I64[MainCapability+856] + 8]; I64[I64[MainCapability+856] + 8] = block_c41G_info; _s3Es::P64 = P64[MainCapability+24]; P64[MainCapability+24] = _s3Ep::P64; P64[I64[MainCapability+856] + 16] = _s3Es::P64; I64[MainCapability+856] = I64[MainCapability+856] + 8; if (P64[MainCapability+24] & 7 != 0) goto u41S; else goto c41K; u41S: call block_c41G_entry(R1) args: 0, res: 0, upd: 0; c41K: call (I64[I64[P64[MainCapability+24]]])(R1) args: 8, res: 8, upd: 8; } } block_c41G_entry() // [R1] { [] } {offset c41G: _s3Ev::P64 = P64[P64[MainCapability+24] + 7]; P64[_s3Ev::P64 + 8] = P64[I64[MainCapability+856] + 8]; call "ccall" arg hints: [PtrHint, PtrHint] result hints: [] dirty_MUT_VAR(MainCapability+24, _s3Ev::P64); P64[MainCapability+24] = ()_closure+1; I64[MainCapability+856] = I64[MainCapability+856] + 16; call (I64[P64[I64[MainCapability+856]]])(R1) args: 8, res: 0, upd: 8; } } }}} The fence should happen before the write of the pointer into the IORef. I can't find the fence, and can't find a codepath in the compiler that would insert it (i.e. with MO_WriteBarrier). `dirty_MUT_VAR` is actually too late to perform the fence, but it doesn't either: {{{ #!C void dirty_MUT_VAR(StgRegTable *reg, StgClosure *p) { Capability *cap = regTableToCapability(reg); if (p->header.info == &stg_MUT_VAR_CLEAN_info) { p->header.info = &stg_MUT_VAR_DIRTY_info; recordClosureMutated(cap,p); } } }}} (Neither does `recordClosureMutated`.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 07:02:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 07:02:15 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.3b0cd59b7010956b0972291fb8e828d7@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: erikd, trommler (added) * architecture: arm => Unknown/Multiple Comment: IIUC, this is also an issue on PowerPC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 10:10:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 10:10:26 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.3b8f38e8482d7781d96815ce5b12f32a@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * cc: heisenbug (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 10:11:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 10:11:20 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.165f129f9791293ac633e2b9649ca3e9@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * cc: heisenbug (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 10:39:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 10:39:59 -0000 Subject: [GHC] #12465: Evil idea: Allow empty record field update syntax for types. In-Reply-To: <051.24b812ed598c409441e148e921dac8f9@haskell.org> References: <051.24b812ed598c409441e148e921dac8f9@haskell.org> Message-ID: <066.993dafd92e5fe4099992b41cc8f05da9@haskell.org> #12465: Evil idea: Allow empty record field update syntax for types. -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -60,1 +60,1 @@ - @Vector{}` to `show @Vector`, `show @(Vector _n)` or `show @(Vector _n + @Vector{}` as `show @Vector`, `show @(Vector _n)` or `show @(Vector _n New description: Use case: Visible type application. I often work with constructors with many arguments that I want to instantiate type variables with: {{{#!hs show @(Vector _ _) :: Show a => Vector n a -> String -- Type arguments reversed, see https://github.com/ekmett/distributive/pull/18 cotraverse @_ @(Vector _) :: (NATTY n, Functor f) => (f a -> b) -> (f (Vector n a) -> Vector n a') fmap @(Bazaar _ _ _) :: (t -> t') -> (Bazaar p a b t -> Bazaar p a b t') show @(Magma _ _ _ _) :: (Show a, Show i) => Magma i t b a -> String }}} This makes no sense since types have nothing to do with record or updates thereof but that syntax is often used to avoid parentheses and unneeded wildcard arguments: {{{#!hs isBar (Bar _ _ _ _ _) = True -- ===> isBar Bar{} = True }}} This also means you don't need to worry about the kind of your constructor wrt the type (class) variable it instantiates. ---- Thus the proposal is to allow: {{{#!hs show @Vector{} :: Show a => Vector n a -> String cotraverse @_ @Vector{} :: (NATTY n, Functor f) => (f a -> b) -> (f (Vector n a) -> Vector n a') fmap @Bazaar{} :: (t -> t') -> (Bazaar p a b t -> Bazaar p a b t') show @Magma{} :: (Show a, Show i) => Magma i t b a -> String }}} ---- This would save quite a few keystrokes in my daily coding but more importantly it saves cognitive load but I expect raised eyebrows (especially since GHC would have to determine whether to interpret `show @Vector{}` as `show @Vector`, `show @(Vector _n)` or `show @(Vector _n _a)`). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 10:57:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 10:57:00 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.c6057fb24b247661828a7c68970a2e3f@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): D2443 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * status: new => patch * differential: => D2443 Comment: I uploaded a diff which includes my changes. I tried to integrate unrolling the unboxed tuples in the bytecode generator now, which seems to work, but may miss some cases. There may be some points which could be done in a better way, so feel free to point them out and I will change them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 10:58:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 10:58:23 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.84ef32477988df0c39cb660f2b228383@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * differential: D2443 => Phab:D2443 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 11:15:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 11:15:47 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.b8ec6266fcd7ef94ab7ce4549261ffd0@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 12:52:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 12:52:52 -0000 Subject: [GHC] #12470: Move LLVM code generator to LLVM bitcode format Message-ID: <046.2d176265e89a9f069bd8e76d6793e054@haskell.org> #12470: Move LLVM code generator to LLVM bitcode format -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently GHC produces LLVM's textual intermediate representation. While this is easy to produce, it's not the path recommended by LLVM's developers. Instead, they [[http://llvm.org/docs/DeveloperPolicy.html#ir- backwards-compatibility|recommend]] that compilers produce LLVM bitcode, which they maintain much stronger backwards compatibility guarantees on. It seems sensible to move the backend over to this format. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 12:53:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 12:53:13 -0000 Subject: [GHC] #12470: Move LLVM code generator to LLVM bitcode format In-Reply-To: <046.2d176265e89a9f069bd8e76d6793e054@haskell.org> References: <046.2d176265e89a9f069bd8e76d6793e054@haskell.org> Message-ID: <061.c30c81c9318cb6344e218b18a2055f85@haskell.org> #12470: Move LLVM code generator to LLVM bitcode format -------------------------------------+------------------------------------- Reporter: bgamari | Owner: angermann Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => angermann Comment: Moritz Angermann is currently looking into this. Yay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 14:01:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 14:01:34 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.0d28b98ef51a84ea11e215c8fc49e077@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): goldfire, are you saying this code should emit a warning? If so, what can be done to fix the code? FWIW, this bug also prevents the [https://github.com/ekmett/constraints/tree/1649e382b8dffe5e2694d0959caeba65e87a411e constraints] library from building with GHC HEAD, although the bug appears in a slightly different form. Here's a stripped-down example that compiles with GHC 8.0.1, but not GHC HEAD: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module ConstraintsBug where import GHC.TypeLits (Nat) import Unsafe.Coerce (unsafeCoerce) data Dict a where Dict :: a => Dict a newtype a :- b = Sub (a => Dict b) axiom :: forall a b. Dict (a ~ b) axiom = unsafeCoerce (Dict :: Dict (a ~ a)) type Divides n m = n ~ Gcd n m type family Gcd :: Nat -> Nat -> Nat where dividesGcd :: forall a b c. (Divides a b, Divides a c) :- Divides a (Gcd b c) dividesGcd = Sub axiom }}} {{{ $ /opt/ghc/head/bin/ghc ConstraintsBug.hs [1 of 1] Compiling ConstraintsBug ( ConstraintsBug.hs, ConstraintsBug.o ) ConstraintsBug.hs:26:14: error: • Couldn't match type ‘a’ with ‘Gcd a b’ ‘a’ is a rigid type variable bound by the type signature for: dividesGcd :: forall (a :: Nat) (b :: Nat) (c :: Nat). (Divides a b, Divides a c) :- Divides a (Gcd b c) at ConstraintsBug.hs:25:1-77 Inaccessible code in a type expected by the context: (Divides a b, Divides a c) => Dict a ~ Gcd a (Gcd b c) • In the first argument of ‘Sub’, namely ‘axiom’ In the expression: Sub axiom In an equation for ‘dividesGcd’: dividesGcd = Sub axiom • Relevant bindings include dividesGcd :: (Divides a b, Divides a c) :- Divides a (Gcd b c) (bound at ConstraintsBug.hs:26:1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 14:31:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 14:31:55 -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.0c0cf9c0ecc369f18a18b62c4152b9b4@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 14:54:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 14:54:02 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.d4038147c94333fe6bcd1f94aca51a43@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I don't think it is clear from this ticket how this code was expected to work in the past. In previous versions, it was possible to use type signatures like this in order to state that only `Int` could provide a different definition from the default definition. So in Ryan's example, `instance Foo Char` would compile with the default definition for `foo`. This always seemed like a bug too me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 15:04:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 15:04:44 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.269730fb30564a82722352376bd04f5e@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To clarify, I think the `constraints` code is an occurrence of the same bug since 1. `dividesGcd`'s type signature has a context (`Divides a b`, which is the same as `a ~ Gcd a b`) in which GHC determines an equality is unattainable. 2. The body of `dividesGcd` doesn't use the context, since it's defined in terms of `axiom` (a.k.a. `unsafeCoerce`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 16:37:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 16:37:11 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.390c33415b3420da16bdd27c148b7c7a@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: Commit d2958bd08a049b61941f078e51809c7e63bc3354 caused this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 18:54:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 18:54:56 -0000 Subject: [GHC] #12471: Weirdness when using quosiquoter in pattern synonyms / GADT context Message-ID: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> #12471: Weirdness when using quosiquoter in pattern synonyms / GADT context -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TemplateHaskell, PatternSynonyms, | GADTs | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using [https://hackage.haskell.org/package/applicative- quoters-0.1.0.8/docs/Control-Applicative-QQ-Idiom.html idiom brackets], is this a bug? {{{#!hs import Control.Applicative.QQ.Idiom data Exp a where I :: Int -> Exp Int pattern MkI :: Int ~ a => a -> Exp a pattern MkI a = I a c :: Exp a -> IO a c (MkI n) = pure n }}} This works. If I replace `pure n` by `[i| n |]` I get this error: {{{ tKTa.hs:10:4-8: error: … • Couldn't match type ‘a’ with ‘Int’ arising from a pattern ‘a’ is a rigid type variable bound by the type signature for: c :: forall a. Exp a -> IO a at /tmp/tKTa.hs:9:6 • In the pattern: MkI n In an equation for ‘c’: c (MkI n) = (pure n) • Relevant bindings include c :: Exp a -> IO a (bound at /tmp/tKTa.hs:10:1) Compilation failed. }}} This works without the pattern synonym {{{#!hs c :: Exp a -> IO a c (I n) = [i| n |] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 18:55:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 18:55:53 -0000 Subject: [GHC] #12471: Weirdness when using quosiquoter in pattern synonyms / GADT context In-Reply-To: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> References: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> Message-ID: <066.493c8ce9f7c1d3ad8c417fe44e94fe71@haskell.org> #12471: Weirdness when using quosiquoter in pattern synonyms / GADT context -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TemplateHaskell, PatternSynonyms, | GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): It also works if I omit the type signature of `MkI` resulting in the inferred type {{{ >>> :i MkI pattern MkI :: () => t GHC.Prim.~# Int => Int -> Exp t }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 19:00:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 19:00:46 -0000 Subject: [GHC] #12471: Weirdness when using quosiquoter in pattern synonyms / GADT context In-Reply-To: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> References: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> Message-ID: <066.9d366ced7f679ac280895c0bd23bb661@haskell.org> #12471: Weirdness when using quosiquoter in pattern synonyms / GADT context -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TemplateHaskell, PatternSynonyms, | GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -1,1 +1,1 @@ - Using [https://hackage.haskell.org/package/applicative- + ~~Using [https://hackage.haskell.org/package/applicative- @@ -40,0 +40,1 @@ + ~~ New description: ~~Using [https://hackage.haskell.org/package/applicative- quoters-0.1.0.8/docs/Control-Applicative-QQ-Idiom.html idiom brackets], is this a bug? {{{#!hs import Control.Applicative.QQ.Idiom data Exp a where I :: Int -> Exp Int pattern MkI :: Int ~ a => a -> Exp a pattern MkI a = I a c :: Exp a -> IO a c (MkI n) = pure n }}} This works. If I replace `pure n` by `[i| n |]` I get this error: {{{ tKTa.hs:10:4-8: error: … • Couldn't match type ‘a’ with ‘Int’ arising from a pattern ‘a’ is a rigid type variable bound by the type signature for: c :: forall a. Exp a -> IO a at /tmp/tKTa.hs:9:6 • In the pattern: MkI n In an equation for ‘c’: c (MkI n) = (pure n) • Relevant bindings include c :: Exp a -> IO a (bound at /tmp/tKTa.hs:10:1) Compilation failed. }}} This works without the pattern synonym {{{#!hs c :: Exp a -> IO a c (I n) = [i| n |] }}} ~~ -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 19:11:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 19:11:13 -0000 Subject: [GHC] #12471: Weirdness when using quosiquoter in pattern synonyms / GADT context In-Reply-To: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> References: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> Message-ID: <066.df3035d4ee47cc6b4537505392291365@haskell.org> #12471: Weirdness when using quosiquoter in pattern synonyms / GADT context -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TemplateHaskell, PatternSynonyms, | GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -1,1 +1,1 @@ - ~~Using [https://hackage.haskell.org/package/applicative- + Using [https://hackage.haskell.org/package/applicative- @@ -8,8 +8,2 @@ - data Exp a where - I :: Int -> Exp Int - - pattern MkI :: Int ~ a => a -> Exp a - pattern MkI a = I a - - c :: Exp a -> IO a - c (MkI n) = pure n + c :: Int -> IO Integer + c n = [i| fromIntegral n::Integer |] @@ -18,1 +12,1 @@ - This works. If I replace `pure n` by `[i| n |]` I get this error: + This works. Removing the type annotation: @@ -20,0 +14,6 @@ + {{{#!hs + import Control.Applicative.QQ.Idiom + + c :: Int -> IO Integer + c n = [i| fromIntegral n |] + }}} @@ -21,10 +21,5 @@ - tKTa.hs:10:4-8: error: … - • Couldn't match type ‘a’ with ‘Int’ arising from a pattern - ‘a’ is a rigid type variable bound by - the type signature for: - c :: forall a. Exp a -> IO a - at /tmp/tKTa.hs:9:6 - • In the pattern: MkI n - In an equation for ‘c’: c (MkI n) = (pure n) - • Relevant bindings include - c :: Exp a -> IO a (bound at /tmp/tKTa.hs:10:1) + t0sj.hs:4:10-27: error: … + • Couldn't match expected type ‘IO Integer’ with actual type ‘Int’ + • In the second argument of ‘(<*>)’, namely ‘n’ + In the expression: (((pure fromIntegral) <*> n)) + In an equation for ‘c’: c n = (((pure fromIntegral) <*> n)) @@ -33,8 +28,0 @@ - - This works without the pattern synonym - - {{{#!hs - c :: Exp a -> IO a - c (I n) = [i| n |] - }}} - ~~ New description: Using [https://hackage.haskell.org/package/applicative- quoters-0.1.0.8/docs/Control-Applicative-QQ-Idiom.html idiom brackets], is this a bug? {{{#!hs import Control.Applicative.QQ.Idiom c :: Int -> IO Integer c n = [i| fromIntegral n::Integer |] }}} This works. Removing the type annotation: {{{#!hs import Control.Applicative.QQ.Idiom c :: Int -> IO Integer c n = [i| fromIntegral n |] }}} {{{ t0sj.hs:4:10-27: error: … • Couldn't match expected type ‘IO Integer’ with actual type ‘Int’ • In the second argument of ‘(<*>)’, namely ‘n’ In the expression: (((pure fromIntegral) <*> n)) In an equation for ‘c’: c n = (((pure fromIntegral) <*> n)) Compilation failed. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 19:11:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 19:11:47 -0000 Subject: [GHC] #12471: Weirdness when using fromIntegral in quosiquoter (was: Weirdness when using quosiquoter in pattern synonyms / GADT context) In-Reply-To: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> References: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> Message-ID: <066.cb7183634618356f29695bd19f4995a3@haskell.org> #12471: Weirdness when using fromIntegral in quosiquoter -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * keywords: TemplateHaskell, PatternSynonyms, GADTs => TemplateHaskell * cc: mpickering (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 20:10:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 20:10:51 -0000 Subject: [GHC] #12472: "lazy" is not optimized away Message-ID: <045.7d7b50e8f2304c6383051ada9816b306@haskell.org> #12472: "lazy" is not optimized away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{ import GHC.Magic {-# INLINE f #-} f x = True g = lazy f False }}} Two things should happen: (1) f should not be inlined, but (2) lazy should not be present in final STG (having been eliminated in core prep). I thought this was briefly working on HEAD, but apparently it never worked at all: {{{ ezyang at sabre:~$ ghc-8.0 -c test.hs -ddump-stg -fforce-recomp -O2 ==================== STG syntax: ==================== Test.f [InlPrag=INLINE (sat-args=1)] :: forall t_axB. t_axB -> GHC.Types.Bool [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType , Unf=OtherCon []] = \r srt:SRT:[] [eta_sHD] GHC.Types.True []; Test.g :: GHC.Types.Bool [GblId, Str=DmdType] = \u srt:SRT:[] [] GHC.Magic.lazy Test.f GHC.Types.False; }}} Clearly it has not been eliminated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 20:48:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 20:48:28 -0000 Subject: [GHC] #12472: "lazy" is not optimized away In-Reply-To: <045.7d7b50e8f2304c6383051ada9816b306@haskell.org> References: <045.7d7b50e8f2304c6383051ada9816b306@haskell.org> Message-ID: <060.8939663b90b6e77ae58120dd52e72054@haskell.org> #12472: "lazy" is not optimized away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2444 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D2444 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 6 22:26:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Aug 2016 22:26:07 -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.43012bd46ec66723b4ceb07391cab466@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 (LLVM) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 9268 Related Tickets: | Differential Rev(s): Phab:D150 -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"6fe235543de7ea4319269f164ea444e4af68f759/ghc" 6fe2355/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6fe235543de7ea4319269f164ea444e4af68f759" configure.ac: Remove checks for bug 9439 Bug #9439 only affects some ghc 7.8 versions of the compiler and since git HEAD no longer builds with ghc-7.8 we can drop this check. Test Plan: Works here! Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2427 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 7 09:18:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Aug 2016 09:18:12 -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.98bb38f082e1c04f1e7e86fbad7a0abe@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): As -feaged-blackholing helps for this case how would one find out statistics of closures needlessly computed multiple times? One of 'unsafeDupable' examples that might be heavyweight when done multiple times: http://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/GHC/Fingerprint.hs#l45 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 7 11:09:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Aug 2016 11:09:04 -0000 Subject: [GHC] #11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int" In-Reply-To: <051.ef9fc6a373cf8eba53b7bf79d29ca288@haskell.org> References: <051.ef9fc6a373cf8eba53b7bf79d29ca288@haskell.org> Message-ID: <066.e99a21612178f5c6e5e64da726908ce5@haskell.org> #11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: drobnik Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #3155 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by drobnik): * owner: => drobnik -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 7 11:56:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Aug 2016 11:56:35 -0000 Subject: [GHC] #12151: GHC 8 allows ambiguous type without AllowAmbiguousTypes In-Reply-To: <045.025d1a9dae2fe540211f842ca4b9eb91@haskell.org> References: <045.025d1a9dae2fe540211f842ca4b9eb91@haskell.org> Message-ID: <060.92fbba222f7f2443926e780328dcfb94@haskell.org> #12151: GHC 8 allows ambiguous type without AllowAmbiguousTypes -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_fail/T12151 Blocked By: | Blocking: Related Tickets: #7437 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 8540c65a61e92e9c4bedb934c241e8e3eaa67047. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 7 11:57:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Aug 2016 11:57:15 -0000 Subject: [GHC] #12076: "lazy" leads to undefined reference to `stg_ap_0_upd_info' In-Reply-To: <045.45bfd5a6dee62b13780515de863d4289@haskell.org> References: <045.45bfd5a6dee62b13780515de863d4289@haskell.org> Message-ID: <060.36036e6d2b8af30dc48eb0814866237e@haskell.org> #12076: "lazy" leads to undefined reference to `stg_ap_0_upd_info' -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2309 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 2a9767ed596679ddf21b7edfa9fc6410443c2a01. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 7 11:57:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Aug 2016 11:57:48 -0000 Subject: [GHC] #9517: hp2ps generates invalid postscript file In-Reply-To: <045.a830b70a270e850cd0392ed106ef100c@haskell.org> References: <045.a830b70a270e850cd0392ed106ef100c@haskell.org> Message-ID: <060.79d1d1b9aa9f5a85edd639067d9f60cc@haskell.org> #9517: hp2ps generates invalid postscript file -------------------------------------+------------------------------------- Reporter: JamesM | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Profiling | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2398 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 11200a08a14751c59ee70018c5078e85abebdb2f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 7 11:58:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Aug 2016 11:58:46 -0000 Subject: [GHC] #7105: Better names for derived SCCs of instances In-Reply-To: <042.2fbb06d1a4b326bebe4b64cda6396110@haskell.org> References: <042.2fbb06d1a4b326bebe4b64cda6396110@haskell.org> Message-ID: <057.cfefcf979df2eee9374d4117edecfec5@haskell.org> #7105: Better names for derived SCCs of instances -------------------------------------+------------------------------------- Reporter: ksf | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Profiling | Version: 7.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11543 | Differential Rev(s): Phab:D2282 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged as 7fc7538fffb9ad4ad2132a8a9ef8cb6543d0b2fc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 7 12:17:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Aug 2016 12:17:39 -0000 Subject: [GHC] #12007: Panic when loading file with nested pattern synonyms into ghci In-Reply-To: <050.6ea75b00ffb245107acfb719a89b7ff6@haskell.org> References: <050.6ea75b00ffb245107acfb719a89b7ff6@haskell.org> Message-ID: <065.fb1cbb542f6d92c18cc8871fd7c169e2@haskell.org> #12007: Panic when loading file with nested pattern synonyms into ghci -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T12007 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 7 12:18:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Aug 2016 12:18:25 -0000 Subject: [GHC] #12172: User's Guide patches In-Reply-To: <045.d9fd99bb9812ed72dd7f0ce1c87b5bc1@haskell.org> References: <045.d9fd99bb9812ed72dd7f0ce1c87b5bc1@haskell.org> Message-ID: <060.78dc77dbf58b3321e7bfe9ea9b4a457e@haskell.org> #12172: User's Guide patches -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 7 15:23:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Aug 2016 15:23:49 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.b97cc591def484bbf8554286baff1b45@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9/ghc" 773e3aad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="773e3aadac4bbee9a0173ebc90ffdc9458a2a3a9" T1969: Enable it again but bump the max residency temporarily T1969 was broken by 714beb (which actually reduced allocations but residency was increased). Instead of disabling it completely, just bump the number a little bit to avoid making things even worse in the meantime. See also #12437. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 7 15:57:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Aug 2016 15:57:24 -0000 Subject: [GHC] #12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies Message-ID: <044.06f71dc396e1085735f13966136f6b82@haskell.org> #12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies -------------------------------------+------------------------------------- Reporter: dylex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{ {-# LANGUAGE DefaultSignatures, FunctionalDependencies, ScopedTypeVariables #-} class Foo a b where foo :: a -> b -> Int class Bar a b | b -> a where get :: b -> a bar :: b -> Int default bar :: Foo a b => b -> Int bar b = foo (get b :: a) b }}} This works fine with ghc 7.10.3 (even without the explicit :: a type spec), but with 8.0.1, produces: {{{ - Could not deduce (Foo a0 b) from the context: Foo a b bound by the type signature for: bar :: Foo a b => b -> Int at t.hs:6:3-17 The type variable `a0'€™ is ambiguous - In the ambiguity check for `bar'™ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: bar :: forall a b. Bar a b => b -> Int In the class declaration for `Bar'€™ }}} Not sure if this is intentional or some good way to get around it, but I couldn't find anything related to it in the release notes or any similar looking bugs. (Real-life case: https://github.com/dylex/postgresql- typed/blob/master/Database/PostgreSQL/Typed/Dynamic.hs#L48 ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 8 03:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Aug 2016 03:26:51 -0000 Subject: [GHC] #12474: Regression: Syntax error in -ddump-minimal-imports for records in GHC 8.0 Message-ID: <042.a524b4a6c3164cd796982501b5b54c85@haskell.org> #12474: Regression: Syntax error in -ddump-minimal-imports for records in GHC 8.0 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found a bug in GHC 8.0.1. File: {{{ import Data.Version main = print (versionBranch undefined, versionTags undefined) }}} Run: {{{ ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs -ddump- minimal-imports && cat Main.imports import Data.Version ( Version(versionTags versionBranch) ) }}} See how there's a comma missing after `versionTags`? This happens for all record functions. It works fine in GHC 7.10.3: {{{ ~/.stack/programs/x86_64-linux/ghc-7.10.3/bin/ghc --make Main.hs -ddump- minimal-imports && cat Main.imports import Data.Version ( Version(versionBranch, versionTags) ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 8 04:31:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Aug 2016 04:31:02 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.b3575cecaed7e7bd7d64066e060fe007@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by konn): I need more flexible control on `-Wredundant-constraints`, too. I'm currently maintaining library to provide algebraic structures. In such a situation, we need '''empty''' class without any member function to express the additional algebraic constraint. Suppose we have following classes: {{{ class Multiplicative r where (*) :: r -> r -> r class Commutative r -- without any member functions! }}} Until here, everything goes well. Suppose we want to write algorithm relying on the commutativity of multiplication: {{{ myGreatAlgorithm :: (Commutative r) => r -> r myGreatAlgorithm = ... }}} Then GHC warns about `Commutative r` as a "redundant constraint", although it is essentially needed to work algorithm properly. Since `Commutative` class doesn't have any member functions, workaround adding "dead code", which is introduced in GHC users' guide, doesn't work at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 8 07:23:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Aug 2016 07:23:04 -0000 Subject: [GHC] #12475: GHCi no longer handles stdin being closed gracefully Message-ID: <049.ca21f0f7906ff6f7363978996c951710@haskell.org> #12475: GHCi no longer handles stdin being closed gracefully -------------------------------------+------------------------------------- Reporter: rowanblush | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It used to be the case that GHCi handled the user closing stdin gracefully, continuing to accept input and restoring stdin on :reload (as is documented in the GHC Users Guide GHCi FAQ (1)). This was the case in 7.6.3, but at least as of 7.8.4 GHCi now dies immediately after printing the prompt following usage of `getContents`. I'm using NixOs version 16.03.1171.9cb194c (Emu). I don't believe this to be a nix- or nixpkgs-related problem, but I don't have any other machines on which to test. I test 7.6.3, 7.8.4, 7.10.3 and 8.0.1 below. {{{ #!sh [rowanblush at coquelicot:~] +$ nix-shell -p haskell.packages.ghc763.ghc --command "ghci" --pure GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> getContents >> return () Prelude> getLine *** Exception: : hGetLine: illegal operation (handle is closed) Prelude> :reload Ok, modules loaded: none. Prelude> getLine echo "echo" Prelude> :q Leaving GHCi. [rowanblush at coquelicot:~] :$ nix-shell -p haskell.packages.ghc784.ghc --command "ghci" --pure GHCi, version 7.8.4: 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> getContents >> return () Prelude> : hGetChar: illegal operation (handle is closed) [rowanblush at coquelicot:~] +$ nix-shell -p haskell.packages.ghc7103.ghc --command "ghci" --pure GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> getContents >> return () Prelude> : hGetChar: illegal operation (handle is closed) [rowanblush at coquelicot:~] +$ nix-shell -p haskell.packages.ghc801.ghc --command "ghci" --pure GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rowanblush/.ghci Prelude> getContents >> return () Prelude> : hGetChar: illegal operation (handle is semi-closed) [rowanblush at coquelicot:~] +$ }}} (1): https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html #faq-and-things-to-watch-out-for -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 8 08:03:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Aug 2016 08:03:24 -0000 Subject: [GHC] #11551: Get doctests into testsuite In-Reply-To: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> References: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> Message-ID: <057.961d16b824087f4364026278e140bf81@haskell.org> #11551: Get doctests into testsuite -------------------------------------+------------------------------------- Reporter: lwm | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | documentation, doctest Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): lwm, is the trouble just integration into the build system or is there a deeper issue here? I quickly tried running `doctest` on some modules in `base` and very quickly ran into issues with multiple `base` versions (e.g. GHC desugared `do` syntax to imply a constraint of the `Monad` class provided by the compiler, not the `Monad` class provided by the `base` library which I was building. This suggests to me that even getting `doctest` running against `base` will take some effort by someone. Have you had different experiences, lwm? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 8 08:44:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Aug 2016 08:44:53 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.d84f1d2038c5554bacc151545bbff705@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): I have another example: The package `llvm-tf` (derived from `llvm`) uses type classes without methods in order to formalize the type restrictions set by the LLVM framework. E.g. `IsPrimitive` is the class for types of elements of vectors, `IsArithmetic` is the class for types supporting addition, multiplication and so on. However, only their super class `IsType` has a method `typeDesc :: Proxy a -> TypeDesc` that returns the `LLVM` structure for the according type. The LLVM function for addition takes this `TypeDesc` and it could in principle hold a non-Arithmetic type. We exclude this using the `IsArithmetic` class, but there is no `IsArithmetic` method to call that would force us to restrict the LLVM additon function to Arithmetic types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 8 09:04:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Aug 2016 09:04:37 -0000 Subject: [GHC] #12476: Error building HList Message-ID: <055.28ab9fc1ee273486170008eb9c974eb4@haskell.org> #12476: Error building HList -------------------------------------+------------------------------------- Reporter: | Owner: DanielWaterworth | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ [21 of 28] Compiling Data.HList.Labelable ( Data/HList/Labelable.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Data/HList/Labelable.o ) /home/dan/fun/HList/Data/HList/Labelable.hs:137:9: warning: [-Wredundant- constraints] • Redundant constraints: (LabeledOpticF ty f, LabeledOpticP ty p) • In the type signature for: hLens' :: (ty ~ LabelableTy LabeledR, LabeledOpticF ty f, LabeledOpticP ty p, LabeledOpticTo ty x to) => Label x -> to (p a (f b)) (p (LabeledR s) (f (LabeledR t))) In the instance declaration for ‘Labelable x LabeledR s t a b’ /home/dan/fun/HList/Data/HList/Labelable.hs:211:10: warning: [-Wredundant- constraints] • Redundant constraint: ToSym (a b c) x • In the instance declaration for ‘EnsureLabel (a b c) (Label x)’ /home/dan/fun/HList/Data/HList/Labelable.hs:277:10: warning: [-Wredundant- constraints] • Redundant constraint: HRLabelSet bs • In the instance declaration for ‘Projected Record s t a b’ /home/dan/fun/HList/Data/HList/Labelable.hs:332:10: warning: [-Wredundant- constraints] • Redundant constraint: ToSym (to p q) x • In the instance declaration for ‘HExtend (to p q) (Proxy '[])’ /home/dan/fun/HList/Data/HList/Labelable.hs:337:10: warning: [-Wredundant- constraints] • Redundant constraint: ToSym (to p q) x • In the instance declaration for ‘HExtend (to p q) (Proxy (x : xs))’ /home/dan/fun/HList/Data/HList/Labelable.hs:344:10: warning: [-Wredundant- constraints] • Redundant constraint: ToSym (to p q) x • In the instance declaration for ‘HExtend (to p q) (Proxy (Lbl n ns desc : xs))’ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): pprIfaceCo Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is the version I was building: https://github.com/DanielWaterworth/HList/tree/66643fb75771e71192ab380e4f2ed56e37650f07 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 8 09:07:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Aug 2016 09:07:24 -0000 Subject: [GHC] #12476: Error building HList In-Reply-To: <055.28ab9fc1ee273486170008eb9c974eb4@haskell.org> References: <055.28ab9fc1ee273486170008eb9c974eb4@haskell.org> Message-ID: <070.438858cfcc61830a31afe10521c1fd56@haskell.org> #12476: Error building HList -------------------------------------+------------------------------------- Reporter: DanielWaterworth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by DanielWaterworth: @@ -51,0 +51,2 @@ + + This may be a duplicate of https://ghc.haskell.org/trac/ghc/ticket/12242 New description: {{{ [21 of 28] Compiling Data.HList.Labelable ( Data/HList/Labelable.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Data/HList/Labelable.o ) /home/dan/fun/HList/Data/HList/Labelable.hs:137:9: warning: [-Wredundant- constraints] • Redundant constraints: (LabeledOpticF ty f, LabeledOpticP ty p) • In the type signature for: hLens' :: (ty ~ LabelableTy LabeledR, LabeledOpticF ty f, LabeledOpticP ty p, LabeledOpticTo ty x to) => Label x -> to (p a (f b)) (p (LabeledR s) (f (LabeledR t))) In the instance declaration for ‘Labelable x LabeledR s t a b’ /home/dan/fun/HList/Data/HList/Labelable.hs:211:10: warning: [-Wredundant- constraints] • Redundant constraint: ToSym (a b c) x • In the instance declaration for ‘EnsureLabel (a b c) (Label x)’ /home/dan/fun/HList/Data/HList/Labelable.hs:277:10: warning: [-Wredundant- constraints] • Redundant constraint: HRLabelSet bs • In the instance declaration for ‘Projected Record s t a b’ /home/dan/fun/HList/Data/HList/Labelable.hs:332:10: warning: [-Wredundant- constraints] • Redundant constraint: ToSym (to p q) x • In the instance declaration for ‘HExtend (to p q) (Proxy '[])’ /home/dan/fun/HList/Data/HList/Labelable.hs:337:10: warning: [-Wredundant- constraints] • Redundant constraint: ToSym (to p q) x • In the instance declaration for ‘HExtend (to p q) (Proxy (x : xs))’ /home/dan/fun/HList/Data/HList/Labelable.hs:344:10: warning: [-Wredundant- constraints] • Redundant constraint: ToSym (to p q) x • In the instance declaration for ‘HExtend (to p q) (Proxy (Lbl n ns desc : xs))’ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): pprIfaceCo Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is the version I was building: https://github.com/DanielWaterworth/HList/tree/66643fb75771e71192ab380e4f2ed56e37650f07 This may be a duplicate of https://ghc.haskell.org/trac/ghc/ticket/12242 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 8 16:26:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Aug 2016 16:26:49 -0000 Subject: [GHC] #12477: Allow left sectioning and tuple sectioning of types Message-ID: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> #12477: Allow left sectioning and tuple sectioning of types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simple syntactic change that would be fine to have, allow writing the type `(•) r` as `(r •)`. Just getting a discussion going === Usage === Used briefly in > This gives rise to the monad `S -> (-, S)` the state monad. According to the facts above, we should have that `Codensity (s ->)` (excuse the sectioning) is the same as state, and if we look, we see: > > — [http://comonad.com/reader/2012/unnatural-transformations-and- quantifiers/ The Comonad.Reader] on Unnatural Transformations and Quantifiers === Visible type application === Makes visible type application seem nicer: {{{#!hs fmap @_ @_ @((:-) _) :: (b :- b') -> (a :- b) -> (a :- b') fmap @_ @_ @((->) _) :: (b -> b') -> (a -> b) -> (a -> b') -- vs fmap @_ @_ @(_ :-) :: (b :- b') -> (a :- b) -> (a :- b') fmap @_ @_ @(_ ->) :: (b -> b') -> (a -> b) -> (a -> b') }}} === Examples === {{{#!hs instance Functor ((->) r) instance Functor ((,) a) instance Copointed ((,,) a b) instance Copointed ((,,) a b c) instance Magnify ((->) b) ((->) a) b a where type instance Key ((:->:) a) = a instance HasTrie e => Lookup ((:->:) e) where instance Memo a => Functor ((~>) a) where instance Functor ((&) a) where type Dom ((&) a) = (:-) type Cod ((&) a) = (:-) instance Functor ((:-) a) where type Dom ((:-) a) = (:-) type Cod ((:-) a) = (->) fmap = (.) instance Functor ((:~:) a) where type Dom ((:~:) a) = (:~:) type Cod ((:~:) a) = (->) fmap = (.) instance Adjunction ((,)a) ((->)a) (->) (->) where }}} becomes {{{#!hs instance Functor (r ->) instance Functor (a,) instance Copointed (a, b,) instance Copointed (a, b, c,) instance Magnify (b ->) (a ->) b a where type instance Key (a :->:) = a instance HasTrie e => Lookup (e :->:) where instance Memo a => Functor (a ~>) where instance Functor (a &) where type Dom (a &) = (:-) type Cod (a &) = (:-) instance Functor (a :-) where type Dom (a :-) = (:-) type Cod (a :-) = (->) fmap = (.) instance Functor (a :~:) where type Dom (a :~:) = (:~:) type Cod (a :~:) = (->) fmap = (.) instance Adjunction (a ,) (a ->) (->) (->) where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 8 21:20:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Aug 2016 21:20:39 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.11e3f9631c8d0cc3a892569fa5334177@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think comment:4 is unrelated. (But let's not lose the fact that there is a terrible pretty-printing bug there, without parentheses around the equality argument to `Dict`.) The commit in comment:7 is all about instances, and comment:4 is unrelated to instances. Yes, I think the original code should produce a warning. To suppress the warning, the user should include an implementation of `foo`, so that the generic-default implementation (which has the wrong type) is not used. But if inaccessible code is an error, then the original code should produce an error, just as it is now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 8 23:27:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Aug 2016 23:27:00 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.07607e06380888e2849b4102177349ef@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Huh, I didn't think that manually implementing `foo` would fix the issue, but sure enough, this compiles without warnings on GHC HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where class Foo a where foo :: (a ~ Int => Int) -> a -> a foo _ a2 = a2 instance Foo Char where foo _ a2 = a2 }}} What I don't understand is how this code is any different from the default implementation. If the default implementation succeeds or fails, shouldn't copy-and-pasting it behave likewise? Even stranger, adding the type signature manually via `InstanceSigs` causes it to fail to typecheck again: {{{#!hs {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where class Foo a where foo :: (a ~ Int => Int) -> a -> a foo _ a2 = a2 instance Foo Char where foo :: (Char ~ Int => Int) -> Char -> Char foo _ a2 = a2 }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:10: error: • Couldn't match type ‘Char’ with ‘Int’ Inaccessible code in the type signature for: foo :: Char ~ Int => Int • In the ambiguity check for ‘foo’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: foo :: (Char ~ Int => Int) -> Char -> Char In the instance declaration for ‘Foo Char’ Bug.hs:11:10: error: • Couldn't match type ‘Char’ with ‘Int’ Inaccessible code in the type signature for: foo :: Char ~ Int => Int • When checking that instance signature for ‘foo’ is more general than its signature in the class Instance sig: (Char ~ Int => Int) -> Char -> Char Class sig: (Char ~ Int => Int) -> Char -> Char In the instance declaration for ‘Foo Char’ }}} So I'm quite lost as to what's happening, and moreover, what //should// happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 00:41:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 00:41:54 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi In-Reply-To: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> References: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> Message-ID: <059.b2a135fb309bec9855104aa4f5eaeef6@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * owner: => mniip -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 01:49:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 01:49:22 -0000 Subject: [GHC] #12088: Promote data family instance constructors In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.e587b79f7f7fd2f4a4093e71c95708bb@haskell.org> #12088: Promote data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexvieth): I'm still trying to grok the latest comments but in the meantime I want to offer an idea similar to this one: > Another idea: when we have a group of type instance decls, suppose we kind check them, but do not yet solve the kind equalities that arise; but add them to the instance environment anyway. Now solve all the kind equalities. In our example, we'd add both instances for Open1 and Open2 before trying to solve their kind equalities. Seems a bit scary somehow. This doesn't seem scary to me. What if we don't even kind check them before adding their equalities to the environment? Just assume they're well-kinded while checking the other declarations. This way, we don't have to make sure the open type family instances come as early as possible in the order. 1. Do SCC analysis on all declarations except for open type family instances, to give ordered `TyClGroup`s and the set of those instances (in source file order). 2. Before checking the `TyClGroup`s, put all equalities arising from the open type family instances into the environment (assume for now that they're well-kinded). 3. Check the `TyClGroup`s in order as usual. 4. Check the open type family instances (verifying or falsifying the assumption in 2). Maybe this is nonsense. Would it be possible to make and use a coercion axiom without kind checking the lhs and rhs types? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 02:14:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 02:14:48 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi In-Reply-To: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> References: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> Message-ID: <059.b099178347fe6598244fdfa335e610fc@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * differential: => D2447 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 02:15:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 02:15:25 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi In-Reply-To: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> References: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> Message-ID: <059.dfeb40e829a12a12605ec85c00308f15@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2439 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * differential: D2447 => Phab:D2439 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 02:16:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 02:16:09 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi In-Reply-To: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> References: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> Message-ID: <059.d7d6b57d03d5e23888fec8c2f3ed3375@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * differential: Phab:D2439 => Phab:D2447 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 02:41:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 02:41:10 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.cb090bda3669e744834aa8335a18d36d@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): As described in [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #class-default-signatures the manual], a generic-default type signature (that is, one using the `default` keyword in a class definition) is ''more specific'' than the "normal" type signature for a class method. When no implementation is given for a method in an instance declaration, the default implementation is typechecked against the generic-default type signature. In the code in the Description, this typecheck fails. On the other hand, if we provide an implementation for `foo`, the generic- default signature is not consulted in the instance declaration, and so there is no problem. When you add an `InstanceSigs` signature, then you're just writing a fresh signature that fails to typecheck. Your new signature is utterly unrelated to the generic-default signature. Does this help to clarify? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 02:45:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 02:45:59 -0000 Subject: [GHC] #12471: Weirdness when using fromIntegral in quosiquoter In-Reply-To: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> References: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> Message-ID: <066.d5083614439843d4ff1574ae6b36c3bf@haskell.org> #12471: Weirdness when using fromIntegral in quosiquoter -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): What makes you think this is a GHC bug and not a bug in the implementation of `i`? Alternatively, what's the behavior when you paste in the output of `-ddump-splices`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 02:50:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 02:50:00 -0000 Subject: [GHC] #12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies In-Reply-To: <044.06f71dc396e1085735f13966136f6b82@haskell.org> References: <044.06f71dc396e1085735f13966136f6b82@haskell.org> Message-ID: <059.c2f4dfdfc646a8c95a2db56f6158acf9@haskell.org> #12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies -------------------------------------+------------------------------------- Reporter: dylex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): There is a fine workaround: `-XAllowAmbiguousTypes`, as the error message suggests. But I tend to agree that this is incorrect behavior by GHC: should we be doing an ambiguity check on generic-default signatures? I think not. Why not? Because we never call a function with the type given by a generic-default signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 13:11:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 13:11:30 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.80eb0c4cf662adadd71e0c31c1d7ccc7@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This example isn't using `DefaultSignatures` at all. That is, it's using a default method (which is Haskell 98), but not a //generic// default method (which requires a language extension). Moreover, the (non-generic) default method I gave is //exactly// the same as the manual implementation, yet one typechecks and the other doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 13:27:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 13:27:15 -0000 Subject: [GHC] #12220: TypeApplications and DefaultSignatures - problems deducing type variables. In-Reply-To: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> References: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> Message-ID: <062.56a6837a589149d823f6c656f318cf7f@haskell.org> #12220: TypeApplications and DefaultSignatures - problems deducing type variables. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | DefaultSignatures, TypeApplications Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | generics/T12220 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This isn't quite non-invasive, since it's causing some packages to fail to compile on GHC HEAD that were compiling on GHC 8.0.1. See #12466. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 13:32:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 13:32:08 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.5ea245308a93e9e646f459296762b279@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, I think I've got a hunch why this code is failing all of a sudden starting with GHC HEAD. As I mentioned earlier, this code was typechecking just fine up until d2958bd08a049b61941f078e51809c7e63bc3354. You can see what code ghc is filling in with `-ddump-deriv`: {{{ $ /opt/ghc/head/bin/ghc Bug.hs -ddump-deriv [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ==================== Filling in method body ==================== Bug.Foo [GHC.Types.Char] Bug.foo = Bug.$dmfoo @GHC.Types.Char }}} If I try to implement something like `$dmfoo` manually, I can get the same error: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} module Bug where class Foo a where foo :: (a ~ Int => Int) -> a -> a foo = fooDefault fooDefault :: (a ~ Int => Int) -> a -> a fooDefault _ a2 = a2 instance Foo Char where foo = fooDefault @Char }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:14:9: error: • Couldn't match type ‘Char’ with ‘Int’ Inaccessible code in a type expected by the context: Char ~ Int => Int • In the expression: fooDefault @Char In an equation for ‘foo’: foo = fooDefault @Char In the instance declaration for ‘Foo Char’ }}} So it's apparent that this behavior is different from before. Unfortunately, `-ddump-deriv` doesn't output this defaulting information on GHC 8.0.1 and earlier, so all we have to work with is `-ddump-simpl`. Compiling the original program with `-ddump-simpl` on GHC 8.0.1 yields: {{{ -- RHS size: {terms: 3, types: 7, coercions: 0} $cfoo_rCm :: ((Char :: *) ~ (Int :: *) => Int) -> Char -> Char [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType] $cfoo_rCm = \ _ [Occ=Dead] (a2_aBf :: Char) -> a2_aBf -- RHS size: {terms: 1, types: 0, coercions: 3} Bug.$fFooChar [InlPrag=INLINE (sat-args=0)] :: Foo Char [GblId[DFunId(nt)], Arity=2, Caf=NoCafRefs, Str=DmdType] Bug.$fFooChar = $cfoo_rCm `cast` (Sym (Bug.N:Foo[0] _N) :: ((((Char :: *) ~ (Int :: *) => Int) -> Char -> Char) :: *) ~R# (Foo Char :: Constraint)) }}} I'm not sure if I'm reading that correctly, but I //think// that instead of defining `$cfoo_rCm` in terms of `$dmfoo`, GHC is inlining the definition of `$dmfoo` directly into `$cfoo` (which has so far accounted for the difference between a succesfully typechecked program and one that fails). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 13:39:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 13:39:23 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.0b6da1c8e8d5e3c85097c0c8ee39eeec@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ekmett (added) Comment: Sorry, my previous estimate was off the mark. It's not that the definition of `$dmfoo` is being inlined. Rather, after reading d2958bd08a049b61941f078e51809c7e63bc3354 more closely, the real culprit is that prior to that commit, default methods weren't being typechecked for each instance! As a result, the code was sneaking past the typechecker. But I'm still confused as to why defining: {{{#!hs instance Foo Char where foo _ x = x }}} typechecks without issue (on all versions of GHC), but defining the instance in terms of a helper method: {{{#!hs fooDefault :: (a ~ Int => Int) -> a -> a fooDefault _ a2 = a2 instance Foo Char where foo = fooDefault @Char }}} is rejected with an error. cc'ing Edward Kmett on this one, since if `lens` really is using code that shouldn't typecheck, `lens` is going to need to come up with a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 14:32:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 14:32:08 -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.b063a7e80de8ae6866e9d13e84c98c9c@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): @slyfox -- can we get a fixed up version of that black hole debugging patch merged? That seems really great. Ideally I'd like to put GHC in a debugging mode were the first time a thread blocks on a black hole the program crashes with a stack trace ;-). Edit rinse repeat until they're all gone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 17:55:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 17:55:47 -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.d0a5a98c04f3342ed4ebe6f3a31f9d78@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Ideally I'd like to put GHC in a debugging mode were the first time a thread blocks on a black hole the program crashes with a stack trace ;-). Edit rinse repeat until they're all gone. You may be interested in Phab:D1216, which builds on the the DWARF-based statistical profiling support that I have [[DWARF/80Status|in the works]] for provide profiling of black-hole entry events. As-written this patch only captures the head of the stack, although this could be changed to provide a deeper stacktrace. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 18:33:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 18:33:54 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.c248892d1d1f820ee2bea9250b65163e@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by ross): I would like to see this turned off for exported functions, like the `Data.Map.singleton` example. Avoiding this warning leads to implementation details leaking from the abstraction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 19:00:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 19:00:42 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.f9b74e17440a563043a3650ebe80364f@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Oh gosh -- I've clearly been very confused. The original example makes sense to me only with a generic-default signature, so I assumed there was one. I've been thus babbling nonsense. Sorry, all! I have no idea why including the method implementation works. I don't think it should. But I still say the original code should be rejected for the same reasons I've already articulated. If inaccessible code were to become a warning, then the way to fix the warning is not to write the instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 19:28:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 19:28:32 -0000 Subject: [GHC] #12478: Template Haskell support for unboxed sums Message-ID: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> #12478: Template Haskell support for unboxed sums -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Template | Version: 8.1 Haskell | Keywords: | Operating System: Unknown/Multiple TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, you can't use unboxed sums with Template Haskell. This makes me sad. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 19:33:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 19:33:27 -0000 Subject: [GHC] #12478: Template Haskell support for unboxed sums In-Reply-To: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> References: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> Message-ID: <065.670342fea225dbdd996b6d252146f957@haskell.org> #12478: Template Haskell support for unboxed sums -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.1 Resolution: | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2448 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2448 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 20:56:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 20:56:57 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.39e6ab47452ba3ac099de19f2788847f@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It makes some sense to warn, by default, when a signature is less polymorphic than it could be. After all, it's quite possible that the programmer didn't realise that the function could be more polymorphic. And indeed I found half a dozen cases of redundant constrains in the `base` package when I first implemented it. But * `-fwarn-redundant-constraints` only does part of the job. It does not warn when you use a tighter constraint than necessary, or indeed instantiate what could be a polymorphic variable to a specific type. * People have argued persuasively that they sometimes want a less polymorphic type. So: * It looks as if we should take it out of `-Wall`. Would someone like to do that, it it hasn't happened already? * I'd be open to a design (and a patch) making it possible to say that a specific type signature deliberately has redundant constraint. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 9 21:52:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Aug 2016 21:52:31 -0000 Subject: [GHC] #12477: Allow left sectioning and tuple sectioning of types In-Reply-To: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> References: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> Message-ID: <066.fc30f5158e04277cebab2657278d3ce4@haskell.org> #12477: Allow left sectioning and tuple sectioning of types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd be ok with this if someone wants to work through the details and implement it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 10 12:28:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Aug 2016 12:28:52 -0000 Subject: [GHC] #12477: Allow left sectioning and tuple sectioning of types In-Reply-To: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> References: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> Message-ID: <066.e173a3331948c4c7f627dad2bd62fc98@haskell.org> #12477: Allow left sectioning and tuple sectioning of types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * owner: => Iceland_jack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 10 15:20:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Aug 2016 15:20:57 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.09adf81081d907ea5be3e8d50eb3c3cb@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by konn): I think that `-fwarn-redundant-constraints` should be still a part of `-Wall`, but we need some way to suppress warning for ''intensionally tightened'' constraints. In such a viewpoint, I like something like Simon's `{-# NO_WARN_REDUNDANT_CONSTRAINTS #-}` annotation. I think it's likely to happen that, in the same function, some constraint is intentionally tightened but other is not. So I think that it's ideal that one can specify ''necessity'' for each constraint. Example: {{{ flipAdd :: (Multiplicative r, {-# NON_REDUNDANT #-} Abelian r) => r -> r -> r flipAdd x y = x + y }}} Compiler should warn `Multiplicative r` as redundant since it doesn't use any multiplication, but `Abelian r` should be unwarned because it's marked as ''non-redundant''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 10 15:27:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Aug 2016 15:27:57 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 Message-ID: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, git clone (commit dfe55e97ed86567aafca2e5f3c19096e2a4cb50f - Sep 20th 2016) of commercialhaskell.com from github: {{{ https://github.com/commercialhaskell/commercialhaskell.com.git }}} follow instructions from that repo exactly for os x (stacksetup installed ghc-7.10.2, but i have seen similar issue with 8): {{{ $ brew install icu4c Add the following to your ~/.stack/stack.yaml: extra-include-dirs: - /usr/local/opt/icu4c/include extra-lib-dirs: - /usr/local/opt/icu4c/lib Now: $ stack build }}} Hit one minor issue in build process with icu4c, resolving with following stack build: {{{ stack build --extra-lib-dirs=/usr/local/opt/icu4c/lib --extra-include- dirs=/usr/local/opt/icu4c/include }}} reach build of yesod-auth, with a failure: {{{ yesod-auth-1.4.6: configure yesod-auth-1.4.6: build texmath-0.8.2.2: copy/register Progress: 35/38 -- While building package yesod-auth-1.4.6 using: /Users/stephen/.stack/setup-exe-cache/x86_64-osx/setup-Simple- Cabal-1.22.4.0-ghc-7.10.2 --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.4.0 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /Users/stephen/Documents/github/commercialhaskell.com/.stack-work/logs /yesod-auth-1.4.6.log Configuring yesod-auth-1.4.6... Building yesod-auth-1.4.6... Preprocessing library yesod-auth-1.4.6... [ 1 of 11] Compiling Yesod.PasswordStore ( Yesod/PasswordStore.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/PasswordStore.o ) /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/PasswordStore.hs:166:31: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Integral b0) arising from a use of ‘^’ at Yesod/PasswordStore.hs:166:31 (Num b0) arising from the literal ‘32’ at Yesod/PasswordStore.hs:166:32-33 In the first argument of ‘(-)’, namely ‘2 ^ 32’ In the first argument of ‘(*)’, namely ‘(2 ^ 32 - 1)’ In the second argument of ‘(>)’, namely ‘(2 ^ 32 - 1) * hLen’ /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/PasswordStore.hs:419:1: Warning: Defined but not used: ‘toStrict’ /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/PasswordStore.hs:422:1: Warning: Defined but not used: ‘fromStrict’ [ 2 of 11] Compiling Yesod.Auth.Message ( Yesod/Auth/Message.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/Auth/Message.o ) /private/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/stack49268 /yesod-auth-1.4.6/Yesod/Auth/Message.hs:22:1: Warning: The import of ‘Data.Monoid’ is redundant except perhaps to import instances from ‘Data.Monoid’ To import instances alone, use: import Data.Monoid() [ 3 of 11] Compiling Yesod.Auth.Routes ( Yesod/Auth/Routes.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/Auth/Routes.o ) [ 4 of 11] Compiling Yesod.Auth ( Yesod/Auth.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.4.0/build/Yesod/Auth.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc64990_0/libghc_21.dylib, 5): no suitable image found. Did find: /var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc64990_0/libghc_21.dylib: malformed mach-o: load commands size (34176) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So reporting.... I've seen the same error attempting to brew install haskell-stack on sierra betas 3 and 4, but on those occasions, an issue with libghc_44.dylib causing the problem. {{{ [ 4 of 87] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/dist-sandbox-558713ad/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc67839_0/libghc_44.dylib, 5): no suitable image found. Did find: /var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ghc67839_0/libghc_44.dylib: malformed mach-o: load commands size (40560) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} stack version: {{{ Version 1.1.2, Git revision cebe10e845fed4420b6224d97dcabf20477bbd4b (3646 commits) x86_64 hpack-0.14.0 }}} stack exec env returns: {{{ stack exec env Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.tEAdTiAWFI/Render GHC_PACKAGE_PATH=/Users/stephen/Documents/github/commercialhaskell.com /.stack- work/install/x86_64-osx/lts-3.0/7.10.2/pkgdb:/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/pkgdb:/Users/stephen/.stack/programs/x86_64-osx/ghc-7.10.2/lib/ghc-7.10.2/package.conf.d HASKELL_DIST_DIR=.stack-work/dist/x86_64-osx/Cabal-1.22.4.0 HASKELL_PACKAGE_SANDBOX=/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/pkgdb HASKELL_PACKAGE_SANDBOXES=/Users/stephen/Documents/github/commercialhaskell.com /.stack- work/install/x86_64-osx/lts-3.0/7.10.2/pkgdb:/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/pkgdb: HOME=/Users/stephen LANG=en_IE.UTF-8 LOGNAME=stephen NAME=Stephen Barrett OLDPWD=/Users/stephen/Documents/github PATH=/Users/stephen/Documents/github/commercialhaskell.com/.stack- work/install/x86_64-osx/lts-3.0/7.10.2/bin:/Users/stephen/.stack/snapshots/x86_64-osx/lts-3.0/7.10.2/bin:/Users/stephen/.stack/programs/x86_64-osx/ghc-7.10.2/bin:/Users/stephen/Library/Haskell/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin PWD=/Users/stephen/Documents/github/commercialhaskell.com SECURITYSESSIONID=186a6 SHELL=/bin/bash SHLVL=1 SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.RTM6V8Lo2y/Listeners STACK_EXE=/Library/Haskell/ghc-8.0.1-x86_64/bin/stack TERM=xterm-256color TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=377 TERM_SESSION_ID=020844C9-1E8A-410E-8892-43DC0C5A8C0B TMPDIR=/var/folders/3k/ycnfbqgx33n7qdytkl9ryx7m0000gn/T/ USER=stephen XPC_FLAGS=0x0 XPC_SERVICE_NAME=0 _=/usr/local/bin/stack __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x6C }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 10 15:34:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Aug 2016 15:34:46 -0000 Subject: [GHC] #12380: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.e34a54a22884f581cc455807c95f0c38@haskell.org> References: <047.e34a54a22884f581cc455807c95f0c38@haskell.org> Message-ID: <062.96d1dc6d24b5321f5d62ad52c2c424eb@haskell.org> #12380: ghc: panic! (the 'impossible' happened) ---------------------------------+-------------------------------------- Reporter: Hassan58 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by stephenb): I have created a ticket that replicates this failure with full context that should make possible a reproduction: #12479 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 10 15:41:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Aug 2016 15:41:25 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.de12b9797bbe5dbf659753d59d2149b6@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:27 konn]: > Example: > > {{{ > flipAdd :: (Multiplicative r, {-# NON_REDUNDANT #-} Abelian r) => r -> r -> r > flipAdd x y = x + y > }}} > > Compiler should warn `Multiplicative r` as redundant since it doesn't use any multiplication, but `Abelian r` should be unwarned because it's marked as ''non-redundant''. I like this approach, too, but I would prefer a positive attribute, e.g. `{-# REQUIRED #-}` or `{-# INTENDED #-}`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 10 16:51:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Aug 2016 16:51:21 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.7d7d9f084962c5f54901387dc9e19209@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Stephen, thanks for the instructions but it would be much easier to make progress if they were simpler. * Didn't rely on stack (essential) * Was reproducible with the latest GHC version * Didn't depend on lots of packages. Could you try removing code and packages/dependencies from `yesod-auth` so that we can a standalone reproducible case? Ideally the reproduction would just be a single command line invocation of GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 10 20:58:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Aug 2016 20:58:27 -0000 Subject: [GHC] #10056: Inconsistent precedence of ~ In-Reply-To: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> References: <047.6a12b15cc084aa108be95f499dfa0014@haskell.org> Message-ID: <062.b8b63e7db17a95d4cecbcfa518f207ac@haskell.org> #10056: Inconsistent precedence of ~ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10059, #10431 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for `-XTypeEqualities`, if someone wants to specify the details, and implement it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 10 21:16:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Aug 2016 21:16:59 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.d2b030bb15012149dfb4ddfd893d62db@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by joehillen): Some great blog posts on compiler error design: http://elm-lang.org/blog/compiler-errors-for-humans https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 10 22:43:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Aug 2016 22:43:48 -0000 Subject: [GHC] #12468: GADTs don't refine hole types In-Reply-To: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> References: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> Message-ID: <070.c1f3c88070daeb81506d691c469c48bf@haskell.org> #12468: GADTs don't refine hole types -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't think this is a bug. Yes we have an equality in scope; but a value of type `a` and one of type `Int` are both equally valid things to fill the hole with. E.g. {{{ f :: T a -> a -> a f I x = _ }}} I could fill the hole with `(3::Int)` or with `x`. Neitehr is better than the other. Another way to say this is that type equalities are not normalising; they are equalities, not left-to-right rewrite rules. Suppose we had `a ~ b` in scope. Should report the hole as having type `a` or `b`? What if it was `a ~ [b]`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 10 22:50:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Aug 2016 22:50:22 -0000 Subject: [GHC] #12468: GADTs don't refine hole types In-Reply-To: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> References: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> Message-ID: <070.cb974bd0bd0b3637553eb18e908f8e68@haskell.org> #12468: GADTs don't refine hole types -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by benjamin.hodgson): Thanks for the reply! I see what you mean about `a` and `Int` both being good options to show for the hole type. However, I do think it would still be helpful to have ''some'' indicator in the error message of the fact that the context gives us a useful equality. Something along the lines of: {{{ • Found hole: _ :: a ... • NB: a ~ [b] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 06:45:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 06:45:28 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.509d3a15f9dbc68f16df9b260c6f6e6b@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Just a word of warning from a library maintainer's point of view: Including new flags into `-Wall` puts some non-trivial burden onto maintainers wanting a warning-free build. Simply adding a new pragma is not enough: Old GHCs don't know that pragma, so you have to put that into some ugly `#ifdef`s, which in turn oftern implies adding another (language) pragma to allow the preprocessor plus perhaps some changes in the `.cabal` file. So including `-fwarn-redundant-constraints` in `-Wall` is far from free for real-world code. I'm not saying that this shouldn't be done, but at least I want to bring up the maintenance issue. From my personal experience, Haskell code is becoming more and more cluttered with CPP stuff because of seemingly innocent changes like this. Of course this isn't a problem if you only consider the latest and greatest GHC, but this isn't an option for most maintainers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 06:46:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 06:46:54 -0000 Subject: [GHC] #12377: getExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS also) In-Reply-To: <047.ce292d74547e5761ab80fddf4c2b76fa@haskell.org> References: <047.ce292d74547e5761ab80fddf4c2b76fa@haskell.org> Message-ID: <062.981de297de057ca9cb8f2f3609737d3c@haskell.org> #12377: getExecutablePath doesn't return absolute path on OpenBSD (and maybe other OS also) -------------------------------------+------------------------------------- Reporter: oherrala | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: Operating System: OpenBSD | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2423 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): The bug reported in `cabal-install` was fixed wrongly and actually made things worse. Using `realpath(3)` on `argv[0]` is rather unreliable, especially when `argv[0]` doesn't contain any `/`s, it's most certainly wrong to assume that `argv[0]` is relative to the current `$CWD`. See also discussion in Phab:D2423 The problem as I see it, is that `getExecutablePath` claims to provide absolute paths even though it's impossible to do so in a platform independent way (i.e. if all you have to work with is `argv[0]`, which can be set to any arbitrary value by the process invoking `exec(3)`. NB: the `exec(3)`-family requires you to specify the filepath to the executable and the value for `argv[0]` separately, and recommends > The first argument, by convention, should point to the filename associated with the file being executed. But there's no requirement to do so. I see some options/ways forward: * Change `getExecutablePath`'s type-signature into something like `getExecutable :: Maybe (IO FilePath)` which returns `Nothing` if we don't have any reliable way to report the absolute executable pathname (which should be statically known). (alternatively, for backward compat sake, deprecate `getExecutablePath`, and introduce a new function with the `Maybe`-typesig) * Add support for **reliable** executable path reporting for as many OS as possible (relevant: http://stackoverflow.com/questions/1023306/finding-current- executables-path-without-proc-self-exe ) * Document that `getExecutablePath` only reports a reliable path on Windows/Linux/OSX currently. And everywhere else only returns what `argv[0]` contains. Unfortunately there's no reliable way to figure out at runtime whether `getExecutablePath` returned the real path, or just whatever `argv[0]` said. * Let `getExecutablePath` raise an IO exception of subtype `UnsupportedOperation` if no reliable absolute path can be returned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 07:07:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 07:07:35 -0000 Subject: [GHC] #2867: Make a way to tell GHC that a pragma name should be "recognised" In-Reply-To: <044.b8d409e55bb3523a205a81d0c4d153a4@haskell.org> References: <044.b8d409e55bb3523a205a81d0c4d153a4@haskell.org> Message-ID: <059.eddedfdc4010f1906fdcff06a8c8c537@haskell.org> #2867: Make a way to tell GHC that a pragma name should be "recognised" -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * cc: ghc@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 07:11:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 07:11:06 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.4812e729ed734ccc5655e3d0837408dc@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:29 svenpanne]: > Just a word of warning from a library maintainer's point of view: Including new flags into `-Wall` puts some non-trivial burden onto maintainers wanting a warning-free build. Simply adding a new pragma is not enough: Old GHCs don't know that pragma, so you have to put that into some ugly `#ifdef`s, which in turn oftern implies adding another (language) pragma to allow the preprocessor plus perhaps some changes in the `.cabal` file. I don't like CPP and would prefer that GHC gets a switch to disable warnings about certain pragmas. This was proposed in #2867. It should be possible to disable those warnings globally in the Cabal file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 07:13:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 07:13:38 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.1a70f4166cab351a69c1f140c1d02eee@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * failure: Other => Compile-time performance bug Comment: This looks bad. Inlining should not go on for ever ... there's a tick counter as a last-ditch hard stop. It could just possibly be too many INLINE pragmas, but it's quite difficult to eat 16G. Does anyone feel able to investigate further? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 07:18:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 07:18:54 -0000 Subject: [GHC] #12418: Make `MonadCont (ContT r m)` polykinded (r::k), (m::k -> Type) In-Reply-To: <051.aa98db01c615f5738620e369aa22a8a6@haskell.org> References: <051.aa98db01c615f5738620e369aa22a8a6@haskell.org> Message-ID: <066.e38e439b2b62dbf8e5ff1b6d0c658118@haskell.org> #12418: Make `MonadCont (ContT r m)` polykinded (r::k), (m::k -> Type) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is a Core Libraries Committee issue, right? As you point out, it's instance-specific (relevant for `MonadCont` but not for `Functor`, say. So perhaps CLC should do as you implicitly suggest? I.e. change the relevant instances to {{{ instance k ~ Type => MonadCont (ContT @k r m) }}} Of course, someone would have to do the homework to figure out what the "relevant" ones are. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 07:20:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 07:20:10 -0000 Subject: [GHC] #10106: GHC doesn't warn on typos in language pragmas In-Reply-To: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> References: <045.21142259cdd05987b2d6e100d7d1e081@haskell.org> Message-ID: <060.4f6a93f3907825214f450b29c912056c@haskell.org> #10106: GHC doesn't warn on typos in language pragmas -------------------------------------+------------------------------------- Reporter: sdemos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #10076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Sometimes I (ab)use `-fdefer-type-errors` in order to see warnings along with errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 07:24:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 07:24:14 -0000 Subject: [GHC] #11646: Make pattern synonym export type mismatch a warning In-Reply-To: <045.9eb8b2d1f35f468ff5981bb2e5b0840b@haskell.org> References: <045.9eb8b2d1f35f468ff5981bb2e5b0840b@haskell.org> Message-ID: <060.e8090b4305146475c08fb05096853bf7@haskell.org> #11646: Make pattern synonym export type mismatch a warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | PatternSynonyms/AssociatingSynonyms| -------------------------------------+------------------------------------- Comment (by simonpj): So to be concrete, you want to allow this: {{{ module M( Maybe( Nothing, Just, P ) ) where pattern P x = [x, True] }}} So now an importing module can import `Maybe(..)` and will get two data constructors for `Maybe` and one for lists. I agree that there is nothing unsound about this, just a bit unexpected. I'd be perfectly OK with issuing a warning rather than an error. But doing anything at all requires ''some'' work from someone. And it may well be that someone then pops up to say "it really really should be an error". So a compelling use-case or two, and evidence of interest from other users would help. Does anyone else have an opinion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 10:57:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 10:57:21 -0000 Subject: [GHC] #12428: Allow pattern synonyms to optionally carry coerceability In-Reply-To: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> References: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> Message-ID: <060.67446f32133b52b0e8570d93aad93395@haskell.org> #12428: Allow pattern synonyms to optionally carry coerceability -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could you give a specific, concrete example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 11:01:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 11:01:25 -0000 Subject: [GHC] #12418: Make `MonadCont (ContT r m)` polykinded (r::k), (m::k -> Type) In-Reply-To: <051.aa98db01c615f5738620e369aa22a8a6@haskell.org> References: <051.aa98db01c615f5738620e369aa22a8a6@haskell.org> Message-ID: <066.7f0f03ae69dc855581f9f8efaf5a6f8b@haskell.org> #12418: Make `MonadCont (ContT r m)` polykinded (r::k), (m::k -> Type) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): > So perhaps CLC should do as you implicitly suggest? I very deliberately didn't suggest that. I actually pointed it out as a sign of quite how bad it would be to do this. It would affect every single user defined monad transformer type that happens to lift over `ContT` as well. Not just code in `transformers`. This would fix the inference for the handful of instances `transformers` defines, but not for every other package out there that builds on top. For the record, I'm pretty strongly against this proposal from the standpoint of what it does in practice to what is currently a very stable part of our ecosystem. A single combinator gets a slightly more general signature, but the result is that the `ContT` type becomes worse at its original stated job as serving as a monad transformer. Given that it comes from `Control.Monad.Trans.Cont`, it seems it is well placed for the current design. The replacement doesn't actually offer any new uses. If you use it at the new kind almost none of the existing instances are useful and they in fact actively get in the way of anything more generic you might want by overlapping these hypothetical instances for hypothetical classes we don't have. This is a situation where a different type offered by a different library is in order. The compromise of adding a ton of constraints is worse than the compromise of simply not PolyKinding the data type in the first place, as it impacts both the existing users badly _and_ whatever potential users the more general form woudl have, as if you wanted to use the power to do something more interesting the instance of these blanket instances would likely prevent you from doing it anyways. If you want the power of this proposal you can get it by just using `Cont (IdentityT m r) a` out of the box today. It has every single one of the admissible instances that would be let through by this proposal. `IdentityT` is already PolyKinded, but doesn't cause these sorts of problems. I'm inclined to close this out until the unlikely day when there is a library out there that shows the change, and people out there who see a need to use it. @Iceland_jack, I'm sorry, but would you object terribly strongly to that resolution? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 11:01:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 11:01:50 -0000 Subject: [GHC] #12429: Pattern synonym parse error should recommend enabling extension In-Reply-To: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> References: <049.a84572b34b0d4ea1faf1de7a2715c84f@haskell.org> Message-ID: <064.02c0970533d055eee7a08d07be5ec578@haskell.org> #12429: Pattern synonym parse error should recommend enabling extension -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That sounds very sensible and do-able. Would anyone like to offer a patch? We have precedents; e.g. a sensible error when people use `forall` without `RankNTypes`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 11:29:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 11:29:56 -0000 Subject: [GHC] #12432: TypeInType: open type family application as type family return kind fails to compile In-Reply-To: <046.81766c43f1232218e828bba3b4f71960@haskell.org> References: <046.81766c43f1232218e828bba3b4f71960@haskell.org> Message-ID: <061.c62fd46a2bdb1a8f14076b0c529f3b6f@haskell.org> #12432: TypeInType: open type family application as type family return kind fails to compile -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: duplicate => Comment: This ticket is closed as a duplicate. But a duplicate of ''what''? The discussion doesn't look like duplication. I'll re-open for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 11:37:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 11:37:35 -0000 Subject: [GHC] #12418: Make `MonadCont (ContT r m)` polykinded (r::k), (m::k -> Type) In-Reply-To: <051.aa98db01c615f5738620e369aa22a8a6@haskell.org> References: <051.aa98db01c615f5738620e369aa22a8a6@haskell.org> Message-ID: <066.226b0b620884ad214f764549fefe3053@haskell.org> #12418: Make `MonadCont (ContT r m)` polykinded (r::k), (m::k -> Type) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:7 ekmett]: > @Iceland_jack, I'm sorry, but would you object terribly strongly to that resolution? I would not, I didn't expect such far-reaching implications. {{{#!hs label :: ContT r m (ContT r m a) label = callCC $ \k -> [ m | let m = k m ] }}} It's unfortunate that `↑` doesn't type check with `PolyKinds` and that the inferred type of `↓` doesn't either, that's somewhat rare {{{#!hs -- foo :: Cont r m a foo = do l <- label l }}} but seems like it can't be helped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 13:13:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 13:13:58 -0000 Subject: [GHC] #12480: Clever mit Revolyn zur Traumfigur Message-ID: <058.ccb0e618544d80d2c2799629073c6642@haskell.org> #12480: Clever mit Revolyn zur Traumfigur -------------------------------------+------------------------------------- Reporter: | Owner: anastasija.hansen92 | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Kombination der beiden Produkte: „Revolyn Tabletten “ und „Pure Cleannse Tabletten“ ergeben kombiniert die perfekte Basis für eine erfolgreiche Diät. Während „Revolyn“ die Fettverbrennung immens beschleunigt, erfüllt die „[http://www.healthprodukte.reviews; Pure Cleanse] Pille“ andere wichtige Punkte. Es steigert extrem ihre Energie, reinigt und entgiftet ihren Organismus und bringt jedermanns Stoffwechsel in Schwung! Es verhindert also die gebräuchlichen Nebenwirkungen einer Diät: das Trägheitsgefühl, die 0-Bock-Phase und die Bauchschmerzen. Inhaltsstoffe von Revolyn: Doch wie ist das alles möglich? Guckt man sich den Inhalt mal im Einzelnen an. Die Revolyn Tablette beinhaltet gleich mehrere natürliche und effektive Inhaltsstoffe. Der grüne Tee und die beinhaltenden Guarana- Bestandteile steigern gehörig den Stoffwechsel. Ferner erhöht Guarana den Puls und aus dem Grund auch den Kalorienverbrauch.Der Bestandteil„Damiana“ ermöglicht eine verbesserte Libido, steigert die Fettverbrennung und stärkt das Nerven- und Immunsystem! Ein echtes Allround-Talent!Das außerdem enthaltene Granatapfel-Extrakt wirkt positiv auf die Blutfette (verbessert dessen Vernichtung) und beinhaltet unglaublich viele gute und für den Körper wichtige Vitamine. Einnahme von den Revolyn-Diäthelfern: Die Verabreichung von Revolyn Tabletten ist super einfach erklärt. Morgens und Am Abend eine Tablette mit einem Glas mit zuckerfreiem Getränk zu sich nehmen – fertig. Das Einnehmen von „Pure Life Cleanse ist noch einfacher und konsumentenfreundlicher: Eine Tablette am Nachmittag mit einem Schluck Wasser runterschlucken, et ce ca! Wie teuer sind die Revolyn-Diäthelfer? Gegenüber anderen Abnehmprodukten mit einer ähnlichen Wirkung „ist [http://www.healthprodukte.reviews/revolyn-pure-cleanse/; Revolyn] “ und „die Pure Cleanse Diät Tabletten“ ist Revolyn recht günstig. Zwar kostet 1 Flasche 39,95 €, allerdings verringert sich der Stück-Preis je nach Bestellmenge. Wenn jemand 2 Flaschen bestellt (79,95Euro) erhält eine für lau dazu. 4 Flaschen kosten 159,80 Taler, erhält aber auch 4 Flaschen für lau obendrauf. Effektiv bekommt ihr also acht Flaschen für nur 159,80 Euro! Ein einzigartiger Hammer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 13:22:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 13:22:44 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.37eeaf9551851587deb3bf1d75e61dec@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Replying to [comment:30 Lemming]: > I don't like CPP and would prefer that GHC gets a switch to disable warnings about certain pragmas. > This was proposed in #2867. It should be possible to disable those warnings globally in the Cabal file. While this might be a worthwhile goal, it doesn't help with the current situation at all: Current and past GHCs don't have that feature, so even if this is implemented, we will have to live with CPP for this purpose for quite a few years to come... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 14:08:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 14:08:39 -0000 Subject: [GHC] #12446: Doesn't suggest TypeApplications when `~` used prefix In-Reply-To: <051.fbdff3a41aaa6fb6f877bb677e6f69a8@haskell.org> References: <051.fbdff3a41aaa6fb6f877bb677e6f69a8@haskell.org> Message-ID: <066.e444893ed8cd787ea801f0b4641e4276@haskell.org> #12446: Doesn't suggest TypeApplications when `~` used prefix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That does look odd. Any volunteers to investigate and fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 14:47:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 14:47:53 -0000 Subject: [GHC] #12428: Allow pattern synonyms to optionally carry coerceability In-Reply-To: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> References: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> Message-ID: <060.919e7ffb7daa501be44de817af8f0d2a@haskell.org> #12428: Allow pattern synonyms to optionally carry coerceability -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 simonpj]: > Could you give a specific, concrete example? Suppose I have a module that defines a newtype {{{#!hs newtype Foo a = Foo a }}} Suppose this module has a zillion users, and at some point its maintainer decides, for internal reasons, to change the definition of `Foo` to {{{#!hs newtype Foo a = Foo (Bar a) }}} where `Bar` is another newtype. She can expose a ''similar'' interface by hiding the `Foo` constructor and instead exporting a pattern synonym {{{#!hs pattern Foo a = Foo (Bar a) }}} But the interface is not quite the same! If someone has a module that imports hers and then uses the `Coercible a (Foo a)` instance, it will simply stop working now that the actual `Foo` constructor is no longer exported. What I'm proposing is that pattern synonym writers who can see the actual constructor should be able to "bless" their pattern synonyms with its magical import/export power, and that this should be available transitively. I ''don't'' want it to be automatic, because sometimes I explicitly want to use a pattern synonym to block coercions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 14:52:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 14:52:42 -0000 Subject: [GHC] #12428: Allow pattern synonyms to optionally carry coerceability In-Reply-To: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> References: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> Message-ID: <060.e585e9763a18d08df980dc72617f3a23@haskell.org> #12428: Allow pattern synonyms to optionally carry coerceability -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I wonder if it makes sense to look at that feature request independently of pattern synonyms. Then it becomes: > Give library authors a way to allow newtype unwrapping for newtypes where the constructor is not imported. or, a bit more concrete > Give library authors a way to allow newtype unwrapping for newtypes where the constructor is not imported, by naming other symbols (functions, constructors, pattern synonyms) that, if in scope, give the user of their library the power to do newtype unwrapping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 15:03:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 15:03:38 -0000 Subject: [GHC] #12428: Allow pattern synonyms to optionally carry coerceability In-Reply-To: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> References: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> Message-ID: <060.f0fb7c766f4ae4df7de41a916a6abc2e@haskell.org> #12428: Allow pattern synonyms to optionally carry coerceability -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Also there's a problem with {{{ pattern Foo a = Foo (Bar a) }}} because it looks recursive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 15:14:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 15:14:41 -0000 Subject: [GHC] #12428: Allow pattern synonyms to optionally carry coerceability In-Reply-To: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> References: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> Message-ID: <060.74436d6e86aa54686c3407d243b9103b@haskell.org> #12428: Allow pattern synonyms to optionally carry coerceability -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:6 simonpj]: > Also there's a problem with > {{{ > pattern Foo a = Foo (Bar a) > }}} > because it looks recursive. That was just a mistake. Rename the new constructor `NewFoo` or something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 16:22:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 16:22:33 -0000 Subject: [GHC] #12468: GADTs don't refine hole types In-Reply-To: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> References: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> Message-ID: <070.53a8856714639cc8121fc726a9dd630d@haskell.org> #12468: GADTs don't refine hole types -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > However, I do think it would still be helpful to have some indicator in the error message of the fact that the context gives us an equality. After all, such information can be very useful when you're trying to fill in a hole. Something along the lines of: Yes, that's plausible and do-able; along the lines of displaying the "relevant bindings". Does anyone want to have a go? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 17:23:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 17:23:01 -0000 Subject: [GHC] #12481: Add MonadFail instance for Either String Message-ID: <045.193124d5344eaa8040ec71117a51861b@haskell.org> #12481: Add MonadFail instance for Either String -------------------------------------+------------------------------------- Reporter: hesiod | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There seems to be the low hanging fruit of a MonadFail instance for Either String. {{{#!hs instance MonadFail (Either String) where fail = Left }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 17:33:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 17:33:50 -0000 Subject: [GHC] #12481: Add MonadFail instance for Either String In-Reply-To: <045.193124d5344eaa8040ec71117a51861b@haskell.org> References: <045.193124d5344eaa8040ec71117a51861b@haskell.org> Message-ID: <060.14c5582bcda4ded8003719adf73df04c@haskell.org> #12481: Add MonadFail instance for Either String -------------------------------------+------------------------------------- Reporter: hesiod | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hesiod): I just realized that this instance has already been mentioned in https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail, not in `base` however, but rather in `transformers`. I'm not quite sure why having that instance in `transformers` would be better, since it would make it an orphan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 18:14:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 18:14:16 -0000 Subject: [GHC] #12481: Add MonadFail instance for Either String In-Reply-To: <045.193124d5344eaa8040ec71117a51861b@haskell.org> References: <045.193124d5344eaa8040ec71117a51861b@haskell.org> Message-ID: <060.b4c788bc862fba5a2b2a101e0e91b562@haskell.org> #12481: Add MonadFail instance for Either String -------------------------------------+------------------------------------- Reporter: hesiod | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hesiod): * status: new => closed * resolution: => duplicate Comment: Nevermind, this is a duplicate of #12160. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 18:44:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 18:44:49 -0000 Subject: [GHC] #12160: MonadFail instance for (Either String)? In-Reply-To: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> References: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> Message-ID: <065.6657ec6a54e7049de2b5944cfede8976@haskell.org> #12160: MonadFail instance for (Either String)? -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9588 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): The danger here is that the `(Either String)` specific instance proposed here rules out reasoning uniformly about any other instance someone might want to put on `Either` that works for more types, which could get to be be common in things like test suites. This lets one 'pointwise' instance override anybody's ability to grab a more general one. e.g. the old `Error` class from `MonadError` approach. I'm not advocating for that class per se, as there is no need for `noMsg` for `MonadFail`, making that class "too big". `IsString` on the other hand, does have the remarkable property that it has precisely the right size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 18:47:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 18:47:20 -0000 Subject: [GHC] #12418: Make `MonadCont (ContT r m)` polykinded (r::k), (m::k -> Type) In-Reply-To: <051.aa98db01c615f5738620e369aa22a8a6@haskell.org> References: <051.aa98db01c615f5738620e369aa22a8a6@haskell.org> Message-ID: <066.f5a003150da8654f50898aa7beec4ce4@haskell.org> #12418: Make `MonadCont (ContT r m)` polykinded (r::k), (m::k -> Type) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 20:31:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 20:31:00 -0000 Subject: [GHC] #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm In-Reply-To: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> References: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> Message-ID: <059.eb8990dd1a3d3026965b4250898acdb5@haskell.org> #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): ON IRC, @slyfox said: {{{ i guess you need another entry for exported symbols from rts ./RtsSymbols.c: SymI_NeedsProto(__divdi3) \ like this one }}} I will try that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 21:29:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 21:29:46 -0000 Subject: [GHC] #12482: Infinite compilation time when using wrongly ordered constraints Message-ID: <046.385955bbc36fdf0c78384562d17bec02@haskell.org> #12482: Infinite compilation time when using wrongly ordered constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello guys! I've seen today a very strange bug in GHC 8. Namely I've got an instance: {{{ instance {-# OVERLAPPABLE #-} (PrimMonad m, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m, HasProperty2' t g) => DynamicM t (HMGraph s rels) m a where addM el = nested (prop2' @t . wrapped') $ (swap ∘ fmap Ptr) <∘> ixed Cont.addM (unsafeCoerce el) }}} and I'm using it indirectly in Main.hs. It compiles fast and works fine. The problem is that when I change the above constraint to: {{{ (PrimMonad m, HasProperty2' t g, g ~ HMGraph s rels, (g ^. t) ~ Hetero2 (MAutoVector s), s ~ PrimState m) }}} Which is basically the same but with different order, the file with this constraint compiles fast and fine, but Main.hs compiles infinite amount of time (I've killed it after 10 minutes). The problem is reproducible, but it is hard right now to make minimal example out of it (we are going to a conference with a product release and we cannot track it right now). I post it here because maybe the bug is known, if not, after the release I'll try to provide more info. If you've got any questions I'd love to assist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 21:56:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 21:56:00 -0000 Subject: [GHC] #12160: MonadFail instance for (Either String)? In-Reply-To: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> References: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> Message-ID: <065.9f6924b46ddd00e75a124345a5a9e706@haskell.org> #12160: MonadFail instance for (Either String)? -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9588 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hesiod): * cc: ekmett (added) Comment: So if I understood you right, ekmett, you would be fine with Iceland_jack's approach, i.e. `instance IsString str => MonadFail (Either str)`? In that case, I'd be glad to assemble a patch provided there are no other concerns remaining. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 22:29:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 22:29:02 -0000 Subject: [GHC] #12160: MonadFail instance for (Either String)? In-Reply-To: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> References: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> Message-ID: <065.da468d40f1b0f76946991022394cd4ae@haskell.org> #12160: MonadFail instance for (Either String)? -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9588 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I support the instance, but this should go out as a real libraries proposal to the libraries@ mailing list, rather than being decided and acted on in relative isolation here. If you want to kickstart that process I'll happily toss in a +1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 11 22:39:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Aug 2016 22:39:55 -0000 Subject: [GHC] #12160: MonadFail instance for (Either String)? In-Reply-To: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> References: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> Message-ID: <065.6b6580d5f6c071e51b90291c74c6f03d@haskell.org> #12160: MonadFail instance for (Either String)? -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9588 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hesiod): Ok, will do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 03:44:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 03:44:46 -0000 Subject: [GHC] #12483: Improve parse error message on indentation mistake Message-ID: <047.316a1198ea6bc5cfdac014b84c3e6cd9@haskell.org> #12483: Improve parse error message on indentation mistake -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code fragment: {{{#!hs (ExecGhc, args) -> execCompiler "" args -- NOTE: this won't currently work for GHCJS, because it doesn't have -- a runghcjs binary. It probably will someday, though. (ExecRunGhc, args) -> }}} The last line is indented by one space but it is hard to notice esp when we looking at this along with a screenful of code and there are many comments between the two lines. When this code is compiled ghc throws the following error: {{{ Main.hs:745:40: error: parse error on input ‘->’ }}} I look at the error and then the code and wonder what is wrong with this code, there is nothing noticeably wrong. If ghc can provide some context I can easily make out where the problem is. ghc can perhaps tell me how the current expression is being parsed e.g. `(ExecRunGhc, args) ->` is being considered as a continuation of the expression on the previous line. I have run into this many times. The first time it was really frustrating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 06:43:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 06:43:39 -0000 Subject: [GHC] #12484: Missing pattern synonym signatures gives incorrect fix Message-ID: <044.a1aab187eadc781630dbc7d467492c17@haskell.org> #12484: Missing pattern synonym signatures gives incorrect fix -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #11053 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following pattern definition {{{#!hs pattern RP pname help type' <- ParamDesc pname help type' Required where RP pname help type' = ParamDesc pname help type' Required }}} Gives the warning {{{ /....../PluginTypes.hs:248:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: RP :: ParamName -> ParamHelp -> ParamType -> ParamDescription }}} The required signature is in fact {{{#!hs pattern RP :: ParamName -> ParamHelp -> ParamType -> ParamDescription }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 07:50:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 07:50:28 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.330cc4082ee5e7b2280e692e61b99915@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Would this change make reflection (the library) obsolete? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 13:54:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 13:54:13 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order Message-ID: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.0.1 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After 39b71e81ec1044518f065d0055676d713521e483 putting the -package-db flags in the wrong order will result in a compile error: {{{ : cannot satisfy -package-id b-1-XXX: b-1-XXX is unusable due to missing or recursive dependencies: a-1-XXX (use -v for more information) }}} See attached file for a repro. It's reproduces in 8.0.1 and HEAD. Doesn't reproduce in GHC 7.10.3 or after reverting the above mentioned commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 13:55:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 13:55:31 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.f36253beaa0883bcd4b493b19b3d0388@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * Attachment "repro.sh" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 14:06:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 14:06:14 -0000 Subject: [GHC] #12432: Use kind equality in instance context in type family instance (was: TypeInType: open type family application as type family return kind fails to compile) In-Reply-To: <046.81766c43f1232218e828bba3b4f71960@haskell.org> References: <046.81766c43f1232218e828bba3b4f71960@haskell.org> Message-ID: <061.f5f46b2174a25692c0c0e160ef127148@haskell.org> #12432: Use kind equality in instance context in type family instance -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by goldfire: @@ -7,0 +7,4 @@ + + EDIT: This ticket got repurposed at comment:3 and below. The original + problem described above is fixed, but the commentary is useful to keep + around and on this ticket. New description: With TypeInType enabled, I can use a closed type family to compute the return kind of a type family from its arguments. But an equivalent open type family used in the same way triggers a compilation failure, as if the relevant instance of that open type family were not considered. (Of course, there may be some subtle prohibition of which I am not aware at the present time.) I will attach a test case. EDIT: This ticket got repurposed at comment:3 and below. The original problem described above is fixed, but the commentary is useful to keep around and on this ticket. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 14:32:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 14:32:52 -0000 Subject: [GHC] #12432: Use kind equality in instance context in type family instance In-Reply-To: <046.81766c43f1232218e828bba3b4f71960@haskell.org> References: <046.81766c43f1232218e828bba3b4f71960@haskell.org> Message-ID: <061.85fbf03f075fe78009fab15c3b194e45@haskell.org> #12432: Use kind equality in instance context in type family instance -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sorry; I'm still lost. Are you saying that there is a still-open bug, described in comment:3, and that's what the ticket is now about? If so let's either change the Description, or open a new ticket that actually describes the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 14:34:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 14:34:49 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.c3ad56cd904fb794599ac063f4776c09@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I'm working on a fix, but I'll be of the grid next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 16:34:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 16:34:43 -0000 Subject: [GHC] #12484: Missing pattern synonym signatures gives incorrect fix In-Reply-To: <044.a1aab187eadc781630dbc7d467492c17@haskell.org> References: <044.a1aab187eadc781630dbc7d467492c17@haskell.org> Message-ID: <059.0fbd9dc650e16e0db1a0232c3c942d7d@haskell.org> #12484: Missing pattern synonym signatures gives incorrect fix -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11053 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ac0e11252af149f085e2262200b7a1638b4a1553/ghc" ac0e1125/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ac0e11252af149f085e2262200b7a1638b4a1553" Improve missing-sig warning Fixes Trac #12484 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 16:35:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 16:35:32 -0000 Subject: [GHC] #12484: Missing pattern synonym signatures gives incorrect fix In-Reply-To: <044.a1aab187eadc781630dbc7d467492c17@haskell.org> References: <044.a1aab187eadc781630dbc7d467492c17@haskell.org> Message-ID: <059.c4e5feba398a54fe7ea464b22c8d7677@haskell.org> #12484: Missing pattern synonym signatures gives incorrect fix -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11053 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Good point, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 16:37:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 16:37:00 -0000 Subject: [GHC] #12432: Use kind equality in instance context in type family instance In-Reply-To: <046.81766c43f1232218e828bba3b4f71960@haskell.org> References: <046.81766c43f1232218e828bba3b4f71960@haskell.org> Message-ID: <061.7f315c75dd3286c3c792c6ef97124a5c@haskell.org> #12432: Use kind equality in instance context in type family instance -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kosmikus): Haven't checked the attached test cases in detail, but from the description and discussion it sounds as if the original issue is #12381, which is fixed in HEAD. And the subsequent issue seems to be #12384, which is not fixed and seems to be difficult to fix. I ran into both of those issues when I tried to write a type-level translation of the new type-level generic metadata that GHC 8 provides into a different representation of type-level metadata that would be useful for generics-sop (and makes use of a type-level GADT and therefore TypeInType). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 16:37:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 16:37:28 -0000 Subject: [GHC] #12482: Infinite compilation time when using wrongly ordered constraints In-Reply-To: <046.385955bbc36fdf0c78384562d17bec02@haskell.org> References: <046.385955bbc36fdf0c78384562d17bec02@haskell.org> Message-ID: <061.065a9da16912ec6d8bc77a2b8e7f3caa@haskell.org> #12482: Infinite compilation time when using wrongly ordered constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That is deeply strange. Can you explain how to reproduce. Preferably cut down the example, especially dependencies, as much as possible. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 17:36:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 17:36:55 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.1b7278b9353d6c80669fa9fe496fc25e@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2450 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * differential: => D2450 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 17:37:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 17:37:10 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.65a820b64f95e48c6c464b5a4eca1007@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * differential: D2450 => phab:D2450 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 19:28:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 19:28:45 -0000 Subject: [GHC] #12486: Investigate removing libGCC symbols from RtsSymbols.c Message-ID: <044.f5820ac38d2492af61df4641ed801b04@haskell.org> #12486: Investigate removing libGCC symbols from RtsSymbols.c -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11981 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS is currently re-exporting symbols from the C compiler runtime in `RtsSymbols.c`. How this works is that the Runtime linker is declaring that it can provide these symbols because it's been linked against the C compiler library itself. In essence it's providing pointers to it's own symbol table. This Is fine but has two downsides: 1) We have to keep adding symbols to export anytime the underlying C compiler changes things or someone needs a new symbol from the library. 2) User code that is linking explicitly against these libraries will probably generate a duplicate symbols error if it needs a symbol we have not yet exported but is in the same object file or dependency of a symbol we have exported. One solution would be to add `libgcc_s` to the dependencies of `ghc-prim` which is the package that seems to require them. This has two issues with it: `GCC_S` doesn't exist for llvm, so we need to somehow know which compiler we're compiling for. Secondly on Windows `GCC_S` is an import library with a non-standard name. (.a instead of .dll.a) and we currently cannot recognize it as such. We'd try to load it as a normal archive and end up trying to execute ascii as code. This task is to find a way to remove the need to export these symbols yet still work with both GCC and LLVM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 19:30:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 19:30:39 -0000 Subject: [GHC] #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm In-Reply-To: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> References: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> Message-ID: <059.1d7c4f16d8e421630fe002fd3699bb51@haskell.org> #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @erikd you could probably just add it to `extra-libraries` in `libraries \ghc-prim\ghc-prim.cabal`. This would pass it on when linking against `ghc-prim` both interpreted and compiled. However this won't work on Windows because on Windows `gcc_s` is an import library with a non-standard name (.a instead of .dll.a), and we can't identify these properly yet. So I think your fix of adding them to `RtsSymbols.c` is good enough for now. I created #12486 for a way to not need to re-export these symbols from the RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 19:43:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 19:43:33 -0000 Subject: [GHC] #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages In-Reply-To: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> References: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> Message-ID: <059.8aa2531e1f88c58febf6ff46c69d9f99@haskell.org> #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages -------------------------------------+------------------------------------- Reporter: ertes | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #12170 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: => ak3n -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 19:51:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 19:51:40 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on all systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.4673780a08f88225536a49c005837355@haskell.org> #10352: Properly link Haskell shared libs on all systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5987 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I'm having a hard time getting this to work on Windows which is what is causing the delay. The issue is that normally you'd be able to do this easily by delay loading the dll. This is done by creating a delay loading import library which essentially, instead of putting the symbols in the IAT of the PE file instead links statically against stubs. These stubs allow it to then load the DLL only on first call of a related function. This is done by those adding a level of indirection. (mingw-w64's implementation is here if curious https://github.com/mirror/mingw-w64/blob/master/mingw-w64-crt/misc/delayimp.c) The issue is that this approach has a major limitation: It only works for Functions! This limitation is described here https://msdn.microsoft.com/en- us/library/yx1x886y.aspx But essentially this is because exported `const data` entries end up becoming stubs too. (empty stubs, but stubs in any case). This address is resolved at link time (because you're linking against the stub instead of the IAT entry being added to the Windows Loader can later resolve it). One way to work around this is to replace constant imports such as {{{ __declspec(dllimport) extern FooS_t fooStruct; }}} With explicit loads using MACROs: {{{ FooS_t fst = *(FooS_t*)GetProcAddress(GetModuleHandle("foo"), "fooStruct"); }}} This works, but I would have to track down each and every use of constants in the RTS and change them to this or to make them functions (e.g `getFooStruct()`). What I am investigating now is a third approach, using an intermediate proxy dll. Link normally against the proxy to the loader resolves the addresses of const data as it should, but have the proxy "forward" the requests to the right dll. This can be done because when the linker looks up symbols in the IAT the OS allows for hooks in the target library to override the returned address. This should allow me to use the proxy to choose at runtime which runtime to use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 12 20:14:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Aug 2016 20:14:08 -0000 Subject: [GHC] #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages In-Reply-To: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> References: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> Message-ID: <059.0daf9d2b7c73d22745cfa5663095970b@haskell.org> #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages -------------------------------------+------------------------------------- Reporter: ertes | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #12170 | Differential Rev(s): Phab:D2451 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * differential: => Phab:D2451 -- Ticket URL: GHC The Glasgow Haskell Compiler From matthew at wellquite.org Fri Aug 12 21:47:10 2016 From: matthew at wellquite.org (matthew) Date: Sat, 13 Aug 2016 00:47:10 +0300 Subject: Fw: exciting news Message-ID: <0000d97d67da$3a694b2a$48601e02$@wellquite.org> Hi! I've just read that news, and I'm so excited, you've got to see it too matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From ghc-devs at haskell.org Sat Aug 13 07:12:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Aug 2016 07:12:26 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on all systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.b678a87429e8317a2cfe13b48c77bdd5@haskell.org> #10352: Properly link Haskell shared libs on all systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5987 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hmm third option using a proxy won't work as I forgot that `__pfnDliNotifyHook2` isn't an OS function but one provided by the lazy loading stubs. I will just have to conditionally modify the GHC code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 13 13:57:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Aug 2016 13:57:12 -0000 Subject: [GHC] #12477: Allow left sectioning and tuple sectioning of types In-Reply-To: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> References: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> Message-ID: <066.cf03fddb9b38aac2a34841247f0dc113@haskell.org> #12477: Allow left sectioning and tuple sectioning of types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -82,0 +82,9 @@ + + **Edit**: Yoneda becomes + + {{{#!hs + type f ~> g = forall xxx. f xxx -> g xxx + + -- Yoneda f a = ((->) a) ~> f + type Yoneda f a = (a ->) ~> f + }}} New description: Simple syntactic change that would be fine to have, allow writing the type `(•) r` as `(r •)`. Just getting a discussion going === Usage === Used briefly in > This gives rise to the monad `S -> (-, S)` the state monad. According to the facts above, we should have that `Codensity (s ->)` (excuse the sectioning) is the same as state, and if we look, we see: > > — [http://comonad.com/reader/2012/unnatural-transformations-and- quantifiers/ The Comonad.Reader] on Unnatural Transformations and Quantifiers === Visible type application === Makes visible type application seem nicer: {{{#!hs fmap @_ @_ @((:-) _) :: (b :- b') -> (a :- b) -> (a :- b') fmap @_ @_ @((->) _) :: (b -> b') -> (a -> b) -> (a -> b') -- vs fmap @_ @_ @(_ :-) :: (b :- b') -> (a :- b) -> (a :- b') fmap @_ @_ @(_ ->) :: (b -> b') -> (a -> b) -> (a -> b') }}} === Examples === {{{#!hs instance Functor ((->) r) instance Functor ((,) a) instance Copointed ((,,) a b) instance Copointed ((,,) a b c) instance Magnify ((->) b) ((->) a) b a where type instance Key ((:->:) a) = a instance HasTrie e => Lookup ((:->:) e) where instance Memo a => Functor ((~>) a) where instance Functor ((&) a) where type Dom ((&) a) = (:-) type Cod ((&) a) = (:-) instance Functor ((:-) a) where type Dom ((:-) a) = (:-) type Cod ((:-) a) = (->) fmap = (.) instance Functor ((:~:) a) where type Dom ((:~:) a) = (:~:) type Cod ((:~:) a) = (->) fmap = (.) instance Adjunction ((,)a) ((->)a) (->) (->) where }}} becomes {{{#!hs instance Functor (r ->) instance Functor (a,) instance Copointed (a, b,) instance Copointed (a, b, c,) instance Magnify (b ->) (a ->) b a where type instance Key (a :->:) = a instance HasTrie e => Lookup (e :->:) where instance Memo a => Functor (a ~>) where instance Functor (a &) where type Dom (a &) = (:-) type Cod (a &) = (:-) instance Functor (a :-) where type Dom (a :-) = (:-) type Cod (a :-) = (->) fmap = (.) instance Functor (a :~:) where type Dom (a :~:) = (:~:) type Cod (a :~:) = (->) fmap = (.) instance Adjunction (a ,) (a ->) (->) (->) where }}} **Edit**: Yoneda becomes {{{#!hs type f ~> g = forall xxx. f xxx -> g xxx -- Yoneda f a = ((->) a) ~> f type Yoneda f a = (a ->) ~> f }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 13 15:18:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Aug 2016 15:18:52 -0000 Subject: [GHC] #12487: configure.ac uses wrong triple information. Message-ID: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> #12487: configure.ac uses wrong triple information. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC's `configure` script seems to normalize the values returned from `config.guess`. So for Windows it turns `x86_64-pc-mingw64` into `x86_64-unknown-mingw32`. These mangled names are stored in the values `$BuildPlatform`, `$HostPlatform` and `$TargetPlatform`. However further down the file when the comparison is done between the stage0 compiler and the host the normalized versions are not used. So when normalization actually changes the triple this check will fail. Not sure why it's worked for all this time.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 13 15:35:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Aug 2016 15:35:03 -0000 Subject: [GHC] #12487: configure.ac uses wrong triple information. In-Reply-To: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> References: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> Message-ID: <059.f877c241af3bb35d528f7bfbacb0aeb0@haskell.org> #12487: configure.ac uses wrong triple information. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- * differential: => Phab:D2452 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 13 15:35:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Aug 2016 15:35:13 -0000 Subject: [GHC] #12487: configure.ac uses wrong triple information. In-Reply-To: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> References: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> Message-ID: <059.9e345bcd65afbd94f62f7dffb8e3fa79@haskell.org> #12487: configure.ac uses wrong triple information. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 13 16:45:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Aug 2016 16:45:10 -0000 Subject: [GHC] #12488: Explicit namespaces doesn't enforce namespaces Message-ID: <049.22659aca0afd9a9976ea8e5a339a006e@haskell.org> #12488: Explicit namespaces doesn't enforce namespaces -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems to me that the type keyword should permanently enforce that a RdrName lives in a particular namespace. Currently it only acts as a syntactic marker so that type constructors which looks like variables can be included in export lists. The following example is accepted by GHC. As `A` is parsed as a type constructor but later put into the data constructor namespace. {{{#!hs {-# LANGUAGE ExplicitNamespaces #-} {-# LANGUAGE TypeFamilies #-} module M ( T (type A) ) where data T = A class Foo a where type A a foo :: a -> Int }}} The fix is to track uses of ExplicitNamespaces in the AST and then use this information in the renamer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 13 18:32:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Aug 2016 18:32:48 -0000 Subject: [GHC] #11592: Self-kinded type variable accepted In-Reply-To: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> References: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> Message-ID: <061.3718420980ccb582727422e03ddc67aa@haskell.org> #11592: Self-kinded type variable accepted -------------------------------------+------------------------------------- Reporter: simonpj | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * owner: => johnleo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 13 18:33:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Aug 2016 18:33:19 -0000 Subject: [GHC] #11963: GHC introduces kind equality without TypeInType In-Reply-To: <045.559d5b56cb415a48409d0ecee32c5ab8@haskell.org> References: <045.559d5b56cb415a48409d0ecee32c5ab8@haskell.org> Message-ID: <060.94034be538f831f67c62fc6275b0ddb4@haskell.org> #11963: GHC introduces kind equality without TypeInType -------------------------------------+------------------------------------- Reporter: ezyang | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * owner: goldfire => johnleo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 13 21:25:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Aug 2016 21:25:15 -0000 Subject: [GHC] #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm In-Reply-To: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> References: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> Message-ID: <059.c38f0391af21cc2b5350ca9b7c02fa37@haskell.org> #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"bd0c31063551744d00796219174739216c398da5/ghc" bd0c3106/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bd0c31063551744d00796219174739216c398da5" Fix GHCi perf-llvm build on x86_64 With BuildFlavour set to `perf-llvm`, GHCi would fail as soon as it was run with: ghc-stage2: .../ghc-prim/dist-install/build/HSghc-prim-0.5.0.0.o: unknown symbol `__udivti3' ghc-stage2: unable to load package `ghc-prim-0.5.0.0' Fix this by adding `__udivti3` and `__umodti3` to RtsSymbols.c. Test Plan: Validate Reviewers: simonmar, austin, bgamari, Phyx, trofi Reviewed By: Phyx, trofi Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2449 GHC Trac Issues: #11981 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 08:20:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 08:20:57 -0000 Subject: [GHC] #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm In-Reply-To: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> References: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> Message-ID: <059.70a05645643a4afa0c8d4fa4d808e116@haskell.org> #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Before commit [changeset:"bd0c31063551744d00796219174739216c398da5/ghc" bd0c3106/ghc] there were over 400 failing tests, and after its less than 50, but the reamaining 50 all seem `ghc-iserv` related. Two examples: {{{ ghc-stage2: ghc-iserv terminated (-11) *** unexpected failure for TH_reifyLocalDefs(ext-interp) }}} {{{ T2700.hs:1:1: error: Exception when trying to run compile-time code: ghc-stage2: ghc-iserv terminated (-11) Code: do { d <- sigD (mkName "foo") [t| (Int -> Bool) -> Bool |]; runIO (hPutStrLn stderr (pprint d)); return [] } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 10:06:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 10:06:17 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.25c8ffcf916bada8d8f1a4917acec958@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): t is certainly hard work on the first ticket. I spent about an hour this morning trying to find out where the right part to change was and then read Ben's email earlier in this thread which made everything much clearer for me! The essential problem we are trying to solve is: > When a module is compiled with -O0, it does not read unfoldings from modules it imports. Because we reuse the unfolding information across modules (to avoid reloading interface files very often), this unfolding information is then not available in the rest of the compilation pipeline. Simon's suggested fix is 1. Always read in unfoldings, etc, including with -O. (Possible exception: one-shot mode.) 2. Check the -fignore-interface-pragmas flag when considering inlining a function. So for part 1, we need to find the part which deals with *reading in* interface files and seeing where the unfolding information is lost. For part 2, we need to find the part of the optimiser which makes decisions about whether to inline a function. So now I'm re-reading Ben's comment and (as usual) his analysis is spot-on. If you trace the origin of the ignore_prags flag then you'll find it is set by checking whether the option `Opt_IgnoreInterfacePragmas` is set or not. You can find that this flag is automatically set when the opt-level is 0 in DynFlags, I'll leave you to find the exact location! It seems like Simon's suggested fix is removing this guard in loadDecls. It isn't clear to me whether the other information (other than the unfoldings) should still be read in or not. Simon will be able to comment. Now for part 2: I think you should start by looking at the callSiteInline function in coreSyn/CoreUnfold. That will at least get you started looking in the right place. Does that help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 12:30:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 12:30:41 -0000 Subject: [GHC] #12489: undefined in view pattern inside pattern synonym causes GHC to panic Message-ID: <043.13b77b21ce220facef2dc94f07499681@haskell.org> #12489: undefined in view pattern inside pattern synonym causes GHC to panic -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following: {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} pattern P :: a -> b pattern P a <- (undefined -> a) }}} causes GHC HEAD and 8.0.1 to panic: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160813 for x86_64-unknown-linux): StgCmmEnv: variable not found }}} Removing the pattern signature or moving `undefined` behind another name work however: {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} bottom :: a bottom = undefined pattern P :: a -> b pattern P a <- (bottom -> a) -- OK! -- No type signature pattern P' a <- (undefined -> a) -- OK! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 14:32:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 14:32:14 -0000 Subject: [GHC] #12489: undefined in view pattern inside pattern synonym causes GHC to panic In-Reply-To: <043.13b77b21ce220facef2dc94f07499681@haskell.org> References: <043.13b77b21ce220facef2dc94f07499681@haskell.org> Message-ID: <058.04f825db0e889f8d8713f63a212ff4ad@haskell.org> #12489: undefined in view pattern inside pattern synonym causes GHC to panic -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 14:33:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 14:33:08 -0000 Subject: [GHC] #12489: undefined in view pattern inside pattern synonym causes GHC to panic In-Reply-To: <043.13b77b21ce220facef2dc94f07499681@haskell.org> References: <043.13b77b21ce220facef2dc94f07499681@haskell.org> Message-ID: <058.bfe3d355a93fe82337605a326339c3b4@haskell.org> #12489: undefined in view pattern inside pattern synonym causes GHC to panic -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This still happens in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 15:05:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 15:05:50 -0000 Subject: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper In-Reply-To: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> References: <044.f94356cf74dc801e8fb7c76a9eaeb24d@haskell.org> Message-ID: <059.da16ce71e3c5b40d322daa4b1f17d0c7@haskell.org> #5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 16:23:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 16:23:32 -0000 Subject: [GHC] #11551: Get doctests into testsuite In-Reply-To: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> References: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> Message-ID: <057.bd46fb7dbe8743c90e9a4e9c8cf8292c@haskell.org> #11551: Get doctests into testsuite -------------------------------------+------------------------------------- Reporter: lwm | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | documentation, doctest Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lwm): bgamari, thanks for the input. > Have you had different experiences, lwm? No, that's pretty much exactly what happened to me. I didn't get as deep as you did with regards to the desugared output. I have since been playing with trying to run doctest against base. I think I will get some logs to illustrate the problem and create an issue over at the doctest repo. It's definitely been blocking me. Otherwise, do you have some recommendations? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 17:41:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 17:41:25 -0000 Subject: [GHC] #12487: configure.ac uses wrong triple information. In-Reply-To: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> References: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> Message-ID: <059.a8e024cb0c83516c37991d71c1fe3ad9@haskell.org> #12487: configure.ac uses wrong triple information. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2452 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"18f06878ed5d8cb0cf366a876f2bfea29647e5f0/ghc" 18f06878/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="18f06878ed5d8cb0cf366a876f2bfea29647e5f0" Fix configure detection. Summary: GHC's configure script seems to normalize the values returned from config.guess. So for Windows it turns x86_64-pc-mingw64 into x86_64-unknown-mingw32. These mangled names are stored in the values $BuildPlatform, $HostPlatform and $TargetPlatform. However further down the file when the comparison is done between the stage0 compiler and the host the normalized versions are not used. So when normalization actually changes the triple this check will fail. Not sure why it's worked for all this time.. Nor if this is the right fix? Does it still work for cross compiling correctly? Test Plan: ./configure Reviewers: hvr, austin, thomie, bgamari, erikd Reviewed By: erikd Subscribers: erikd, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2452 GHC Trac Issues: #12487 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 17:43:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 17:43:04 -0000 Subject: [GHC] #12487: configure.ac uses wrong triple information. In-Reply-To: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> References: <044.116d241c2cd46cfb60f6a0d288061a03@haskell.org> Message-ID: <059.e8b5bdb534c8f8ab8602f7c8a1e5bfe3@haskell.org> #12487: configure.ac uses wrong triple information. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2452 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 18:07:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 18:07:05 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.8bf9050ec28705ffe22f8f3387752d0a@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: I've been thinking about this recently, and I suspect there might be a way to accomplish this without needing anything like `Functor` or `Invariant`. The //only// reason we currently use `Functor` constraints in derived `Generic1` instances is to give us the ability to "tunnel into" data structures that are polymorphically recursive at least two levels deep (e.g., `newtype Compose f g a = Compose (f (g a))`). Consider a `Generic1` instance for `Foo`: {{{#!hs instance Functor f => Generic1 (Compose f g) where type Rep1 (Compose f g) = D1 ('MetaData "Compose" "Ghci3" "interactive" 'True) (C1 ('MetaCons "Compose" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (f :.: Rec1 g))) from1 (Compose x) = M1 (M1 (M1 (Comp1 (fmap Rec1 x)))) to1 (M1 (M1 (M1 x))) = Compose (fmap unRec1 (unComp1 x)) }}} This works, but requires that ugly `Functor` constraint. Is there an alternative? If we replace the `fmap` calls with holes: {{{#!hs instance Generic1 (Compose f g) where type Rep1 (Compose f g) = D1 ('MetaData "Compose" "Ghci3" "interactive" 'True) (C1 ('MetaCons "Compose" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (f :.: Rec1 g))) from1 (Compose x) = M1 (M1 (M1 (Comp1 (_1 x)))) to1 (M1 (M1 (M1 x))) = Compose (_2 (unComp1 x)) }}} Then it becomes clear what functions we need: {{{#!hs _1 :: f (g a) -> f (Rec1 g a) _2 :: f (Rec1 g a) -> f (g a) }}} All that `_1` and `_2` are doing is wrapping and unwrapping a `newtype` underneath an `f`! This would be a perfect job for `Data.Coerce.coerce`. If we could write something like this: {{{#!hs instance (Coercible (f (g a)) (f (Rec1 g a)), Coercible (f (Rec1 g a)) (f (g a)) => Generic1 (Compose f g) where type Rep1 (Compose f g) = D1 ('MetaData "Compose" "Ghci3" "interactive" 'True) (C1 ('MetaCons "Compose" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (f :.: Rec1 g))) from1 (Compose x) = M1 (M1 (M1 (Comp1 (coerce x)))) to1 (M1 (M1 (M1 x))) = Compose (coerce (unComp1 x)) }}} It would work! But we can't write this since `a` isn't in scope in the instance's context. I can't even figure out how to hack it using something like [http://hackage.haskell.org/package/constraints-0.8/docs/Data- Constraint-Forall.html Data.Constraint.Forall] from the `constraints` library. Of course, there's the issue that we don't know //a priori// what role the type argument to `f` has, so there would still be some types for which this `Generic1` instance wouldn't typecheck. But I claim that any type for which `f` is forced to be nominal (i.e., for which you couldn't `coerce` underneath `f`) couldn't have a `Functor` instance anyway, so this approach should be no less expressive than the current one. goldfire, would #9123 (higher-kinded roles) give us the ability to express this? If so, I think we could sidestep the issue of including `Invariant` in `base` entirely, since it would become unnecessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 20:25:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 20:25:34 -0000 Subject: [GHC] #12490: ApplicativeDo and RebindableSyntax do not desugar as expected Message-ID: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> #12490: ApplicativeDo and RebindableSyntax do not desugar as expected -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a module with -XApplicativeDo, -XRebindableSyntax, and local definitions for everything in the Functor-Applicative-Monad hierarchy, do- notation always desugars to "join (... (return ...))" (or /s/return/pure/). This forces the result to have at least the constraints of join, which in my case is "IxMonad m". {{{#!hs {-# LANGUAGE RebindableSyntax, ApplicativeDo #-} module My where -- straightforward definitions of fmap, pure, (<*>), join, return, (>>=), (>>) and fail in terms of IxFunctor, IxPointed, IxApplicative, IxMonad fPure m = do a <- m b <- m pure (a, b) fReturn m = do a <- m b <- m return (a, b) }}} According to -ddump-ds, these desugar to: {{{#!hs fPure :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fPure m = My.join ( My.(<*>) (My.fmap (\a b -> My.pure (a, b)) m) m ) fReturn :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fReturn m = My.join ( My.(<*>) (My.fmap (\a b -> My.return (a, b)) m) m ) }}} But I would expect: {{{#!hs fPure m = My.(<*>) (My.fmap (\a b -> (a, b)) m) m fReturn m = -- same }}} It appears that when "return" is not from base, ApplicativeDo only partially desugars to the specification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 20:27:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 20:27:26 -0000 Subject: [GHC] #12490: ApplicativeDo and RebindableSyntax do not desugar as expected In-Reply-To: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> References: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> Message-ID: <064.eeaa67ea6742a97b7589c7c9ba7e8028@haskell.org> #12490: ApplicativeDo and RebindableSyntax do not desugar as expected -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by AaronFriel: @@ -13,1 +13,1 @@ - (>>) and fail in terms of IxFunctor, IxPointed, IxApplicative, IxMonad + -- (>>) and fail in terms of IxFunctor, IxPointed, IxApplicative, IxMonad New description: In a module with -XApplicativeDo, -XRebindableSyntax, and local definitions for everything in the Functor-Applicative-Monad hierarchy, do- notation always desugars to "join (... (return ...))" (or /s/return/pure/). This forces the result to have at least the constraints of join, which in my case is "IxMonad m". {{{#!hs {-# LANGUAGE RebindableSyntax, ApplicativeDo #-} module My where -- straightforward definitions of fmap, pure, (<*>), join, return, (>>=), -- (>>) and fail in terms of IxFunctor, IxPointed, IxApplicative, IxMonad fPure m = do a <- m b <- m pure (a, b) fReturn m = do a <- m b <- m return (a, b) }}} According to -ddump-ds, these desugar to: {{{#!hs fPure :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fPure m = My.join ( My.(<*>) (My.fmap (\a b -> My.pure (a, b)) m) m ) fReturn :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fReturn m = My.join ( My.(<*>) (My.fmap (\a b -> My.return (a, b)) m) m ) }}} But I would expect: {{{#!hs fPure m = My.(<*>) (My.fmap (\a b -> (a, b)) m) m fReturn m = -- same }}} It appears that when "return" is not from base, ApplicativeDo only partially desugars to the specification. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 20:28:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 20:28:26 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.8baea9a8bc86e70a9814acc6839a3f2b@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): Ryan, this looks very promising! I think this snippet presents the idea clearly, if I understand correctly. Please confirm. {{{#!hs -- | We suspect higher-order kinds (#9123) would supplant this typeclass. class RoleIsRep f where mapCoerce :: Coercible a b => f a -> f b data T f a = T (f [a]) instance RoleIsRep f => Generic1 (T f) where type Rep1 (T f) = D1 ('MetaData "T" "module" "package" 'True) (C1 ('MetaCons "T" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (f :.: Rec1 []))) from1 (T x) = M1 (M1 (M1 (Comp1 (mapCoerce x)))) to1 (M1 (M1 (M1 x))) = T (mapCoerce (unComp1 x)) }}} Note that this is a performance improvement in some cases to boot! And your observation is that if we can define a lawful `Functor f` then we can define `RoleRep f`, right? Can we anticipate a time where a user would want these three things simultaneously: 1) a lawful `Functor f`, 2) a `nominal` role for `f`'s argument, and 3) an automatically derived `Generic1` instance? That's the only case where this would be "worse" for the user, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 20:34:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 20:34:28 -0000 Subject: [GHC] #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure (was: ApplicativeDo and RebindableSyntax do not desugar as expected) In-Reply-To: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> References: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> Message-ID: <064.deb179f8c9772ab275e101ce1052ca27@haskell.org> #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by AaronFriel: @@ -45,1 +45,2 @@ - partially desugars to the specification. + partially desugars to the specification, and the final "return" or "pure" + remains in the output. New description: In a module with -XApplicativeDo, -XRebindableSyntax, and local definitions for everything in the Functor-Applicative-Monad hierarchy, do- notation always desugars to "join (... (return ...))" (or /s/return/pure/). This forces the result to have at least the constraints of join, which in my case is "IxMonad m". {{{#!hs {-# LANGUAGE RebindableSyntax, ApplicativeDo #-} module My where -- straightforward definitions of fmap, pure, (<*>), join, return, (>>=), -- (>>) and fail in terms of IxFunctor, IxPointed, IxApplicative, IxMonad fPure m = do a <- m b <- m pure (a, b) fReturn m = do a <- m b <- m return (a, b) }}} According to -ddump-ds, these desugar to: {{{#!hs fPure :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fPure m = My.join ( My.(<*>) (My.fmap (\a b -> My.pure (a, b)) m) m ) fReturn :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fReturn m = My.join ( My.(<*>) (My.fmap (\a b -> My.return (a, b)) m) m ) }}} But I would expect: {{{#!hs fPure m = My.(<*>) (My.fmap (\a b -> (a, b)) m) m fReturn m = -- same }}} It appears that when "return" is not from base, ApplicativeDo only partially desugars to the specification, and the final "return" or "pure" remains in the output. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 20:39:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 20:39:51 -0000 Subject: [GHC] #12491: ghc-iserv pattern match failure Message-ID: <044.f85efc3f55eac6e07bb4aa316e8edafc@haskell.org> #12491: ghc-iserv pattern match failure -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to debug the issue in https://ghc.haskell.org/trac/ghc/ticket/11981#comment:10 I found that that `ghc-iserv` executable run without any arguments fails with a pattern match failure: {{{ $ inplace/lib/bin/ghc-iserv ghc-iserv: user error (Pattern match failure in do expression at iserv/src/Main.hs:28:3-18) }}} Would be far nicer if it printed out an error message saying what arguments it expected, or how to run it to avoid this pattern match failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 20:40:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 20:40:16 -0000 Subject: [GHC] #12491: ghc-iserv pattern match failure with no command line arguments (was: ghc-iserv pattern match failure) In-Reply-To: <044.f85efc3f55eac6e07bb4aa316e8edafc@haskell.org> References: <044.f85efc3f55eac6e07bb4aa316e8edafc@haskell.org> Message-ID: <059.0f01e8cef3814e4061d6939dfb966b74@haskell.org> #12491: ghc-iserv pattern match failure with no command line arguments -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 20:52:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 20:52:01 -0000 Subject: [GHC] #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm In-Reply-To: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> References: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> Message-ID: <059.5568b16fe971d6f6e7a7862913910ce4@haskell.org> #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Running `inplace/bin/ghc-stage2 --interactive -fexternal-interpreter` seems to work as it should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 21:27:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 21:27:19 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.6522e8958fd82fb8ba8740e048ecfdb1@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): nfrisby, that sounds about right. What you call `RoleIsRep` is what Edward Kmett calls [https://ghc.haskell.org/trac/ghc/ticket/9123#comment:5 Representational], which has the definition: {{{#!hs class Representational f where rep :: Coercible a b => Coercion (f a) (f b) }}} goldfire raised the idea of making `Representational` a superclass of `Functor` [https://ghc.haskell.org/trac/ghc/ticket/9123#comment:3 here]. Indeed, every `Functor` instance should also admit a `Representational` instance. I can't prove this directly, since you aren't allowed to implement `Coercible` instances directly, but you can at least write both halves of the isomorphism a `Coercion` induces: {{{#!hs functorRep1 :: (Coercible a b, Functor f) => f a -> f b functorRep1 = fmap coerce functorRep2 :: (Coercible a b, Functor f) => f b -> f a functorRep2 = fmap coerce }}} And since the `Functor` laws dictate that `fmap id = id`, and `coerce` is morally the same thing as `id`, we can reason that `fmap coerce = coerce` for all law-abiding `Functor`s. With that above machinery, our new `Generic1` instance looks like: {{{#!hs data T f a = T (f [a]) instance Representational f => Generic1 (T f) where type Rep1 (T f) = D1 ('MetaData "T" "module" "package" 'True) (C1 ('MetaCons "T" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (f :.: Rec1 []))) from1 (T x) = M1 (M1 (M1 (Comp1 (coerceWith rep x)))) to1 (M1 (M1 (M1 x))) = T (coerceWith rep (unComp1 x)) }}} Replying to [comment:6 nfrisby]: > Can we anticipate a time where a user would want these three things simultaneously: 1) a lawful `Functor f`, 2) a `nominal` role for `f`'s argument, and 3) an automatically derived `Generic1` instance? That's the only case where this would be "worse" for the user, I think. My hope is that (1) and (2) won't happen simultaneously, but now that I think about it more closely, there is a case where this does happen: type families. Consider this code: {{{#!hs type family Id a where Id a = a newtype I a = I (Id a) instance Functor I where fmap f (I a) = I (f a) newtype T a = T (I [a]) deriving Generic1 }}} However, if we switched over to `Representational`, this would no longer typecheck, since GHC always infers `nominal` roles for every argument of a type family. The fact that `Id`'s argument is `nominal` is a bit annoying, since it //feels// like it should be `representational`, but at present we have no way of enforcing that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 22:03:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 22:03:37 -0000 Subject: [GHC] #10832: Generalize injective type families In-Reply-To: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> References: <048.1487f224b00112fe37d31a1812a748a4@haskell.org> Message-ID: <063.a61a289a11855db6c93167d8db742120@haskell.org> #10832: Generalize injective type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6018 | Differential Rev(s): Phab:D1287 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 14 22:48:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Aug 2016 22:48:52 -0000 Subject: [GHC] #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? In-Reply-To: <042.7aea578c33e94085f5776f18cba04998@haskell.org> References: <042.7aea578c33e94085f5776f18cba04998@haskell.org> Message-ID: <057.a8e0c862f6809c7dfe609c33bdb1ec6e@haskell.org> #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? -------------------------------------+------------------------------------- Reporter: spl | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This `Functor` issue might become less important in the future if we switch over to using a coercion-based approach to deriving `Generic1`. See https://ghc.haskell.org/trac/ghc/ticket/8516#comment:5 for more info. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 00:47:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 00:47:42 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large Message-ID: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm getting this error error when trying to use the `ghc-datasize` package from Hackage to calculate the in memory size of a data structure. The full error is: {{{ load-test: internal error: allocation of 1048608 bytes too large (GHC should have complained at compile-time) (GHC version 8.0.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} However, this message is bogus because this is not a static data structure known at compile time, but data loaded from disk. Currently, my test program just loads this complex data structure (about 27 megabytes of CSV with embedded JSON on disk) into memory and then calls `recursiveSize` from `GHC.Datasize` on it. I get this same error message with both ghc7.10.3 and ghc-8.0.1. If I remove the call to `recursiveSize` there is no error. If I `Control.Deepseq.force` the data structures before calling `recursiveSize` there is no error. So, who is to blame? `ghc-datasize` is just Haskell code that calls public APIs so I think the blame lies with GHC. I'll work on getting a small re-producable test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 02:45:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 02:45:32 -0000 Subject: [GHC] #12136: SIGABRT on right-shift operation against long negative integer In-Reply-To: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> References: <046.ca96221614dc5a54b96ee86f683c2b18@haskell.org> Message-ID: <061.b399681c152b27bc11226bc9f8d07109@haskell.org> #12136: SIGABRT on right-shift operation against long negative integer -----------------------------------+-------------------------------------- Reporter: khibino | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Description changed by khibino: @@ -17,1 +17,1 @@ - and I found the same problem in GHC 8.0.1 too. + and I found the same problem in '''GHC 8.0.1''' too. New description: When the code like bellow is executed, the '''shiftR''' call causes SIGABRT. c128.hs {{{#!hs import Data.Bits x:: Integer x = 1 - (1 `shiftL` (128 + 64)) main :: IO () main = print $ x `shiftR` 128 }}} I make this report using examples in GHC 7.10.3, and I found the same problem in '''GHC 8.0.1''' too. backtrace using GDB {{{ % ghc -O0 c128.hs [1 of 1] Compiling Main ( c128.hs, c128.o ) Linking c128 ... % gdb ./c128 GNU gdb (Debian 7.10-1+b1) 7.10 ... Reading symbols from ./c128...(no debugging symbols found)...done. (gdb) run Starting program: /home/hibi/src/haskell/crash/Haskell/c128 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGABRT, Aborted. 0x00007ffff6ed4478 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 55 ../sysdeps/unix/sysv/linux/raise.c: そのようなファイルやディレクト リはありません. (gdb) bt #0 0x00007ffff6ed4478 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007ffff6ed58fa in __GI_abort () at abort.c:89 #2 0x00000000004716df in integer_gmp_mpn_rshift_2c () #3 0x000000000046e004 in salz_info () #4 0x0000000000000000 in ?? () (gdb) frame 2 #2 0x00000000004716df in integer_gmp_mpn_rshift_2c () (gdb) disas Dump of assembler code for function integer_gmp_mpn_rshift_2c: 0x0000000000471630 <+0>: push %r13 ... 0x00000000004716d8 <+168>: jne 0x4716c0 0x00000000004716da <+170>: callq 0x402c80 => 0x00000000004716df <+175>: nop 0x00000000004716e0 <+176>: lea 0x0(,%rdx,8),%rdx ... End of assembler dump. (gdb) }}} I found '''abort''' call in '''integer_gmp_mpn_rshift_2c'''. ghc-7.10.3/libraries/integer-gmp2/cbits/wrappers.c {{{#!c mp_limb_t integer_gmp_mpn_rshift_2c (mp_limb_t rp[], const mp_limb_t sp[], const mp_size_t sn, const mp_bitcnt_t count) { ... // round if non-zero bits were shifted out if (nz_shift_out) if (mpn_add_1(rp, rp, rn, 1)) abort(); /* should never happen */ return rp[rn-1]; } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 03:08:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 03:08:12 -0000 Subject: [GHC] #11794: Switch to LLVM 3.8 In-Reply-To: <044.5919f8519f8a0f8245fba031199e2674@haskell.org> References: <044.5919f8519f8a0f8245fba031199e2674@haskell.org> Message-ID: <059.8fdf90b7f100c9a6af667d844e5befb9@haskell.org> #11794: Switch to LLVM 3.8 -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed Comment: This was done in commit in [changeset:"672314cbeb8ac386a58f17dc4650dbdf4c55d8b5/ghc" 672314cb/ghc]. Closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 07:44:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 07:44:36 -0000 Subject: [GHC] #12432: Use kind equality in instance context in type family instance In-Reply-To: <046.81766c43f1232218e828bba3b4f71960@haskell.org> References: <046.81766c43f1232218e828bba3b4f71960@haskell.org> Message-ID: <061.52048e8183bda0d0a3c70ac4826085e5@haskell.org> #12432: Use kind equality in instance context in type family instance -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 07:57:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 07:57:09 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.51c56c04569aa47d450f6dc37200fe05@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by spl): * cc: spl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 07:58:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 07:58:16 -0000 Subject: [GHC] #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? In-Reply-To: <042.7aea578c33e94085f5776f18cba04998@haskell.org> References: <042.7aea578c33e94085f5776f18cba04998@haskell.org> Message-ID: <057.201e222f382427aaa8c1763d0fc90fa0@haskell.org> #7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1? -------------------------------------+------------------------------------- Reporter: spl | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by spl): * cc: leather@… (removed) * cc: spl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 08:39:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 08:39:10 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.0ef4c6600eb5bb0cfe47c54f2809229e@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Crumbs... #9123 (about `Representational`) is a long thread! I'm totally not up to speed with all that. However, part of the mix seems to be the feasibility (or otherwise) of allowing constraints like `(forall a. Eq a => Eq [a]` instance contexts; see #2893, #2456, and #5927, etc. For example: {{{ instance (Binary a, forall b. Binary b => Binary (f b)) => Binary (GRowe f a) where ... }}} I've always said "I don't know how to implement that", but this morning it feels different. Suppose that we only allowed those quantified constraints ''in the context of a top-level instance declaration''. * Solving "Wanted" constraints of this form is easy: it's just an implication constraint. * Allowing them as "Given" constraints would be a little awkward, because it'd need a new field in the "inert set" of the constraint solver. But for instances it's all top-level-ish, so we could perhaps just extend the "local instance environment". But even in the more general form it would be quite do-able I think. So, if allowing quantified constraints will help, perhaps it's time we bit that bullet. Simon Then it would only show up as a "Given" constraint when solving instance declarations, not in some arbitrary -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 08:49:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 08:49:13 -0000 Subject: [GHC] #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure In-Reply-To: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> References: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> Message-ID: <064.f3f390086f8e2a0c900d9cb67a3e0200@haskell.org> #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 09:19:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 09:19:46 -0000 Subject: [GHC] #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm In-Reply-To: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> References: <044.ad3f32463aae7c699d4d4bd8ae6b6c27@haskell.org> Message-ID: <059.4e5643fd5ee588e32321c7d7dc217f13@haskell.org> #11981: unknown symbol `__udivti3' when BuildFlavour = perf-llvm -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): If I move `inplace/lib/bin/ghc-iserv` to `inplace/lib/bin/ghc-iserv.exe` and then created shell script at `inplace/lib/bin/ghc-iserv` containing: {{{ #!/bin/bash gdb --args inplace/lib/bin/ghc-iserv.exe $@ }}} Then I can run `ghc-iserv` under gdb and get a backtrace: {{{ Thread 1 "ghc-iserv.exe" received signal SIGSEGV, Segmentation fault. 0x0000000040aba3ff in ?? () (gdb) bt #0 0x0000000040aba3ff in ?? () #1 0x0000000040dbcf52 in ?? () #2 0x0000000040112d81 in ?? () #3 0x0000000001345e18 in MainCapability () #4 0x0000000200098eb8 in ?? () #5 0x00000002000910c0 in ?? () #6 0x0000000000000000 in ?? () (gdb) quit }}} which tells me very little. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 09:59:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 09:59:27 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.c93fcfb668b38febc1af94e36f8ba6c1@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Matthew is right. * Part 1: the easiest thing is to set `Opt_IgnoreInterfacePragmas` to true ''only'' if you specify the flag `-fignore-interface-pragmas` explicitly, and ''not'' with `-O0`. Do that in `DynFlags`. That way an explicit `-fignore-interface-pragmas` flag will still work. * Part 2: with `O0` we want to switch off all inlining (except "compulsory" inlinings; see `InlineCompulsory` in CoreSyn). I think this can conveniently be done by setting `sm_inline = False` in the `SimplMode` in `SimplCore`. Set it in `base_mode`. So actually it looks fairly simple. Does that help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 13:31:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 13:31:26 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.8032c81cf71ca76028c786ce149910e6@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 13:51:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 13:51:24 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.0f0ac7550d6ec7ac96a11d581a4c03b4@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: I //do// have a pratical use-case for this feature: I think it would help solve part of the story for being able to derive `Generic` instances for GADTs (see Trac issues #8560 and #10514). In particular, I think `ImplicationConstraints` would allow be to be polymorphic over any existentially quanitified constraint in a GADT. In particular, there are GADTs like this: {{{#!hs class GShow a where gshow :: a -> String data T a where MkT :: GShow a => a -> T a }}} GHC generics currently lacks a facility for expressing the existential `GShow` constraint. I think we could add something like this: {{{#!hs data EC c f a where MkEC :: c => f a -> EC c f a }}} Then we could derive a `Generic` instance for `T` like so: {{{#!hs instance Generic (T a) where type Rep (T a) = D1 ('MetaData "T" "Ghci2" "interactive" 'False) (C1 ('MetaCons "MkT" 'PrefixI 'False) (EC (GShow a) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 a)))) from (MkT x) = M1 (M1 (MkEC (M1 (K1 x)))) to (M1 (M1 (MkEC (M1 (K1 x))))) = MkT x }}} So far, so good. Now I want to be able to define a generic `GShow` instance for `T` (where `GShow` comes from the [http://hackage.haskell.org/package/generic-deriving-1.10.7/docs/Generics- Deriving-Show.html generic-deriving] library). We already have cases for all generic datatypes except `EC`. This is what I want to be able to write: {{{#!hs class GShow' f where gshow' :: f a -> String instance (c => GShow' f) => GShow' (EC c f) where gshow' (MkEC x) = gshow' x }}} But for that, I need `ImplicationConstraints`. If I want to generalize this to `Generic1` instances, I'd probably need `QuantifiedConstraints` too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 13:53:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 13:53:03 -0000 Subject: [GHC] #10514: Generic for existential types In-Reply-To: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> References: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> Message-ID: <066.0b12d37ea5cac79a0a91753c7ce7edb0@haskell.org> #10514: Generic for existential types -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8560 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think that we'd need new language extensions (`QuantifiedConstraints` and `ImplicationConstraints`) to do this properly. See [https://ghc.haskell.org/trac/ghc/ticket/5927#comment:17 my comment] on #5927. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 14:03:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 14:03:42 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.e5873f198d4a6a3c6440d508c339adef@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: goldfire, I do have a need for this in order to do "real work"... at some point in the future after #9123 is fixed :) My use case is laid out in [https://ghc.haskell.org/trac/ghc/ticket/8516#comment:7 this comment] in #8516. I'm interested in using higher-kinded roles to increase the number of datatypes for which you can derive `Generic1` instances by replacing `Functor` constraints with `Representational` constraints (where `Representational` is the typeclass proposed [https://ghc.haskell.org/trac/ghc/ticket/9123#comment:5 here]). Unfortunately, at the moment, my proposed plan would actually //decrease// that number, because there are datatypes defined in terms of type families for which you can declare `Functor` instances. However, type families always default to `nominal` roles for its type arguments, which means they can't be `Representational`! Ack! It definitely seems like //some// type families should be able to have `Representational` (or even `Phantom`!) roles for its arguments. A prime example is from [https://ghc.haskell.org/trac/ghc/ticket/8516#comment:7 this comment]: {{{#!hs type family Id a where Id a = a }}} I have a strong hunch that `a` should be have a `representational` role. Unfortunately, I have no way to inform GHC of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 14:11:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 14:11:51 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.799a2d12df29eb53d4a263a725a924fd@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks, Simon! `ImplicationConstraints`/`QuantifiedConstraints` is something I've been wanting for a while, and it would definitely help me express more things in GHC generics than I've been wanting to express (see [https://ghc.haskell.org/trac/ghc/ticket/5927#comment:17 this comment] in #5927 for more). nfrisby, I thought of one more scenario in which conditions (1) and (2) could hold, but it's a bit of a silly one: {{{#!hs type role Wat nominal newtype Wat a = Wat a deriving (Functor, Generic1) }}} A scheming user could use `RoleAnnotations` to explicitly mark a role as `nominal` that would otherwise be inferred as `representational` (or `phantom`). But this feels extremely silly to me, since having a `Functor` instance seems to defeat the whole point of having a `nominal` role, since you can just use `fmap` to change the internal representation yourself. Indeed, the only examples I can think of where users mark roles as `nominal` are: 1. `Set` (from the [http://hackage.haskell.org/package/containers-0.5.7.1/docs/Data- Set.html#t:Set containers] package) 2. `HashSet` (from the [http://hackage.haskell.org/package/unordered- containers-0.2.7.1/docs/Data-HashSet.html#t:HashSet unordered-containers] package) 3. `Key` (from the [http://hackage.haskell.org/package/vault-0.3.0.6/docs /Data-Vault-ST-Strict.html#t:Key vault] package) And none of those can have `Functor` instances anyway. So I don't think this "counterexample" is much of a concern at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 14:17:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 14:17:06 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.eef289fafdde0c64571d50617d355bf1@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): And as it turns out, goldfire has a separate ticket (#8177) for the proposed idea of being able to give explicit role signatures to type families, which might make the potential regression in [https://ghc.haskell.org/trac/ghc/ticket/8516#comment:7 this comment] not an actual regression. See my comment [https://ghc.haskell.org/trac/ghc/ticket/8177#comment:31 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 16:21:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 16:21:29 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large In-Reply-To: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> References: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> Message-ID: <059.43078a4336391e87e47d11a340338b50@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @erikd the message indicates that somehow the compiled program attempted to allocate 1048608 in one go, which is supposed to cause a compile-time error. It is not related to whether the data being processed is static or dynamic, but has to do with how the compiled code allocates memory. I don't know what's causing it, but it shouldn't be too hard to track down - find out which bit of code is causing the offending allocation, and find out why GHC didn't detect the overlarge allocation at compile-time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 17:33:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 17:33:24 -0000 Subject: [GHC] #12493: Add gcoerceWith to Data.Type.Coercion Message-ID: <050.16d7bf39c4da65dfb0a405557bc95eac@haskell.org> #12493: Add gcoerceWith to Data.Type.Coercion -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Haskell libraries mailing list discussion: https://mail.haskell.org/pipermail/libraries/2016-July/027207.html > In Data.Type.Equality, we have both > > {{{#!hs > castWith :: (a :~: b) -> a -> b > }}} > > and > > {{{#!hs > gcastWith :: (a :~: b) -> (a ~ b => r) -> r > }}} > > > But in `Data.Type.Coercion` we only have > > {{{#!hs > coerceWith :: Coercion a b -> a -> b > }}} > > It seems to me that for the sake of consistency, we should add > > {{{#!hs > gcoerceWith :: Coercion a b -> (Coercible a b => r) -> r > gcoerceWith Coercion a = a > }}} > > David Feuer I've wanted this too. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 17:35:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 17:35:51 -0000 Subject: [GHC] #12493: Add gcoerceWith to Data.Type.Coercion In-Reply-To: <050.16d7bf39c4da65dfb0a405557bc95eac@haskell.org> References: <050.16d7bf39c4da65dfb0a405557bc95eac@haskell.org> Message-ID: <065.3c506de383e253cfdbb7a9d26bb60eb2@haskell.org> #12493: Add gcoerceWith to Data.Type.Coercion -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2456 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2456 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 17:47:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 17:47:33 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.1b1a1118ea0561f2ec1e75727c5ab07f@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 18:37:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 18:37:59 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.f7912843b155535a9c0847fefc62e2e1@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:31 Iceland_jack]: > > {{{#!hs > data LanO j where > LanO :: LanO (S i) > > data LanS j where > LanS :: Fin i -> LanS (S i) > }}} > > `Fin` defined as > Do `LanO`, `LanS` satisfy the conditions to be newtypes? `LanO` does not, because its constructor takes no arguments. But that's perfectly fine; there's only one `LanO` value anyway. `LanS` does not either, because its constructor is lazy. If you wrote `LanS :: !(Fin i) -> LanS (S i)` then it would satisfy the conditions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 15 19:57:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Aug 2016 19:57:06 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.8d7469d649d8c2a4d30a43aa8c682ff4@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by richardfung): Yes that helps tremendously! This change was a lot simpler than I expected.. I only wish I asked for help sooner. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 00:07:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 00:07:43 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.0d112002a368ab29a1fe96dd0932376f@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by oerjan): `LanO` might, however, be a candidate for being zero width when in a strict field, which could help ''other'' types satisfy the newtype condition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 06:15:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 06:15:41 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows Message-ID: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Relevant code: {{{ -- | @setEnv name value@ sets the specified environment variable to @value at . -- -- On Windows setting an environment variable to the /empty string/ removes -- that environment variable from the environment. For the sake of -- compatibility we adopt that behavior. In particular -- -- @ -- setEnv name \"\" -- @ -- -- has the same effect as -- -- @ -- `unsetEnv` name -- @ }}} This sounds nice and authoritative... and it's also not true. https://msdn.microsoft.com/en- us/library/windows/desktop/ms686206(v=vs.85).aspx states that only if the pointer is NULL (as opposed to an empty string) is the environment variable deleted. https://github.com/golang/go/issues/5610 corroborates So `setEnv` has been given bogus semantics that don't make sense because empty environment variables ARE supported on Windows. My suggestion is to just fix this so that setEnv takes empty environment variables. But this would be a BC breaking change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 08:09:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 08:09:02 -0000 Subject: [GHC] #12243: RebindableSyntax and OverloadedLabels In-Reply-To: <048.6e564fb4c32d0e67f5680b5b6de4225b@haskell.org> References: <048.6e564fb4c32d0e67f5680b5b6de4225b@haskell.org> Message-ID: <063.7aac15d45f6aed6b06549176e2bde345@haskell.org> #12243: RebindableSyntax and OverloadedLabels -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: => adamgundry * milestone: => 8.2.1 Comment: A [https://www.reddit.com/r/haskell/comments/4x8tk8/overloadedlabels_considered_awesome/d6jg78i reddit discussion] made me realise that there are some use cases for this. In particular, the translation of overloaded labels to `IsLabel` may introduce ambiguous type variables, which could be avoided using a more restrictive `fromLabel` (e.g. constraining it to be a field selector, one we have `OverloadedRecordFields`). Essentially, rebindable syntax makes it possible to choose a single `IsLabel` instance for an entire module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 08:13:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 08:13:21 -0000 Subject: [GHC] #11343: Unable to infer type when using DuplicateRecordFields In-Reply-To: <049.6becc7f1facb1381b419a45f19851622@haskell.org> References: <049.6becc7f1facb1381b419a45f19851622@haskell.org> Message-ID: <064.3724d93f87498c9373af509561f68410@haskell.org> #11343: Unable to infer type when using DuplicateRecordFields -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: adamgundry => Comment: I'm inclined to think we should close this and recommend use of the forthcoming `OverloadedRecordFields` in cases like this. But if anyone wants to argue for a well-specified but more permissive `DuplicateRecordFields`, I'm not strongly opposed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 08:19:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 08:19:19 -0000 Subject: [GHC] #12384: Type family not reduced, again In-Reply-To: <047.4aa60b42d6ca7ab25500fb26e0021c6b@haskell.org> References: <047.4aa60b42d6ca7ab25500fb26e0021c6b@haskell.org> Message-ID: <062.34ec341c15eec4229bb2a9103b441c92@haskell.org> #12384: Type family not reduced, again -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Yes, I think this is something we simply don't support at all. Associated type declarations are just a way to remind you to add `type instance` decl for D whenever you make an `instance` decl for `C`. It's always equivalent to doing it separately, thus: {{{ type instance D a = True instance (F a ~ Bool) => C a where }}} And you can see that this isn't going to work. The point is that `(F a ~ Bool)` is has local evidence, bound by the dictionary lambda for the instance dfun. That evidence can't be used in a `type instance` decl. So I'll close this as invalid, but you can re-open as a feature request if (a) you think it's important, (b) you can specify what it does, and (c) you can extend System FC to support it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 09:47:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 09:47:49 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.3fda3c4757f5e73ed1be11b08db83b3e@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bergmark): I think it's important to make sure that there is some kind of mention/warning to let users know that their code changed because of this. I see three ways to accomplish this: * Deprecate `setEnv` and add the new function under a new name * Add a warning pragma for one release cycle and then make the change * Change the parameter to only accept non-empty strings What about staying compatible with several versions of base? Should users never use an empty string (effectively banning the use of empty env vars), and/or should we refer users to the base-compat package? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 11:35:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 11:35:36 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.ee452bdf08f79314fa77cd24a7b473e6@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): It's maybe worth pointing out that `setEnv` has been introduced with base-4.7.0.0 (via #7427 & https://mail.haskell.org/pipermail/libraries/2012-October/018560.html) Replying to [comment:1 bergmark]: > I think it's important to make sure that there is some kind of > mention/warning to let users know that their code changed because of > this. On the one hand, we use semantic versioning to signal this very kind of semantic API changes; on the other hand, `base` makes inflationary use of major version increments due to its large API surface, so that we end up with a sub-optimal signal/noise ratio, resulting in API consumers not paying attention anymore... :-( > I see three ways to accomplish this: > * Deprecate `setEnv` and add the new function under a new name I think that'd be the safest approach given the circumstances, and it would side-step all the BC issues; the only downside is having to figure out a good name for the new function... :-) > * Add a warning pragma for one release cycle and then make the change That's still gonna result in silent failures for users which don't pay attention to semantic version signalling nor compile warnings or which happen to skip that one release cycle which warned about it. > * Change the parameter to only accept non-empty strings how? > What about staying compatible with several versions of base? Should users never use an empty string (effectively banning the use of empty env vars), and/or should we refer users to the base-compat package? In hindsight, maybe we should have thrown an exception for situations where `setEnv` would act like `unsetEnv`, or unify `setEnv` with `unsetEnv` by using `:: String -> Maybe String -> IO ()`... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 11:52:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 11:52:08 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.3ee1fc9e4e156435796b4c60a8432ce7@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bergmark): > On the one hand, we use semantic versioning to signal this very kind of semantic API changes; on the other hand, base makes inflationary use of major version increments due to its large API surface, so that we end up with a sub-optimal signal/noise ratio, resulting in API consumers not paying attention anymore... :-( Do people actually care less about the base changelog than for other packages? Semantic changes are always scary since they can be missed, but your point still stands. > > Change the parameter to only accept non-empty strings > how? Using NonEmpty Char, which is a bit wonky. ''dreams of non-empty literals'' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 12:00:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 12:00:49 -0000 Subject: [GHC] #12428: Allow pattern synonyms to optionally carry coerceability In-Reply-To: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> References: <045.f7b089d2570bb063442b06cde2fff958@haskell.org> Message-ID: <060.bd7574a36f1eefbdfccc7d83dc48649c@haskell.org> #12428: Allow pattern synonyms to optionally carry coerceability -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Joachim is right. This has really has nothing to do with pattern synonyms. It would apply just as much if instead of `pattern NewFoo` we offered {{{ getFoo :: Foo a -> a getFoo (Foo (Bar x)) = x }}} Now I suppose you might want to * Export the type `Foo` and function `getFoo`, but not the data constructors `Foo` and `Bar`. * And still get `(Coercible (Foo a) a)` in importing modules, although the relevant data constructors are not in scope. Yes, that's possible. If lots of people want it, I guess we can look for some way to control the export of the `Coercible` instance. But it's rather orthogonal to pattern synonyms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 13:39:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 13:39:57 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.845610b7217e502c36d39c3af3963e45@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): I think it's OK to just change the semantics of this function and make the change clearly marked in the change log and its documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 13:55:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 13:55:13 -0000 Subject: [GHC] #9498: GHC links against unversioned .so files In-Reply-To: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> References: <049.d32b3f82e5dcd1a97fdfbd3f9b5afd1e@haskell.org> Message-ID: <064.2b13b6377b9ede2bb8748e964d9bd830@haskell.org> #9498: GHC links against unversioned .so files -------------------------------------+------------------------------------- Reporter: Kritzefitz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 (Linking) | Resolution: | Keywords: Debian Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11238 | Blocking: 9237 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): This, or a related problem, came up in Debian: https://bugs.debian.org /cgi-bin/bugreport.cgi?bug=834026#10 The summary is: Currently, if a Haskell library foo depends on bar, and bar uses a C library libbaz, then creating the shared library libHSfoo.so will be built with -lbaz, and hence link to libbaz.so.42, even though that dependency is already encoded in libHSbar.foo. Now, if libbaz is upgraded and bar is rebuilt the new version of libbaz, then baz’s ABI stays the same (so foo is not going to be rebuilt), but now foo is broken, as it cannot find `libbaz.so.42` any more. @trommler writes on LinkingHaskell (Emphasis mine), which should avoid this problem for us. > All Haskell libraries and all '''directly''' dependent C libraries must be passed to the linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 16:30:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 16:30:43 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.55c4fcfe0141806ce4b93d7fc6f4b6f7@haskell.org> #12463: SPECIALIZABLE pragma? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think you are describing what INLINEABLE already does, although I agree that SPECIALISABLE would be a less confusing name (or synoynym). INLINEABLE: * Keeps a copy of the original (desugared) source code for the function. * If it has any type-class overloading in its type, it specialises the function in every module where it is called, at the types at which it is called. This works even if the function is recursive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 16:33:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 16:33:41 -0000 Subject: [GHC] #11385: Unify named wildcards in different type applications In-Reply-To: <051.0076b412916fb4cfc0823d8e3d44b32d@haskell.org> References: <051.0076b412916fb4cfc0823d8e3d44b32d@haskell.org> Message-ID: <066.06a920c905b49faecad46ee051cdf566@haskell.org> #11385: Unify named wildcards in different type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: duplicate | NamedWildCards TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11350 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: OK well I'll close this one them, in favour of #11350 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 16:42:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 16:42:59 -0000 Subject: [GHC] #12495: GHC's configure script detects MADV_FREE when it shouldn't Message-ID: <044.997e9b75dfddfee0f98aa3aabfdabed9@haskell.org> #12495: GHC's configure script detects MADV_FREE when it shouldn't -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: MADV_FREE | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In osDecommitMemory there is a [http://git.haskell.org/ghc.git/blob/4986837f8168cacf95c24fecc84d7b36c47f3c11:/rts/posix/OSMem.c#l507 #define] for MADV_FREE. The presence of MADV_FREE is detected by the [http://git.haskell.org/ghc.git/blob/4986837f8168cacf95c24fecc84d7b36c47f3c11:/configure.ac#l1052 configure] script, however merely testing for the presence of this symbol does not prove that MADV_FREE is supported by the kernel (which was [https://kernelnewbies.org/Linux_4.5#head- 42578a3e087d5bcc2940954a38ce794fe2cd642c introduced in 4.5]). On newer versions of GCC (e.g. 6.1.1 on Alpine Edge), [https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=981569c74cbb6bafa2ddcefa6dd9dbdc938ff1c8 MADV_FREE is included in the compiler's header files], thus leading to a false positive. The impact of this bug is that when GHC is compiled with a more recent version of GCC, "unable to decommit memory: Invalid argument" errors will abound. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 16:47:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 16:47:17 -0000 Subject: [GHC] #12474: Regression: Syntax error in -ddump-minimal-imports for records in GHC 8.0 In-Reply-To: <042.a524b4a6c3164cd796982501b5b54c85@haskell.org> References: <042.a524b4a6c3164cd796982501b5b54c85@haskell.org> Message-ID: <057.6ddf79ebe43c794d1020e4fa67e49b3b@haskell.org> #12474: Regression: Syntax error in -ddump-minimal-imports for records in GHC 8.0 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Fixed in HEAD by {{{ commit 018487e686793e22efd595491be5b5305ed2b9c0 Author: Matthew Pickering Date: Fri May 6 17:15:54 2016 +0100 Fix pretty printing of IEThingWith }}} Merge to stable branch (if it hasn't been already). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 17:36:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 17:36:50 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.17d3ab4bac5a36b4e80e7a7b578c2f50@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I also support just fixing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 18:01:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 18:01:18 -0000 Subject: [GHC] #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows In-Reply-To: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> References: <045.fd6c657ae3b3eb1c0db68ee27fdabe97@haskell.org> Message-ID: <060.b132b45f71d9b898e7b4056ecac8aa04@haskell.org> #12494: Implementation of setenv in base incorrectly claims empty environment variable not supported on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Btw, if we go for the first option, i.e. just change semantics of the existing `setEnv` operation (in which case I'd argue not to use any warnings, as we don't have any facility to properly acknowledge specific warnings yet), then we need to make sure that the hackage:setenv package gets retrofitted with an upper bound on `base`, since `setenv` re-exports `setEnv` from `base`... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 20:24:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 20:24:36 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.c8ab987466a7bc30ddcc5b5fdc413df1@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 20:24:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 20:24:56 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on all systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.ac6b77faf38d907f7999fa5705a61746@haskell.org> #10352: Properly link Haskell shared libs on all systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5987 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 20:42:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 20:42:26 -0000 Subject: [GHC] #12495: GHC's configure script detects MADV_FREE when it shouldn't In-Reply-To: <044.997e9b75dfddfee0f98aa3aabfdabed9@haskell.org> References: <044.997e9b75dfddfee0f98aa3aabfdabed9@haskell.org> Message-ID: <059.ca44931a8d92b11992bf9d65a3cec5c1@haskell.org> #12495: GHC's configure script detects MADV_FREE when it shouldn't -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: MADV_FREE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by orion): * Attachment "ghc-fix-madv-free.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 16 20:43:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Aug 2016 20:43:01 -0000 Subject: [GHC] #12495: GHC's configure script detects MADV_FREE when it shouldn't In-Reply-To: <044.997e9b75dfddfee0f98aa3aabfdabed9@haskell.org> References: <044.997e9b75dfddfee0f98aa3aabfdabed9@haskell.org> Message-ID: <059.27c182535855f7a2bf153d57c248df9d@haskell.org> #12495: GHC's configure script detects MADV_FREE when it shouldn't -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: MADV_FREE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by orion): Attached is a patch which fixes the problem for me. It may not be the ideal solution however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 00:23:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 00:23:12 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large In-Reply-To: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> References: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> Message-ID: <059.e014068d59b07e455a491c69f618a1c6@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I suspect this issue was actually a problem with an attoparsec parser not handing escape sequences correctly (my fault) and then causing an allocation that was too big. Still not understanding how this could have been detected at compile time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 08:51:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 08:51:14 -0000 Subject: [GHC] #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs Message-ID: <041.fe13b79f3753d34e58ed0cb274b335c2@haskell.org> #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs ------------------------------+--------------------------------- Reporter: pl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+--------------------------------- GHCi (win32, v8.0.1) gives strange unknown symbols when being run using a library that interfaces code written in C or C++. Compiled code runs fine. As an example I use the eigen-2.1.6 package from hackage. However, it should be noted that I get a similar error message when trying to link a package that uses libgsl (gsl has been compiled with the mingw-gcc that ships with haskell-platform). When I compile the little script from the eigen-manual on hackage {{{#!hs module Main where import Data.Eigen.Matrix import Data.Eigen.LA main = do let a :: MatrixXd a = fromList [[1,2,3], [4,5,6], [7,8,10]] b = fromList [[3],[3],[4]] x = solve ColPivHouseholderQR a b putStrLn "Here is the matrix A:" >> print a putStrLn "Here is the vector b:" >> print b putStrLn "The solution is:" >> print x }}} I get (as expected): {{{ Here is the matrix A: Matrix 3x3 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 10.0 Here is the vector b: Matrix 3x1 3.0 3.0 4.0 The solution is: Matrix 3x1 -2.0 1.0000000000000016 0.9999999999999988 }}} However, when I try to run it in GHCi I get {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, modules loaded: Main. *Main> main ghc.exe: C:/Program Files (x86)/Haskell Platform/8.0.1/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/libstdc++.a: unknown symbol `___emutls_get_address' ghc.exe: Could not on-demand load symbol '___cxa_get_globals' ghc.exe: C:/Program Files (x86)/Haskell Platform/8.0.1/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/libstdc++.a: unknown symbol `___cxa_get_globals' ghc.exe: Could not on-demand load symbol '___cxa_begin_catch' ghc.exe: D:\Users\U439644\AppData\Roaming\cabal\i386-windows- ghc-8.0.1\eigen-2.1.6-6ZlfU8NIal9qgw3j5GclW\HSeigen-2.1.6-6 ZlfU8NIal9qgw3j5GclW.o: unknown symbol `___cxa_begin_catch' ghc.exe: unable to load package `eigen-2.1.6' }}} I tried the same on OS X using GHCi v8.0.1. There everything works as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 13:32:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 13:32:49 -0000 Subject: [GHC] #12162: Concatenation of type level symbols missing In-Reply-To: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> References: <047.a39dfecb4a77da1ac163d250ec666f55@haskell.org> Message-ID: <062.9a5771afe7a634838132c135e58c4945@haskell.org> #12162: Concatenation of type level symbols missing -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 13:33:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 13:33:02 -0000 Subject: [GHC] #11342: Character kind In-Reply-To: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> References: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> Message-ID: <063.1ba4db3e6a1c8522dcccbd2f83b76b6a@haskell.org> #11342: Character kind -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: alexvieth Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: DataKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10776, #12162 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 13:41:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 13:41:29 -0000 Subject: [GHC] #12177: Relevant bindings includes shadowed bindings In-Reply-To: <045.0e76a562090c9d87371f445f74b8515d@haskell.org> References: <045.0e76a562090c9d87371f445f74b8515d@haskell.org> Message-ID: <060.fcaac0c740c50614485e67860ad44b16@haskell.org> #12177: Relevant bindings includes shadowed bindings -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12177 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2434 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T12177 Comment: It looks as though Edward committed the patch, so shouldn't the status change to 'merge' or 'fixed' depending on whether we plan to merge this to 8.0? I've also updated the Testcase: field, which no one seems to do. Thanks Annie and Edward. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 13:44:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 13:44:38 -0000 Subject: [GHC] #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages In-Reply-To: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> References: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> Message-ID: <059.6ffc0a3f780b079e91fbf36631d9763b@haskell.org> #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages -------------------------------------+------------------------------------- Reporter: ertes | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #12170 | Differential Rev(s): Phab:D2451 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for the patch, ak3n! I reviewed it, but found an easier way. I'll commit a patch shortly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 15:09:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 15:09:21 -0000 Subject: [GHC] #12489: undefined in view pattern inside pattern synonym causes GHC to panic In-Reply-To: <043.13b77b21ce220facef2dc94f07499681@haskell.org> References: <043.13b77b21ce220facef2dc94f07499681@haskell.org> Message-ID: <058.628f7723bef4e7c4f91c2c9a1b8cc2e5@haskell.org> #12489: undefined in view pattern inside pattern synonym causes GHC to panic -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f352e5cd7bb629fe0ca3b913bfbe7bee43d62f3a/ghc" f352e5c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f352e5cd7bb629fe0ca3b913bfbe7bee43d62f3a" Keep the bindings local during defaultCallStacks defaultCallStacks generates evidence bindings for call stacks, but wasn't setting the binding site correctly. As a result they were simply discarded in the case of pattern synonyms, giving rise to Trac #12489. The fix is easy; and I added an ASSERT to catch the error earlier. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 15:09:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 15:09:21 -0000 Subject: [GHC] #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages In-Reply-To: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> References: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> Message-ID: <059.39f57fa44b4e4824d7643c8a6d7d0e64@haskell.org> #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages -------------------------------------+------------------------------------- Reporter: ertes | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #12170 | Differential Rev(s): Phab:D2451 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"efc0372a157eadeee58bbada77c64d53590e04af/ghc" efc0372a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="efc0372a157eadeee58bbada77c64d53590e04af" Not-in-scope variables are always errors This fixes Trac #12406. A not-in-scope error shoudl be an error even if you have -fdefer-typed-holes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 15:12:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 15:12:44 -0000 Subject: [GHC] #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages In-Reply-To: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> References: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> Message-ID: <059.581c56e18e5ff51050833e9f0da02eef@haskell.org> #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages -------------------------------------+------------------------------------- Reporter: ertes | Owner: ak3n Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_fail/T12406 Blocked By: | Blocking: Related Tickets: #12170 | Differential Rev(s): Phab:D2451 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_fail/T12406 Comment: Let's merge to 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 15:13:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 15:13:51 -0000 Subject: [GHC] #12489: undefined in view pattern inside pattern synonym causes GHC to panic In-Reply-To: <043.13b77b21ce220facef2dc94f07499681@haskell.org> References: <043.13b77b21ce220facef2dc94f07499681@haskell.org> Message-ID: <058.ac9fdcad1e409a39d99c34eb22bd2818@haskell.org> #12489: undefined in view pattern inside pattern synonym causes GHC to panic -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | patsyn/should_compile/T12489 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => patsyn/should_compile/T12489 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 15:31:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 15:31:30 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.b945b170419390c57c894f7dd0892149@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've lost context on this. The trac ticket is very long, and I'm no longer sure * What, exactly, is the problem we are trying to solve? * What's the overview of the proposed solution? * How the solution works in detail I wonder whether you might write a wiki page on Literal Strings, to describe how literal strings are handled, at least in your proposal? Are there any tests that check that the problem is indeed solved? I notice that the Phab patch changes `.gitmodules` to point to your repos, which presumably can't be right for a commit to GHC master. Sorry to be dense. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 19:26:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 19:26:36 -0000 Subject: [GHC] #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs In-Reply-To: <041.fe13b79f3753d34e58ed0cb274b335c2@haskell.org> References: <041.fe13b79f3753d34e58ed0cb274b335c2@haskell.org> Message-ID: <056.7c05247e95e08331e05ab86125287bd9@haskell.org> #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs -------------------------------------+------------------------------------- Reporter: pl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pl): * failure: None/Unknown => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 20:29:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 20:29:23 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.b8cfc35fd76754883051760b6e8a101c@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by richardfung): Sorry even though you basically did the ticket for me already I still have more questions.. I'm trying to think of a good test case to add for this but it seems like the tests are limited to comparing stdout and stderr and checking if it compiled or ran successfully, at least if I understand correctly. That being the case, I was thinking I could make a test that runs with -ddump-inlinings and compare the output. Would that work? Ideally I would like to run --make twice (with the scenario that someone else mentioned where we force the module with optimizations to run first and where it runs second) and compare the inlining output to make sure they're the same. This would be nice in case the -ddump-inlinings format ever changes but I'm not sure this kind of test is supported and I also don't know how likely it is that the format would change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 20:37:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 20:37:38 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.17029742d530b08e841c4aacf4b0b56e@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): There are few cases where we have just directly checked in output to the test suite, grepping for `-ddump` I see `-ddump-simpl` (be sure to add `-dsuppress-uniques`), I also recently added a `-ddump-stg`. If you want to go your original approach, you'll need to write a `Makefile` rule for it. If you look at, for example, `testsuite/tests/driver/Makefile` you can see examples. Note that you'll have to edit `testsuite/driver/extra_files.py` to make sure all your test files get added -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 22:59:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 22:59:23 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large In-Reply-To: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> References: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> Message-ID: <059.a613db0c16f1dd2e7c25986d606a0b61@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): The parser bug has been fixed and all the Attoparsec parsers now check that all input has been consumed. I thought that this had killed this problem, but then it reared its ugly head again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 17 23:43:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Aug 2016 23:43:45 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large In-Reply-To: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> References: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> Message-ID: <059.55f21570ad8e4408f36baceec6d0c3d6@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Running with the debug RTS and `-Ds` I get: {{{ cap 0: finished GC task exiting cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (heap overflow) load-test: internal error: allocation of 1034912 bytes too large (GHC should have complained at compile-time) (GHC version 7.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} To me, "heap overflow" sounds bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 00:30:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 00:30:05 -0000 Subject: [GHC] #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes In-Reply-To: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> References: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> Message-ID: <064.1f7e2bc4feb1d3ab38fe837690394e1d@haskell.org> #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10569, #12156, | Differential Rev(s): #12406 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: => ak3n -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 00:47:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 00:47:39 -0000 Subject: [GHC] #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes In-Reply-To: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> References: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> Message-ID: <064.c3736021a378c4f8471abdd45700713a@haskell.org> #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10569, #12156, | Differential Rev(s): Phab:D2458 #12406 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * differential: => Phab:D2458 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 00:52:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 00:52: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.41e1ed0eca13e151b08dce5f219f7798@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by niteria): It's been a while since my last commit, so I will give a quick status update. Determinism is coming to 8.0.2, Ben Gamari kindly merged all the patches I sent him. Thanks Ben! That's a subset of the patches on this ticket, but a subset that was sufficient during my testing on GHC and Stackage to make the results deterministic (interface file determinism). That said phab:D2288, being a TH change couldn't make it into 8.0.2. Fortunately the packages that tripped up on it have been fixed: https://github.com/aelve/microlens/issues/83, https://github.com/ekmett/lens/issues/669. Props to the maintainers for the lightning fast fix! If you're in a position to test 8.0.2 for determinism before it comes out, any reports would be appreciated. No refunds though! Is this ticket ready to be closed? Not yet, it's still possible to accidentally reintroduce non-determinism in GHC. `Ord Unique` is removed, but `UniqFM` doesn't use it and just gets the underlying integer. More work needs to be done to remove non- deterministic operations on `UniqFM`. I intend to do this work, but currently I shifted my focus to migrating to the soon-to-be GHC 8.0.2 within my company. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 01:34:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 01:34:04 -0000 Subject: [GHC] #12432: Use kind equality in instance context in type family instance In-Reply-To: <046.81766c43f1232218e828bba3b4f71960@haskell.org> References: <046.81766c43f1232218e828bba3b4f71960@haskell.org> Message-ID: <061.c000ba896d6a1c70ca9a52229c160ee0@haskell.org> #12432: Use kind equality in instance context in type family instance -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: I concur with comment:9 that this has become #12384. Closing as a duplicate. Please reopen if you want to, as per comment:3:ticket:12384. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 02:37:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 02:37:29 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.8629e3f65ef879933b3dc170c6ad8d52@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:9 simonpj]: > But even in the more general form it would be quite do-able I think. So, if allowing quantified constraints will help, perhaps it's time we bit that bullet. I think this is do-able. (I'm not currently volunteering to do it, though. Perhaps in the future, as doing this looks fun.) See our conversation starting at comment:14:ticket:2256. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 03:03:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 03:03:22 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.2029efdc19bcf38dbea213301b8e81e0@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): How would we write the body for, say, `with :: c -> (c => r) -> r`? What about `whichOne :: c -> c -> (c => r) -> r` (which takes two elements of type `c`)? I'm worried that the disadvantages of comment:11 are a bit painful. Perhaps no worse than where we are now, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 06:24:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 06:24:48 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large In-Reply-To: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> References: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> Message-ID: <059.aeb9f82425ad4651264c16049d650dcf@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Looking at function `scheduleHandleHeapOverflow` in `rts/Schedule.c` it looks like its not possible to allocate a single block larger than `252 * 4096` bytes. Is that right? I *know* I've allocated `ByteString`s bigger than that or are `ByteString`s allocated in a different way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 06:40:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 06:40:04 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.e36223acbaff1a93347ddc312ee60460@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by richardfung): Unless someone has a strong preference otherwise I'm inclined to go with the easier solution of comparing against a hard coded -ddump-inlinings output. I don't think I'd be able to manage the more complicated test without help and I'm not convinced it's worth the extra effort especially if we're already doing things the simpler way elsewhere. Where should these tests go though? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 07:05:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 07:05:37 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large In-Reply-To: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> References: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> Message-ID: <059.cf00d037e7d03f16e23862a0a05ae7d4@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Begining to think this is actually a problem with `ghc-datasize` or `ghc- heap-view` which it sits on top of. I have a function `readComplexDataStructureFromDisk`. If I do: {{{#!hs x <- readComplexDataStructureFromDisk size <- recursiveSize $ Control.DeepSeq.force x print size }}} I get the error above. If I rewrite it as: {{{#!hs x <- Control.DeepSeq.force <$> readComplexDataStructureFromDisk size <- recursiveSize x print size }}} there is no error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 07:11:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 07:11:54 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.52e52de0ce81df9790af756e67a84f23@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Tests should got in `testsuite/tests/simplCore` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 07:28:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 07:28:38 -0000 Subject: [GHC] #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes In-Reply-To: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> References: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> Message-ID: <064.4716d428f585a0eaf397468d95e76d66@haskell.org> #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10569, #12156, | Differential Rev(s): Phab:D2458 #12406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Personally I'm not sure it's worth having more flag, but I don't object provided it is well-documented. I've commented on the Phab patch too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 08:51:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 08:51:33 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.a7041d916cae3df9899eb3db57c1a560@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Unpolished ideas: use `djinn`, [https://mail.haskell.org/pipermail /haskell-cafe/2015-April/119385.html Exference] or any other [http://www.cis.upenn.edu/~stevez/papers/OZ15.pdf program synthesiser]) to supply the function body {{{#!hs {-# SYNTHESISE id #-} id :: forall a. a -> a }}} would be as if the user had written {{{#!hs id :: forall a. a -> a id x = x }}} Perhaps this could be implemented using plugin + annotations, I'm not familiar with the details: {{{#!hs {-# ANN f Exference #-} f :: Show b => (a -> b) -> [a] -> [String] }}} producing {{{#!hs f :: Show b => (a -> b) -> [a] -> [String] f b = fmap (\g -> show (b g)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 10:09:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 10:09:29 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi In-Reply-To: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> References: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> Message-ID: <059.ab814565b6d7be54f71f828a8d7409a1@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2447 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The implementation is easy: delete code. But what is the user-facing specification? We need user-manual stuff explaining what all this `Ghci4.foo` stuff means. How would you know whether to say `:t Ghci2.foo` or `:t Ghci3.foo`? Can you list all the `foo` functions? Etc. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 10:18:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 10:18:47 -0000 Subject: [GHC] #8955: Syscall intrinsic In-Reply-To: <046.87831a2ab7ed854bc7dbc1d0bed32dbe@haskell.org> References: <046.87831a2ab7ed854bc7dbc1d0bed32dbe@haskell.org> Message-ID: <061.9d4f9c9542127ae561229a244939de96@haskell.org> #8955: Syscall intrinsic -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: What is your vision on how it's supposed to be used in haskell? A new 'foreign import' type per OS/arch target type? A new syntax to be able to call assembly instructions directly from haskell? > Also, marginally increased speed for calling syscalls since it doesn't need to go through libffi into C-land. On at least i386 and amd64 GHC does not use libffi to call simple libc functions. For 'foreign import ccall unsafe' symbols GHC emits '''call ''' instruction directly. Native/via-libc difference might be in order of a few instructions. Note the amount of existing indirections: {{{#!hs module M where import Foreign.C foreign import ccall unsafe "foo" c_foo :: CInt -> IO CInt }}} gets translated to {{{ .section .data .align 8 .align 1 .globl __stginit_M .type __stginit_M, @object __stginit_M: .section .rodata .align 8 .align 1 c2oj_str: .byte 109 .byte 97 .byte 105 .byte 110 .byte 0 .section .data .align 8 .align 1 .globl M_zdtrModule2_closure .type M_zdtrModule2_closure, @object M_zdtrModule2_closure: .quad ghczmprim_GHCziTypes_TrNameS_static_info .quad c2oj_str .section .rodata .align 8 .align 1 c2om_str: .byte 77 .byte 0 .section .data .align 8 .align 1 .globl M_zdtrModule1_closure .type M_zdtrModule1_closure, @object M_zdtrModule1_closure: .quad ghczmprim_GHCziTypes_TrNameS_static_info .quad c2om_str .section .data .align 8 .align 1 .globl M_zdtrModule_closure .type M_zdtrModule_closure, @object M_zdtrModule_closure: .quad ghczmprim_GHCziTypes_Module_static_info .quad M_zdtrModule2_closure+1 .quad M_zdtrModule1_closure+1 .quad 3 .section .data .align 8 .align 1 r2eE_closure: .quad r2eE_info .section .text .align 8 .align 8 .quad 8589934597 .quad 0 .quad 15 r2eE_info: .Lc2ow: leaq -8(%rbp),%rax cmpq %r15,%rax jb .Lc2oF .Lc2oG: movq $c2ot_info,-8(%rbp) movq %r14,%rbx addq $-8,%rbp testb $7,%bl jne .Lc2ot .Lc2ou: jmp *(%rbx) .Lc2oJ: movq $16,904(%r13) jmp stg_gc_unpt_r1 .align 8 .quad 0 .quad 31 c2ot_info: .Lc2ot: addq $16,%r12 cmpq 856(%r13),%r12 ja .Lc2oJ .Lc2oI: movq 7(%rbx),%rdi subq $8,%rsp xorl %eax,%eax call foo addq $8,%rsp movq $base_GHCziInt_I32zh_con_info,-8(%r12) movslq %eax,%rax movq %rax,(%r12) leaq -7(%r12),%rbx addq $8,%rbp jmp *(%rbp) .Lc2oF: movl $r2eE_closure,%ebx jmp *-8(%r13) .size r2eE_info, .-r2eE_info .section .data .align 8 .align 1 .globl M_czufoo_closure .type M_czufoo_closure, @object M_czufoo_closure: .quad M_czufoo_info .section .text .align 8 .align 8 .quad 8589934597 .quad 0 .quad 15 .globl M_czufoo_info .type M_czufoo_info, @object M_czufoo_info: .Lc2oT: jmp r2eE_info .size M_czufoo_info, .-M_czufoo_info .section .data.rel.ro .align 8 .align 1 S2p0_srt: .section .note.GNU-stack,"", at progbits .ident "GHC 8.1.20160817" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 10:41:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 10:41:13 -0000 Subject: [GHC] #8955: Syscall intrinsic In-Reply-To: <046.87831a2ab7ed854bc7dbc1d0bed32dbe@haskell.org> References: <046.87831a2ab7ed854bc7dbc1d0bed32dbe@haskell.org> Message-ID: <061.9550fd73fc2dece88f927cc7043264f5@haskell.org> #8955: Syscall intrinsic -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): As mentioned in the blog post (I'm the author), on x86-64 we can even use foreign primops to avoid the "call" indirection. https://github.com/hsyl20/ViperVM/blob/master/src/lib/ViperVM/Arch/X86_64/Linux/Syscall.hs#L27 https://github.com/hsyl20/ViperVM/blob/master/src/lib/ViperVM/Arch/X86_64/Linux/syscall.c#L95 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 11:06:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 11:06:43 -0000 Subject: [GHC] #8955: Syscall intrinsic In-Reply-To: <046.87831a2ab7ed854bc7dbc1d0bed32dbe@haskell.org> References: <046.87831a2ab7ed854bc7dbc1d0bed32dbe@haskell.org> Message-ID: <061.494ce5576b636894c94dd6a17e95355e@haskell.org> #8955: Syscall intrinsic -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * cc: hsyl20 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 12:09:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 12:09:16 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.4f4ac9f63777e8259807884f2c017caa@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I see no need for writing a body neither for `reify` nor `with` -- just make them GHC primitives. As to what to do when multiple constraints are in scope, I think that GHC should refuse to compile: {{{ with (10 :: Int) $ with (20 :: Int) $ -- When GHC looks for an `Int` to satisfy -- the `Int =>` constraint, it finds both -- 10 and 20, so it's a compile-time error. (reify :: Int) }}} Am I missing something important? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 12:38:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 12:38:43 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311632=3A_Data=2EChar_repeated_readL?= =?utf-8?q?itChar_barfs_on_output_from_show_=22=C3=B31=22?= In-Reply-To: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> References: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> Message-ID: <064.80ac3ad5e10f3cd500c3b05c0a3734d0@haskell.org> #11632: Data.Char repeated readLitChar barfs on output from show "ó1" -------------------------------------+------------------------------------- Reporter: inversemot | Owner: kgupta Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: readLitChar Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2391 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: 8.2.1 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 13:12:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 13:12:32 -0000 Subject: [GHC] #12493: Add gcoerceWith to Data.Type.Coercion In-Reply-To: <050.16d7bf39c4da65dfb0a405557bc95eac@haskell.org> References: <050.16d7bf39c4da65dfb0a405557bc95eac@haskell.org> Message-ID: <065.f33a245df2777fff84ea982026bb2d59@haskell.org> #12493: Add gcoerceWith to Data.Type.Coercion -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2456 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"113d50b791c469394d38fab6ce5b760e5e8c35e2/ghc" 113d50b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="113d50b791c469394d38fab6ce5b760e5e8c35e2" Add gcoerceWith to Data.Type.Coercion Summary: For symmetry with `gcastWith` in `Data.Type.Equality`. Fixes #12493. Test Plan: It compiles Reviewers: bgamari, goldfire, hvr, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2456 GHC Trac Issues: #12493 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 13:13:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 13:13:11 -0000 Subject: [GHC] #12493: Add gcoerceWith to Data.Type.Coercion In-Reply-To: <050.16d7bf39c4da65dfb0a405557bc95eac@haskell.org> References: <050.16d7bf39c4da65dfb0a405557bc95eac@haskell.org> Message-ID: <065.b9100f079d5b473bfa45a5dbb85ea651@haskell.org> #12493: Add gcoerceWith to Data.Type.Coercion -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2456 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 13:20:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 13:20:29 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.2de08d3da8c31a1e23d5723d29af22c8@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): {{{#!hs a `asTypeIn` f = a where _ = f a }}} Checking the type of fails due to ambiguous `Functor`, `Applicative` constraints {{{#!hs flip id `asTypeIn` \x -> x <$> undefined <*> undefined <*> undefined }}} The user must either possess some prior knowledge and rewrite the expression {{{#!hs -- fixity of <$>, <*> flip id `asTypeIn` \x -> (<$>) @[] x undefined <*> undefined <*> undefined :: a -> (a -> b -> c) -> b -> c -- liftA3 f a b c = f <$> a <*> b <*> c flip id `asTypeIn` \x -> liftA3 @[] x undefined undefined undefined :: a -> (a -> b -> c) -> b -> c -- the return type of `_ <$> _ <*> _ <*> _` is some Applicative `f _` flip id `asTypeIn` \x -> (x <$> undefined <*> undefined <*> undefined :: [_]) :: a -> (a -> b -> c) -> b -> c }}} With infix type application they can directly write {{{#!hs flip id `asTypeIn` \x -> x <$> @[] undefined <*> undefined <*> undefined flip id `asTypeIn` \x -> x <$> @[] undefined <*> @[] undefined <*> @[] undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 14:30:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 14:30:36 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.d7a37eab65b83cbbf2f4c09735a357ee@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 14:44:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 14:44:11 -0000 Subject: [GHC] #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes In-Reply-To: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> References: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> Message-ID: <064.327caa30f016003c5e04eb5ebad0a5d7@haskell.org> #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ak3n Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10569, #12156, | Differential Rev(s): Phab:D2458 #12406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by ertes): I'd be very grateful, if you could include the flag in 8.0.2, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 14:50:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 14:50:47 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi In-Reply-To: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> References: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> Message-ID: <059.8367bed62fef512c9ba9e14f488436c2@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2447 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Well in the current implementation all `Ghci#.foo` bindings would show up in `:show bindings`, although it has been argued that they should be removed from there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 17:38:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 17:38:10 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on all systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.fa89acd9d8d53424065e2b5bb8bf1357@haskell.org> #10352: Properly link Haskell shared libs on all systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5987 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Ok, have an approach that should work, just link normally and use SxS to select the proper RTS runtime through a manifest file and SxS activation contexts. Should require no modification to linking which is good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 19:00:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 19:00:46 -0000 Subject: [GHC] #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs In-Reply-To: <041.fe13b79f3753d34e58ed0cb274b335c2@haskell.org> References: <041.fe13b79f3753d34e58ed0cb274b335c2@haskell.org> Message-ID: <056.4283eefcd2ab5243a2ff6f3a46a8c268@haskell.org> #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs -------------------------------------+------------------------------------- Reporter: pl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: #11072 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate * related: => #11072 Comment: Hi Thanks for the report. This will be fixed by #11072, In the mean time there are several ways to work around this. including editing the cabal file for `Eigen` to include `stdc++-6` instead of `stdc++`. This will get it to work in GHCi but the executable will need `libstdc++-6.dll` to work. As a side note, even if you do this, Eigen needs to #ifdef some posix calls that are named differently on Windows. e.g. `strdup` on Windows is `_strdup`. The compiled version works because mingw-w64 has them still defined under their deprecated names. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 19:05:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 19:05:53 -0000 Subject: [GHC] #12497: Make runtime linker be able to find POSIX functions under their deprecated name. Message-ID: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> #12497: Make runtime linker be able to find POSIX functions under their deprecated name. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.2 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: newcomer | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With GHC 8.0.1 the new runtime linker stopped re-exporting posix symbols under their deprecated names and instead follows the names on MSDN. Unfortunately there seems to be far more libraries than expected using these deprecated names. (Rather, far more libraries using posix functions and it happening to work on Windows). These are all broken now, and while we're doing the right thing, for the sake of compatibility with mingw-w64's behavior and allowing all these packages to work then we should re-export these symbols. e.g. rexport `strdup` as a forward from `_strdup`. We don't have to actually re-export them. just forward them in `RtsSymbol.c`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 19:11:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 19:11:41 -0000 Subject: [GHC] #12498: Support unconventionally named import libraries Message-ID: <044.5e703c77c226248ade6b1c9ac24961ab@haskell.org> #12498: Support unconventionally named import libraries -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11072 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use. Instead we should look at the presence of certain patterns. e.g. .o files contain only `.idata` sections etc. This would allow us to be able to support import libraries such as `gcc_s` and no longer need to hardcode the GCC library full name in cabal file. This should add more compatibility with packages on hackage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 19:16:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 19:16:20 -0000 Subject: [GHC] #12499: Support multiple library import libs Message-ID: <044.f8a196b5cc44f6576f7ecd4b42c8187e@haskell.org> #12499: Support multiple library import libs -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Our implementation of import libraries only support single library import libs. These are by far the most common ones. However it is possible to make multi library import libraries. E.g. one import library pointing to multiple dlls. `binutils` correct supports these and with #5987 GHC will be relying on them to work. It makes sense that we are able to load them in GHCi as well. This will be required for a fully working dynamic GHC on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 19:17:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 19:17:55 -0000 Subject: [GHC] #5987: Too many symbols in ghc package DLL In-Reply-To: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> References: <044.2d87ca11391c23e0fa5f3c5418ae791f@haskell.org> Message-ID: <059.2b463f4db07430d575e81323bb8e4a93@haskell.org> #5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * milestone: => 8.2.1 Comment: This will be finished by `8.2.1` (probably earlier as well). Though it requires some thinking about how the bindist should go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 19:18:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 19:18:24 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on all systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.e80bcb9ffcd5d643dd5e9ba3a8a8ecf3@haskell.org> #10352: Properly link Haskell shared libs on all systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5987 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 19:31:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 19:31:45 -0000 Subject: [GHC] #12500: Open Type Family Kind Resolution Message-ID: <049.fdab04ca48c4a90d4881d6ee1742d08a@haskell.org> #12500: Open Type Family Kind Resolution -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following is a minimal example of this problem: {{{#!hs -- Section 1 data Animal = Dog | Cat | Mouse data Planet = Earth | Jupiter | Mars | Saturn type family ToRes (k :: Type) = (j :: Type) type instance ToRes Planet = Animal -- Section 2 type family Thing k (a :: k) = (b :: ToRes k) type instance Thing Planet 'Earth = 'Dog }}} The last line fails with: {{{ Expected kind 'ToRes Planet', but 'Dog has kind Animal }}} What's weird is that, if I take the part labeled Section 1 and move it into another module and then import that module into one that contains Section 2, it compiles fine. In this minimal case, that's not a huge problem, but for my real use case, splitting the type instances into two modules like this forces me to use an orphan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 19:31:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 19:31:51 -0000 Subject: [GHC] #12501: Windows builds segfault (as in doesn't work at all). Message-ID: <044.91fe5ae0a498fe0a90730091545b81ee@haskell.org> #12501: Windows builds segfault (as in doesn't work at all). -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC doesn't work Unknown/Multiple | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit a9bc54766ddd1bdb011f1656ad58fb409055d08f is the last known good commit for the Windows build of GHC. After this point multiple segfaults were introduced due to changes in the rts and GC. One was introduced by the compacts regions patch cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453 but fixed by f9a11a241b8056ac2b9c771172a48919fb3d0ed1 Unfortunately because many of the intermediate commits between cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453 also break the build I can't run a proper bisect. And because of some very large commits in between it makes it really hard to cherry-pick individual commits or rebase certain ones out manually to try. Effectively something was committed that makes GC go horribly wrong. {{{ Tamar at Kino MINGW64 ~/ghc2 $ inplace/bin/ghc-stage2.exe --version The Glorious Glasgow Haskell Compilation System, version 8.1.20160817 Segmentation fault }}} In GDB {{{ Program received signal SIGSEGV, Segmentation fault. 0x0000000002aa35d9 in LOOKS_LIKE_CLOSURE_PTR (p=0x2cd1dd000000000) at includes/rts/storage/ClosureMacros.h:275 275 (UNTAG_CONST_CLOSURE((const StgClosure *)(p)))->header.info); (gdb) bt #0 0x0000000002aa35d9 in LOOKS_LIKE_CLOSURE_PTR (p=0x2cd1dd000000000) at includes/rts/storage/ClosureMacros.h:275 #1 0x0000000002aa3e3e in evacuate1 (p=0x31c1a04 ) at rts\sm\Evac.c:416 #2 0x0000000002a7a183 in scavenge_srt (srt=0x31c1a04 , srt_bitmap=1) at rts\sm\Scav.c:351 #3 0x0000000002a7a253 in scavenge_fun_srt (info=0x278dfb0 ) at rts\sm\Scav.c:390 #4 0x0000000002a7c245 in scavenge_static () at rts\sm\Scav.c:1747 #5 0x0000000002a7c8f2 in scavenge_loop1 () at rts\sm\Scav.c:2081 #6 0x0000000002a722bb in scavenge_until_all_done () at rts\sm\GC.c:968 #7 0x0000000002a71008 in GarbageCollect (collect_gen=1, do_heap_census=rtsFalse, gc_type=2, cap=0x320f5c0 ) at rts\sm\GC.c:403 #8 0x0000000002a61856 in scheduleDoGC (pcap=0x3b4fbb8, task=0x6c6e0d0, force_major=rtsFalse) at rts\Schedule.c:1797 #9 0x0000000002a5fb68 in schedule (initialCapability=0x320f5c0 , task=0x6c6e0d0) at rts\Schedule.c:552 #10 0x0000000002a62355 in scheduleWaitThread (tso=0x7205b98, ret=0x0, pcap=0x3b4fd40) at rts\Schedule.c:2494 #11 0x0000000002a4e24a in rts_evalLazyIO (cap=0x3b4fd40, p=0x2aabad0 , ret=0x0) at rts\RtsAPI.c:500 #12 0x0000000002a4d350 in hs_main (argc=1, argv=0x6c640b0, main_closure=0x2aabad0 , rts_config=...) at rts\RtsMain.c:64 #13 0x00000000004b4c75 in main () }}} It seems that all `info` tables are messed up. In `frame #4` the table contains very suspicious values: {{{ (gdb) frame 4 #4 0x0000000002a7c245 in scavenge_static () at rts\sm\Scav.c:1747 1747 scavenge_fun_srt(info); (gdb) p info $3 = (const StgInfoTable *) 0x278dfb0 (gdb) pinfo info $4 = {layout = {payload = {ptrs = 10697284, nptrs = 0}, bitmap = 10697284, large_bitmap_offset = 10697284, __pad_large_bitmap_offset = 10697284, selector_offset = 10697284}, type = 3, srt_bitmap = 1, code = 0x278dfb0 ""} }}} Unfortunately my knowledge of GHC's `GC` is severely lacking at this moment so I have no idea how to debug this effectively and without knowing the commit that introduced it's rather slow going. Any help or hints appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 19:36:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 19:36:33 -0000 Subject: [GHC] #12502: Reject wrong find utility Message-ID: <044.bf466ae198a25fe9a5df2ca0f70bd734@haskell.org> #12502: Reject wrong find utility -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: newcomer | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently our configure scripts try to find the correct find tool on the `PATH`. However because Windows also has a utility named `find`, depending on the user's configuration the Windows one may be on the path first. The Configure script currently rejects the tool and continues trying to find the correct `find` utility from `msys2`. However the binary distribution script doesn't get to know which find utility to use. So if the wrong `find` is on the path then the windows binary downloads will fail with a weird error. The find utility to use should probably be passed to the tarballs download script. We could just stuff it in an `Env variable` and use it in the script if available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 19:49:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 19:49:15 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.0afa9576637660237a3b6ef28aafb3ef@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Use case from [http://ozark.hendrix.edu/~yorgey/pub/twisted.pdf How to Twist Pointers without Breaking Them]: > {{{#!hs > class Monoid m => Action m a where > act :: m -> a -> a > }}} > ''[...]'' > > We first formalise the action of monoids on functors. Intuitively, for a monoid `m` to act on the functor `f`, it should act in a uniform way on all the types `f a`. Therefore, we would like to assert a constraint something like `forall a. Action m (f a)`. Unfortunately, Haskell does not allow the use of universally quantified constraints and hence we need a new type class. > > {{{#!hs > class (Monoid m, Functor f) => ActionF m f where > act' :: m -> f a -> f a > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 19:57:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 19:57:06 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.00a9ed343b845ff098ef0e4151264920@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 21:33:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 21:33:20 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large In-Reply-To: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> References: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> Message-ID: <059.c3a2eefa564bec9145c1b652b1b0f2e0@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): The `ghc-datasize` package I'm using depends on `ghc-heap-view` and @nomeata suggests that its a little brittle and possibly the problem here: https://github.com/nomeata/ghc-heap-view/issues/10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 21:34:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 21:34:43 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.401d2fb43cc83a8e6d734afda4ea12f5@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): What about this: {{{ type family F a where F Int = Int F a = Char foo :: F a -> a -> (a => r) -> r foo x y k = with x $ with y $ k }}} When `a` is specialized to `Int`, the body of `foo` is ambiguous, even though it isn't under other conditions. How do we resolve this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 18 21:56:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Aug 2016 21:56:50 -0000 Subject: [GHC] #12500: Open Type Family Kind Resolution In-Reply-To: <049.fdab04ca48c4a90d4881d6ee1742d08a@haskell.org> References: <049.fdab04ca48c4a90d4881d6ee1742d08a@haskell.org> Message-ID: <064.e67925ebb5fcc6d1ac96710b0af273ce@haskell.org> #12500: Open Type Family Kind Resolution -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #11348. Fixed in HEAD. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 00:19:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 00:19:48 -0000 Subject: [GHC] #12500: Open Type Family Kind Resolution In-Reply-To: <049.fdab04ca48c4a90d4881d6ee1742d08a@haskell.org> References: <049.fdab04ca48c4a90d4881d6ee1742d08a@haskell.org> Message-ID: <064.2ba5c1f47be8f9517e7f55cbbc61a033@haskell.org> #12500: Open Type Family Kind Resolution -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Glad to know that it's already been addressed. Thanks for letting me know! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 03:53:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 03:53:35 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.481cde5d63e6966e9324e00017e44005@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Just passing by ---- A [http://sf.snu.ac.kr/jeehoon.kang/assets/bs_math.pdf definition] of composition of an opposite category. The different instantiations of composition are made explicit but the arrows are cast implicitly: {{{ f ∘_C^op g = g ∘_C f }}} Awodey uses the notation `f* : B* -> A*` in `ℂ^op` for `f : A -> B` in `ℂ` making conversions between categories explicit. The category of the identity arrow is named but not of composition: {{{ 1_ℂ* = (1_ℂ)* f* ∘ g* = (g ∘ f)* }}} Haskell makes switching between categories explicit, using `Op f :: (Op ℂ) B A` for `f :: ℂ A B` {{{#!hs type Cat k = k -> k -> Type newtype Op :: Cat i -> Cat i where Op :: cat b a -> (Op cat) a b instance Category cat => Category (Op cat) where id :: (Op cat) a a id = Op id (.) :: (Op cat) b c -> (Op cat) a b -> (Op cat) a c Op f . Op g = Op (g . f) }}} can be made more explicit by {{{#!hs id :: (Op cat) a a id = Op (id @cat) (.) :: (Op cat) b c -> (Op cat) a b -> (Op cat) a c Op f . Op g = Op (g . @cat f) }}} ---- A separate proposal is visible type applications on methods, corresponding to their instance type arguments (`Op cat` in this case) which gives us an (overly?) explicit definition {{{#!hs id @(Op cat) = Op (id @cat) Op f . @(Op cat) Op g = Op (g . @cat f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 07:21:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 07:21:42 -0000 Subject: [GHC] #12502: Reject wrong find utility In-Reply-To: <044.bf466ae198a25fe9a5df2ca0f70bd734@haskell.org> References: <044.bf466ae198a25fe9a5df2ca0f70bd734@haskell.org> Message-ID: <059.fd0d492ea3535645633da47517d108a5@haskell.org> #12502: Reject wrong find utility -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have been personally bitten by this. The error message is obscure, and it was extremely painful to unravel. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 08:10:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 08:10:57 -0000 Subject: [GHC] #11758: Drop x86_64 binutils <2.17 hack In-Reply-To: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> References: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> Message-ID: <061.e5c49bd25d48958083cc9abbcd25ef90@haskell.org> #11758: Drop x86_64 binutils <2.17 hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: avd Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 8.0.1-rc2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12433 | Differential Rev(s): Phab:D2426 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This patch made the ghc-stage2 compiler seg-fault, on 64-bit Windos. It seg-faults when doing anything -- compiling `HelloWorld.hs` or even `ghc --version`. It took me a full day of bisection to find this. Very painful. It would be so great if we had continuous-integration on Windows going. I hate playing the role of Windows test engine. Anyway, here's the revert patch. Would someone like to work out what is going on, and re-apply when fixed? {{{ commit b2c5e4ce5c44a7be7c2b81c2600cae40c5b225ad Author: Simon Peyton Jones Date: Thu Aug 18 18:16:01 2016 +0100 Revert "codeGen: Remove binutils<2.17 hack, fixes T11758" This reverts commit e3e2e49a8f6952e1c8a19321c729c17b294d8c92. I'm reverting because it makes ghc-stage2 seg-fault on 64-bit Windows machines. Even ghc-stage2 --version seg-faults. compiler/nativeGen/X86/CodeGen.hs | 15 ++++++++++++++- compiler/nativeGen/X86/Ppr.hs | 23 +++++++++++++++++++++-- includes/rts/storage/InfoTables.h | 11 +++++++++++ 3 files changed, 46 insertions(+), 3 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 08:11:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 08:11:22 -0000 Subject: [GHC] #11758: Drop x86_64 binutils <2.17 hack In-Reply-To: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> References: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> Message-ID: <061.662f20f55ed48770acdd88619c5138a9@haskell.org> #11758: Drop x86_64 binutils <2.17 hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: avd Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 8.0.1-rc2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12433 | Differential Rev(s): Phab:D2426 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could perhaps be the cause of #12501? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 08:15:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 08:15:20 -0000 Subject: [GHC] #12501: Windows builds segfault (as in doesn't work at all). In-Reply-To: <044.91fe5ae0a498fe0a90730091545b81ee@haskell.org> References: <044.91fe5ae0a498fe0a90730091545b81ee@haskell.org> Message-ID: <059.426f9545cc976dc0c14c9e31fc4b6738@haskell.org> #12501: Windows builds segfault (as in doesn't work at all). -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (added) Comment: Adding Simon Marlow since he committed the compact-region patch. Add in cc anyone else who committed a patch you are suspicious about. See my reversion of #11758. Might that help? Oddly, I ''could'' bisect, and found #11758. After that HEAD works on my 64-bit Windows. We must fix this, and soon. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 08:29:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 08:29:28 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.1b073414bc301cf4e28f17886e62e467@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): At definition site `F a` cannot satisfy the `a =>` constraint unless `F a ~ a` is also in scope (it's not), so there's no ambiguity here. The way I see it, when you instantiate `a` with `Int`, instance resolution is already done. Is this not the case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 08:48:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 08:48:22 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.73e4ed3e1ad2d811ba53940bbdbb6e9e@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): I have no answers here, just more questions. I ran into this problem again with a large project that uses conduit. My program suffered from a large memory leak, and in the `-hy` profile the types were reported as `->Pipe` and `Sink`; moreover, the `-hc` profile told me memory was being retained by a CAF. All of this pointed to the exact problem discussed in this ticket, and indeed adding {{{#!hs {-# OPTIONS_GHC -fno-full-laziness #-} }}} to the top of my module got rid of the problem. However, I can't say I fully understand what is going on. Experimenting with @snoyberg 's examples, above, I noticed that the memory behaviour of these modules interacts in odd ways with profiling options, which doesn't make this any easier! For @snoyberg's first example (https://ghc.haskell.org/trac/ghc/ticket/9520#comment:4): {{{ | No profiling | -prof | -prof -fprof-auto ----+--------------+---------+------------------ -O0 | OK | OK | OK -O1 | OK | OK | LEAK(1) -O2 | OK | OK | LEAK(1) }}} where OK means "runs in constant space" and LEAK(1) indicates a memory leak consisting of `Int`, `->Sink` and `Sink`, according to `+RTS -hy`. In other words, this has a memory leak ''only'' when ''both'' optimization ''and'' `-fprof-auto` are specified (`-fprof` by itself is not enough). Bizarrely, for the second example the behaviour is reversed (perhaps this is why Michael concluded that this example "however, does '''not''' demonstrate the problem"?): {{{ | No profiling | -prof | -prof -fprof-auto ----+--------------+---------+------------------ -O0 | OK | OK | OK -O1 | LEAK | LEAK(1) | OK -O2 | LEAK | LEAK(1) | OK }}} Unlike for the first example, here we also get a LEAK without any profiling enabled (as indicated by a very high maximum residency reported by `+RTS -s`). I added a third example: {{{#!hs foreign import ccall "doNothing" doNothing :: IO () data Sink i r = Sink (i -> Sink i r) r sinkCount :: Sink i Int sinkCount = loop 0 where loop cnt = Sink (\_ -> loop $! cnt + 1) cnt feed :: Sink Char r -> IO r feed = loop 10000000 where loop 0 (Sink _ g) = return g loop i (Sink f _) = doNothing >> loop (i - 1) (f 'A') action :: IO () action = do feed sinkCount return () main :: IO () main = do action action }}} This differs from @snoyberg 's second example only in the additional call to `doNothing` in `feed.loop`; `doNothing` is defined in an external `.c` file: {{{#!c void doNothing() {} }}} (I used an externally defined C function because I wanted something that the optimizer couldn't get rid of but without getting all kinds of crud about `Handle`s etc in the core/STG output, which is what would happen with a print statement, say.) I have no idea why, but this program's memory behaviour is quite different from version 2: {{{ | No profiling | -prof | -prof -fprof-auto ----+--------------+---------+------------------ -O0 | LEAK | LEAK(2) | LEAK(2) -O1 | LEAK | LEAK(1) | LEAK(1) -O2 | LEAK | LEAK(1) | LEAK(1) }}} Now this program leaks no matter what we do; although LEAK(2) reported here, according to `RTS -hy`, consists of different type (a single type, in fact: `PAP`). Getting to the bottom of this would require more time than I currently have; I guess for me the take-away currently is: full laziness is dangerous when using free monads such as conduit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 08:51:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 08:51:51 -0000 Subject: [GHC] #12501: Windows builds segfault (as in doesn't work at all). In-Reply-To: <044.91fe5ae0a498fe0a90730091545b81ee@haskell.org> References: <044.91fe5ae0a498fe0a90730091545b81ee@haskell.org> Message-ID: <059.75ff9b0aa9890c4f363ec49aebd456b4@haskell.org> #12501: Windows builds segfault (as in doesn't work at all). -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hi Simon, Thanks!, I was trying to find it by looking at commits that touched the `rts`, which that commit hadn't so I never considered it (and the codegen!). I think the mileage with bisect would depend on where you start, since cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453 , d068220f4249cce66ed5b6cc5504f79e7c8c0184 and cac3fb06f4b282eee21159c364c4d08e8fdedce9 all broke the build at one point and were fixed at different points. I didn't try it for this reason, but maybe I should have. I'll try building head again once I get home. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 09:23:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 09:23:00 -0000 Subject: [GHC] #11758: Drop x86_64 binutils <2.17 hack In-Reply-To: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> References: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> Message-ID: <061.e654c5a058430ed59dc55c4d4b1b2faf@haskell.org> #11758: Drop x86_64 binutils <2.17 hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: avd Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 8.0.1-rc2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12433 | Differential Rev(s): Phab:D2426 Wiki Page: | -------------------------------------+------------------------------------- Comment (by avd): I would like to work on this, but I will need some time to setup Windows build (mingw and stuff). I guess, while the patch is reverted, I can work on this without rush - is that right? Also, should this be tested on other 64 bit systems like Solaris and *BSD? Are there any resources/workflow? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 11:58:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 11:58:03 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.6beaff5c5495aba302f24c489d108bc5@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, that's true, but this is just the situation with `IncoherentInstances`, where specializing a type changes the meaning of an expression. Normally, we can assign an expression a more specific type at will. In this case, if we try to assign `foo` the more specific type `Int -> Int -> (Int => r) -> r`, we will get a duplicate-`with` error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 12:50:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 12:50:02 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.d7915fe01be452ea11fd34f8254cc25d@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Yes, a `with` error is not a viable solution. Since we'd like to treat anything to the LHS of `=>` the same way, issuing an error would break this example: {{{ data SomeOrd a where SomeOrd :: Ord a => a -> SomeOrd a cmp :: SomeOrd a -> SomeOrd a -> Ordering cmp (SomeOrd a) (SomeOrd b) = -- Do we use an 'Ord a' dictionary from the first argument -- or the second argument? We know it's the same dictionary -- because class instances are coherent, but this might be -- not the case for values provided by `with`. compare a b }}} By the way, how does GHC currently decide which dictionary to use in the example above? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 12:57:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 12:57:49 -0000 Subject: [GHC] #9520: Running an action twice uses much more memory than running it once In-Reply-To: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> References: <047.6b6fd7e4449a99480495bce3d0c7323b@haskell.org> Message-ID: <062.2bc2e5fc00c04cacba472ed76fc1e645@haskell.org> #9520: Running an action twice uses much more memory than running it once -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): As Andres points out, my version 3 is not particularly enlightening; without any optimization, the loop in `feed` is not tail recursive (this relies on unfolding of `>>`); with optimization, we are bitten by the full laziness problem again. Bit of a red herring. (I had been trying to simulate the `hIsEOF` in the original example.) So I guess the only take away from my experimentation is: CAFs/full laziness and profiling modes interact in ways that make memory behaviour very unpredictable. Proceed with caution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 15:27:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 15:27:23 -0000 Subject: [GHC] #12501: Windows builds segfault (as in doesn't work at all). In-Reply-To: <044.91fe5ae0a498fe0a90730091545b81ee@haskell.org> References: <044.91fe5ae0a498fe0a90730091545b81ee@haskell.org> Message-ID: <059.79c8d3248543e37528e65244d3633102@haskell.org> #12501: Windows builds segfault (as in doesn't work at all). -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed Comment: Yup, HEAD works again now here too. So it was the codegen changes. Thanks again! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 16:01:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 16:01:37 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.85fe8c2fa0b7c79fdf476007fc17b6b3@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Here's a GHCi session you might find interesting. GHC just picks the first instance. {{{ GHCi, version 8.1.20160813: http://www.haskell.org/ghc/ :? for help Prelude> :set -XGADTs Prelude> :set -XFlexibleContexts Prelude> data X where X :: Given Int => X Prelude> import Data.Reflection Prelude Data.Reflection> data X where X :: Given Int => X Prelude Data.Reflection> f X X = given :: Int Prelude Data.Reflection> a = give (10 :: Int) X Prelude Data.Reflection> b = give (20 :: Int) X Prelude Data.Reflection> f a b 10 Prelude Data.Reflection> f b a 20 }}} And here's the behavior of the type family example (when rewritten using reflection): {{{ {-# LANGUAGE TypeFamilies, RankNTypes #-} import Data.Reflection type family F a where F Int = Int F a = Char foo :: F a -> a -> (Given a => r) -> r foo x y k = give x $ give y $ k }}} {{{ GHCi, version 8.1.20160813: http://www.haskell.org/ghc/ :? for help Prelude> :l With.hs [1 of 1] Compiling Main ( With.hs, interpreted ) Ok, modules loaded: Main. *Main> foo (10 :: Int) (20 :: Int) (given :: Int) 20 }}} If you specialize `foo` by adding `a ~ Int` to its type signature, you get a different result! {{{ foo :: (a ~ Int) => F a -> a -> (Given a => r) -> r foo x y k = give x $ give y $ k }}} {{{ *Main> foo (10 :: Int) (20 :: Int) (given :: Int) 10 }}} So, I say that the safe bet would be to *preserve* the current behavior, just get rid of `Given`. When multiple `with` are used, it is implementation defined which instance will get picked. Adding an equality constraint can indeed change the meaning of your code. But this is already the case, so at least we're not making things worse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 17:12:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 17:12:28 -0000 Subject: [GHC] #3314: Add compilation date to +RTS --info In-Reply-To: <044.ba2b5095895a2d1777a79a9b191f08e5@haskell.org> References: <044.ba2b5095895a2d1777a79a9b191f08e5@haskell.org> Message-ID: <059.c19e7255735f9c0124f81aea6a0cf21e@haskell.org> #3314: Add compilation date to +RTS --info -------------------------------------+------------------------------------- Reporter: Orphi | Owner: ak3n Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2460 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: => ak3n * failure: => None/Unknown * differential: => Phab:D2460 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 18:17:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 18:17:10 -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.4b8afbb34d61394e5c513d9a72f2edcf@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): I've experimented a bit more with trying to pin down where slowdown comes from. Some observations: Observation 1. -j not only allows modules to be compiled at the same time, but also enables: - Capabilities - and garbage collection threads I've locally removed Capability adjustment from -j handling and used -j +RTS -N. That does not make performance as bad with increasing K. That makes sense GC OS threads don't fight over the same cache. It would be nice if '''+RTS -N''' would have a precedence over -j option Observation 2. [Warning: I have no idea how parallel GC works]. The more GC threads we have - the more chances are that one of GC threads will finish scanning it's part oh heap and will sit in sched_yield() loop on a free core while main GC thread waits for completion of other threads doing useful work. I've found it out by changing yieldThread() to print it's caller. Vast majority of calls comes from any_work(): {{{ static rtsBool any_work (void) { int g; gen_workspace *ws; gct->any_work++; write_barrier(); // scavenge objects in compacted generation if (mark_stack_bd != NULL && !mark_stack_empty()) { return rtsTrue; } // Check for global work in any gen. We don't need to check for // local work, because we have already exited scavenge_loop(), // which means there is no local work for this thread. for (g = 0; g < (int)RtsFlags.GcFlags.generations; g++) { ws = &gct->gens[g]; if (ws->todo_large_objects) return rtsTrue; if (!looksEmptyWSDeque(ws->todo_q)) return rtsTrue; if (ws->todo_overflow) return rtsTrue; } #if defined(THREADED_RTS) if (work_stealing) { uint32_t n; // look for work to steal for (n = 0; n < n_gc_threads; n++) { if (n == gct->thread_index) continue; for (g = RtsFlags.GcFlags.generations-1; g >= 0; g--) { ws = &gc_threads[n]->gens[g]; if (!looksEmptyWSDeque(ws->todo_q)) return rtsTrue; } } } #endif gct->no_work++; #if defined(THREADED_RTS) yieldThread("any_work"); #endif return rtsFalse; } }}} I need to dig more into how parallel GC traverses heap to understand how much of a problem it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 19 20:05:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Aug 2016 20:05:47 -0000 Subject: [GHC] #12239: Dependent type family does not reduce In-Reply-To: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> References: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> Message-ID: <063.a2e7d5d3ec4d8b781229197379783701@haskell.org> #12239: Dependent type family does not reduce -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * priority: normal => high * milestone: => 8.2.1 Comment: I'm raising the priority and setting the milestone to 8.2 since 8.2 is a consolidation release and I would love to see the bug fixed. Tried to fix it myself but after a few hours of reading GHC source I realized that I lack the necessary expertise (although I could try again if someone was to mentor me). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 01:41:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 01:41:12 -0000 Subject: [GHC] #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind Message-ID: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program compiles without issue on GHC 7.6.3 through GHC 7.10.3, but fails to compile on GHC 8.0.1 and GHC HEAD. (I added a CPP guard simply because the `DataD` constructor changed between 7.10 and 8.0.) {{{#!hs {-# LANGUAGE CPP #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Regression where import Language.Haskell.TH data T k class C a $(do TyConI (DataD [] tName [ KindedTV kName kKind] #if __GLASGOW_HASKELL__ >= 800 _ #endif _ _) <- reify ''T d <- instanceD (cxt []) (conT ''C `appT` (conT tName `appT` sigT (varT kName) kKind)) [] return [d]) }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Regression.hs [1 of 1] Compiling Regression ( Regression.hs, Regression.o ) Regression.hs:(13,3)-(19,15): Splicing declarations do { TyConI (DataD [] tName_a2RT [KindedTV kName_a2RU kKind_a2RV] _ _ _) <- reify ''T; d_a31Y <- instanceD (cxt []) (conT ''C `appT` (conT tName_a2RT `appT` sigT (varT kName_a2RU) kKind_a2RV)) []; return [d_a31Y] } ======> instance C (T (k_avB :: k_avC)) Regression.hs:13:3: error: Variable ‘k_avB’ used as both a kind and a type Did you intend to use TypeInType? }}} Somewhat confusingly, you can use `instance C (T (k_avB :: k_avC))` on its own, and it will compile without issue. Also, quoting it doesn't seem to trip up this bug, as this also compiles without issue: {{{#!hs {-# LANGUAGE CPP #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module WorksSomehow where import Language.Haskell.TH data T k class C a $([d| instance C (T k) |]) }}} The original program has several workarounds: 1. Turn off `PolyKinds` (OK, this isn't a very good workaround...) 2. Add an explicit kind signature to `T`, e.g., `data T (k :: k1)` 3. Change the type variable of `T` to some other letter, e.g., `data T p` or `data T k1` Given that (3) is a successful workaround, I strongly suspect that GHC is confusing the type variable `k` (which gets `ddump-splice`d as `k_avB`) with the kind variable `k` (which gets `ddump-splice`d as `k_avC`) due to their common prefix `k`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 03:00:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 03:00:40 -0000 Subject: [GHC] #12239: Dependent type family does not reduce In-Reply-To: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> References: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> Message-ID: <063.88961fda148e98145d4785c6f74982ac@haskell.org> #12239: Dependent type family does not reduce -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is annoying to fix but I don't think will require any great engineering feats. The be clear, the problem is to convert a type `forall (a :: F x). blah` to `forall (b :: s). blah[a |-> b |> co]`, where `s` is the flattened form of `F x` (either an fuv or some other type) and `co :: s ~ F x`. Here's the approach I have in mind: include a `TCvSubst` in `FlattenEnv`. Whenever the kind of a bound type variable is flattened, extend the substitution to map the original variable (that is, `a`) to a new one `b` (with a fresh unique -- use `uniqAway`) that has the flattened kind (and is casted, as above). This substitution must be applied over the entire scope of the bound variable (the `blah` in our example). But it would be inefficient just to apply the substitution, so we consult this substitution in `flattenTyVar` as appropriate. Specifically, I think we would need to update the first case in `flatten_tyvar1`, which deals with non-`TcTyVar`s -- that is, locally bound variables. Does this sound like something you might tackle? I'm sure bumps will come up along the road, but if you're feeling like getting your hands dirty here, I can continue to advise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 03:03:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 03:03:59 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.0ec99de2d6f87a5f87b469d481ef6f8b@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): These examples are very helpful. Now that you have collected them, I think a good next step is soliciting feedback from the community so that we can see if others agree with you. I'll admit to becoming more convinced by your examples, but I'm still leaning against. Other voices in agreement with yours would make a big difference here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 04:31:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 04:31:27 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths Message-ID: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths ----------------------------------------+---------------------------- Reporter: rcook | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- Repro steps: * Install Stack on a ''Windows'' development machine. * Create new simple project with `stack new inlinecbug simple`. * Rename `src/Main.hs` to `src/Main.hsc` in the `inlinecbug` project directory. * Build project with `stack build` and run with `stack exec inlinecbug` to verify that hsc2hs works correctly. * Replace content of `src/Main.hsc` with following: {{{#!hs {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE TemplateHaskell #-} import qualified Language.C.Inline as C C.include "" main :: IO () main = do x <- [C.exp| double{ cos(1) } |] print x }}} * In `inlinecbug.cabal` add `inline-c` to the `build-depends` section of `executable inlinecbug`. * Add the line `c-source-files: src/Main.c` to the `executable inlinecbug` section. * Rebuild with `stack build`. Build will fail with a linker error referring to a undefined reference to an `inline_c_main...` function. List the files in the root directory of the project and you'll see that inline-c has generated a file with the name `srcMain.c`: i.e. the backslashes in the Windows path have been removed. Building under Linux generates the C output file with the correct, expected path of `src/Main.c` and the program will compile, link and run as expected. See also: https://github.com/fpco/inline-c/issues/50 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 07:15:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 07:15:52 -0000 Subject: [GHC] #12239: Dependent type family does not reduce In-Reply-To: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> References: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> Message-ID: <063.e99f2947cc53d1c50ec21f0df14c97a3@haskell.org> #12239: Dependent type family does not reduce -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): > Does this sound like something you might tackle? Yes. Your explanation is very helpful. > I'm sure bumps will come up along the road, but if you're feeling like getting your hands dirty here, I can continue to advise. Thank you. So, my understanding is that during type checking `ForAllTy`s arise, but the `Kind`s in `TyVarBinder`s don't get flattened, hence the error. However, once I added a `traceFlat` to the beginning of `flatten_one` clause for `ForAllTy` it didn't show up in the compilation logs (adding it in other clauses worked, so I assume that I added it correctly). Therefore I conclude that control flow doesn't reach this part of the code and no changes will affect the result of compilation. (1) What other parts of code should be changed and how, before I can start fixing `flatten_one` for `ForAllTy`? (2) Where exactly those `ForAllTy` get inserted in the example code (in the ticket description)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 09:22:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 09:22:04 -0000 Subject: [GHC] #11758: Drop x86_64 binutils <2.17 hack In-Reply-To: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> References: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> Message-ID: <061.e74874286b98b6c6693d50db8f09608d@haskell.org> #11758: Drop x86_64 binutils <2.17 hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 8.0.1-rc2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12433 | Differential Rev(s): Phab:D2426 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) * status: closed => new * resolution: fixed => * owner: avd => Comment: Yes while it's reverted there's no rush. Usually if you don't have a distribution set up you can just ask someone to test it for you. If there's no issues then you save the time having to set up those distros. Let me know if you need any help setting up a Windows build. I also have a powershell script that would automate the entire thing if you want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 09:22:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 09:22:31 -0000 Subject: [GHC] #11758: Drop x86_64 binutils <2.17 hack In-Reply-To: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> References: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> Message-ID: <061.a2bcaafd0026d3c924d555e77177580f@haskell.org> #11758: Drop x86_64 binutils <2.17 hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: avd Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 8.0.1-rc2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12433 | Differential Rev(s): Phab:D2426 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => avd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 14:16:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 14:16:17 -0000 Subject: [GHC] #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind In-Reply-To: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> References: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> Message-ID: <065.b0fec9ff54dab66cda31159c82e80c0e@haskell.org> #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The above program might seem somewhat contrived, but I actually ran into this problem in real code. The `generic-deriving` library does something very similar to derive `Generic1` instances using Template Haskell (that is, it re-uses the kind information it gets from `reify`). Here's some code that triggers the same error: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PackageImports #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices #-} module Regression where -- Using generic-deriving-1.11 import "generic-deriving" Generics.Deriving.TH data T k a $(deriveAll1 ''T) }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Regression.hs [1 of 1] Compiling Regression ( Regression.hs, Regression.o ) Regression.hs:13:3-16: Splicing declarations deriveAll1 ''T ======> instance GHC.Generics.Generic1 (T (k_avv :: k_avx) :: GHC.Types.Type -> GHC.Types.Type) where type GHC.Generics.Rep1 (T (k_avv :: k_avx) :: GHC.Types.Type -> GHC.Types.Type) = GHC.Generics.D1 (GHC.Generics.MetaData "T" "Regression" "main" False) GHC.Generics.V1 GHC.Generics.from1 = \ val_a3ph -> case val_a3ph of { y_a3pi -> GHC.Generics.M1 (case y_a3pi of { _ -> error "No generic representation for empty datatype T" }) } GHC.Generics.to1 = \ val_a3pj -> case val_a3pj of { GHC.Generics.M1 y_a3pk -> case y_a3pk of { _ -> error "No values for empty datatype T" } } Regression.hs:13:3: error: Variable ‘k_avv’ used as both a kind and a type Did you intend to use TypeInType? Regression.hs:13:3: error: Variable ‘k_avv’ used as both a kind and a type Did you intend to use TypeInType? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 15:04:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 15:04:31 -0000 Subject: [GHC] #12505: Add foldl1' to Data.Foldable Message-ID: <047.4f75a32ad3d2176237f216dd9785b96d@haskell.org> #12505: Add foldl1' to Data.Foldable -------------------------------------+------------------------------------- Reporter: tserduke | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With the change strict `Foldable` instances could be written in a simple and performant manner: {{{#!hs maximum = foldl1' max minimum = foldl1' min sum = foldl1' (+) product = foldl1' (*) }}} Also `foldl1'` from `Data.List` gets generalized. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 16:35:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 16:35:34 -0000 Subject: [GHC] #12239: Dependent type family does not reduce In-Reply-To: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> References: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> Message-ID: <063.d1892dd39bcb37a633f4ad42b8a2ede7@haskell.org> #12239: Dependent type family does not reduce -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: => #11348 Comment: Int-index and I have been working through this together this afternoon and it is nothing to do with what Richard initially expected. Instead, the problem is that whilst checking the kind of the argument to `FieldType`, we need knowledge of the instances of `FieldCount` which only get added to the environment *after* all the type family instances have been type checked. So instead this ticket is related to #11348. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 17:11:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 17:11:29 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.127604f759f7b8f953cc542b83c2209c@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:8 goldfire]: > These examples are very helpful. Now that you have collected them, I think a good next step is soliciting feedback from the community so that we can see if others agree with you. I'll admit to becoming more convinced by your examples, but I'm still leaning against. Other voices in agreement with yours would make a big difference here. I agree that this needs input from the community. The notation often feels clunky and asymmetric, mathematicians would use subscript instead. Visual type application (+ partial type signatures) have been very useful * '''Interactive use''' Toying around, getting ''ghci'' to resolve instances for me {{{#!hs mappend @(_ -> _) :: Monoid b => (a -> b) -> (a -> b) -> (a -> b) quickCheck @(_ -> _) :: (Arbitrary a, Show a, Testable b) => (a -> b) -> IO () quickCheck @(Int -> _) :: Testable b => (Int -> b) -> IO () }}} * '''Teaching''' Using valid Haskell syntax to simplify complex signatures that users can verify on their own {{{#!hs length @[] :: [a] -> Int sequence @[] @IO :: [IO a] -> IO [a] }}} Less so in actual code. The same seems true for this so I am not overly concerned with the syntax. Indeed most of the benefits of the examples don't have to do with actual code, rather presenting concepts with explicit/valid syntax or interactive use: allowing users to quickly specify a type without rearranging/rewriting syntax and adding parentheses (`(.) @A (id @A) f`). No need to muck about with expressions which reduces mental load: if you want `<$>` for lists, write `<$> @[]`. If it's all the same I will post examples until told to stop ;) (for operators, `_` with no spaces looks nicer (`1 +_Int 10`) but I won't seriously suggest it) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 17:12:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 17:12:11 -0000 Subject: [GHC] #12239: Dependent type family does not reduce In-Reply-To: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> References: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> Message-ID: <063.026657ae28d82f2ca6d578d1cda2507c@haskell.org> #12239: Dependent type family does not reduce -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: #11348 => #11348, #12088 Comment: In fact, also intimately related to #12088 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 17:27:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 17:27:55 -0000 Subject: [GHC] #12239: Dependent type family does not reduce In-Reply-To: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> References: <048.080c799bf1728edbd965cda3e26adbaf@haskell.org> Message-ID: <063.194ecf627d57cf46405f18e8c6274c4c@haskell.org> #12239: Dependent type family does not reduce -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: duplicate | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 17:34:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 17:34:51 -0000 Subject: [GHC] #12088: Promote type/data family instance constructors (was: Promote data family instance constructors) In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.99d6dfe0151df8a09a70233543667a46@haskell.org> #12088: Promote type/data family instance constructors -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * priority: normal => high * type: feature request => bug * milestone: => 8.2.1 Comment: So it turns out that https://ghc.haskell.org/trac/ghc/ticket/12239 is a manifestation of the same issue. Copying the example from it for completeness: {{{ {-# LANGUAGE TypeInType, GADTs, TypeFamilies #-} import Data.Kind (Type) data N = Z | S N data Fin :: N -> Type where FZ :: Fin (S n) FS :: Fin n -> Fin (S n) type family FieldCount (t :: Type) :: N type family FieldType (t :: Type) (i :: Fin (FieldCount t)) :: Type data T type instance FieldCount T = S (S (S Z)) type instance FieldType T FZ = Int type instance FieldType T (FS FZ) = Bool type instance FieldType T (FS (FS FZ)) = String }}} Reordering the declarations slightly makes it compile: {{{ {-# LANGUAGE TypeInType, GADTs, TypeFamilies #-} import Data.Kind (Type) data N = Z | S N data Fin :: N -> Type where FZ :: Fin (S n) FS :: Fin n -> Fin (S n) type family FieldType (t :: Type) (i :: Fin (FieldCount t)) :: Type data T -- Note that 'FieldCount' is now declared after 'FieldType' and 'T'. type family FieldCount (t :: Type) :: N type instance FieldCount T = S (S (S Z)) type instance FieldType T FZ = Int type instance FieldType T (FS FZ) = Bool type instance FieldType T (FS (FS FZ)) = String }}} Hope it helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 17:47:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 17:47:14 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.82fa9912076e151a0e47c129d8defa3e@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths ----------------------------+---------------------------------------- Reporter: rcook | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------+---------------------------------------- Comment (by rcook): See comment from "awson" at: https://github.com/fpco/inline-c/issues/50#issuecomment-241212544: The culprit is `{-# LINE ... #-}` pragmas in the files generated by hsc2hs. hsc2hs on Windows emits paths with non-escaped backslashes in it: {{{#!hs {-# LINE 1 "src\Language\C\Clang\Internal\FFI.hsc" #-} }}} I don't know how GHC's `LINE` pragma behavior is specified, but this is at least inconsistent with how Windows C compilers operate. GCC emits line directives with forward slashes in paths and Visual C emits escaped backslashes. Thus I mostly inclined to treat this as a bug in hsc2hs (easily fixable). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 17:55:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 17:55:51 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking (was: Promote type/data family instance constructors) In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.87f83fa847f29b76bcd2e57317f1a3ea@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) * related: #11348 => #11348, #12239 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 19:33:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 19:33:33 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. Message-ID: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This bug is entirely reproducible but unfortunately takes some setup. I don't have a minimal example. The regression is happening in FLTKHS (https://github.com/deech/fltkhs), the Haskell bindings to the FLTK(http://fltk.org) toolkit, and in particular to this GUI (https://github.com/deech/fltkhs/blob/master/images /tree-complex-windows.png). In GHC 7.8, it taks 5-9 seconds to compile and link in 7.10.3, that goes up to 12-15 seconds and finally in GHC 8 it shoots up to 45 seconds. While these numbers come from my i7, 16GB RAM Linux laptop, the compile time regression is proportionally reproducible across machines and operating systems. Here are the steps to reproduce it * Install FLTK Please follow the instructions here (https://github.com/deech/fltkhs #linux-and-bsd) but only the first set which about for installing FLTK 1.3. * Clone the repo with the offending application: `git clone https://github.com/deech/fltkhs-fluid-demos` * Build the application and reproduce the problem: - `cabal install fltkhs` - At the root of the repo do `cabal build fltkhs-fluid-tree` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 19:52:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 19:52:07 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.2443b31cba054f957970877fa5a379d9@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by deech: @@ -16,2 +16,1 @@ - #linux-and-bsd) but only the first set which about for installing FLTK - 1.3. + #linux-and-bsd) but only the first set which is about installing FLTK 1.3. New description: This bug is entirely reproducible but unfortunately takes some setup. I don't have a minimal example. The regression is happening in FLTKHS (https://github.com/deech/fltkhs), the Haskell bindings to the FLTK(http://fltk.org) toolkit, and in particular to this GUI (https://github.com/deech/fltkhs/blob/master/images /tree-complex-windows.png). In GHC 7.8, it taks 5-9 seconds to compile and link in 7.10.3, that goes up to 12-15 seconds and finally in GHC 8 it shoots up to 45 seconds. While these numbers come from my i7, 16GB RAM Linux laptop, the compile time regression is proportionally reproducible across machines and operating systems. Here are the steps to reproduce it * Install FLTK Please follow the instructions here (https://github.com/deech/fltkhs #linux-and-bsd) but only the first set which is about installing FLTK 1.3. * Clone the repo with the offending application: `git clone https://github.com/deech/fltkhs-fluid-demos` * Build the application and reproduce the problem: - `cabal install fltkhs` - At the root of the repo do `cabal build fltkhs-fluid-tree` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 21:03:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 21:03:51 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.48fdb3cb2b5600bd82e293f3b9e28760@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Moved from #5927. Use case from [http://ozark.hendrix.edu/~yorgey/pub/twisted.pdf How to Twist Pointers without Breaking Them]: > {{{#!hs > class Monoid m => Action m a where > act :: m -> a -> a > }}} > ''[...]'' > > We first formalise the action of monoids on functors. Intuitively, for a monoid `m` to act on the functor `f`, it should act in a uniform way on all the types `f a`. Therefore, we would like to assert a constraint something like `forall a. Action m (f a)`. Unfortunately, Haskell does not allow the use of universally quantified constraints and hence we need a new type class. > > {{{#!hs > class (Monoid m, Functor f) => ActionF m f where > act' :: m -> f a -> f a > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 21:16:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 21:16:56 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.5ebf355fce2f6c6b1f5263eab7410bd7@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------- Reporter: jcristovao | Owner: ak3n Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: => ak3n -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 21:37:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 21:37:10 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.3ef3b8c08465c30debfe02a77f87a45d@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This functionality does my head in so bear with me. In the definition of [https://www.reddit.com/r/haskell/comments/2ag8h2/recovering_preconditions_from_dataconstraint/civ9tm2 Fmt], constraints of `(p a, p b, p (a, b))` are assumed for `:&` {{{#!hs data Fmt :: (* -> Constraint) -> (* -> *) -> * -> * where Int :: p Int => Fmt p r Int (:&) :: (p a, p b, p (a,b)) => Fmt p r a -> Fmt p r b -> Fmt p r (a,b) Lift :: p (r a) => r a -> Fmt p r a }}} `(p a, p b)` often implies `p (a, b)`, would this be captured by `QuantifiedConstraints`? {{{#!hs (:&) :: (p a, p b, forall xx yy. (p xx, p yy) => p (xx, yy)) => Fmt p r a -> Fmt p r b -> Fmt p r (a,b) }}} Does this even give us any additional power? Is this more or less powerful than the `:=>` class from [https://hackage.haskell.org/package/constraints constraints]? {{{#!hs class b :=> h | h -> b where ins :: b :- h instance (Eq a, Eq b) :=> Eq (a, b) where ins = Sub Dict instance (Ord a, Ord b) :=> Ord (a, b) where ins = Sub Dict instance (Show a, Show b) :=> Show (a, b) where ins = Sub Dict instance (Read a, Read b) :=> Read (a, b) where ins = Sub Dict instance (Bounded a, Bounded b) :=> Bounded (a, b) where ins = Sub Dict instance (Monoid a, Monoid b) :=> Monoid (a, b) where ins = Sub Dict ... }}} What if we assume that GHC generates instances of `:=>`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 21:38:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 21:38:44 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.a1a474528de380586904fbf90476f154@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Would this `Show` instance for [https://www.reddit.com/r/haskell/comments/2ag8h2/recovering_preconditions_from_dataconstraint/civ9tm2 Fmt] work with `ImplicationConstraints` (`(=>) :: Constraints -> Constraints -> Constraints`): {{{#!hs data Fmt :: (* -> Constraint) -> (* -> *) -> * -> * where Int :: p Int => Fmt p r Int (:&) :: (p a, p b, p (a,b)) => Fmt p r a -> Fmt p r b -> Fmt p r (a,b) Lift :: p (r a) => r a -> Fmt p r a instance (p => Show) => (Show (Fmt ctx r a) where show t = case t of Int -> "Int" l :& r -> show l ++ "&" ++ show r Lift r -> show r }}} A question on `QuantifiedConstraints` on this same example in ticket:2893#comment18. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 21:45:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 21:45:10 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.f5798727ac95345b415f03e994ee8b52@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Has there been any discussion about GHC generating instances of [https://hackage.haskell.org/package/constraints-0.8/docs/Data- Constraint.html#t::-61--62- :=>] and [https://hackage.haskell.org/package/constraints-0.8/docs/Data- Constraint.html#t:Class Class]: {{{#!hs -- Given -- class Foo a => Bar a -- GHC should generate -- instance Class (Foo a) (Bar a) where -- cls :: Bar a :- Foo a -- cls = Sub Dict class Class b h | h -> b where cls :: h :- b }}} or [https://hackage.haskell.org/package/constraints-0.8/docs/Data- Constraint-Lifting.html#t:Lifting Lifting] {{{#!hs class Lifting p f where lifting :: p a :- p (f a) class Lifting2 p f where lifting2 :: p a :- Lifting p (f a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 22:01:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 22:01:14 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.2d242d50c8393b0728d372222373d26b@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Iceland_jack, there are two problems with using typeclasses like these to "solve" this problem: 1. They're based on explicit `Dict` values. As a result, using them requires lots of pattern matching and type variable scoping hullabaloo, which gets annoying pretty quickly. 2. What does it mean to automatically generate instances for `(:=>)`? Do we only generate instances that correspond to actual instance contexts? If so, then the following would typecheck, since there is an `instance () :=> Eq ()`: {{{#!hs ins :: () :- Eq () }}} But the following would //not// typecheck! {{{#!hs ins :: Eq () :- Eq () }}} Because there is no `instance Eq () => Eq ()` anywhere (and thus no `instance Eq () :=> Eq ()`), only `instance Eq ()`. But the implication `Eq () => Eq ()` should obviously hold. Does that mean we should also generate an `instance Eq () :=> Eq ()` automatically? But what about `(Eq (), Ord ()) => Eq ()`? `(Eq (), Ord (), Show ()) => Eq ()`? There is an extremely high number of contexts in which `Eq ()` holds, and generating every possible one of them would result in a combinatorial explosion. While those classes are neat tricks that can get you some of the functionality of `QuantifiedConstraints`/`ImplicationConstraints`, they don't go all the way. I really feel that some compiler smarts would make these features manageable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 23:19:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 23:19:37 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.d06cc7fbeb7081332f623fce079b6907@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------- Reporter: jcristovao | Owner: ak3n Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2461 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * differential: => Phab:D2461 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 20 23:22:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Aug 2016 23:22:12 -0000 Subject: [GHC] #12507: Can't deduce implicit parameter Message-ID: <051.55756e2de2f8b649cd84d740d6b1fdee@haskell.org> #12507: Can't deduce implicit parameter -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried running a [https://gist.github.com/llelf/6c01ded225877914f38a gist] {{{#!hs {-# LANGUAGE GADTs, ConstraintKinds, Rank2Types, ImplicitParams #-} data Rec fields where Rec :: fields => Rec fields infixr 1 ? (?) :: Rec fields -> (fields => r) -> r Rec ? e = e record :: Rec (?a :: Int, ?b :: String) record = Rec where ?a=42 ?b="hey" access :: Int access = record ? ?a }}} and got {{{ $ ghci -ignore-dot-ghci tCHB.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tCHB.hs, interpreted ) tCHB.hs:15:19: error: • Could not deduce: ?a::Int arising from a use of implicit parameter ‘?a’ from the context: (?a::Int, ?b::String) bound by a type expected by the context: (?a::Int, ?b::String) => Int at tCHB.hs:15:10-20 • In the second argument of ‘(?)’, namely ‘?a’ In the expression: record ? ?a In an equation for ‘access’: access = record ? ?a Failed, modules loaded: none. Prelude> }}} I would certainly expect the context `(?a::Int, ?b::String)` to imply `?a::Int`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 09:46:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 09:46:19 -0000 Subject: [GHC] #12035: hs-boot knot tying insufficient for ghc --make In-Reply-To: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> References: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> Message-ID: <060.ed7ab6ef0014393d22d67b4b60e9781a@haskell.org> #12035: hs-boot knot tying insufficient for ghc --make -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: | backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2213 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"8fd184887e7c240c7089367c6f737fa66cf409fc/ghc" 8fd1848/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8fd184887e7c240c7089367c6f737fa66cf409fc" Retypecheck both before and after finishing hs-boot loops in --make. Summary: This makes ghc --make's retypecheck behavior more in line with ghc -c, which is able to tie the knot as we are typechecking. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2213 GHC Trac Issues: #12035 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 09:46:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 09:46:19 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.04a30af24a70451bd87b68d87bf79903@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2210 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"5a8fa2e662fce9ef03f0ec7891d7f81740e630bc/ghc" 5a8fa2e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5a8fa2e662fce9ef03f0ec7891d7f81740e630bc" When a value Id comes from hi-boot, insert noinline. Fixes #10083. Summary: This also drops the parked fix from efa7b3a474bc373201ab145c129262a73c86f959 (though I didn't revert the refactoring). Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2211 GHC Trac Issues: #10083 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 09:46:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 09:46:19 -0000 Subject: [GHC] #12035: hs-boot knot tying insufficient for ghc --make In-Reply-To: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> References: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> Message-ID: <060.edd7e47d47eeabedd72f9b10008b2073@haskell.org> #12035: hs-boot knot tying insufficient for ghc --make -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: | backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2213 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"e528061e2779ce475927f44d817eaf15a02cbac7/ghc" e528061/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e528061e2779ce475927f44d817eaf15a02cbac7" We also need to retypecheck before when we do parallel make. Summary: Kept this seperate from the previous patch for clarity. Comes with a test. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2220 GHC Trac Issues: #12035 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 09:46:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 09:46:19 -0000 Subject: [GHC] #12472: "lazy" is not optimized away In-Reply-To: <045.7d7b50e8f2304c6383051ada9816b306@haskell.org> References: <045.7d7b50e8f2304c6383051ada9816b306@haskell.org> Message-ID: <060.2ad5a2974c00cd740b9dac556b69da0a@haskell.org> #12472: "lazy" is not optimized away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2444 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"0d3bf62092de83375025edca6f7242812338542d/ghc" 0d3bf62/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0d3bf62092de83375025edca6f7242812338542d" Fix #12472 by looking for noinline/lazy inside oversaturated applications. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2444 GHC Trac Issues: #12472 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 09:55:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 09:55:45 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.27164746a1113e3e00da9f41f26a2424@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2210 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 09:55:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 09:55:59 -0000 Subject: [GHC] #12035: hs-boot knot tying insufficient for ghc --make In-Reply-To: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> References: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> Message-ID: <060.fbf8610c13f3af4a6351c3620674e4a3@haskell.org> #12035: hs-boot knot tying insufficient for ghc --make -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: fixed | backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2213 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 09:56:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 09:56:11 -0000 Subject: [GHC] #12472: "lazy" is not optimized away In-Reply-To: <045.7d7b50e8f2304c6383051ada9816b306@haskell.org> References: <045.7d7b50e8f2304c6383051ada9816b306@haskell.org> Message-ID: <060.9c56d5204f07dfe41ef336890a838936@haskell.org> #12472: "lazy" is not optimized away -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2444 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 10:09:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 10:09:01 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.fcef9239ad28c27a2b4082432bb26999@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Another example, where a newtype complicates things ever further. I tried adding TH sections to enforce an order in which type family instances are added but it didn't help: {{{ {-# LANGUAGE TemplateHaskell, TypeInType, GADTs, TypeFamilies #-} {-# OPTIONS -Wno-unticked-promoted-constructors #-} import Data.Kind (Type) data N = Z | S N data Fin :: N -> Type where FZ :: Fin (S n) FS :: Fin n -> Fin (S n) type family FieldCount (t :: Type) :: N type family FieldType (t :: Type) (i :: Fin (FieldCount t)) :: Type newtype Field (t :: Type) (i :: Fin (FieldCount t)) = Field (FieldType t i) return [] -- split TH section data L type instance FieldCount L = S Z return [] -- split TH section type instance FieldType L FZ = () return [] -- split TH section -- newtype not involved, compiles. l_fz :: FieldType L FZ l_fz = () -- newtype involvoed, doesn't compile. field_l_fz :: Field L FZ field_l_fz = Field l_fz }}} The error I'm getting is: {{{ field.hs:36:20: error: • Couldn't match type ‘FieldType L 'FZ’ with ‘()’ • In the first argument of ‘Field’, namely ‘l_fz’ In the expression: Field l_fz In an equation for ‘field_l_fz’: field_l_fz = Field l_fz }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 10:22:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 10:22:21 -0000 Subject: [GHC] #12508: Show evaluation step-by-step in GHCi Message-ID: <047.dc71f1709f1e1765fbce2e96bfb5d340@haskell.org> #12508: Show evaluation step-by-step in GHCi -------------------------------------+------------------------------------- Reporter: Hi-Angel | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: interactive | Operating System: Unknown/Multiple evaluation debugging | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The ability see every evaluation step for executing a particular code in ghci is needed. Earlier that could have [[http://stackoverflow.com/a/554391/2388257|done in HAT]], or ghc-vis. But as of today, HAT doesn't compile even with stack. And, at least personally for me, neither ghc-vis could be installed. I want to point out that the funcionality is **very** important for the language. Without that ''(i.e. as it is now)'' it is impossible for newcomers to see how a particular construction going to be evaluated, how much memory it going to take. Nowadays newcomers have to deal with memory issues post-mortem: an app takes all system memory, dies, then one build everything for profiling, and start playing a Battleship with the allocation graph; which going to be a hard game, unless you're experienced enough to not even allow that to happen most of the times. However, if there was a way to execute functions in GHCI, looking the evaluation step-by-step, days of hard debugging would turn into a few hours of executing a couple of functions in ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 11:19:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 11:19:55 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.817fd6503b27048ae5d3b5715fa4c847@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): The [[https://gist.github.com/llelf/6c01ded225877914f38a code] from #12507, whether or not it's supposed to compile, it would be nice to be able to specify the result type `r` {{{#!hs (?) :: forall r fields. Rec fields -> (fields => r) -> r Rec ? e = e }}} {{{#!hs access = record ? ?a }}} Doesn't compile, but {{{#!hs -- access :: (?a::Int) => Int access = (?) @Int record ?a }}} which could be `record ? @Int ?a`.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 15:40:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 15:40:52 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.86f17b04b4957d2517bddae9061fd58e@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Points well taken, but I'm a little uncomfortable with the directional of travel, because we ''are'' making things worse: the `reflection` library depends critically on `unsafeCoerce`. If we implement `with`, then we've essentially blessed this operation as safe. So the behavior is the same, but what was previously considered unsafe is now safe. It doesn't sound great to me. The example in comment:23 is, in my view, an infelicity in the design of the language. I'm not convinced that rejecting `cmp` is a good idea, but it is dangerously implementation-dependent. Indeed in GHC the choice of `Ord` dictionary might change between minor releases or depending on what order functions are written in a module. Here's an idea, based on visible type application (that is, `id @Int :: Int -> Int`) that allows us to specify usually-inferred parameters: * Extend the visible type application mechanism to work with dictionaries (that is, constraints). * Add the ability to bind a variable to an inferred parameter in a pattern, with `@`. * Reject code that uses dictionaries ambiguously, now that we have a workaround. The example from comment:23 is now rejected. But here is the working version: {{{ cmp :: SomeOrd a -> SomeOrd a -> Ordering cmp (SomeOrd @_ @d1 a) (SomeOrd @_ @_d2 b) = compare @_ @d1 a b }}} All the `@_` arguments above are because we don't care about the type variables, which come before the dictionaries. Here, we've explicitly chosen the first dictionary, so there is no ambiguity or implementation- dependence. Unfortunately, implementing this plan is a ways off. Perhaps we could just special-case `with` to error on ambiguity (naturally, this wouldn't break existing code) and know that we'll have a better solution later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 15:57:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 15:57:46 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.c55d65ee93a2306ca560aa2f47c97ef1@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:16 alexvieth]: > 1. Do SCC analysis on all declarations except for open type family instances, to give ordered `TyClGroup`s and the set of those instances (in source file order). > 2. Before checking the `TyClGroup`s, put all equalities arising from the open type family instances into the environment (assume for now that they're well-kinded). > 3. Check the `TyClGroup`s in order as usual. > 4. Check the open type family instances (verifying or falsifying the assumption in 2). > > Maybe this is nonsense. Would it be possible to make and use a coercion axiom without kind checking the lhs and rhs types? I'm not sure I understand. Currently, kind-checking an instance and desugaring it are all done at the same time, so step (2) is hard to implement. Let's say we get around that barrier, though. This would then put ill-kinded equalities into the context. I think it would be awfully hard to avoid getting GHC to loop or do other silly things with a bad context. Perhaps you could squeeze this through, but I'm very skeptical. Or am I misunderstanding something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 16:05:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 16:05:09 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.e81c0af1571ca7172faa75c2333facf1@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm not convinced that comment:17 is the same bug here. That, to me, looks like a bug in the resolution to #11348. Doing the major rewrite I propose in comment:13 and comment:15 may likely help, but there's a good chance comment:17 could be fixed with much less effort. Alex, you're the expert here. What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 18:21:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 18:21:17 -0000 Subject: [GHC] #12465: Evil idea: Allow empty record field update syntax for types. In-Reply-To: <051.24b812ed598c409441e148e921dac8f9@haskell.org> References: <051.24b812ed598c409441e148e921dac8f9@haskell.org> Message-ID: <066.69b02a11f2e4132297350adc43c5e32b@haskell.org> #12465: Evil idea: Allow empty record field update syntax for types. -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I would love to see full support for record-like syntax at the type level. This would be (almost) forward-compatible with such an idea. I like it, with one exception: empty braces always always mean that the type is fully applied. If you wish for it to be partially applied, then use underscores. The (almost) part above is that you mean the type `Vector {}` to have a subtly different meaning than an expression `MkRec {}`. In the former, you wish for GHC to infer the values for the arguments. In the latter, you wish for GHC to use `undefined`. In some future world where we can sometimes infer the value of term-level arguments (because we have dependent types), perhaps we can have `MkRec {}` mean "infer arguments where possible, otherwise use `undefined`". Such an interpretation of `MkRec {}` seems fully backward-compatible, for two reasons: (1) no term- level arguments can be inferred today, and (2) even if they could, we would simply be making a term-level value be more defined, which can't hurt the semantics of a program. So I, for one, support this move. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 19:30:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 19:30:19 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.75fea8b82d0f46da674953fdd1c6813b@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I really think this exactly the same problem. The crux of this ticket is > (type/data) instances can depend on other (type/data) instances so we have to get the order right. #11348 goes some of the way to get the right order but doesn't account for dependencies between (type/data) instances. I am trying to write up these discussions on a wiki page as it is very messy currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 19:52:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 19:52:06 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.48ca2bf6793e9483d447106899bd0ffa@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But comment:17 has no data instances. There are only type instances there, hence my confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 19:59:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 19:59:16 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way Message-ID: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Trying to run `ghci -XSafe` produces the following output: {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help :1:6: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. :1:30: error: Not in scope: ‘System.IO.stdin’ No module named ‘System.IO’ is imported. :1:46: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. :1:70: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. :1:94: error: Not in scope: ‘System.IO.stdout’ No module named ‘System.IO’ is imported. :1:111: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. :1:135: error: Not in scope: ‘System.IO.hSetBuffering’ No module named ‘System.IO’ is imported. :1:159: error: Not in scope: ‘System.IO.stderr’ No module named ‘System.IO’ is imported. :1:176: error: Not in scope: data constructor ‘System.IO.NoBuffering’ No module named ‘System.IO’ is imported. }}} I'm not sure whether this should work, but in any case the error message is horrible. I tried adding `-trust base` to no avail. For comparison, ghc-7.10.3 starts with no trouble: {{{ > ghci -XSafe GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> }}} (Motivation: I'm using ghci in Safe mode to track down import problems with SafeHaskell. As a workaround, I can use `:set -XSafe` after ghci's startup is done.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 20:31:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 20:31:02 -0000 Subject: [GHC] #12510: GHC.Prim.~# shows up unexpectedly in a pattern synonym type Message-ID: <047.ad7e977487b917e1a3e677314f30bad7@haskell.org> #12510: GHC.Prim.~# shows up unexpectedly in a pattern synonym type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I load {{{ data T a where MkT :: Bool -> T Bool pattern P x <- MkT x }}} into GHCi and ask `:info P`, I get {{{ pattern P :: () => t GHC.Prim.~# Bool => Bool -> T t }}} That should say `t ~ Bool` without `-fprint-equality-relations`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 20:52:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 20:52:41 -0000 Subject: [GHC] #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy Message-ID: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The reason why this module isn't inferred safe is that it uses `unsafePerformIO` to create a global `IORef`. From a SafeHaskell perspective, this module isn't very useful in itself, but its unsafety prevents other modules that import it to provide class instances from being inferred as safe. A concrete example is https://hackage.haskell.org/package/exceptions-0.8.3/docs/src/Control- Monad-Catch.html#line-186 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 21:05:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 21:05:43 -0000 Subject: [GHC] #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy In-Reply-To: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> References: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> Message-ID: <059.7e6835872f33f4f8da97237a20dfd327@haskell.org> #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * component: libraries (other) => Template Haskell Comment: Seems reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 21:15:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 21:15:35 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.268bd60d63052c851d83f0540cde925b@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): @Richard, it seems to me the crux of the problem is that type instances introduce equalities so they must be interleaved with the other declarations. Data instances are just one place where these extra equalities can be used, another being kind checking for type equalities as in comment:17. Here is the wiki page I started. It is not complete but I am too tired to carry on tonight. Perhaps you could look Alex and fill in some of the details? https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 22:23:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 22:23:21 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.40531a9f79c68c3aa765280d4104b5d8@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I don't think that `cmp` should be rejected. I see no problem that GHC just picks one of the available dictionaries. Let me explain why. Currently, all of those types are equivalent: * `(a, b) => t` * `(b, a) => t` * `a => b => t` * `b => a => t` Also, those types are equivalent: * `c => t` * `(c, c) => t` * `c => c => t` This means that the only thing that identifies a value to the left of `=>` is its type. Whereas you can pass two distinct `Int`s to a function explicitly (`Int -> Int -> r`), you can't do the same implicitly (`Given Int => Given Int => r` ~ `Given Int => r`). It is therefore reasonable to expect that there's only *one unique value* of each type to the left of `=>`. If there are more, you can't distinguish between them anyway. This plays really well with type classes: since instances are coherent, `Ord a` is a unique value for each `a`. With the `Given`/`given`/`give` machinery from `reflection` we can now enrich the context with different values of the same type. I say that this is a violation of the philosophy behind `=>` and we don't want features (such as explicitly binding dictionaries using `@`-syntax) that get us further down this road. Partial solutions will not help. Say we forbid using nested `give`s with the same type as proposed in comment:22: the example in comment:24 demonstrates that we can violate the "one type - one value" principle without using nested `give`s by packaging the dictionaries in a GADT. I propose the following: let's get rid of `Given` and allow arbitrary things of kind `Type` to the left of `=>`. However, let's not call `give` some pretty name like `with` and add special casing; instead, let's call it `incoherentWithDict` and put it into a deep dark corner of `GHC.Exts`. Why bother at all? Now we can implement the safe interface (`Reifies`/`reflect`/`reify` from `reflection`) without `unsafeCoerce`, using `incoherentWithDict` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 23:07:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 23:07:47 -0000 Subject: [GHC] #12512: UnboxedTupleRep-related panic involving typeclasses Message-ID: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> #12512: UnboxedTupleRep-related panic involving typeclasses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #11723 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- You can trigger a GHC panic by abusing `UnboxedTupleRep` in just the right way: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE UnboxedTuples #-} import GHC.Exts class Wat (a :: TYPE 'UnboxedTupleRep) deriving instance Wat (# a, b #) }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): newTyConEtadArity (#,#) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is probably a leak that #11723 didn't plug, as it only considered datatypes, not typeclasses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 21 23:56:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Aug 2016 23:56:13 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.6cdd7d79cbb0d46137586e852d7db50b@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): Thomie, could you share the program from which you derived your example? Does it also use `undefined` or was it using CallStacks in some other manner? And if it was using `undefined`, do you see a similar slowdown if you replace `undefined` with the old (callstack-less) `error`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 00:02:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 00:02:40 -0000 Subject: [GHC] #12513: Template Haskell boxes singleton unboxed tuples when splicing them Message-ID: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> #12513: Template Haskell boxes singleton unboxed tuples when splicing them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: #5332 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As noticed [https://phabricator.haskell.org/D2448#71603 here], this program somehow compiles: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE UnboxedTuples #-} module Bug where import Language.Haskell.TH.Lib import Language.Haskell.TH.Ppr import Language.Haskell.TH.Syntax f :: $([t| (# Int #) |]) -> Int f x = x g :: $(unboxedTupleT 1 `appT` conT ''Int) -> Int g x = x }}} Despite the fact that `(# Int #)` and `Int` are most definitely //not// the same type! If you compile with `-ddump-splices`, you'll see what's going on: {{{ $ /opt/ghc/head/bin/ghc Bug.hs -ddump-splices [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:12:8-40: Splicing type unboxedTupleT 1 `appT` conT ''Int ======> Int Bug.hs:9:8-23: Splicing type [t| (# Int #) |] ======> In }}} It appears that the splicing machinery is turning `(# Int #)` into `Int` behind the scenes. Luckily, this should be easy to fix. Patch coming soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 00:06:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 00:06:43 -0000 Subject: [GHC] #12514: Can't write unboxed sum type constructors in prefix form Message-ID: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> #12514: Can't write unboxed sum type constructors in prefix form -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- You can write `(# Int | Char #)`, but not `(# | #) Int Char`. This is annoying since it prevents you from partially applying unboxed sum type constructors, and it also precludes you from doing cool things like `reify ''(#||#)` (as I woefully noted [https://phabricator.haskell.org/D2448 here]). Luckily, I don't think fixing this would be too hard. The special case of parsing unboxed tuple type constructors as prefix is handled [http://git.haskell.org/ghc.git/blob/0d3bf62092de83375025edca6f7242812338542d:/compiler/parser/Parser.y#l2861 here], so I //think// we'd just need to add a similar case for unboxed sums. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 00:22:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 00:22:17 -0000 Subject: [GHC] #12513: Template Haskell boxes singleton unboxed tuples when splicing them In-Reply-To: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> References: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> Message-ID: <065.68af565761e9e267a5a88be0c46da2c0@haskell.org> #12513: Template Haskell boxes singleton unboxed tuples when splicing them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #5332 | Differential Rev(s): Phab:D2462 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2462 * milestone: => 8.0.2 @@ -29,1 +29,1 @@ - Bug.hs:9:8-23: Splicing type [t| (# Int #) |] ======> In + Bug.hs:9:8-23: Splicing type [t| (# Int #) |] ======> Int New description: As noticed [https://phabricator.haskell.org/D2448#71603 here], this program somehow compiles: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE UnboxedTuples #-} module Bug where import Language.Haskell.TH.Lib import Language.Haskell.TH.Ppr import Language.Haskell.TH.Syntax f :: $([t| (# Int #) |]) -> Int f x = x g :: $(unboxedTupleT 1 `appT` conT ''Int) -> Int g x = x }}} Despite the fact that `(# Int #)` and `Int` are most definitely //not// the same type! If you compile with `-ddump-splices`, you'll see what's going on: {{{ $ /opt/ghc/head/bin/ghc Bug.hs -ddump-splices [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:12:8-40: Splicing type unboxedTupleT 1 `appT` conT ''Int ======> Int Bug.hs:9:8-23: Splicing type [t| (# Int #) |] ======> Int }}} It appears that the splicing machinery is turning `(# Int #)` into `Int` behind the scenes. Luckily, this should be easy to fix. Patch coming soon. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 00:41:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 00:41:43 -0000 Subject: [GHC] #12510: GHC.Prim.~# shows up unexpectedly in a pattern synonym type In-Reply-To: <047.ad7e977487b917e1a3e677314f30bad7@haskell.org> References: <047.ad7e977487b917e1a3e677314f30bad7@haskell.org> Message-ID: <062.e4a27b098dd3a396ccb9b50048869713@haskell.org> #12510: GHC.Prim.~# shows up unexpectedly in a pattern synonym type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): See #12024 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 00:51:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 00:51:30 -0000 Subject: [GHC] #12514: Can't write unboxed sum type constructors in prefix form In-Reply-To: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> References: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> Message-ID: <065.b2363cb6d958a83aa6b735e51c04e3fc@haskell.org> #12514: Can't write unboxed sum type constructors in prefix form -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, it's not //quite// that simple, unfortunately. Vertical bars are a bit more finicky to parse than commas, so simply adding a new case to `ntgtycon` in `Parser.y` like so: {{{#!diff diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y index b9479d9..fa0d0af 100644 --- a/compiler/parser/Parser.y +++ b/compiler/parser/Parser.y @@ -75,7 +75,8 @@ import TcEvidence ( emptyTcEvBinds ) import ForeignCall import TysPrim ( eqPrimTyCon ) import PrelNames ( eqTyCon_RDR ) -import TysWiredIn ( unitTyCon, unitDataCon, tupleTyCon, tupleDataCon, nilDataCon, +import TysWiredIn ( unitTyCon, unitDataCon, tupleTyCon, sumTyCon, + tupleDataCon, nilDataCon, unboxedUnitTyCon, unboxedUnitDataCon, listTyCon_RDR, parrTyCon_RDR, consDataCon_RDR ) @@ -2861,6 +2862,9 @@ ntgtycon :: { Located RdrName } -- A "general" qualified tycon, exc | '(#' commas '#)' {% ams (sLL $1 $> $ getRdrName (tupleTyCon Unboxed (snd $2 + 1))) (mo $1:mc $3:(mcommas (fst $2))) } + | '(#' bars '#)' {% ams (sLL $1 $> $ getRdrName (sumTyCon + (snd $2 + 1))) + (mo $1:mc $3:(mbars (fst $2))) } | '(' '->' ')' {% ams (sLL $1 $> $ getRdrName funTyCon) [mop $1,mu AnnRarrow $2,mcp $3] } | '[' ']' {% ams (sLL $1 $> $ listTyCon_RDR) [mos $1,mcs $2] } @@ -3468,6 +3472,11 @@ mcs ll = mj AnnCloseS ll mcommas :: [SrcSpan] -> [AddAnn] mcommas ss = map (\s -> mj AnnCommaTuple (L s ())) ss +-- | Given a list of the locations of vertical bars, provide a [AddAnn] with an +-- AnnVbar entry for each SrcSpan +mbars :: [SrcSpan] -> [AddAnn] +mbars ss = map (\s -> mj AnnVbar (L s ())) ss + -- |Get the location of the last element of a OrdList, or noSrcSpan oll :: OrdList (Located a) -> SrcSpan oll l = }}} doesn't quite make the cut: Things that will parse successfully: * `(#| #)` * `(# | #)` * `(#| | #)` * `(# | | #)` That is, all sum type constructors such that (1) there's a space between the last bar and the `#)`, and (2) all bars are separated with at least one character of whitespace. Things that fail to parse: * `(#|#)` * `(# |#)` * `(#||#)` * `(#| |#)` * `(# | |#)` * `(# ||#)` * `(# || #)` (interestingly, GHC will parse this as the type operator `||` surrounded by hash-parens) Perhaps we require that bars must be separated by spaces as a prefix type constructor? Or perhaps we can finagle with the parser more to fix this above issues? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 01:17:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 01:17:54 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.c863301312846948f0e1bf2a9351261f@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Hm. Perhaps you're right that my suggestion goes against the spirit of Haskell constraints and that it would be more sensible to simply rename `with` to `incoherentWith`. Instead of my proposed error, we could simply add a warning when GHC detects (on a best effort basis) an ambiguous constraint. This warning would be triggered in `cmp`, for example, and silly uses of `incoherentWith`. Or perhaps not in `cmp` because GHC can detect that the ambiguously satisfied constraint is actually a class constraint and therefore assumed to be coherent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 01:20:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 01:20:05 -0000 Subject: [GHC] #12512: UnboxedTupleRep-related panic involving typeclasses In-Reply-To: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> References: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> Message-ID: <065.3108331e750da6099f5d1b3c6b03febe@haskell.org> #12512: UnboxedTupleRep-related panic involving typeclasses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: Urgh. `UnboxedTupleRep` is a lie, and liars never prosper. This falls in my pile, but it will be a little while until I get to it, so if you (for any value of "you") are inspired, go for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 01:22:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 01:22:02 -0000 Subject: [GHC] #12510: GHC.Prim.~# shows up unexpectedly in a pattern synonym type In-Reply-To: <047.ad7e977487b917e1a3e677314f30bad7@haskell.org> References: <047.ad7e977487b917e1a3e677314f30bad7@haskell.org> Message-ID: <062.3eceba748ab5245f865f25f2d83df02a@haskell.org> #12510: GHC.Prim.~# shows up unexpectedly in a pattern synonym type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Oops -- thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 01:47:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 01:47:13 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.6714a4c854402a2c61be984225f33c1d@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:26 int-index]: > Currently, all of those types are equivalent: > > * `(a, b) => t` > * `(b, a) => t` > * `a => b => t` > * `b => a => t` Edwardk [https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70 #reddit-you-can-write-show-a--read-a--a---a-instead-of-show-a-read-a--a--- a notes] that `a => b => t` is slightly weaker than `(a, b) => t` since it can “only reference backwards up the chain”. I can't produce an example of this though, there may be differences between `a => b => t` and `b => a => t` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 01:52:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 01:52:40 -0000 Subject: [GHC] #12515: Pattern synonyms with non-conid/consym names give poor error messages Message-ID: <043.9a36e1acf40d36ce58465f6cfd7175c9@haskell.org> #12515: Pattern synonyms with non-conid/consym names give poor error messages -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following: {{{#!hs {-# LANGUAGE PatternSynonyms #-} -- Correct: pattern P = () pattern p = () }}} gives a rather unhelpful error message: {{{ parse error on input ‘=’ Perhaps you need a 'let' in a 'do' block? e.g. 'let x = 5' instead of 'x = 5' }}} Ideally, it should hint that the name of pattern should follow constructor identifier rules. ---- In the same vein, the following: {{{#!hs {-# LANGUAGE PatternSynonyms #-} -- Correct: pattern (:+) = () pattern (+) = () }}} currently gives: {{{ error: parse error on input ‘+’ }}} It should hint that the operator should begin with a {{{:}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 03:38:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 03:38:48 -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.f9bbd5b637a75cde42f624080a103ea7@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: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: dsrun014 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): I can think of a few options - Auto-generate a bunch of return frames for different length tuples. Doesn't work because unboxed tuples can store unboxed data, so we get an exponential code size blowup. - Write a little interpreter (directly in Cmm) that looks at metadata in stack frame and does the appropriate operations. This one should work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 07:02:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 07:02:56 -0000 Subject: [GHC] #12516: Preprocessing: no way to portably use stringize and string concatenation Message-ID: <047.d2338b23eeeda984fa4982226d5ecfbe@haskell.org> #12516: Preprocessing: no way to portably use stringize and string concatenation -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To reduce boilerplate code in an FFI implementation file I am trying to use the stringizing and string concatenation features of the C preprocessor. But it seems there is no portable way to do that. I am listing what I tried below: 1. Using stringizing and string concatenation in traditional mode (https://gcc.gnu.org/onlinedocs/cpp/Traditional-macros.html). ghc uses cpp in traditional mode by passing `-traditional`. The behavior of `-traditional` mode is not consistent across gcc and clang. While gnu cpp supports stringizing and string concatenation in traditional mode clang cpp does not support it. 2. Disable traditional mode on the given file. There is no way to disable `-traditional` via `-optP` since it only appends new options to the preprocessor and does not override the old ones. 3. There is an issue in using the clang cpp via `-pgmP cpp`. clang cpp does not accept a space between `-I` flag and the include directory. For example `cpp -I .` fails with `clang: error: no such file or directory: 'c'`. ghc passes this flag with a space. 4. Finally, using cc as a preprocessor worked for me: `{-# OPTIONS_GHC -pgmP cc -optP -E -optP -undef -optP -std=c89 #-}`. But This relies on cc being in `PATH` and always pointing to a compiler which behaves in the way we want. In theory, cc may turn out to be different than the compiler and preprocessor actually used by ghc. But this still seems to be the best practical option and I am using this one. Possible solutions could be: * Use a native preprocessor, something like `cpphs`. * A temporary workaround could be to provide a way to override the preprocessor options (rather than appending to them) so that we can knowingly use the configured ghc preprocessor program without the traditional flag, something like `-optP--override`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 07:07:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 07:07:20 -0000 Subject: [GHC] #12516: Preprocessing: no way to portably use stringize and string concatenation In-Reply-To: <047.d2338b23eeeda984fa4982226d5ecfbe@haskell.org> References: <047.d2338b23eeeda984fa4982226d5ecfbe@haskell.org> Message-ID: <062.6ff00685bd2d154556fe1486e8f3428f@haskell.org> #12516: Preprocessing: no way to portably use stringize and string concatenation -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harendra): * keywords: => cpp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 07:15:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 07:15:16 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.4c5dc5797a24fb7ad2bb3ceb63cd6419@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have not read every word here, but to me it seems: * The main issue is whether `(Ord a)` is a singleton type. That is, if you have two `Ord` dictionaries around, does it matter which you choose? If it was a singleton, then `with` could not be incoherent. Of course, we can have two different `Ord` dictionaries by declaring two instances in different places. We could exclude that, if we wanted, by doing as we do with type families and checking for incompatible instances. But it's not a soundness issue so we don't. So, is that enough? Adding `with` does not make things any more incoherent, provided we limit the ways you can construct a value of kind `Constraint`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 07:33:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 07:33:12 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.65dbf32e3d660b13ac05ef0898915476@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 07:38:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 07:38:29 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.9ff14c81a3dc78273a044c88a67c1926@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Replying to [comment:27 goldfire]: A warning sounds like a plausible solution, provided that it's suppressed for class constraints. ---- Replying to [comment:28 Iceland_jack]: That's interesting, although I am not quite sure what "reference" means in this context. ---- Replying to [comment:29 simonpj]: > Of course, we can have two different `Ord` dictionaries by declaring two instances in different places. You can't have both of them in scope. And unless they are orphan instances, which are frowned upon, you can't use both of them in one program. > provided we limit the ways you can construct a value of kind `Constraint`. If I understand correctly, the plan is to abolish kind 'Constraint' in favor of 'Type'. So 'with' does make things more incoherent, as now you can have `Int => t` and `Int` is clearly not a singleton type, and you can have two distinct `Int`s in one scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 07:43:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 07:43:57 -0000 Subject: [GHC] #12035: hs-boot knot tying insufficient for ghc --make In-Reply-To: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> References: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> Message-ID: <060.4a767de75c053fe453abc4a8cb57512a@haskell.org> #12035: hs-boot knot tying insufficient for ghc --make -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: fixed | backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2213 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Edward, both these changes are small but subtle. But they both lack any commentary. Would it be worth adding some? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 07:46:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 07:46:46 -0000 Subject: [GHC] #12035: hs-boot knot tying insufficient for ghc --make In-Reply-To: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> References: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> Message-ID: <060.42b36dad128caf99dac6d3c72971a99a@haskell.org> #12035: hs-boot knot tying insufficient for ghc --make -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: fixed | backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2213 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Already done, in https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/TyingTheKnot :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 08:09:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 08:09:16 -0000 Subject: [GHC] #12514: Can't write unboxed sum type constructors in prefix form In-Reply-To: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> References: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> Message-ID: <065.e528526dfe8f5136714203899eb3b26d@haskell.org> #12514: Can't write unboxed sum type constructors in prefix form -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There's a debate to be had about what concrete syntax for sums both unboxed and (not yet implemented) boxed. But if we stick to the current unary notation, I rather think we should not allow spaces anywhere. Ditto for tuples. Maybe we should do it in the lexer, not the parser? Also for data constructors what is the prefix form. E.g. Instead of `(#| True ||#)`, do we write * `(#| ||#) True`, or * `(#_||#) True`? I prefer the latter. We should not have spaces in the middle of names? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 08:17:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 08:17:27 -0000 Subject: [GHC] #12035: hs-boot knot tying insufficient for ghc --make In-Reply-To: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> References: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> Message-ID: <060.56b74f1abc586def4a899b414aeafd53@haskell.org> #12035: hs-boot knot tying insufficient for ghc --make -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: fixed | backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2213 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Very good -- but that wiki page is not referred to by the crucial code changes in the above patches. And it might be worth connecting the code changes to the tickets... an example (in the ticket) is often so illuminating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 08:23:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 08:23:52 -0000 Subject: [GHC] #12460: Solaris linker does not recognize option --gc-sections In-Reply-To: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> References: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> Message-ID: <060.119a4e8e7d0854359cb5e86a6572c496@haskell.org> #12460: Solaris linker does not recognize option --gc-sections -------------------------------------+------------------------------------- Reporter: herzen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Solaris | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kgardas): My Solaris 11.3 testing machine is currently not working and waiting for hardware tweaking, but on Solaris 11.2 I've not been able to duplicate this issue. Simply speaking there is no --gc-sections param passed to the linker at all. Side note: binary distributions for Solaris are built on Solaris 11.2. I've attempted to test GHC build on Solaris 11.3 but so far was not able to come up with working build. The reason is that in between 11.2 and 11.3 there are quite some low-level changes which affects GHC build. Possible workaround: search for setting file in your GHC installation directory and see if -Wl,--gc-sections option is there. If so, edit file and remove this option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 08:56:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 08:56:33 -0000 Subject: [GHC] #12517: Simplify runghc command line options Message-ID: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Keywords: runghc | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently there are three ways runghc can pass options to GHC: 1. unrecognized options are automatically passed to GHC 2. options after a `--` are passed to GHC 3. `--ghc-args=` passes arg to GHC The command line is difficult to comprehend and non-intuitive with all these different ways to pass options to GHC. Other than having multiple ways to do the same thing there are other problems too. For example: 1. The meaning of `--` is overloaded, the usual meaning is that everything after it is non option or opaque args. This is difficult to explain and creates confusion. 2. To pass a filename starting with a dash we need something like `runghc -- -- -prog.hs`. Which is not a usual use case but it needs to be explained in the manual anyway. 3. It first appears that options after `--` will be passed to GHC including those not starting with a `-` but that is not the case. For args not starting with a `-` we need to use `--ghc-arg=` so there is not much use of the `--` anyway other than increased confusion. I propose to do away with all other mechanisms other than the explicit `--ghc-arg=` method. This will make the documentation and understanding of the command straightforward and intuitive. Though the change will not be backward compatible. If backward compatibility is really needed we will have to use deprecation warnings for the unsupported methods and remove them from the official documentation and wait for some time before we actually remove them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 10:23:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 10:23:45 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.e8609cc7e3d30ef2ec07d2b8b0a9d34f@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I have a couple of reservations about this ticket. Issue 1) {{{#!hs reify :: c => c with :: c -> (c => r) -> r }}} are morally close to `reflect` and `reify` from the `reflection` package respectively. (Chung-chieh Shan has a pretty compelling argument for why your `reify` is actually a `reflect`.) With the stated intent of working around the `Dict` hack, they work fine! However, they can also be used to model reflection in a dangerous way: By letting you pack up an arbitrary Int => ... now the instance for "Int" isn't unique. This means that the category of constraints isn't thin, and that now we care about provenance about where you got the Int from. This yields all the same problems as {{{#!hs class (?foo :: Int) => Bar a }}} from {{{#!hs class Int => Bar a }}} whereas we very explicitly disallow the former today. Right now every way you can compose an entailment in Constraint in the absence of IncoherentInstances and ImplicitParams is unique. This lets things like `Set` know the instance won't change on it between `insert` and `lookup`. I'm very scared of letting in something that would break that guarantee. Going the other way, and letting you bring constraints out to the right side of the => isn't hazardous, as with and reify don't give you tools to construct such a dictionary, and this just lets you move things around in the same manner as `Dict` does today. But with `Constraint = *`, it isn't clear how to keep that safe. `Given` in the `reflection` library, which provides this functionality today is actually being demoted to a supplemental package due to the amount of pain and confusion it causes users when multiple instances find themselves in scope. `reify` and `reflect` do not have those problems due to the quantifier. To preserve your desire to embed Constraint into * without overhead, in theory `Dict` could just be a magical newtype, put on and removed by the equivalent of your `reify` and `with` combinators: {{{ dict :: c => Dict c with :: Dict c -> (c => r) -> r }}} This avoids the `class Int => Bar a` issue entirely and doesn't interfere with a sound reflection story. Issue 2) It is a fairly common newbie error to write `foo :: Ord a -> a -> Set a` -- which would now very confusingly pass the type system rather than get caught. We should at least have the discussion about if this is desirable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 10:32:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 10:32:14 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.f62912ed0960ed16a62c253bb01c49d0@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Maybe we want `with` to work on only on ''singleton types'', if we could somehow isolate those? So rather than "be of kind `Constraint`" for `with` we need "is a singleton type"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 11:47:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 11:47:05 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.af9fa73d47ee5675d6619ef50f2acf8a@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Replying to [comment:32 simonpj]: This should work, although I would prefer to have `incoherentWith` at my disposal as well, for cases when I'm willing to manually ensure that in any local scope only one value is available. Consider this case: {{{ module M (f) where f :: Int -> ... helper1 :: Int => ... helper2 :: Int => ... }}} Here I'd like to pass `Int` to the helpers using `incoherentWith`, but since only `f` is exported, the unsafety is contained within the module boundaries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 12:08:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 12:08:34 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking Message-ID: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 8.0.1 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- = Package Selection Across Multiple Package DBs = As explained by ezyang, when there are multiple package dbs, GHC chooses the packages to use in the following manner. I might have misunderstood so please correct me if I am wrong. * If there are multiple packages with different versions the latest non- broken version is chosen. * If the there are multiple packages with the same version the behavior is unspecified. * If there are multiple packages with the same package-id (shadowing) then the one which comes first in `GHC_PACKAGE_PATH` or which comes first on command line (`-package` flag) will be used. = The Problem = The build tool `Stack` implements stacked package databases. It uses a base package database and then stacks another package database on top of it to customise it further without modifying. The behavior is such that the package db on top of the stack completely overrides the ones below. That means you choose a package from top of the stack even if the version is older. Stack implements this by passing explicit package-ids of the packages to GHC. This scheme works well for cabal projects where we know ALL the packages used by the project in advance. But it does not work for scripts run using runghc. In that case we do not know the packages required by the script in advance and therefore cannot pass the package-ids to GHC. That means we cannot make GHC use the packages in the right way. GHC will choose the latest version even though we want it to choose a possibly older version from the top of the db stack. = Proposed Solution = Implement a new CLI option, something like `--stacked-pkg-dbs`. If this option is used GHC will use `GHC_PACKAGE_PATH` or the -package-db options as a stack of dbs. The first db in the path or the first CLI option will be considered the top of the stack. GHC will choose a package from the first db from the top of the stack irrespective of the version of the package. If the package is broken it should report error rather than silently choosing from the next db. This will allow us to modify an immutable package db by stacking another db on top. Implementing this as a separate option will keep the existing behavior so as to remain backward compatible. This has been discussed in a stack issue on github [https://github.com/commercialhaskell/stack/issues/1957 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 12:14:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 12:14:12 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.9d95eed220ba2e2cde573c6339e6193f@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pggiarrusso): * cc: pggiarrusso (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 12:24:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 12:24:54 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.7a9e2f52636844a6df5e9a0e26f79253@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I have a hard time believing you'd "like" to do this. Wouldn't it be more sensible to use implicit parameters? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 12:46:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 12:46:26 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.74701e6bdec5f06061ae403b6d14f38d@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Replying to [comment:34 rwbarton]: > I have a hard time believing you'd "like" to do this. Wouldn't it be more sensible to use implicit parameters? I have a disdain for implicit parameters that stems from the fact that their names are represented by strings (`Symbol`s, to be precise), and names are not strings in my view, they are unique identifiers declared somewhere. More importantly, I may want to declare (unexported) data types in this module, and instances for those data types may require a context too: {{{ data Helper = ... instance Int => Eq Helper where ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 13:03:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 13:03:36 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.d9c3fae6fc6488062f7a4d010d3debd9@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well pretending `Int` is a constraint seems far more distasteful, and this whole discussion seems like a solution in search of a problem to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 13:24:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 13:24:30 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.72d2d52c28055b408ae4d9598fe20d6d@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I find pretending that `Int` is a constraint to be quite appealing, actually: it elevates the intuition that `=>` is like `->`, only implicit. The current design of `ImplicitParameters` will be easily expressible on top of this new feature with `(?param :: T) => t` desugaring into `Tagged "param" T =>` at type level and `?cmp` desugaring into `unTagged @"param" reflect` at term level. To sum it up, making `Type ~ Constraint` unifies/simplifies: * The `Dict` wrapper * `Typeable` & type-indexed `TypeRep` * `Given`-style and `Reifies`-style reflection * `-XImplicitParameters` To me, this kind of simplification is far from "distasteful". Meanwhile, I agree with issue (1) from comment:31 and we should certainly document to what problems `incoherentWith` leads, and actively discourage its incorrect use. I wouldn't be happy if people started using it to model implicits from Scala (which are basically incoherent type classes). It's still a useful function to have, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 13:37:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 13:37:23 -0000 Subject: [GHC] #12519: Rendered Haddock for Eq and Ord are missing class methods Message-ID: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> #12519: Rendered Haddock for Eq and Ord are missing class methods -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The rendered haddock for the {{{Eq}}} and {{{Ord}}} classes are missing: * Their class methods * Their source links See: * http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Eq.html#t:Eq * http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#t:Eq * http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Ord.html#t:Ord * http://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html#t:Ord Other (deriviable) classes, for example {{{Show}}}, or {{{Enum}}}, do not have these problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 13:43:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 13:43:56 -0000 Subject: [GHC] #12116: No easy way to add cost-centre to top-levels In-Reply-To: <043.6b04c4666f71935c9beabebf233c1a73@haskell.org> References: <043.6b04c4666f71935c9beabebf233c1a73@haskell.org> Message-ID: <058.5bf58ed8108a9ef7d9a2d2f4c113d269@haskell.org> #12116: No easy way to add cost-centre to top-levels -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2407 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This was merged in b5ec09dff6b865550f3bd225f86028a304596c61. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 13:44:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 13:44:52 -0000 Subject: [GHC] #12125: Field accessors unnecessarily kept alive In-Reply-To: <043.0981b0708581432c190c561d66c8ba25@haskell.org> References: <043.0981b0708581432c190c561d66c8ba25@haskell.org> Message-ID: <058.8661a1248854e7d15bf641176748c8fd@haskell.org> #12125: Field accessors unnecessarily kept alive -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature request | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2270 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 Comment: This was merged in b5ec09dff6b865550f3bd225f86028a304596c61. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 13:45:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 13:45:01 -0000 Subject: [GHC] #12519: Rendered Haddock for Eq and Ord are missing class methods In-Reply-To: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> References: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> Message-ID: <061.f77091f42201c8a1c04dbfd847df8d3e@haskell.org> #12519: Rendered Haddock for Eq and Ord are missing class methods -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): I've also reported it as a haddock issue: https://github.com/haskell/haddock/issues/549 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 13:47:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 13:47:40 -0000 Subject: [GHC] #12408: "ghc: panic! (the 'impossible' happened)" only when compiled with "-O" In-Reply-To: <046.d29ea653b6a5476c1904e0cd28bb26ab@haskell.org> References: <046.d29ea653b6a5476c1904e0cd28bb26ab@haskell.org> Message-ID: <061.f90d52d7421a1f20013965f92f3afaaf@haskell.org> #12408: "ghc: panic! (the 'impossible' happened)" only when compiled with "-O" -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Indeed the example compiles fine with b5ec09dff6b865550f3bd225f86028a304596c61. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 13:47:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 13:47:49 -0000 Subject: [GHC] #12408: "ghc: panic! (the 'impossible' happened)" only when compiled with "-O" In-Reply-To: <046.d29ea653b6a5476c1904e0cd28bb26ab@haskell.org> References: <046.d29ea653b6a5476c1904e0cd28bb26ab@haskell.org> Message-ID: <061.952cb59912fcfabbc3d9c56411ca6075@haskell.org> #12408: "ghc: panic! (the 'impossible' happened)" only when compiled with "-O" -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 13:58:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 13:58:15 -0000 Subject: [GHC] #12217: PowerPC NCG: Remove TOC save for calls. In-Reply-To: <047.9e933c12a40c44141b6563372c17d615@haskell.org> References: <047.9e933c12a40c44141b6563372c17d615@haskell.org> Message-ID: <062.76b64d6e30a9576de5be27bd5bc98d95@haskell.org> #12217: PowerPC NCG: Remove TOC save for calls. -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2328 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in b5ec09dff6b865550f3bd225f86028a304596c61. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 13:58:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 13:58:42 -0000 Subject: [GHC] #12217: PowerPC NCG: Remove TOC save for calls. In-Reply-To: <047.9e933c12a40c44141b6563372c17d615@haskell.org> References: <047.9e933c12a40c44141b6563372c17d615@haskell.org> Message-ID: <062.262244b1cb0b55ef3aafa3f2f183e6c3@haskell.org> #12217: PowerPC NCG: Remove TOC save for calls. -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2328 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 14:04:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 14:04:10 -0000 Subject: [GHC] #12381: Type family not reduced In-Reply-To: <046.0dea1b11f4af8f3cac37c083d6847cd7@haskell.org> References: <046.0dea1b11f4af8f3cac37c083d6847cd7@haskell.org> Message-ID: <061.279055d9c1eedac74654841be1eba310@haskell.org> #12381: Type family not reduced -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.0.2 => 8.2.1 Comment: Sadly the fix in #11348 (353d8ae6fafe117a1cac4adf6f029a5baccc2780) is a very large patch which looks to not apply easily. It looks like this will have to wait until 8.2. Sorry everyone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 14:08:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 14:08:15 -0000 Subject: [GHC] #12514: Can't write unboxed sum type constructors in prefix form In-Reply-To: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> References: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> Message-ID: <065.a78595e4c80060dd98a824d707811ae6@haskell.org> #12514: Can't write unboxed sum type constructors in prefix form -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 simonpj]: > But if we stick to the current unary notation, I rather think we should not allow spaces anywhere. Ditto for tuples. Maybe we should do it in the lexer, not the parser? Just to be clear on the is/ought distinction being discussed, GHC //currently// accepts spaces in prefix tuple types/expressions/patterns: {{{ $ /opt/ghc/head/bin/ghci -fobject-code -XUnboxedTuples GHCi, version 8.1.20160819: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :t ( , , ) ( , , ) :: a -> b -> c -> (a, b, c) λ> :t (# , , #) (# , , #) :: a -> b -> c -> (# a, b, c #) λ> :k ( , , ) ( , , ) :: * -> * -> * -> * λ> :k (# , , #) (# , , #) :: * -> * -> * -> TYPE 'GHC.Types.UnboxedTupleRep λ> :t \a -> case a of ( , , ) x y z -> (# , , #) x y z \a -> case a of ( , , ) x y z -> (# , , #) x y z :: (a, b, c) -> (# a, b, c #) }}} Also, there is a current restriction for unboxed sums (as noted in osa1's [http://osa1.net/posts/2016-07-22-unboxed-sums-faq.html#syntax-is-awful- why blog]) that fully saturated applications of unboxed sum expressions must separate their bars by whitespace: > Data constructors use the same syntax, except we have to put spaces between bars. For example, if you have a type with 10 alternatives, you do something like `(# | | | | value | | | | | #)`. Space between bars is optional in the type syntax, but not optional in the term syntax. The reason is because otherwise we’d have to steal some existing syntax. For example, `(# ||| a #)` can be parsed as singleton unboxed tuple of `Control.Arrow.|||` applied to an argument, or an unboxed sum with 4 alternatives. So if we require that the prefix counterparts must not have whitespace, then we ought to consider what effects that would/should have on the above. Food for thought. > Also for data constructors what is the prefix form. E.g. Instead of `(#| True ||#)`, do we write > * `(#| ||#) True`, or > * `(#_||#) True`? > > I prefer the latter. We should not have spaces in the middle of names? Indeed, the latter notation is what GHC is [https://git.haskell.org/ghc.git/blob/0d3bf62092de83375025edca6f7242812338542d:/compiler/prelude/TysWiredIn.hs#l854 using internally], I believe. But I'll be honest in that I'm not a huge fan of that notation. For one thing, the underscore in the expression `(#_||#) True` feels like it could represent a typed hole. Also, if `(#_||#) True` is allowed to appear in pattern syntax, is the underscore a wildcard pattern? Perhaps we could rule out these possibilities by carefully designing the lexer/parser, but it's worth thinking over. One more thing worth bringing up: in the [https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes#Designquestions UnpackedSumTypes wiki page], Richard brings up an interesting alternative syntax for unboxed sum expressions, where `(# 0 of 3 | x #)` would mean `(# x | | #)`. If we adopted that, we could have a much less ambiguous prefix form: {{{ (# 0 of 3 |#) x \x -> case x of (# 0 of 3|#) x -> x }}} But I don't know if redesigning the term-level syntax is on the agenda. osa1 mentions it in [osa1.net/posts/2016-07-22-unboxed-sums-faq.html the conclusion] of his blog post, so maybe he can chime in on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 14:36:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 14:36:59 -0000 Subject: [GHC] #12520: Segfault when using unboxed tuples in GHCi Message-ID: <044.bba28760ed7c8a02bec3c23cab523249@haskell.org> #12520: Segfault when using unboxed tuples in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you put this module in a package: {{{#!hs {-# LANGUAGE MagicHash, UnboxedTuples #-} module Bug ( box, wrap, proxy ) where import GHC.Prim box :: (# Proxy# a, b #) -> b box (# x, y #) = y wrap :: b -> Proxy# a -> (# Proxy# a, b #) wrap x = \i# -> (# i#, x #) proxy :: () -> Proxy# a proxy () = proxy# }}} Then in GHCi you can do: {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> import Bug Prelude Bug> box (wrap "foo" (proxy ())) "Segmentation fault (core dumped) }}} Alternatively you can crash `runhaskell` if you put the above code in main. It seems that GHCi fails to pickup usage of (# VoidRep, PtrLiftedRep #) tuples or something. The same trick works with `State#` in place of `Proxy#`, but not with `Int#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 14:40:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 14:40:43 -0000 Subject: [GHC] #12513: Template Haskell boxes singleton unboxed tuples when splicing them In-Reply-To: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> References: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> Message-ID: <065.f307aa519a1506c7266608c7f50d7242@haskell.org> #12513: Template Haskell boxes singleton unboxed tuples when splicing them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #5332 | Differential Rev(s): Phab:D2462 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"fb0d87f1c4a35fa2aaf7f6dd55edbc71c7c3b44d/ghc" fb0d87f1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fb0d87f1c4a35fa2aaf7f6dd55edbc71c7c3b44d" Splice singleton unboxed tuples correctly with Template Haskell Summary: Previously, TH would implicitly remove the parentheses when splicing in singleton unboxed tuple types (e.g., turning `(# Int #)` into `Int`). Luckily, the fix is simply to delete some code. Fixes #12513. Test Plan: make test TEST=T12513 Reviewers: hvr, bgamari, austin, goldfire Reviewed By: goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2462 GHC Trac Issues: #12513 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 14:42:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 14:42:15 -0000 Subject: [GHC] #12513: Template Haskell boxes singleton unboxed tuples when splicing them In-Reply-To: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> References: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> Message-ID: <065.de2e632f65d60c6609c55a4fa8ad0c48@haskell.org> #12513: Template Haskell boxes singleton unboxed tuples when splicing them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: th/T12513 Blocked By: | Blocking: Related Tickets: #5332 | Differential Rev(s): Phab:D2462 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => th/T12513 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 14:45:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 14:45:04 -0000 Subject: [GHC] #12520: Segfault when using unboxed tuples in GHCi In-Reply-To: <044.bba28760ed7c8a02bec3c23cab523249@haskell.org> References: <044.bba28760ed7c8a02bec3c23cab523249@haskell.org> Message-ID: <059.e1121543cb4175e7cba693c464f4da4b@haskell.org> #12520: Segfault when using unboxed tuples in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * status: new => closed * resolution: => fixed Comment: This is fixed in HEAD apparently -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 14:46:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 14:46:27 -0000 Subject: [GHC] #12520: Segfault when using unboxed tuples in GHCi In-Reply-To: <044.bba28760ed7c8a02bec3c23cab523249@haskell.org> References: <044.bba28760ed7c8a02bec3c23cab523249@haskell.org> Message-ID: <059.cac8fca348b2b74b3e9c520eb5f6018a@haskell.org> #12520: Segfault when using unboxed tuples in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This is fixed in HEAD. Unboxed tuple handling in the interpreter is a bit hacky (we have special cases for tuples with one void value etc.), but it was recently improved during the implementation of unboxed sums (see new `RepType` module and its uses in `BytecodeGen`). That also fixed this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 15:25:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 15:25:48 -0000 Subject: [GHC] #12048: Allow CustomTypeErrors in type synonyms (+ evaluate nested type family?) In-Reply-To: <051.f5a3bb82cbacb1093f08604448c52c48@haskell.org> References: <051.f5a3bb82cbacb1093f08604448c52c48@haskell.org> Message-ID: <066.19ec59ec984fe917e3cd113e48e84536@haskell.org> #12048: Allow CustomTypeErrors in type synonyms (+ evaluate nested type family?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jkarni): * cc: jkarni (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 15:36:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 15:36:00 -0000 Subject: [GHC] #12514: Can't write unboxed sum type constructors in prefix form In-Reply-To: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> References: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> Message-ID: <065.5415a23676e4189e73f100582ca1a922@haskell.org> #12514: Can't write unboxed sum type constructors in prefix form -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > GHC currently accepts spaces in prefix tuple types/expressions/patterns: Indeed. But I don't think it should. It an accident of implementation, not a goal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 15:45:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 15:45:15 -0000 Subject: [GHC] #12520: Segfault when using unboxed tuples in GHCi In-Reply-To: <044.bba28760ed7c8a02bec3c23cab523249@haskell.org> References: <044.bba28760ed7c8a02bec3c23cab523249@haskell.org> Message-ID: <059.17ce6dfa68648f579ff72cde9c5cb736@haskell.org> #12520: Segfault when using unboxed tuples in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great that it's fixed. Would it be worth adding a regression tests, so that it ''stays'' fixed? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 16:18:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 16:18:48 -0000 Subject: [GHC] #12521: Thread blocked indefinitely in an MVar operation Message-ID: <053.f0da307ad87f1df98e8d5b92884f7e14@haskell.org> #12521: Thread blocked indefinitely in an MVar operation -------------------------------------+------------------------------------- Reporter: | Owner: SwiftsNamesake | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: GHCi crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs C:\Users\Jonatan>ghci 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. λ> putStrLn "\35753Haskell\25110\32773Ghci\33021\27491\30830\26174\31034\27721\23383\24182\19988\35835\21462\27721\23383\21629\21517\30340\25991\26723" *** Exception: : hPutChar: invalid argument (invalid character) λ> λ> λ> λ> λ> λ> λ> chcp 6 ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation 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 Mon Aug 22 17:39:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 17:39:43 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker Message-ID: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure if this is a bug or hanging the compiler is expected here. This was the minimal example that causes GHC to hang: {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE AllowAmbiguousTypes #-} main = return $ f (Just 'c') data D1 x data D2 type family TF x = t | t -> x type instance TF (D1 x, a) = Maybe (TF (x, a)) type instance TF (D2, ()) = Char class C p where f :: TF (x, a) -> () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 19:36:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 19:36:50 -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.d6cc774c4cc7fae153b3ea7d7651aa39@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @slyfox the GC threads all spin in this `any_work()` loop looking for work they can steal from other threads. It's how the GC work gets distributed amongst the available worker threads. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 19:39:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 19:39:10 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large In-Reply-To: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> References: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> Message-ID: <059.8068314b06f48ff5d02fa06641eec651@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Regardless of what's going on in `ghc-datasize` and `ghc-heap-view`, if the GHC-compiled program emits this message then it's a bug in GHC, because we're supposed to fail at compile-time instead. (the number in the error message is a compile-time constant, not a runtime value) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 20:15:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 20:15:55 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.9ed368d9f5a7ef78cf925288410cfde2@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -10,3 +10,4 @@ - * If there are multiple packages with the same package-id (shadowing) then - the one which comes first in `GHC_PACKAGE_PATH` or which comes first on - command line (`-package` flag) will be used. + * If there are multiple packages with the same installed package id + (shadowing) then the one which comes first in `GHC_PACKAGE_PATH` or which + comes last on command line (according to `-package-db` flags) will be + used. New description: = Package Selection Across Multiple Package DBs = As explained by ezyang, when there are multiple package dbs, GHC chooses the packages to use in the following manner. I might have misunderstood so please correct me if I am wrong. * If there are multiple packages with different versions the latest non- broken version is chosen. * If the there are multiple packages with the same version the behavior is unspecified. * If there are multiple packages with the same installed package id (shadowing) then the one which comes first in `GHC_PACKAGE_PATH` or which comes last on command line (according to `-package-db` flags) will be used. = The Problem = The build tool `Stack` implements stacked package databases. It uses a base package database and then stacks another package database on top of it to customise it further without modifying. The behavior is such that the package db on top of the stack completely overrides the ones below. That means you choose a package from top of the stack even if the version is older. Stack implements this by passing explicit package-ids of the packages to GHC. This scheme works well for cabal projects where we know ALL the packages used by the project in advance. But it does not work for scripts run using runghc. In that case we do not know the packages required by the script in advance and therefore cannot pass the package-ids to GHC. That means we cannot make GHC use the packages in the right way. GHC will choose the latest version even though we want it to choose a possibly older version from the top of the db stack. = Proposed Solution = Implement a new CLI option, something like `--stacked-pkg-dbs`. If this option is used GHC will use `GHC_PACKAGE_PATH` or the -package-db options as a stack of dbs. The first db in the path or the first CLI option will be considered the top of the stack. GHC will choose a package from the first db from the top of the stack irrespective of the version of the package. If the package is broken it should report error rather than silently choosing from the next db. This will allow us to modify an immutable package db by stacking another db on top. Implementing this as a separate option will keep the existing behavior so as to remain backward compatible. This has been discussed in a stack issue on github [https://github.com/commercialhaskell/stack/issues/1957 here]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 20:17:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 20:17:00 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.b97773ec9ad3cd64a9a39fc6d297717e@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ak3n Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: => ak3n -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 20:34:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 20:34:53 -0000 Subject: [GHC] #12035: hs-boot knot tying insufficient for ghc --make In-Reply-To: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> References: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> Message-ID: <060.be38df687769ffc681495a0b69ad1456@haskell.org> #12035: hs-boot knot tying insufficient for ghc --make -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: fixed | backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2213 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"1f75440fc7e4577190d98c0f4643d54d9c934540/ghc" 1f75440/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f75440fc7e4577190d98c0f4643d54d9c934540" Extra comments, as per SPJ in #12035. Signed-off-by: Edward Z. Yang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 20:35:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 20:35:33 -0000 Subject: [GHC] #12035: hs-boot knot tying insufficient for ghc --make In-Reply-To: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> References: <045.e388ac2b960dff94b80b0bffb9130187@haskell.org> Message-ID: <060.b020b8da7682db97a9cc3665f8c55559@haskell.org> #12035: hs-boot knot tying insufficient for ghc --make -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: fixed | backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2213 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Done! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 21:15:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 21:15:06 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.a60e4026cc00b526e722dee3a90da815@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: richardfung Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by richardfung): Am I correct in thinking the right way to test this is to write a function which would only be inlined if the INLINE pragma is there? Otherwise, the function would be inlined even in source files that import it with OPTIONS_GHC -O0 right? I was completely unfamiliar with inlining before this ticket so please bear with me. It seems like imported modules are still inlined even if OPTIONS_GHC -O0 is set if you run ghc --make -O. The documentation also says that -O enables cross module inlining so I'm guessing even if the source file has OPTIONS_GHC -O0, inlinings from other modules are still supposed to happen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 21:15:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 21:15:14 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large In-Reply-To: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> References: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> Message-ID: <059.5371433f52db9abafb34169230a0a115@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Simon, is that true even in view of the fact that `ghc-heap-view` contains Cmm that calls `ALLOC_PRIM_P` directly? (https://github.com/nomeata/ghc- heap-view/blob/master/cbits/HeapViewPrim.cmm#L27) It's not clear to me how custom Cmm is supposed to allocate heap objects that might be either small or large, with small objects allocated into the nursery for efficiency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 21:57:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 21:57:54 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large In-Reply-To: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> References: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> Message-ID: <059.fbd8adce793da205ba857669ee372230@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ah, I didn't realise it had custom Cmm. Yes, that could account for the observed behaviour. I think it should be possible to use a conditional on the size of the object and call `allocate()` for a large object (with a `MAYBE_GC` check), or `ALLOC_PRIM_P` for a small object. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 21:59:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 21:59:26 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.87ef896aceafdcfa638c001c4f6aa3b4@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): So, what do you want to happen if a single package database has multiple exposed copies of a package; e.g. package.conf has both p-0.1 and p-0.2 (which are both exposed). Then do you want p-0.2? How about if it has two copies of p-0.2 (with different installed package IDs)? Which one is picked is left unspecified? It's also worth mentioning how the `exposed` flag ties into this. For the initial visibility calculation, you probably don't want not-exposed packages to be considered at all. So if we have pkg-0.1 (exposed), and then on the occluding package db, pkg-0.2 (not exposed), we should use pkg-0.1. (Maybe you don't care, because you never not expose? But the behavior needs to be ironed out.) If so, what should happen if I say `-package pkg`? The current behavior (without occlusion) is to pick the latest version in ANY database, no matter if it's exposed or not. So I guess we would then have to pick out pkg-0.2 from the top database, hiding pkg-0.1 in the process. I am also unsure about this comment: > If the package is broken it should report error rather than silently choosing from the next db. OK I also need more clarification on this. So if I say `-package base` you still want to pick out `base` from the system package database, right? So do you want something like, "if you request a package `pkgname`, and it is occluded by a broken package, you want this to error. Do you also want this behavior for `-package pkg-1.0`? What if there are two copies of `pkg-1.0` in the top-most package db, one is broken and one isn't? How about if there is `pkg-0.9` which is broken and `pkg-1.0` which is not? Also, suppose there is no `-package` flag specified. If there are broken packages in the top-most database, should we immediately error? (I guess not?) (When you answer these, please edit the ticket description so that it's up-to-date.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 22:06:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 22:06:36 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.78edbd9bf721cb66f02fe23c2c6cc9f1@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): While I certainly want to remove some of the ugliness around `Constraint`/`Type`, more clouds are appearing on the horizon. Specifically, I think {{{ f :: Int -> ... helper :: Int => ... }}} is problematic. When `f` calls `helper`, there are lots and lots of `Int`s available: the one passed into `f` as well as all of the others. Note that this is not the same with {{{ g :: a -> (a => r) -> r }}} where only one value of type `a` is in scope. (Thanks, parametricity!) Yes, `=>` should merely introduce an implicit argument, but GHC should not guess an implicit value when there is more than one option. This brings us back to Simon's suggestion about singleton types. I conjecture that there is no way to identify all singleton types without user direction. We could have users write a `{-# SINGLETON Either () Void #-}` pragma. But then we haven't come very far, as I don't know a way to check whether a `SINGLETON` pragma is lying or telling the truth. I also want to amplify Issue 2 from comment:31 to make sure that `blah :: Ord a -> a -> Set a` gets a reasonable error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 22:08:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 22:08:28 -0000 Subject: [GHC] #12513: Template Haskell boxes singleton unboxed tuples when splicing them In-Reply-To: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> References: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> Message-ID: <065.873e7bd9c5f8c76966e9c220df5a205b@haskell.org> #12513: Template Haskell boxes singleton unboxed tuples when splicing them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: th/T12513 Blocked By: | Blocking: Related Tickets: #5332 | Differential Rev(s): Phab:D2462 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Should we really merge this? Perhaps there's code that assumes the broken treatment that has existed for some time... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 22:18:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 22:18:59 -0000 Subject: [GHC] #12513: Template Haskell boxes singleton unboxed tuples when splicing them In-Reply-To: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> References: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> Message-ID: <065.192570ac9c72963c751fa8475ec7c40a@haskell.org> #12513: Template Haskell boxes singleton unboxed tuples when splicing them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: th/T12513 Blocked By: | Blocking: Related Tickets: #5332 | Differential Rev(s): Phab:D2462 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm, that's a good point. I was mentally lumping this ticket in the same category as #12403, which I also marked as merge... perhaps that ought to be moved to the 8.2.1 release as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 22:23:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 22:23:57 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.a07c43dc7f9efffc9dfa6e87af0f69ac@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Replying to [comment:38 goldfire]: > When `f` calls `helper`, there are lots and lots of `Int`s available: the one passed into `f` as well as all of the others. How is this problematic? `f` is free to pass any `Int` using `incoherentWith`. E.g.: {{{ f :: Int -> Int f x = incoherentWith (x * 2) helper helper :: Int => Int helper = reflect + 1 }}} Here `f = (+1) . (*2)`. It is the programmer's responsibility to make sure that no other `Int`s are available in any given context. This is my idea behind `incoherentWith`: it is an unsafe function that requires discipline from the programmer; same as `Given` from `reflection` today. The safe interface can be built on top. > Yes, `=>` should merely introduce an implicit argument, but GHC should not guess an implicit value when there is more than one option. I propose no such thing. GHC shouldn't guess anything. > This brings us back to Simon's suggestion about singleton types. I conjecture that there is no way to identify all singleton types without user direction. We could have users write a `{-# SINGLETON Either () Void #-}` pragma. But then we haven't come very far, as I don't know a way to check whether a `SINGLETON` pragma is lying or telling the truth. I suppose that what's important here is not how many values *inhabit* the type, but how many ways are there to construct an inhabitant. There are clearly numerous ways to write `instance Show T`, but there's only one instance available, therefore it can safely go to the left of `=>`. > I also want to amplify Issue 2 from comment:31 to make sure that `blah :: Ord a -> a -> Set a` gets a reasonable error message. How about this: if a function is ill-typed, try replacing the first `->` with a `=>`. If this makes the function well-typed, adjust the error message accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 22:33:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 22:33:47 -0000 Subject: [GHC] #12513: Template Haskell boxes singleton unboxed tuples when splicing them In-Reply-To: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> References: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> Message-ID: <065.60d52be6841140eece0f9cb655e95421@haskell.org> #12513: Template Haskell boxes singleton unboxed tuples when splicing them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: th/T12513 Blocked By: | Blocking: Related Tickets: #5332 | Differential Rev(s): Phab:D2462 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Well, yes. They should both be merged or neither. I favor "neither"... unless it's important for your work that they be merged. As a heavy TH user, I've worked around a bunch of TH bugs to get th-desugar and singletons working, and a fix like this between major releases would cause me a headache. (Not in this particular case, though.) That said, perhaps no one other than you has hit these bugs, in which case it's safe to merge. I leave it to your judgment, based on how it would affect your work if these were not merged until 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 23:05:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 23:05:05 -0000 Subject: [GHC] #12513: Template Haskell boxes singleton unboxed tuples when splicing them In-Reply-To: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> References: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> Message-ID: <065.3aca52f0b7bc5fec82e8615a25224fd7@haskell.org> #12513: Template Haskell boxes singleton unboxed tuples when splicing them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: th/T12513 Blocked By: | Blocking: Related Tickets: #5332 | Differential Rev(s): Phab:D2462 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"acdbd16ffca4f13cfae6eeed045a6fc5969adee2/ghc" acdbd16f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="acdbd16ffca4f13cfae6eeed045a6fc5969adee2" Move #12403, #12513 users guide notes to 8.2.1 release notes The changes in #12403 and #12513 subtly changed the behavior of Template Haskell reification and splicing. While the old behavior was certainly buggy, it's possible that there's code in the wild that depended on the old behavior to work. To err on the side of caution, I'll postpone these changes to GHC 8.2.1 instead of having them merged into GHC 8.0.2. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 23:05:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 23:05:05 -0000 Subject: [GHC] #12403: Template Haskell boxes unboxed tuple types when reifying them In-Reply-To: <050.3278a8386bb0a4b6b9320911f2b0a639@haskell.org> References: <050.3278a8386bb0a4b6b9320911f2b0a639@haskell.org> Message-ID: <065.e754a3210964a727bb91fe478bf25330@haskell.org> #12403: Template Haskell boxes unboxed tuple types when reifying them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T12403 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2405 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"acdbd16ffca4f13cfae6eeed045a6fc5969adee2/ghc" acdbd16f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="acdbd16ffca4f13cfae6eeed045a6fc5969adee2" Move #12403, #12513 users guide notes to 8.2.1 release notes The changes in #12403 and #12513 subtly changed the behavior of Template Haskell reification and splicing. While the old behavior was certainly buggy, it's possible that there's code in the wild that depended on the old behavior to work. To err on the side of caution, I'll postpone these changes to GHC 8.2.1 instead of having them merged into GHC 8.0.2. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 23:05:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 23:05:50 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.93b52fcae3a42d1ecfb2b897907906ee@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Oh, perhaps it's a miscommunication on my behalf. When I say "available in the context", by "context" I mean implicit parameters to the left of `=>`. So this should not compile: {{{#!hs f :: Int -> Int f x = -- error: The 'Int =>' constraint is NOT satisfied by 'x' helper helper :: Int => Int helper = ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 23:06:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 23:06:48 -0000 Subject: [GHC] #12403: Template Haskell boxes unboxed tuple types when reifying them In-Reply-To: <050.3278a8386bb0a4b6b9320911f2b0a639@haskell.org> References: <050.3278a8386bb0a4b6b9320911f2b0a639@haskell.org> Message-ID: <065.29126bbde74677cf54f4762b6f2de3ac@haskell.org> #12403: Template Haskell boxes unboxed tuple types when reifying them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T12403 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2405 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: merge => closed * resolution: => fixed Comment: I decided not to merge these per goldfire's advice [https://ghc.haskell.org/trac/ghc/ticket/12513#comment:6 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 23:07:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 23:07:47 -0000 Subject: [GHC] #12513: Template Haskell boxes singleton unboxed tuples when splicing them In-Reply-To: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> References: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> Message-ID: <065.d69483a75fa6a71444e5554c11bfaf3f@haskell.org> #12513: Template Haskell boxes singleton unboxed tuples when splicing them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: th/T12513 Blocked By: | Blocking: Related Tickets: #5332 | Differential Rev(s): Phab:D2462 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: merge => closed * resolution: => fixed Comment: I don't have an overwhelmingly strong desire to use these changes in 8.0.2, so I'll be conservative and postpone this change until GHC 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 22 23:54:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Aug 2016 23:54:33 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers Message-ID: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If we have in a file: {{{#!hs data X = X String unX (X s) = s }}} And then load the file in ghci with `-fobject-code` and {{{ > data Y = Y String > unX (Unsafe.Coerce.unsafeCoerce (Y "foo")) "Segmentation fault (core dumped) }}} Even though we are shooting ourselves in the foot there, the constructors `X` and `Y` are represented identically internally, so the code is supposed to work. And it does work if we either move `unX` into ghci'd code, or `Y` into compiled code. After a legthy debugging session with @rwbarton over IRC, we've identified the culprit of this. As [[Commentary/Rts/HaskellExecution/PointerTagging]] states, "In the continuation of an algebraic case, R1 is assumed tagged". And all compiled constructors tag the pointer when entered, e.g: {{{ Dump of assembler code for function ghczmprim_GHCziTypes_False_static_info: 0x00007fffef8dd018 <+0>: 48 ff c3 inc %rbx 0x00007fffef8dd01b <+3>: ff 65 00 jmpq *0x0(%rbp) Dump of assembler code for function base_GHCziBase_Just_static_info: 0x00007ffff03eb780 <+0>: 48 83 c3 02 add $0x2,%rbx 0x00007ffff03eb784 <+4>: ff 65 00 jmpq *0x0(%rbp) Dump of assembler code for function ghczmprim_GHCziTypes_GT_static_info: 0x00007fffef8dd1f8 <+0>: 48 83 c3 03 add $0x3,%rbx 0x00007fffef8dd1fc <+4>: ff 65 00 jmpq *0x0(%rbp) Dump of assembler code for function base_GHCziRTSziFlags_HeapByClosureType_static_info: 0x00007ffff057e768 <+0>: 48 ff c3 inc %rbx // more than 7 constructors so all tags are '1' 0x00007ffff057e76b <+3>: ff 65 00 jmpq *0x0(%rbp) }}} Whereas all ghci-bound data constructors share the `stg_interp_constr_entry` entry code (with an optional trampoline leading there): {{{ Dump of assembler code from 0x7ffff7ff3080 to 0x7ffff7ff3090: => 0x00007ffff7ff3080: jmpq *0x2(%rip) # 0x7ffff7ff3088 0x00007ffff7ff3088: 0x00007fffef4c9388 Dump of assembler code for function stg_interp_constr_entry: 0x00007fffef4c9388 <+0>: ff 65 00 jmpq *0x0(%rbp) }}} Relevant code: source:libraries/ghci/GHCi/InfoTable.hsc#L32 So in the end, compiled code relies on the assumption that the pointer is tagged, and ghci constructors produce untagged pointers. Even though it is currently impossible to have compiled code pattern match on a ghci constructor, I think this shouldn't happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 01:40:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 01:40:42 -0000 Subject: [GHC] #12524: RFC: Allow prefixing result evaluated at GHCi prompt Message-ID: <051.37f7bc8117fcf9b4c55eab131373e4e2@haskell.org> #12524: RFC: Allow prefixing result evaluated at GHCi prompt -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Similar to `prompt`, `prompt-cont` (previously `prompt2`): allowing users to supply a prefix to evaluation results with `result` has two use cases I can think of {{{ :set prompt " ghci> " :set prompt-cont " ghci| " :set result " " }}} the desired outcome would be `↓` as indented code for IRC, also reddit code format: {{{ ghci> 1 + 2 + 3 6 ghci> reverse "hello" "olleh" }}} ---- The other case came from [https://twitter.com/rightfold/status/767301255140179968 this tweet] {{{ :set prompt "" :set result "-- " }}} {{{ 1 + 2 + 3 -- 6 reverse "hello" -- "olleh" }}} This can be copied/pasted back to a separate GHCi session where the result is ignored. ---- I haven't seen this feature in any other repl, I'm not sure if this would see much use. This wouldn't work with IO actions without some magic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 02:54:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 02:54:39 -0000 Subject: [GHC] #12525: Internal identifiers creeping into :show bindings Message-ID: <044.1bd8a372e3005251359006b86de7988e@haskell.org> #12525: Internal identifiers creeping into :show bindings -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When binding variables the "new" way, or defining typeclasses, some things that are better left unseen manage to creep into the `:show Bindings` list. {{{#!html 
 GHCi, version 8.1.20160725: http://www.haskell.org/ghc/  :? for help
 > :show bindings
 > x = ()
 > :show bindings
 $trModule :: GHC.Types.Module = _
 x :: () = _
 > class Foo a
 > :show bindings
 x :: () = _
 class Foo a
 $tcFoo :: GHC.Types.TyCon = _
 $tc'C:Foo :: GHC.Types.TyCon = _
 $trModule :: GHC.Types.Module = _
}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 06:47:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 06:47:24 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.22cffb29aa0c087ba0f87bfafef5bed7@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: simonmar (added) Comment: Yes, tagging really is part of the return convention for data constructors, so I'm a bit surprised that GHCi gets away without it. Is `unsafeCoerce` really part of this? What happens for {{{ unX (X "foo") }}} or {{{ unX (id (X "foo")) }}} ? Why would it be different to what happens with `unsafeCoerce`? I'm adding Simon Marlow (king of GHCi) in cc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 06:53:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 06:53:37 -0000 Subject: [GHC] #12520: Segfault when using unboxed tuples in GHCi In-Reply-To: <044.bba28760ed7c8a02bec3c23cab523249@haskell.org> References: <044.bba28760ed7c8a02bec3c23cab523249@haskell.org> Message-ID: <059.53d3a865fb12b357043d374d135ef613@haskell.org> #12520: Segfault when using unboxed tuples in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"89facad267ff79f1f20b4866428693f423c2d0cc/ghc" 89facad2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="89facad267ff79f1f20b4866428693f423c2d0cc" Add T12520 as a test #12520 was already fixed in HEAD. Adding a test to make sure it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 07:07:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 07:07:52 -0000 Subject: [GHC] #12525: Internal identifiers creeping into :show bindings In-Reply-To: <044.1bd8a372e3005251359006b86de7988e@haskell.org> References: <044.1bd8a372e3005251359006b86de7988e@haskell.org> Message-ID: <059.5d7087ec1d12b0f9203d6a6a6e9729ef@haskell.org> #12525: Internal identifiers creeping into :show bindings -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ugh. The underlying problem is that the GHCi `InteractiveContext` doesn't make a proper distinction between * things lexically in scope (`ic_rn_gbl_env :: GlobalRdrEnv`) * things that the typechecker might need (`ic_tythings :: [TyThing]`) Instead the former is (more or less, I think) generated from the latter. But that's problematic for these internal identifiers. We came across this before: #11051. Easiest fix is to use the same solution for `showBindings`, namely to use `isDerivedOccName` to filter out the internal ones. See `Note [What to show to users]` in `InteractiveEval.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 07:40:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 07:40:54 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.d9c844af86e2e50f23aabab752e20cb1@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @simonpj the .gitmodules changes are because the diff on phabricator includes changes to submodules, and to avoid having to push to the upstream for those submodules it's necessary to fork the repos and point the .gitmodules file at your fork for the purposes of uploading the patch to phabricator. The idea is that before pushing the final patch, you revert the .gitmodules changes and push the necessary submodule changes to the relevant upstream repos. I've been encouraging @bgamari and @austin to document this (slightly complex) workflow on the wiki, it really needs to go here: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 09:28:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 09:28:49 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.0d0b25b7e501834e755c2dd6191eba3f@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Good catch. Simon, I think the answer to your question is that you can't construct that example, because compiled code cannot depend on interpreted code. Still, we should really respect the pointer tagging invariants both in compiled and interpreted code, so I agree this is a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 09:35:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 09:35:19 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.ba2ac2cb88e94510fda4c14baf895739@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): In general, this ticket is mostly about how we combine multiple databases. The existing behavior wrt a single database scope seems to be fine. Since stack does not install multiple instances with the same package name in the same db it does not matter what is picked in that case. In general I guess picking the latest version and any IPID should be fine. What you described wrt `exposed` makes sense to me. Though it does not matter for my use case. Also, the behavior of `-package` as you described is exactly what is required. The point of erroring out is to make sure we always have a reliable behavior. We should control the behavior rather than GHC doing it automatically without us even knowing about it. If a broken package comes in the way we have to report error. If we say `-package base` we pick it from the topmost db that has it whether it is broken or not. If it is broken we say so. Same for `-package pkg-1.0`. Within a given db scope, again it does not matter for my use case so we can use the usual rule of latest non-broken package. In general one can imagine the following package db policy flags to control the behavior more flexibly: * `--allow-multiple-ipid`: default is to error on detecting ipid conflict * `--ignore-broken-pkgs`: default is to error on encountering broken packages. * `--allow-multiple-versions`: default is to error on detecting multiple versions Defaults can be changed but keeping strict defaults may be better for reliable behavior. These flags in addition to stacking (`--stacked-pkg- dbs`) or unioning combining policy will create a fully flexible system. All the above flags always apply to a single db scope. When stacking is in effect then across dbs stacking rules will apply (i.e. top db prevails) and in a single db scope these flags will apply. When unioning is in effect all the dbs are combined into one and these flags are applied to the combined db. Though I am not sure if it is worth implementing all of this. This scheme answers some of your questions elegantly because now we do not worry about what is the correct default. For example what do we do if a top db has a broken package but a lower one has a working one. If `--ignore-broken-pkgs` is specified then we will ignore the top and go ahead and use the lower one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 09:59:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 09:59:15 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.afc02d54e815f0198c78f00f15f5fbd1@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Replying to [comment:1 simonpj]: The whole problem lies in the code assigned to the `Y` constructor. When ghci uses `X` it uses the compiled info table and entry code so no problem arises. Indeed this bug is impossible to trigger without unsafeCoerce or other questionable functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 10:17:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 10:17:51 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.5b92bc3e28e49a2c9bf901d41f052e86@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by harendra: @@ -36,6 +36,19 @@ - option is used GHC will use `GHC_PACKAGE_PATH` or the -package-db options - as a stack of dbs. The first db in the path or the first CLI option will - be considered the top of the stack. GHC will choose a package from the - first db from the top of the stack irrespective of the version of the - package. If the package is broken it should report error rather than - silently choosing from the next db. + option is used GHC will use `GHC_PACKAGE_PATH` or the `-package-db` + options to specify a stack of dbs. The first db in the path or the last + CLI option will be considered the top of the stack. + + The default behavior of GHC is to union all databases whereas this feature + is about vertically stacking them. The following stacking rules will + apply: + + * GHC will search a package from top to bottom and stop at the first db in + which the package exists. + * If GHC is not looking for a specific version then it will stop at the + first db in which ANY version is found. + * It will ignore the hidden packages when searching, but `-package ` + will have the effect of unhiding all versions of ``. + * If there are multiple versions available in the same db then usual rules + of latest non-broken package will be used to select one. + * If the candidate package(s) found is broken it will not search further. + When a broken package is needed in compilation it will report an error. It + will not report errors in general when a broken package is encountered. New description: = Package Selection Across Multiple Package DBs = As explained by ezyang, when there are multiple package dbs, GHC chooses the packages to use in the following manner. I might have misunderstood so please correct me if I am wrong. * If there are multiple packages with different versions the latest non- broken version is chosen. * If the there are multiple packages with the same version the behavior is unspecified. * If there are multiple packages with the same installed package id (shadowing) then the one which comes first in `GHC_PACKAGE_PATH` or which comes last on command line (according to `-package-db` flags) will be used. = The Problem = The build tool `Stack` implements stacked package databases. It uses a base package database and then stacks another package database on top of it to customise it further without modifying. The behavior is such that the package db on top of the stack completely overrides the ones below. That means you choose a package from top of the stack even if the version is older. Stack implements this by passing explicit package-ids of the packages to GHC. This scheme works well for cabal projects where we know ALL the packages used by the project in advance. But it does not work for scripts run using runghc. In that case we do not know the packages required by the script in advance and therefore cannot pass the package-ids to GHC. That means we cannot make GHC use the packages in the right way. GHC will choose the latest version even though we want it to choose a possibly older version from the top of the db stack. = Proposed Solution = Implement a new CLI option, something like `--stacked-pkg-dbs`. If this option is used GHC will use `GHC_PACKAGE_PATH` or the `-package-db` options to specify a stack of dbs. The first db in the path or the last CLI option will be considered the top of the stack. The default behavior of GHC is to union all databases whereas this feature is about vertically stacking them. The following stacking rules will apply: * GHC will search a package from top to bottom and stop at the first db in which the package exists. * If GHC is not looking for a specific version then it will stop at the first db in which ANY version is found. * It will ignore the hidden packages when searching, but `-package ` will have the effect of unhiding all versions of ``. * If there are multiple versions available in the same db then usual rules of latest non-broken package will be used to select one. * If the candidate package(s) found is broken it will not search further. When a broken package is needed in compilation it will report an error. It will not report errors in general when a broken package is encountered. This will allow us to modify an immutable package db by stacking another db on top. Implementing this as a separate option will keep the existing behavior so as to remain backward compatible. This has been discussed in a stack issue on github [https://github.com/commercialhaskell/stack/issues/1957 here]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 11:42:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 11:42:44 -0000 Subject: [GHC] #12492: internal error: allocation of 1048608 bytes too large In-Reply-To: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> References: <044.af4fae4c5ac779f1d7011b4f9c9acb9d@haskell.org> Message-ID: <059.b79917d5a97031b9f28dff1911c30883@haskell.org> #12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: I believe this can be closed; and further discussion should happen at https://github.com/nomeata/ghc-heap-view/issues/10, as this is clearly a problem with the hack that is called `ghc-heap-view`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 11:42:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 11:42:48 -0000 Subject: [GHC] #12518: Allow customizing immutable package dbs by stacking In-Reply-To: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> References: <047.bac3816e881298bb423591aca78a9ee0@haskell.org> Message-ID: <062.b1747fb984a0bbf4c6bf0e84e74fc0a8@haskell.org> #12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): We can also add `--include-hidden-pkgs` to this list to address the handling of `exposed` flag that you raised. That will complete the whole story. If we combine these with the `environment file` it will become a powerful way to compose package databases and can be widely useful. Let me know what you think, does it make sense to make it so flexible? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 12:54:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 12:54:26 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.c4d83026983a6b17015d41d66dd69476@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ah. I suppose comment:40 was clear from the beginning, but your {{{ f :: Int -> ... helper :: Int => ... }}} (without bodies) confused me. Perhaps we can phrase your intent in terms of implicit parameters: a "type" (as opposed to a constraint) appearing left of `=>` is just like an implicit parameter with a distinguished name `""`. Now, understanding `with 3 $ with 4 $ ...` is easy: the `...` will have access to `4`, which shadows `3`. I'm not saying it would necessarily be ''implemented'' like implicit parameters, but our understanding of IPs can inform this new feature. As for your suggestion > if a function is ill-typed, try replacing the first -> with a =>. If this makes the function well-typed, adjust the error message accordingly. I'm afraid this would be hard to implement, because types can appear in so many different contexts. But here's an idea: We add a "validity" check -- something not really part of the type system -- that looks for types like `Ord a -> a -> Set a`. The validity check will fail if it sees a type to the left of an `->` that is headed by a class. To disable the validity check, enable `-XExplicitDictionaries`. But the error message would suggest using `=>` more prominently than enabling `-XExplicitDictionaries`! This validity check might not catch all cases all the time, but it would catch the common newbie error Edward brought up. Thinking about `Int =>` as a special implicit parameter makes this more palatable to me, somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 13:04:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 13:04:05 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families Message-ID: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following bug is present in ghc-8.0.1.20160725, ghc-8.0.1.20160822 (ghc-8.0.2) and ghc-8.1.20160819 (ghc-head) and was not there in ghc-8.0.1. When compiling the head version of synthesizer-llvm package from http://code.haskell.org/synthesizer/llvm/ I get the following error: {{{ src/Synthesizer/LLVM/Server/CausalPacked/Instrument.hs:296:23: error: • Couldn't match type ‘Synthesizer.Causal.Class.ProcessOf t0’ with ‘CausalP.T (SampleRate Real, ())’ Expected type: CausalP.T (SampleRate Real, ()) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)), (Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Real, VectorValue)) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float))) Actual type: Synthesizer.Causal.Class.ProcessOf t0 (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)), (Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float, Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float))) The type variable ‘t0’ is ambiguous • In the first argument of ‘($&)’, namely ‘osci’ In the second argument of ‘liftA2’, namely ‘(osci $& shapeCtrl &|& (expo &|& fmap Stereo.left freqs))’ In the expression: liftA2 Stereo.cons (osci $& shapeCtrl &|& (expo &|& fmap Stereo.left freqs)) (osci $& shapeCtrl &|& (negate expo &|& fmap Stereo.right freqs)) • Relevant bindings include osci :: Synthesizer.Causal.Class.ProcessOf t0 (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)), (Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float, Serial.Value (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float)) (Serial.T (LLVM.Value (LLVM.Vector (TypeNum.Pos Type.Data.Num.Decimal.Digit.Dec4 TypeNum.EndDesc) Float))) (bound at src/Synthesizer/LLVM/Server/CausalPacked/Instrument.hs:294:19) }}} The type for `t0` should be known and then the type checker should be able to check that `ProcessOf t0` equals `CausalP.T`. It did so in earlier versions but now fails on that part. I still have to reduce that example, but for now I want to alert you that there seems to be a regression in the type inference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 13:12:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 13:12:22 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.7377d53ab8af6a3c51ed10a2eb473034@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 13:22:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 13:22:07 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.0de42d1729fa3fbef279cef1e2417476@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The whole problem lies in the code assigned to the Y constructor. When ghci uses X it uses the compiled info table and entry code so no problem arises. Ah, I see. Yes, if the `Y` constructor doesn't return a properly tagged result, any compiled code consuming `Y` values is going to seg-fault. Hence the need for `unsafeCoerce` to trigger the bug. Normally if `data Y = Y String` was interpreted then so is every function that consumes Y values. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 13:35:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 13:35:14 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.32f41718123bd788d5cbd8f10b1eec6e@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Replying to [comment:41 goldfire]: > Now, understanding `with 3 $ with 4 $ ...` is easy: the `...` will have access to `4`, which shadows `3`. I am very suspicious about shadowing semantics. I'd rather see `Int` treated like any other constraint, no different than `Given Int`. We don't have shadowing semantics for `Given Int`: the example from comment:24 demonstrates that the first dictionary was picked, not the second one (and this behavior can change with a minor compiler version). Once again, it moves us further down the road where we admit that there can be more than one value of one type to the left of `=>`. There shouldn't be. Well-defined semantics for using nested `incoherentWith` will encourage people to do so. In Edward's parlance, the `Constraint` category is thin; let's not change it. I also couldn't find any mention of shadowing in the "Implicit parameters" section of the GHC user guide. Could you point me where I can read how it gets resolved? As far as I know, implicit parameters use the `IP` class under the hood, but GHC seems to consistently choose the innermost binding (in contrast to `Given`, where the outermost binding prevails): {{{#!hs GHCi, version 8.1.20160813: http://www.haskell.org/ghc/ :? for help Prelude> :set -XImplicitParams Prelude> :set -XGADTs Prelude> data X where X :: (?x :: Int) => X Prelude> f :: X -> X -> Int; f X X = ?x Prelude> f (let ?x = 1 in X) (let ?x = 2 in X) 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 14:22:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 14:22:00 -0000 Subject: [GHC] #11702: Constant folding on 'mod/Word' - incorrect result In-Reply-To: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> References: <045.42a7a89d3dbc3f7a7dab4e9397e0d0a6@haskell.org> Message-ID: <060.9ec304856f7efce1d56e65857be2705a@haskell.org> #11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Prelude | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2004 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hjarvi): On my x64 the given test case goes through without a problem on GHC7.10 and GHC8.0, but I find a more effective test case to be (produces "5 0" on GHC7.10.3 and GHC8.0.0.20160302. The correct result "0 0" is produced by GHC 7.6.3 and GHC 8.0.1.20160822): {{{ -- -*- haskell -*- module Main ( main ) where import Data.IORef import Data.Word main = do i <- newIORef (5 :: Word) >>= readIORef print $ i `mod` 1 print $ (5 :: Word) `mod` 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 14:35:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 14:35:10 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.f8533e53665499b606b7ff27005414a3@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): It is pretty strange: If I compile synthesizer-llvm in one go then it can be compiled by ghc-8.0.1. Then I alter the problematic module (update of date is enough), re-compile, and now surprisingly also ghc-8.0.1 produces the same error message. That is, the error already existed in ghc-8.0.1 but was not always triggered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 14:39:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 14:39:44 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.369ad0c9c646ef40ceff3434dfbac58c@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: niteria (added) Comment: It seems that this might be related to the work that Bartosz has done in making GHC more deterministic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 14:44:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 14:44:15 -0000 Subject: [GHC] #12477: Allow left sectioning and tuple sectioning of types In-Reply-To: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> References: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> Message-ID: <066.dbc919375b3761c030eaa55188016911@haskell.org> #12477: Allow left sectioning and tuple sectioning of types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): In the wild [https://www.reddit.com/r/haskell/comments/4z28nk/tear_down_cofree/d6sbmwr wild]: > For example, if you have a stream of values, `given by Cofree (, a)`, then you can use the free monad for `(a ->)` to extract a value at some index. At each step, you can either `return` a function to extract a value from the current position in the comonad, or `liftF` a function which tells you how to handle the next value in the stream. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 14:56:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 14:56:55 -0000 Subject: [GHC] #12527: GHC segfault while linking llvm-general while compiling a file using Template Haskell Message-ID: <048.fbe4473a110464991c2c11f9a72d9f54@haskell.org> #12527: GHC segfault while linking llvm-general while compiling a file using Template Haskell -------------------------------------+------------------------------------- Reporter: HMPerson1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I have a file {{{#!hs -- Lib.hs module Lib where [d| foo = 1 |] }}} and I add `llvm-general` as a dependency, compiling with -v yields the attached log, followed by `segmentation fault (core dumped)`. Investigating with gdb, the back trace is {{{ ... Loading package llvm-general-3.5.1.2 ... linking ... Thread 1 "ghc" received signal SIGSEGV, Segmentation fault. 0x000000004490f604 in ?? () (gdb) bt #0 0x000000004490f604 in ?? () #1 0x0000000044a8798d in ?? () #2 0x0000000000000132 in ?? () #3 0x0000000044a98b38 in ?? () #4 0x0000000044a87b30 in ?? () #5 0x00007fffeed667b1 in ocRunInit_ELF (oc=0xf7f520) at rts/Linker.c:6198 #6 resolveObjs_ () at rts/Linker.c:3196 #7 resolveObjs () at rts/Linker.c:3218 #8 0x00007ffff5eb03a3 in ?? () from /home/michael/.stack/programs/x86_64-linux/ghc-7.10.3/lib/ghc-7.10.3/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/libHSghc-7.10.3 -0AG9TOjDEtx4Ji3wSwHOBe-ghc7.10.3.so #9 0x0000000000000000 in ?? () }}} Note that without the quasi-quotation in `Lib.hs` it will compile fine, and without the `llvm-general` dependency it will also compile fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 14:57:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 14:57:20 -0000 Subject: [GHC] #12527: GHC segfault while linking llvm-general while compiling a file using Template Haskell In-Reply-To: <048.fbe4473a110464991c2c11f9a72d9f54@haskell.org> References: <048.fbe4473a110464991c2c11f9a72d9f54@haskell.org> Message-ID: <063.8df03e1c11ea38925015e05299278591@haskell.org> #12527: GHC segfault while linking llvm-general while compiling a file using Template Haskell -------------------------------------+------------------------------------- Reporter: HMPerson1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by HMPerson1): * Attachment "crash.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 15:32:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 15:32:26 -0000 Subject: [GHC] #11068: Make Generic/Generic1 methods inlinable In-Reply-To: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> References: <044.2644399b8f2d6a8d61669300e8f810a3@haskell.org> Message-ID: <059.85ae5716a5495c606f05e9ed55887176@haskell.org> #11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Generics, | newcomer, Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sweirich): * cc: sweirich (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 16:22:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 16:22:54 -0000 Subject: [GHC] #12528: ghc: panic! while cimpiling Message-ID: <043.95585e35b9a89b0e6db0a39510a03c5d@haskell.org> #12528: ghc: panic! while cimpiling -------------------------------------+------------------------------------- Reporter: nek0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While building one of my projects, GHC crashes with the following message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): find_tycon Block [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The project I'm trying to build can be found at https://github.com/nek0/eidolon. The file it crashes at is called `Foundation.hs` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 16:23:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 16:23:33 -0000 Subject: [GHC] #12528: ghc: panic! while compiling (was: ghc: panic! while cimpiling) In-Reply-To: <043.95585e35b9a89b0e6db0a39510a03c5d@haskell.org> References: <043.95585e35b9a89b0e6db0a39510a03c5d@haskell.org> Message-ID: <058.10052a2ff9a93c41549c8d031c54e238@haskell.org> #12528: ghc: panic! while compiling -------------------------------------+------------------------------------- Reporter: nek0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 16:32:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 16:32:02 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.0a1f9846bde26f1c8cc9d98f5d1e8584@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): > It seems that this might be related to the work that Bartosz has done in making GHC more deterministic. > That is, the error already existed in ghc-8.0.1 but was not always triggered. Most of the determinism patches were merged *after* ghc-8.0.1, so it sounds unlikely. My best bet would be that some exposed thing isn't recorded in the interface file. Lemming: Can you provide step by step repro? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 16:41:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 16:41:54 -0000 Subject: [GHC] #12528: ghc: panic! while compiling In-Reply-To: <043.95585e35b9a89b0e6db0a39510a03c5d@haskell.org> References: <043.95585e35b9a89b0e6db0a39510a03c5d@haskell.org> Message-ID: <058.5b5ca42d35e017bb721a6203e742c369@haskell.org> #12528: ghc: panic! while compiling -------------------------------------+------------------------------------- Reporter: nek0 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: Dup of #12130 almost certainly. Do re-open if not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 16:48:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 16:48:19 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.67688c8d273c26e7d562a6398c9746f2@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * related: => 10634 Comment: Replying to [comment:4 niteria]: > > It seems that this might be related to the work that Bartosz has done in making GHC more deterministic. > > > That is, the error already existed in ghc-8.0.1 but was not always triggered. > > Most of the determinism patches were merged *after* ghc-8.0.1, so it sounds unlikely. Why? GHC-8.0.1 showed the error sometimes, GHC-8.0.2 shows it always. mpickering's guess matches perfectly. > Lemming: Can you provide step by step repro? I am currently reducing the example. It looks like another instance of the fake injective type functions problem. https://ghc.haskell.org/trac/ghc/ticket/10634 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 16:55:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 16:55:56 -0000 Subject: [GHC] #12527: GHC segfault while linking llvm-general while compiling a file using Template Haskell In-Reply-To: <048.fbe4473a110464991c2c11f9a72d9f54@haskell.org> References: <048.fbe4473a110464991c2c11f9a72d9f54@haskell.org> Message-ID: <063.0227a8400ff494bee3c0c5e400a17abc@haskell.org> #12527: GHC segfault while linking llvm-general while compiling a file using Template Haskell -------------------------------------+------------------------------------- Reporter: HMPerson1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): It looks like a bug in the ghci linker. As a workaround I suggest you try building llvm-general with its cabal flag `-fshared-llvm`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 17:00:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 17:00:14 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.a6f05e7bf718affc54ab593eff4bc5ed@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * Attachment "InjectiveInference.hs" added. A minimal self-contained example demonstrating the problem -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 17:05:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 17:05:51 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.8336ba153977aab54c5c0b44fbcdeffe@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): The `let` in `ping` is essential for triggering the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 17:29:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 17:29:08 -0000 Subject: [GHC] #12527: GHC segfault while linking llvm-general while compiling a file using Template Haskell In-Reply-To: <048.fbe4473a110464991c2c11f9a72d9f54@haskell.org> References: <048.fbe4473a110464991c2c11f9a72d9f54@haskell.org> Message-ID: <063.a543402ee2faa39250fb9df4587feaf1@haskell.org> #12527: GHC segfault while linking llvm-general while compiling a file using Template Haskell -------------------------------------+------------------------------------- Reporter: HMPerson1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I could reproduce this just by running `ghci -package llvm-general`. What's going on here is that the ghci linker is loading an archive that contains two object files, let's call them `A.o` and `B.o`. For whatever reason ghci processes `A.o` before `B.o`. Now `A.o` has an `.init_array` section that contains a function that eventually calls a function defined in `B.o`. The problem is that `resolveObjs_` works like this: for each object file, resolve its relocations and then run its initializers so `B.o` hasn't had its relocations resolved when the initializer of `A.o` runs and tries to call a function defined in `B.o`. Seems like it should instead work like this: for each object file, resolve its relocations for each object file, run its initializers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 18:30:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 18:30:39 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter In-Reply-To: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> References: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> Message-ID: <061.fe45393a878b3dd2ef7b3374b505f239@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11466 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): It says this should be rejected {{{#!hs -- But this should be rejected instance Bla => Eq T }}} but should this be allowed? {{{#!hs instance ?x::Int => Eq T }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 20:11:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 20:11:30 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.13e5e02a2987c76475b7c1d1371a9424@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Nice catch @mniip. Just to understand the problem here: Entry code for the constructor is correct, but the allocator should have marked the pointer, right? So the real problem is not InfoTable.hsc:32. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 20:34:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 20:34:17 -0000 Subject: [GHC] #12514: Can't write unboxed sum type constructors in prefix form In-Reply-To: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> References: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> Message-ID: <065.a25cbc85ccbc5f837a5e7a674084dc41@haskell.org> #12514: Can't write unboxed sum type constructors in prefix form -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"613d745523f181991f6f916bbe58082b7970f7e6/ghc" 613d7455/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="613d745523f181991f6f916bbe58082b7970f7e6" Template Haskell support for unboxed sums This adds new constructors `UnboxedSumE`, `UnboxedSumT`, and `UnboxedSumP` to represent unboxed sums in Template Haskell. One thing you can't currently do is, e.g., `reify ''(#||#)`, since I don't believe unboxed sum type/data constructors can be written in prefix form. I will look at fixing that as part of #12514. Fixes #12478. Test Plan: make test TEST=T12478_{1,2,3} Reviewers: osa1, goldfire, austin, bgamari Reviewed By: goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2448 GHC Trac Issues: #12478 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 20:34:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 20:34:17 -0000 Subject: [GHC] #12478: Template Haskell support for unboxed sums In-Reply-To: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> References: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> Message-ID: <065.410c7bf4d91c1d47f2f66ab7eb45d8fe@haskell.org> #12478: Template Haskell support for unboxed sums -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.1 Resolution: | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2448 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"613d745523f181991f6f916bbe58082b7970f7e6/ghc" 613d7455/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="613d745523f181991f6f916bbe58082b7970f7e6" Template Haskell support for unboxed sums This adds new constructors `UnboxedSumE`, `UnboxedSumT`, and `UnboxedSumP` to represent unboxed sums in Template Haskell. One thing you can't currently do is, e.g., `reify ''(#||#)`, since I don't believe unboxed sum type/data constructors can be written in prefix form. I will look at fixing that as part of #12514. Fixes #12478. Test Plan: make test TEST=T12478_{1,2,3} Reviewers: osa1, goldfire, austin, bgamari Reviewed By: goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2448 GHC Trac Issues: #12478 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 20:34:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 20:34:17 -0000 Subject: [GHC] #12458: Segfault in GHCi runtime type reconstruction In-Reply-To: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> References: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> Message-ID: <059.84c5eba6cac4993aff9bf074a29162ec@haskell.org> #12458: Segfault in GHCi runtime type reconstruction -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2439 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1766bb3cfd1460796c78bd5651f89d53603586f9/ghc" 1766bb3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1766bb3cfd1460796c78bd5651f89d53603586f9" RtClosureInspect: Fix off-by-one error in cvReconstructType Replaced error-prone index manipulation on a pointer array with a simple fold on the array elements. Test Plan: Added a test case that triggers the bug Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2439 GHC Trac Issues: #12458 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 20:36:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 20:36:52 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.9669445c8d8a369bcb8af3e01b0b1de0@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Perhaps the user guide is deficient with regard to implicit parameter shadowing. Maybe it's not even reliable -- I'm not sure. As for your first paragraph, I'm not convinced yet: `Int` is not like any other constraint, in that it's not a class. In GHC 8.0, we have a few forms of constraint: 1. Fully-applied classes 2. Implicit parameters 3. Tuples (which is actually special syntax for (1)) 4. Equality constraints 5. Other built-in constraints (`Coercible`, `Typeable`, are there more?) 6. Type families and synonyms which produce constraints You are advocating for something new: 7. Other Haskell types We thus can choose how to handle case (7) independently of how we handle other constraints, just like (2) has different "shadowing" behavior than (1). So `Int` will always be different from `Given Int`, and I think that's OK. As long as implicit parameters are around, then we've already lost the thinness of constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 20:39:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 20:39:55 -0000 Subject: [GHC] #11466: Constraint synonym with Implicit Parameter In-Reply-To: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> References: <046.f75a0dfb23c31b8e4f3fc93cd04e89d3@haskell.org> Message-ID: <061.781d2bddcf261a75e7de5c03d6a3392c@haskell.org> #11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11466 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): {{{ instance ?x::Int => Eq T }}} No it should not be allowed! Instances are resolved in unpredicatable places, which is incompatible with knowing exactly which `?x` is used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 21:47:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 21:47:21 -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.21b1e75e47a9aecd42f417eba0c835d0@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:54 simonmar]: > @slyfox the GC threads all spin in this `any_work()` loop looking for work they can steal from other threads. It's how the GC work gets distributed amongst the available worker threads. Aha, thanks! I've read through http://community.haskell.org/~simonmar/papers/parallel-gc.pdf The paper does not look outdated. The crucial detail: work stealing is enabled by default for gen=1 and upper. As default nursery is tiny we don't do stealing from it. That's why I see poor GC parallelism on large nurseries for this compilation workload: [ The numbers below are for 4-CPU system, not 8-CPU i used to post before. I'll redo tests in a few days once I get access to it. ] -qb1/-qb0 comparison: -qb1 (default): {{{ $ time ./mk.bash -j4 +RTS -N4 -RTS +RTS -sstderr -A768M -RTS -O0 -j4 +RTS -l 55,162,983,632 bytes allocated in the heap 639,999,688 bytes copied during GC 88,807,552 bytes maximum residency (2 sample(s)) 4,100,072 bytes maximum slop 3379 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 20 colls, 20 par 5.617s 1.582s 0.0791s 0.1410s Gen 1 2 colls, 1 par 0.227s 0.081s 0.0405s 0.0500s Parallel GC work balance: 22.34% (serial 0%, perfect 100%) TASKS: 13 (1 bound, 12 peak workers (12 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.027s ( 0.026s elapsed) MUT time 59.245s ( 18.963s elapsed) GC time 5.843s ( 1.663s elapsed) EXIT time 0.032s ( 0.034s elapsed) Total time 65.174s ( 20.686s elapsed) Alloc rate 931,102,797 bytes per MUT second Productivity 91.0% of total user, 91.8% of total elapsed gc_alloc_block_sync: spin=10830; yield=5 whitehole_spin: 0 gen[0].sync: spin=6297; yield=5 gen[1].sync: spin=4240; yield=3 real 0m20.863s user 1m5.752s sys 0m4.724s }}} -qb0: {{{ 55,154,416,472 bytes allocated in the heap 840,077,056 bytes copied during GC 135,018,976 bytes maximum residency (3 sample(s)) 5,739,552 bytes maximum slop 2375 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 31 colls, 31 par 3.078s 0.859s 0.0277s 0.0682s Gen 1 3 colls, 2 par 0.607s 0.177s 0.0591s 0.0947s Parallel GC work balance: 74.48% (serial 0%, perfect 100%) TASKS: 13 (1 bound, 12 peak workers (12 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.023s ( 0.023s elapsed) MUT time 59.476s ( 18.325s elapsed) GC time 3.685s ( 1.036s elapsed) EXIT time 0.027s ( 0.028s elapsed) Total time 63.244s ( 19.412s elapsed) Alloc rate 927,345,481 bytes per MUT second Productivity 94.1% of total user, 94.5% of total elapsed gc_alloc_block_sync: spin=58847; yield=38 whitehole_spin: 0 gen[0].sync: spin=126024; yield=104 gen[1].sync: spin=34648; yield=31 real 0m19.575s user 1m6.804s sys 0m1.760s }}} Note how GC parallelism increases from ~20% to ~75% for this huge nursery of 768M. Something hinders mutator's parallelism still. threadscope says threads are usually blocked on MVars for long periods of time (order of 0.1-0.2 seconds). Perhaps those wait for external gcc/gas to assemble modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 22:03:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 22:03:21 -0000 Subject: [GHC] #12507: Can't deduce implicit parameter In-Reply-To: <051.55756e2de2f8b649cd84d740d6b1fdee@haskell.org> References: <051.55756e2de2f8b649cd84d740d6b1fdee@haskell.org> Message-ID: <066.d1021f65065b4b4fdea9b186244e8cd3@haskell.org> #12507: Can't deduce implicit parameter -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Works with `Given` from reflection: {{{#!hs record :: Rec (Given Int, Given String) record = give (1::Int) (give "hi" Rec) access :: Int access = record ? given @Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 22:04:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 22:04:05 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.ef85c932b010f4048f221d123c0ea136@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): This reproduces in HEAD (from Aug 9) with: {{{ InjectiveInference.hs:35:8: error: • Couldn't match type ‘ProcessOf t0’ with ‘Causal’ Expected type: Causal Float Float Actual type: ProcessOf t0 Float Float The type variable ‘t0’ is ambiguous • In the first argument of ‘($&)’, namely ‘osci’ In the expression: osci $& frequencies In the expression: let osci = shapeModOsci in osci $& frequencies • Relevant bindings include osci :: forall y. ProcessOf t0 Float y (bound at InjectiveInference.hs:34:8) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 23:16:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 23:16:45 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.7a6f8ac05c476ec42e8cec807dfdd92a@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Adding: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE FlexibleContexts #-} }}} produces a different message: {{{ InjectiveInference.hs:36:8: error: • Could not deduce: ProcessOf t0 ~ ProcessOf t from the context: CausalProcess (ProcessOf t) bound by the inferred type for ‘osci’: CausalProcess (ProcessOf t) => ProcessOf t Float y at InjectiveInference.hs:36:8-26 Expected type: ProcessOf t Float y Actual type: ProcessOf t0 Float y NB: ‘ProcessOf’ is a type function, and may not be injective The type variable ‘t0’ is ambiguous • In the ambiguity check for the inferred type for ‘osci’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type osci :: forall y (t :: * -> *). CausalProcess (ProcessOf t) => ProcessOf t Float y In the expression: let osci = shapeModOsci in osci $& frequencies }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 23:16:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 23:16:52 -0000 Subject: [GHC] #3314: Add compilation date to +RTS --info In-Reply-To: <044.ba2b5095895a2d1777a79a9b191f08e5@haskell.org> References: <044.ba2b5095895a2d1777a79a9b191f08e5@haskell.org> Message-ID: <059.28757eb572f4925e8af3fa7b5c8d618b@haskell.org> #3314: Add compilation date to +RTS --info -------------------------------------+------------------------------------- Reporter: Orphi | Owner: ak3n Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.10.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * status: new => closed * differential: Phab:D2460 => * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 23 23:19:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Aug 2016 23:19:04 -0000 Subject: [GHC] #3314: Add compilation date to +RTS --info In-Reply-To: <044.ba2b5095895a2d1777a79a9b191f08e5@haskell.org> References: <044.ba2b5095895a2d1777a79a9b191f08e5@haskell.org> Message-ID: <059.32a8cbb6bd19bb35b42dbf61c36c2737@haskell.org> #3314: Add compilation date to +RTS --info -------------------------------------+------------------------------------- Reporter: Orphi | Owner: ak3n Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.10.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ak3n): Since there is no so much need for such feature, ticket is closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 07:17:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 07:17:52 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.f3e7811a8c01a4fb3a9140d5979a9904@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): A problem with transparently passing unrecognized flags to ghc is a very confusing and hard to understand behavior like this: {{{ runghc -package text-1.2.2.1 hello.hs text-1.2.2.0:1:74: Not in scope: ‘main’ Perhaps you meant ‘min’ (imported from Prelude) }}} What happened here is that runghc passed `-package` option to ghc but it did not pass text-1.2.2.0 which is being treated as the program name. This happens because of different ways to pass `-package` and its argument. So we will have to use `--ghc-arg=` for the arg like this: {{{ runghc -package --ghc-arg=text-1.2.2.1 hello.hs hello }}} If we had the same way to pass both the flag and the argument we won't have this very confusing behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 07:30:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 07:30:57 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.d14bc01a0f5857fed780d7b9af561371@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here is a yet simpler version of the problem {{{ {-# LANGUAGE TypeFamilies, MonoLocalBinds #-} module T12526 where type family P (s :: * -> *) :: * -> * -> * type instance P Signal = Causal type family S (p :: * -> * -> *) :: * -> * type instance S Causal = Signal class (P (S p) ~ p) => CP p instance CP Causal data Signal a = Signal data Causal a b = Causal shapeModOsci :: CP p => p Float Float shapeModOsci = undefined f :: Causal Float Float -> Bool f = undefined -- This fails ping :: Bool ping = let osci = shapeModOsci in f osci -- This works -- ping :: Bool -- ping = f shapeModOsci }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 07:45:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 07:45:29 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.2d6b733edfb733771460273a4211aa3e@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I spent some time finding out what is going on here. * We typecheck the binding for `osci` with generalisation (despite `NoMonoBinds`) because the RHS has no locally-bound free variables. * But `osci` triggers the monomorphism restriction because of the `(CP t)` constraint. * So from `osci`s binding we initially get (where `pp` is a unification variable) {{{ osci :: pp Float Float Constraints: CP pp }}} * However, during inference of `osci`'s type we try to simplify those constraints (`simplifyInfer`). So we get {{{ [W] CP pp --> add derived superclass constraints [W] CP pp [D] pp ~ P (S pp) But we flatten those constraints to get --> flatten (the fuv1/2 are flatten-meta-vars) [W] CP pp [D] pp ~ fuv1 [D] S pp ~ fuv2 (CFunEqCan) [D] P fuv2 ~ fuv1 (CFunEqCan) --> Now (here is the problem) we unify pp := fuv1 [W] CP fuv1 [D] S fuv1 ~ fuv2 (CFunEqCan) [D] P fuv2 ~ fuv1 (CFunEqCan) --> Nothing further happens, so we unflatten to get fuv1 := P fuv2 [W] CP (P fuv2) [D] P (S fuv2) ~ fuv2 Discarding the derived constraint we have ended up with osci :: P fuv2 Float Float Constaints: CP (P fuv2) }}} * But replacinng `pp := P fuv2` is bad, because in the call `f osci`, we now get {{{ [W] Causal Float Float ~ P fuv2 Float Float }}} which leads to `P fuv2 ~ Causal`, which doesn't tell us how to choose `fuv2`. If we had only left it alone, we'd have had {{{ [W] Causal Float Float ~ pp Float Float }}} which tells us `p := Causal` and everything gets solved. I have not investigated why it worked before, but it's clearly terribly delicate. For now I'm just recording the breadcrumbs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 08:27:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 08:27:37 -0000 Subject: [GHC] #12444: Regression: panic! on inaccessible code with constraint In-Reply-To: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> References: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> Message-ID: <060.ef4f9bdcf9e114a6874b4ebef4565ece@haskell.org> #12444: Regression: panic! on inaccessible code with constraint -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I spent some time investigating. Here's a smaller test case. This program, closely related to the original, makes the constraint solver loop: {{{ data Nat = Zero | Succ Nat data SNat (n :: Nat) type family (:+:) (a :: Nat) (b :: Nat) :: Nat where m :+: Zero = m m :+: (Succ n) = Succ (m :+: n) foo :: SNat (Succ c) -> SNat b -> SNat (Succ (c :+: b)) foo _ x = x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 08:32:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 08:32:51 -0000 Subject: [GHC] #12444: Regression: panic! on inaccessible code with constraint In-Reply-To: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> References: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> Message-ID: <060.be9b4462b7c0cf91ee7359aafcc41a31@haskell.org> #12444: Regression: panic! on inaccessible code with constraint -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here’s a slightly simpler example {{{ type instance F (Succ x) = Succ (F x) [W] alpha ~ Succ (F alpha) }}} Solving the constraint goes like this: {{{ Flatten: [W] alpha ~ Succ fuv (CTyVarEq) [W] F alpha ~ fuv (CFunEqCan) Unify alpha := Succ fuv; there’s no occurs check here; and substitute in the other constraint [W] F (Succ fuv) ~ fuv (CFunEqCan) Now we can fire the rule (hooray?) [W] Succ (F fuv) ~ fuv }}} Normally we’d declare at this point that we have figured out what `fuv` is, so we call `dischargeFmv` to update it in place. But we don’t want to unify `fuv := Succ (F fuv)` because that’s makes an infinite type. So instead we turn the fuv into an ordinary unification variable beta, thus `fuv := beta`. So now we have {{{ [W] Succ (F beta) ~ beta }}} And lo, that’s exactly what we started with, so the whole process iterates. This is terrible. It’s a kind of occurs-check loop, but it goes via function call. If we didn’t do flattening we’d have `[W] alpha ~ Succ (F alpha)`, which is an occurs check, so we would not substitute for alpha. Instead we put such occurs-check equalities aside in the “insoluble”. But we do flatten! Of course this example isn’t soluble, but this variant is: {{{ type instance F (Succ a) = Zero [W] alpha ~ Succ (F alpha) }}} Now if we flatten, unify alpha we get {{{ [W] F (Succ fuv) ~ fuv }}} Now fire the rule, and we get {{{ Zero ~ fuv }}} Which is a fine solution. However I would not be too bothered if we didn’t find it. So what should we do? Its bad bad bad for the solver to diverge: note that the type family instance for `F` is perfectly nice. I wasted an entire evening thinking about and trying several ideas, none of which worked. One possibility I didn’t try is to beef up the “occurs check” so that when seeing if `a ~ ty` has an occurs check, we unflatten on-the-fly to see if `a` occurs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 08:33:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 08:33:12 -0000 Subject: [GHC] #12444: Regression: panic! on inaccessible code with constraint In-Reply-To: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> References: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> Message-ID: <060.259d986ca50cea2383e1cb277424da06@haskell.org> #12444: Regression: panic! on inaccessible code with constraint -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Related: #12526 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 08:33:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 08:33:32 -0000 Subject: [GHC] #12444: Regression: panic! on inaccessible code with constraint In-Reply-To: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> References: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> Message-ID: <060.6a38ac50c8d7fb61760adbf0590f8699@haskell.org> #12444: Regression: panic! on inaccessible code with constraint -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12526 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: => #12526 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 08:59:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 08:59:17 -0000 Subject: [GHC] #12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies In-Reply-To: <044.06f71dc396e1085735f13966136f6b82@haskell.org> References: <044.06f71dc396e1085735f13966136f6b82@haskell.org> Message-ID: <059.dfe6b12c8c1b10a21dc36774a6f80809@haskell.org> #12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies -------------------------------------+------------------------------------- Reporter: dylex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But we ''do'' call a function with the type given by the generic default signature! In effect the generic-default declaration gives rise to a definition {{{ $gdm_bar :: forall a b. (Bar a b, Foo a b) => b -> Int $gdm_bar b = foo (get b :: a) b }}} In an instance declaration where you do not give a declaration for `bar`, we fill in with this generic default method. That is {{{ instance blah => Bar t1 t2 where {} }}} becomes {{{ instance blah => Bar t1 t2 where bar = $gdm_bar }}} If the type of `$gdm_bar` was ambiguous, this really would be a problem. But in this case it isn't! I'll investigate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 09:15:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 09:15:14 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.93d9bf92cf32b80d8040738fbb6cf43e@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:9 simonpj]: > Here is a yet simpler version of the problem Thank you for the simplification! I guess we can also drop the type parameters of `Signal` and `Causal`. For now I have solved the problem in my package by adding type signatures to the let binding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 09:16:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 09:16:43 -0000 Subject: [GHC] #12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies In-Reply-To: <044.06f71dc396e1085735f13966136f6b82@haskell.org> References: <044.06f71dc396e1085735f13966136f6b82@haskell.org> Message-ID: <059.47b69fbbb8349a4dc8623b0a04d4e251@haskell.org> #12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies -------------------------------------+------------------------------------- Reporter: dylex | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Happily, this is (I am almost certain) a dup of #12151, which is both fixed, and merged to the 8.0.2 branch. So worth checking that this works with 8.0.2, then close. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 09:50:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 09:50:58 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.94267cefded6bdfe5d549db1a2b7ad4a@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): The main difference is that while we've lost the thinness of constraints in this narrow area, nobody uses them as they are largely regarded as a terrible idea with clunky syntax and, far more importantly, you explicitly can't actually use them as super-classes, so the damage is currently quite well contained. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 10:36:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 10:36:34 -0000 Subject: [GHC] #12442: Pure unifier usually doesn't need to unify kinds In-Reply-To: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> References: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> Message-ID: <062.ca63b2fb10c5cc79b1a3f1c55ee17016@haskell.org> #12442: Pure unifier usually doesn't need to unify kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Status (see Phab:D2433 comment): Richard says: Please don't merge yet. When I validated, there were some hiccups, including around performance. IIRC, there were actually three performance improvements along with one regression, but I have to investigate properly. (A performance improvement is certainly not unexpected with this patch.) When I saw these problems, I prioritized other tasks, but will return to this eventually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 12:48:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 12:48:00 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.919d0cd9488f9a78ca5ef233b96fa62e@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Replying to [comment:5 osa1]: > Just to understand the problem here: Entry code for the constructor is correct, > but the allocator should have marked the pointer, right? Nope, the problem is that the entry code should have marked the pointer but it did not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 12:48:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 12:48:13 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.2b3e27b5cf9823a5a1fa460779209424@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * owner: => mniip -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 13:30:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 13:30:53 -0000 Subject: [GHC] #11179: Allow plugins to access "dead code" In-Reply-To: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> References: <045.edf87fb49745a83b7970370d7dccde2a@haskell.org> Message-ID: <060.e2a8e27172bbda93c81ea999be8f425c@haskell.org> #11179: Allow plugins to access "dead code" -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ak3n Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ak3n): Which solution is better? Move out dead code elimination from `simpleOptPgm` to later pass after plugins? Or add `KeepAlive` pragma with flags? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 14:30:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 14:30:46 -0000 Subject: [GHC] #12529: Error message: visible type application of constructor/variable that is not in scope Message-ID: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> #12529: Error message: visible type application of constructor/variable that is not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I use an identifier not in scope: {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> p :1:1: error: Variable not in scope: p Prelude> P :2:1: error: Data constructor not in scope: P }}} Using visible type application: {{{ $ ghci -ignore-dot-ghci -XTypeApplications GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> p @Int :1:1: error: • Cannot apply expression of type ‘t0’ to a visible type argument ‘Int’ • In the expression: p @Int In an equation for ‘it’: it = p @Int Prelude> P @Int :2:1: error: • Cannot apply expression of type ‘t0’ to a visible type argument ‘Int’ • In the expression: P @Int In an equation for ‘it’: it = P @Int }}} I would prefer these error messages to be the same as the first two: thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 14:34:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 14:34:36 -0000 Subject: [GHC] #12529: Error message: visible type application of constructor/variable that is not in scope In-Reply-To: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> References: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> Message-ID: <066.4f976fe078f2ec8e2e81c854ffcef5b4@haskell.org> #12529: Error message: visible type application of constructor/variable that is not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This gave me pause when I thought `Proxy` was in scope and tried applying to to a type variable `Proxy @s` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 14:51:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 14:51:26 -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.5efc6afeef12890a52cc9ba6474376b2@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Yes, perhaps we should default to -qb0 when -A is larger than some threshold. The mutator parallelism looks not too bad (3.24 out of 4). Was there enough parallelism in the program you were compiling to do better than that? The `MVar`s are probably just the compilation manager: it fires up a thread for every module, and they wait on the results of compiling the modules they depend on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 15:09:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 15:09:11 -0000 Subject: [GHC] #12411: GHC panic on TypeApplications + TemplateHaskell In-Reply-To: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> References: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> Message-ID: <066.3e22e039d139e1b6942fda3311f1d5a7@haskell.org> #12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Note that not enabling `-XTypeApplications` is critical for this bug to trigger. When `-XTypeApplications` is enabled, the above code works as intended. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 15:15:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 15:15:28 -0000 Subject: [GHC] #12530: Template Haskell support for TypeApplications Message-ID: <050.0f7e72af0d2d64a3645c78721f01e356@haskell.org> #12530: Template Haskell support for TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One more TH trick I'd like to have up my sleeve. Patch coming soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 15:22:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 15:22:51 -0000 Subject: [GHC] #12530: Template Haskell support for TypeApplications In-Reply-To: <050.0f7e72af0d2d64a3645c78721f01e356@haskell.org> References: <050.0f7e72af0d2d64a3645c78721f01e356@haskell.org> Message-ID: <065.875bb6035348d21946481acba7c0c668@haskell.org> #12530: Template Haskell support for TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2472 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2472 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 15:32:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 15:32:40 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.789ebf6ba33c85b40325cb5a973f1f7a@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2473 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * status: new => patch * differential: => Phab:D2473 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 15:56:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 15:56:11 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.51341b4fbff74105ab4119826784004a@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Would there be a difference between {{{#!hs data Some :: (Type -> Constraint) -> Type where Some :: c a => a -> Some c }}} and {{{#!hs data Some' :: (Type -> Constraint) -> Type where Some' :: (ctx `Implies` c, c a) => a -> Some' ctx }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 16:18:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 16:18:18 -0000 Subject: [GHC] #12531: Holes should be kind-polymorphic Message-ID: <044.38d412e29e728e7d1a4333b441265291@haskell.org> #12531: Holes should be kind-polymorphic -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I often use holes while writing long expressions out in GHCi in order to let the typechecker assist me with type inference. Sometimes though I find myself in a situation where I want to use holes near unlifted types and results in kind check messages obscuring the holes or having hole errors not show up at all: {{{#!hs > I# (_ +# 1#) :5:5: error: • Couldn't match a lifted type with an unlifted type When matching the kind of ‘Int#’ • In the first argument of ‘(+#)’, namely ‘_’ In the first argument of ‘I#’, namely ‘(_ +# 1#)’ In the expression: I# (_ +# 1#) :5:5: error: • Found hole: _ :: Int# • In the first argument of ‘(+#)’, namely ‘_’ In the first argument of ‘I#’, namely ‘(_ +# 1#)’ In the expression: I# (_ +# 1#) • Relevant bindings include it :: Int (bound at :5:1) }}} (Don't be deceived, the type of `_` there is actually `Int# |> (TYPE U(hole:{a1qG}, 'IntRep, 'PtrRepLifted)_N)_N`) Perhaps the type of `_` should be `forall r (a :: TYPE r). a` or even `forall k (a :: k). a` instead? This might lead to issues with `-fdefer-typed-holes` but maybe we could at first disallow deferred unlifted-kinded holes? But in theory a hole is just a call to `error` which is representation-polymorphic already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 16:19:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 16:19:14 -0000 Subject: [GHC] #12531: Holes should be kind-polymorphic In-Reply-To: <044.38d412e29e728e7d1a4333b441265291@haskell.org> References: <044.38d412e29e728e7d1a4333b441265291@haskell.org> Message-ID: <059.b84f0e2334e06c50e260a8c013e16545@haskell.org> #12531: Holes should be kind-polymorphic -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mniip: @@ -5,2 +5,2 @@ - near unlifted types and results in kind check messages obscuring the holes - or having hole errors not show up at all: + near unlifted types and that results in kind check messages obscuring the + holes or having hole errors not show up at all: New description: I often use holes while writing long expressions out in GHCi in order to let the typechecker assist me with type inference. Sometimes though I find myself in a situation where I want to use holes near unlifted types and that results in kind check messages obscuring the holes or having hole errors not show up at all: {{{#!hs > I# (_ +# 1#) :5:5: error: • Couldn't match a lifted type with an unlifted type When matching the kind of ‘Int#’ • In the first argument of ‘(+#)’, namely ‘_’ In the first argument of ‘I#’, namely ‘(_ +# 1#)’ In the expression: I# (_ +# 1#) :5:5: error: • Found hole: _ :: Int# • In the first argument of ‘(+#)’, namely ‘_’ In the first argument of ‘I#’, namely ‘(_ +# 1#)’ In the expression: I# (_ +# 1#) • Relevant bindings include it :: Int (bound at :5:1) }}} (Don't be deceived, the type of `_` there is actually `Int# |> (TYPE U(hole:{a1qG}, 'IntRep, 'PtrRepLifted)_N)_N`) Perhaps the type of `_` should be `forall r (a :: TYPE r). a` or even `forall k (a :: k). a` instead? This might lead to issues with `-fdefer-typed-holes` but maybe we could at first disallow deferred unlifted-kinded holes? But in theory a hole is just a call to `error` which is representation-polymorphic already. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 17:22:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 17:22:52 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.04d456ee7e013d600d94bf78fe9ea8c2@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:6 diatchki]: > 2. "Fails instances", which are of the form `instance Num Char fails`; they enable programmers to state explicitly that an instance should never exits. Interestingly, I just found a very related ticket asking for the same sort of thing (#7775). Using `Any` as a superclass we can effectively [https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70 #hackage-no-instances-allowed forbid instances], of course the compiler is not privy to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 17:38:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 17:38:42 -0000 Subject: [GHC] #12415: Fancy BinIface encoding for tuples is broken for constraint tuples In-Reply-To: <046.36b5b84566124dc8ed2f6851c925d504@haskell.org> References: <046.36b5b84566124dc8ed2f6851c925d504@haskell.org> Message-ID: <061.6e0bdb29193c7c842d0de80608dc72b8@haskell.org> #12415: Fancy BinIface encoding for tuples is broken for constraint tuples -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12357 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Simon and I have been doing a lot of thinking about how best to fix this: here is the current story. It looks like we can get rid of the entirely tuple serialization since tuples (and indeed all other wired-in things) are known-key and are therefore already serialized efficiently with the existing known-key logic in `BinIface`. I've gone ahead and removed this codepath in Phab:D2467. However, Phab:D2467 still leaves some room for improvement as we have an extremely large number of tuple and sum names in `knownKeyNames` and hence the name cache unnecessarily. These can in principle be removed (and indeed this was what lead me to this ticket to begin with). However, as this is largely an orthogonal matter I'll be tracking it in # -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 17:43:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 17:43:05 -0000 Subject: [GHC] #12532: Remove sum and tuple names from knownKeyNames Message-ID: <046.a3a9bb80f751ea54075614466c373666@haskell.org> #12532: Remove sum and tuple names from knownKeyNames -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As noted in ticket:12415#comment:5 there are a large number of names inhabiting `knownKeyNames` and therefore the original name cache due to tuples and sums. It shouldn't be so hard to remove these and handle them in an ad-hoc manner: * original name cache lookups (e.g. finding out the `Name` associated with an `OccName`) can been handled by parsing the `OccName`'s string * looking up the `Name` associated with a `Unique` (which is needed in `BinIface` during interface file deserialization) can be done with a set of static functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 17:48:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 17:48:25 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.17321d8dd0e237e39e5720185fd4bc2a@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:9 aavogt]: > In some sense this can already be done: > {{{ > class FailHasNoInstances a => Fail a > class FailHasNoInstances a -- not exported to ban Fail instances > > instance Fail "Char may not have a Num instance" => Num Char > main = print $ '1' + '1' > }}} Is there a difference between using `Fail` and Proposal/CustomTypeErrors? (see #11967) {{{#!hs instance TypeError (Text "Boo-urns!") => Num Char }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 18:02:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 18:02:16 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.04fad96673eaec8d6479439935beb420@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:1 goldfire]: > 2. This doesn't necessarily mean that we'll never need overlapping instances -- instance chains seem to only work when the overlap would be contained only in one module. Some programs require inter-module overlap (say, for a global "default" instance). Here's some data from [http://homepages.inf.ed.ac.uk/jmorri14/d/final.pdf Type Classes and Instance Chains: A Relational Approach] > Our first question was how frequently the open-endedness of overlapping instances was necessary in practice. To answer this question, we determined whether the instances in each set were located in the same module, in different modules within the same package, or in different packages (Figure 3.1). Out of the 123 sets, 19 included overlapping instances from different modules, and 6 (of those 19) included overlapping instances from different packages. THe[sic] majority (104, or 85%) of the sets only included instances from a single module. This suggests that, while applications exist for instances overlapping across modules, most overlapping instances are defined locally. > > — page 37 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 18:18:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 18:18:31 -0000 Subject: [GHC] #12532: Remove sum and tuple names from knownKeyNames In-Reply-To: <046.a3a9bb80f751ea54075614466c373666@haskell.org> References: <046.a3a9bb80f751ea54075614466c373666@haskell.org> Message-ID: <061.de9568dc89c24949d6609806d484fc7a@haskell.org> #12532: Remove sum and tuple names from knownKeyNames -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have an initial attempt (Phab:D2469) at doing this. Here I remove all of the sum and tuples names from `knownKeyNames` implement the codepaths listed above for handling original name lookups and `Name`s from `Unique`s. However, I found that there is one wrinkle: there are actually two places where we need to lookup in the original name cache during interface file deserialization, 1. While deserializing the symbol table. This is the case that I had anticipated and indeed it poses no problem since we have a special encoding for known-key names, so indeed we should never need to do a name cache lookup in this case. 2. To lookup `IfaceTopBndr`s of, e.g., `IfaceDecl`s. This case I only realized after neck-deep in the refactoring and requires a bit more work to handle correctly. = My approach: Changing `IfaceTopBndr` = My approach to (2) is to essentially duplicate the special encoding of known key names that we use for the symbol table for `IfaceTopBndr`. This is done by changing it from a synonym for `OccName` to a sum of, {{{#!hs data IfaceTopBndr = IfaceTopOccName OccName | IfaceKnownKeyName Unique }}} the knock-on changes for this approach go through pretty easily. = An alternative: Using the symbol table = Simon PJ has suggested an alternative: rather than duplicating the known- key encoding, we should instead simply make `IfaceTopBndr` a synonym for `Name`; in principle this would mean that known-key names would "just work" since `IfaceTopBndr` would be encoding via the symbol table. Sadly, it seems that this is too good to be true. The trouble comes from the fingerprinting logic in `MkIface` (namely `addFingerprints`) which works roughly as follows, 1. we look at the `IfaceDecl`s being processed and compute strongly- connect groups of them. 2. we walk the list of groups in dependency order and compute a fingerprint for each. As we progress we maintain an `NameEnv Fingerprint` which maps each name we've looked at to its fingerprint. 3. The fingerprint for a group is determined by serializing it with `Binary` to a buffer and MD5ing the result. However, this isn't quite normal serialization: we override the `putName` operation to, rather than merely serializing the `Name`, lookup the name in the fingerprint environment and instead writing the fingerprint. To see the issue consider what happens when we try to fingerprint a single `IfaceId` with `IfaceTopBndr ~ Name`: the very first thing we do is `put` the `IfaceId`'s `ifName`; this will attempt to lookup the `Name` in the fingerprint environment but this will of course fail since we haven't yet fingerprinted it (which results in a panic exclaiming "urk! lookup local fingerprint"). "Well," you might say, "perhaps we can simply add a special case to the dummy `putName` logic not to attempt to lookup the `Name` of the `IfaceDecl` which we are currently fingerprinting. Sadly, however, this isn't enough since we also need the other names which the decl binds implicitly (e.g. the datacons of a `IfaceData`). It is indeed possible to compute these but all-in-all the situation ends up looking much messier than the relatively simple solution I proposed above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 19:42:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 19:42:11 -0000 Subject: [GHC] #12533: Internal error using redundant forall with default signature Message-ID: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> #12533: Internal error using redundant forall with default signature -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ScopedTypeVariables, DefaultSignatures #-} class Foo x where foo :: forall a . x a -> x a default foo :: forall a . x a -> x a foo x = go where go :: x a go = undefined }}} GHC (7.8.3 and 8.0.1) chokes on the above with the message {{{ Buggy.hs:7:19: error: • GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [aoY :-> Type variable ‘x’ = x, ap0 :-> Type variable ‘a’ = a, ap1 :-> Identifier[x::x a, ]] • In the first argument of ‘x’, namely ‘a’ In the type signature: go :: x a In an equation for ‘foo’: foo x = go where go :: x a go = undefined }}} If I remove the redundant `forall` it works fine: {{{#!hs class Foo x where foo :: x a -> x a default foo :: forall a . x a -> x a foo x = go where go :: x a go = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 19:54:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 19:54:48 -0000 Subject: [GHC] #12533: Internal error using redundant forall with default signature In-Reply-To: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> References: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> Message-ID: <060.e94693405fee7803c0dd973e2c95af52@haskell.org> #12533: Internal error using redundant forall with default signature -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * component: Compiler => Compiler (Type checker) Comment: mniip says this is a renamer problem, with `-ddump-rn` producing {{{#!hs class Main.Foo x_apt where Main.foo :: forall a_apu. x_apt a_apu -> x_apt a_apu default Main.foo :: forall a_apv. x_apt a_apv -> x_apt a_apv Main.foo x_apw = go_apx where go_apx :: x_apt a_apu go_apx = undefined }}} That is, GHC is using `a_apu` when it should be using `a_apv`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 20:45:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 20:45:19 -0000 Subject: [GHC] #12423: Panic with DeriveAnyClass and DefaultSignatures In-Reply-To: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> References: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> Message-ID: <061.b99080094b292d8f1d27de327073ac82@haskell.org> #12423: Panic with DeriveAnyClass and DefaultSignatures -------------------------------------+------------------------------------- Reporter: knrafto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): `DefaultSignatures` isn't actually relevant here; `DeriveAnyClass` seems to be solely responsible. I get the same error using {{{#!hs {-# LANGUAGE DeriveAnyClass #-} class Eq1 f where (==#) :: Eq a => f a -> f a -> Bool data Foo a = Foo (Either a a) deriving (Eq, Eq1) }}} Most surprisingly, to me, these examples compile successfully if `Foo` is modified just a drop. Both of the following work: {{{#!hs data Foo2 a = Foo2 a deriving (Eq, Eq1) data Foo3 a b = Foo3 (Either a b) deriving (Eq, Eq1) }}} (the latter needing the obvious `Eq a => Eq1 (Either a)` instance.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 20:46:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 20:46:02 -0000 Subject: [GHC] #12423: Panic with DeriveAnyClass (was: Panic with DeriveAnyClass and DefaultSignatures) In-Reply-To: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> References: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> Message-ID: <061.403e8ec57a4582f8e29f423934c1aab3@haskell.org> #12423: Panic with DeriveAnyClass -------------------------------------+------------------------------------- Reporter: knrafto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 20:59:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 20:59:35 -0000 Subject: [GHC] #12529: Error message: visible type application of constructor/variable that is not in scope In-Reply-To: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> References: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> Message-ID: <066.9a62f9c66ba82ad58390208e160ef8f3@haskell.org> #12529: Error message: visible type application of constructor/variable that is not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The fact that GHC treats out-of-scope errors as type errors causes degradation of certain error messages, like what you see here. I'm sure there's another ticket tracking this problem, but I'm unable to find it at the moment. Perhaps you can? If I recall, the original error message was about a lack of class instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 21:04:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 21:04:16 -0000 Subject: [GHC] #12531: Holes should be representation-polymorphic (was: Holes should be kind-polymorphic) In-Reply-To: <044.38d412e29e728e7d1a4333b441265291@haskell.org> References: <044.38d412e29e728e7d1a4333b441265291@haskell.org> Message-ID: <059.3165a2046dbfa2fdc3f33bb393c4c91e@haskell.org> #12531: Holes should be representation-polymorphic -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This looks quite plausible and shouldn't be hard to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 22:52:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 22:52:53 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.1bc99042ab15dc94dda2dbdf9e7d86fc@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.2.1 => 8.0.2 Comment: Moving to 8.0.2, since this could cause `lens` to break if this change makes it in. Please revert if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 24 23:50:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Aug 2016 23:50:17 -0000 Subject: [GHC] #12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects Message-ID: <050.b7a046da7579b02aae5af1a75be2c102@haskell.org> #12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 7.10 rejects this datatype: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} module Bug where data T (a :: a) }}} {{{ $ /opt/ghc/7.10.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:1: Kind variable also used as type variable: ‘a’ In the data type declaration for ‘T’ }}} But GHC 8.0 accepts the above code! It appears that GHC implicitly freshens the kind-level `a` so as to have a different name, since the following modification to `T`: {{{#!hs data T a (a :: a) }}} Results in this error: {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:8: error: Conflicting definitions for ‘a’ Bound at: Bug.hs:5:8 Bug.hs:5:11 Bug.hs:5:16: error: Type variable ‘a’ used in a kind. Did you mean to use TypeInType? the data type declaration for ‘T’ }}} But with this modification: {{{#!hs data T (a :: a) a }}} You won't get an error message about `a` being used as both a kind and type: {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:9: error: Conflicting definitions for ‘a’ Bound at: Bug.hs:5:9 Bug.hs:5:17 }}} To make things even more confusing, this behavior doesn't seem to carry over to typeclass instances. For example: GHC 8.0 will (rightfully) reject this code: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE PolyKinds #-} module Bug where data T (a :: a) class C x instance C (T (a :: a)) }}} {{{ $ /opt/ghc/8.0.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:8:16: error: Variable ‘a’ used as both a kind and a type Did you intend to use TypeInType? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 00:51:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 00:51:31 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.f52c9c01dff647d1a0692515b8ca3d9c@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): So am I correct in guessing that this causes us to fail for the `Conjoined` class in `lens`? I've stripped it down removing the superclasses here: {{{#!hs class Conjoined p where conjoined :: ((p ~ (->)) => q (a -> b) r) -> q (p a b) r -> q (p a b) r conjoined _ r = r }}} (This is just a noisier version of `Foo`.) This is a rather big huge of the optimization story in `lens`, as we use it to avoid fiddling around with updating indices when the user isn't using them. This can make a 100x difference in performance for user code, so it isn't a trivial thing to throw away. If this suddenly isn't legal any more I'm really not sure what the heck we're going to do. That said, I don't see how that statement is illegal. `conjoined` takes two argument, one says _if_ you can tell me that p is (->) i'll give you a thing. The other is unconditionally usable. Once you learn p isn't `(->)` you simply can't use the first argument, as you could never satisfy its precondition. It isn't an error on the behalf of the signature of `conjoined`. It seems something is hinky in the way we're judging who has incurred an obligation here and when. We seem to be being far too eager to discharge an obligation we have no reason to even look at. Until something tries to use the first argument, why are we even doing anything with its constraints at all? The constraint being unsatisfiable in this limited situation is very much the point of the expression in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 01:46:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 01:46:44 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.bfea57b3ef32ddd02e049ea05798a1ff@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Probably not worth it, but fake definitions are generated for Commentary/PrimOps {{{#!hs newArray# :: Int# -> a -> State# s -> (# State# s,MutableArray# s a #) newArray# = let x = x in x sameMutableArray# :: MutableArray# s a -> MutableArray# s a -> Int# sameMutableArray# = let x = x in x nullAddr# :: Addr# nullAddr# = let x = x in x }}} If this feature is enabled the bodies could be omitted and if we make holes representation-polymorphic (#12531) it's not such a reach to allow top-level unlifted bindings as well when body is omitted: {{{#!hs newArray# :: Int# -> a -> State# s -> (# State# s,MutableArray# s a #) sameMutableArray# :: MutableArray# s a -> MutableArray# s a -> Int# nullAddr# :: NullAddr# }}} This might avoid hacky tests mentioned in `[Compiling GHC.Prim]`. ---- === Note `[Placeholder declarations]` === > We are generating fake declarations for things in [https://hackage.haskell.org/package/ghc-prim-0.4.0.0/candidate/docs/src /GHC-Prim.html GHC.Prim], just to keep GHC's renamer and typechecker happy enough for what Haddock needs. Our main plan is to say > {{{#!hs > foo :: > foo = foo > }}} > We have to silence GHC's complaints about unboxed-top-level declarations with an ad-hoc fix in `TcBinds`: see Note `[Compiling GHC.Prim]` in `TcBinds`. > > > That works for all the primitive functions except `tagToEnum#`. If we generate the binding > {{{#!hs > tagToEnum# = tagToEnum# > }}} > GHC will complain about "`tagToEnum#` must appear applied to one argument". We could hack GHC to silence this complaint when compiling `GHC.Prim`, but it seems easier to generate > {{{#!hs > tagToEnum# = let x = x in x > }}} > We don't do this for *all* bindings because for ones with an unboxed RHS we would get other complaints (e.g.can't unify "`*`" with "`#`"). === Note `[Compiling GHC.Prim]` === > Module `GHC.Prim` has no source code: it is the host module for primitive, built-in functions and types. However, for Haddock-ing purposes we generate (via `utils/genprimopcode`) a fake source file `GHC/Prim.hs`, and give it to Haddock, so that it can generate documentation. It contains definitions like > {{{#!hs > nullAddr# :: NullAddr# > }}} > which would normally be rejected as a top-level unlifted binding. But we don't want to complain, because we are only "compiling" this fake mdule [sic] for documentation purposes. Hence this hacky test for `gHC_PRIM` in `checkStrictBinds`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 04:05:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 04:05:13 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.0b56c228c4381d90be64526d936841b1@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aavogt): Replying to [comment:14 Iceland_jack]: > Replying to [comment:9 aavogt]: > Is there a difference between using `Fail` and Proposal/CustomTypeErrors? (see #11967) Not much difference. All I can think of is that `TypeError` requires ghc >= 8 to give prettier messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 06:56:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 06:56:20 -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.7755cef9350c2219b005b0caa936787f@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:56 simonmar]: > Yes, perhaps we should default to -qb0 when -A is larger than some threshold. > > The mutator parallelism looks not too bad (3.24 out of 4). Was there enough parallelism in the program you were compiling to do better than that? I assumed there is as it's ~100 independent haskell modules, but some of them are disproportionally large. Got to 24-core VM to run the same benchmark. At first it manages to peak 24 HEC utilisation but at the tail it clearly has not enough parallelism: -qb1: http://code.haskell.org/~slyfox/T9221/ghc- stage2.eventlog.N24.j24.png -qb0: http://code.haskell.org/~slyfox/T9221/ghc- stage2.eventlog.N24.j24.A256M.qb0.png > The `MVar`s are probably just the compilation manager: it fires up a thread for every module, and they wait on the results of compiling the modules they depend on. Yes, that's more likely. It would be cool to have labelMVar similar to existing labelThread to see IDs/names of blocker MVars. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 07:16:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 07:16:22 -0000 Subject: [GHC] #12532: Remove sum and tuple names from knownKeyNames In-Reply-To: <046.a3a9bb80f751ea54075614466c373666@haskell.org> References: <046.a3a9bb80f751ea54075614466c373666@haskell.org> Message-ID: <061.be194f8b26644bde6834df723d9f79b6@haskell.org> #12532: Remove sum and tuple names from knownKeyNames -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the `IfaceTopBndr = Name` idea may be simpler than you think. In `BinIface.putName` we see two cases: {{{ putName ... name | isKnownKeyName name = ...serialise the unique... | otherwise = ...go via the symbol table... }}} where `isKnownKeyName` knows how to parse the uniques for tuples etc. Very well then. In "My approach", when fingerprinting an `IfaceDecl`, you are presumably going to have something like: {{{ putIfaceTopBndr :: IfaceTopBndr -> M () putIfaceTopBndr (IfaeKnownKeyName uniq) = ...uniq... putIFaceTopBndr (IfaceTopNameOccName occ) = ...occ... }}} But instead of making the distiction with a data constructur, you can use `isKnownKeyName` just like `putName`! {{{ putIfaceTopBndr :: IfaceTopBndr -> M () putIFaceTopBndr name | isKnownKeyName name = ...(getUnique name)... | otherwise = ...(getOccName name)... }}} Your proposed `IfaceTopBndr` lets you distinguish the known-key situation. But so does `isKnownKeyName`. (Indeed we could use your `IfaceTopBndr` sum type at ''every'' occurrence of a name, i.e. for `IfaceExtName`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 07:29:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 07:29:07 -0000 Subject: [GHC] #12529: Error message: visible type application of constructor/variable that is not in scope In-Reply-To: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> References: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> Message-ID: <066.73361aa7dbe4106968575a6c793b2f6a@haskell.org> #12529: Error message: visible type application of constructor/variable that is not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's #12170 I think. Ben, I think that patch (for #12170) is ready to go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 07:54:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 07:54:32 -0000 Subject: [GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym In-Reply-To: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> References: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> Message-ID: <060.0e1f2d09189c1ed7c894fa225131c9e6@haskell.org> #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Edward and I discussed this. What if we wrote this: {{{ pattern VCons :: a -> Vec a n -> Vec a (n + 1) pattern VCons x xs = Vec (x : unVec xs) }}} What makes it OK to use bidirectional "=" is that the RHS is invertible. Constructors are invertible. '''But so is `unVec`''', because it's inverse is just `Vec`. So maybe we should just expand the class of invertible RHSs a little? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 07:57:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 07:57:05 -0000 Subject: [GHC] #12535: Bad error message when unidirectional pattern synonym used in bidirectional pattern synonym Message-ID: <045.eebf0c55eab72345a926d062d9879981@haskell.org> #12535: Bad error message when unidirectional pattern synonym used in bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I write: {{{ {-# LANGUAGE PatternSynonyms #-} module I where pattern P2 x y <- (x, y) pattern P1 x y = P2 x y }}} I get the error: {{{ ezyang at sabre:~$ ghc-8.0 -c I.hs I.hs:5:18: error: • non-bidirectional pattern synonym ‘P2’ used in an expression • In the expression: P2 x y In an equation for ‘$bP1’: $bP1 x y = P2 x y }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 09:11:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 09:11:11 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.f990857cb2b0604221337cef46a43f35@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Ryan, I am very confused here. If I try the code from the ticket description, I can't call `foo @Char` so the defined instance is useless. Is this intentional? The same happens on GHC 8.0.1 and GHC 7.10.3. {{{ *Foo> :t foo @Char foo @Char :: (Char ~ Int => Int) -> Char -> Char *Foo> :t foo @Char 5 'a' :1:1: error: • Couldn't match type ‘Char’ with ‘Int’ Inaccessible code in a type expected by the context: Char ~ Int => Int • In the second argument of ‘foo’, namely ‘5’ In the expression: foo @Char 5 'a' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 09:17:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 09:17:06 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.f4e031f566f93b82ec5e823e4400f95a@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Replying to [comment:16 ekmett]: > So am I correct in guessing that this causes us to fail for the `Conjoined` class in `lens`? Yes this is where the example was reduced from.; > > This is a rather big huge of the optimization story in `lens`, as we use it to avoid fiddling around with updating indices when the user isn't using them. This can make a 100x difference in performance for user code, so it isn't a trivial thing to throw away. If this suddenly isn't legal any more I'm really not sure what the heck we're going to do. It seems that removing the constraint would preserve existing performance gains? Is the constraint used for something more than ensuring that only `p ~ (->)` can use the first argument and all other instances must use the default method? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 10:20:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 10:20:11 -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.29872d118bc24bb3c0c75cfa15d197a0@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 10:33:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 10:33:26 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.32b542681b310004c1ba1d377285011e@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by garrett): Replying to [comment:14 Iceland_jack]: > Another [https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70#pdf- type-classes-and-instance-chains-a-relational-approach-1 approach] that uses the module system to hide this class and type: > > {{{#!hs > class Fail t > data TypeExists t > }}} > > and uses it as > > {{{#!hs > instance Fail (TypeExists t) => HasNone t (Cons t ts) > }}} This isn't really the goal of `fails` instances (or other negative information) in instance chains. Negative information is used to direct instance selection; encodings, like this one, are only useful for the same purpose if the compiler knows that the `Fail (TypeExists t)` predicate is unsatisfiable. For an example that doesn't rely on `fails`, consider the following {{{#!hs class F t u | t -> u instance F Bool Int class C t where f :: t -> t -> t instance F t Bool => C t where f x y = x else C t where f x y = y }}} We expect that `f True False` evaluates to `False`; but, to know that the first clause of the chain does not apply, we need to know that the constraint `F Bool Bool` cannot hold (not just that it does not hold at the current point). In this case, we know that because of the functional dependency on `F`. This is not to say that a sufficient smart solver might not be able to determine that the `Fail (...)` or `Any` constraints are unsatisfiable. Just that a design which attempts to use these constraints in the role of the `fails` constraints in instance chains must presuppose such a solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 12:12:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 12:12:15 -0000 Subject: [GHC] #12532: Remove sum and tuple names from knownKeyNames In-Reply-To: <046.a3a9bb80f751ea54075614466c373666@haskell.org> References: <046.a3a9bb80f751ea54075614466c373666@haskell.org> Message-ID: <061.e842b0cf05f1d511a726b873f0da8eb3@haskell.org> #12532: Remove sum and tuple names from knownKeyNames -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Right, but the problem that I describe is actually quite orthogonal to the known-key encoding issue. The problem is that while generating a fingerprint for an `IfaceDecl` we override the implementation of `putName` in to resolve ensure that the fingerprints the things it refers to are included in its fingerprint. We do this by building up a `NameEnv Fingerprint` as we walk the `IfaceDecl`s in dependency order. Previously this was fine since none of the `Name`s we would serialize were binding occurrences. However, now that `IfaceTopBndr` is also a `Name` we have lost the ability to distinguish binding from non-binding occurrences. This breaks the fingerprinting implementation since we then end up attempting to lookup the `Name` (and implicit `Name`s) of the thing we are trying to fingerprint since its serialization contains a binding `Name`. In writing this the solution here became fairly obvious: simply tell `putName` whether it is serializing a binding or non-binding occurrence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 12:37:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 12:37:47 -0000 Subject: [GHC] #12532: Remove sum and tuple names from knownKeyNames In-Reply-To: <046.a3a9bb80f751ea54075614466c373666@haskell.org> References: <046.a3a9bb80f751ea54075614466c373666@haskell.org> Message-ID: <061.8f2b4226a94c79c595c048152bda393b@haskell.org> #12532: Remove sum and tuple names from knownKeyNames -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > In writing this the solution here became fairly obvious: simply tell putName whether it is serializing a binding or non-binding occurrence. Yes, precisely. Hence my name `putIfaceTopBndr`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 13:27:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 13:27:40 -0000 Subject: [GHC] #12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects In-Reply-To: <050.b7a046da7579b02aae5af1a75be2c102@haskell.org> References: <050.b7a046da7579b02aae5af1a75be2c102@haskell.org> Message-ID: <065.c11ed7b0a7e436256de63aa2ba62df42@haskell.org> #12534: GHC 8.0 accepts recursive kind signature that GHC 7.10 rejects -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: I'll put this one in my pile... but if you (for any definition of "you") want to tackle it, I'm happy to advise. This shouldn't actually be all that hard, I don't think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 13:28:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 13:28:59 -0000 Subject: [GHC] #12529: Error message: visible type application of constructor/variable that is not in scope In-Reply-To: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> References: <051.872fdf6f1b0518631bd35fbe4276affe@haskell.org> Message-ID: <066.3ae9db676563fac7075affd9b8bdccea@haskell.org> #12529: Error message: visible type application of constructor/variable that is not in scope -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm afraid I wasn't referring to #12170, which is concerned with the interaction between `-fdefer-type-errors` and the new treatment of out-of- scope variables. The bug reported here triggers without `-fdefer-type- errors`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 13:35:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 13:35:17 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.c6f3d5794ae17a03c86a5043c514fb1d@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Urgh. It seems I was even more confused than I realized in comment:14. Quite likely every word I've posted (hopefully not including these) is simply utter nonsense. Deep apologies. The confusion is entirely my own fault and not the result of anyone else's miscommunication. Let me try again. Yes, this is a bug. We should indeed accept the original program without any warnings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 14:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 14:10:09 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.5b68d69d1f93c5f7f4d6b10babd9c5d6@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): @mpickering: Without the constraint none of the code that actually uses this combinator works at all. Those use sites exploit that extra bit of knowledge passed to the first argument by `instance Conjoined (->)` which knows `p ~ (->)` and therefore can use the first argument. The typical workflow is to do something like {{{#!hs traversed :: Traversable f => IndexedTraversal Int (f a) (f b) a b traversed = conjoined traverse (indexing traverse) }}} `traverse` requires its argument to be a function. `indexing traverse` isn't so picky and works for more choices of `p`. Now using that if you use `traversed` as a simple `Traversal` it'll pick the fast `traverse` path, but if you need access to the numerical indices we put on each member, and use a combinator like `itoListOf` or (`^@..`), then it'll pay the price of computing indices in an extra bit of state. This is equivalent to traversing the original `Traversable` container with `Compose (State Int) f` and bumping the counter after visiting each member, rather than just using your original functor `f`. This is much much slower. `traversed` and `indexing traverse` should be indistinguishable for users, except for the fact that the former is much much faster for the common case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 14:18:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 14:18:10 -0000 Subject: [GHC] #12423: Panic with DeriveAnyClass In-Reply-To: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> References: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> Message-ID: <061.12fa15245933ee246071769e5b734e2b@haskell.org> #12423: Panic with DeriveAnyClass -------------------------------------+------------------------------------- Reporter: knrafto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | GenericDeriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12144 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => GenericDeriving * related: => #12144 Comment: *sigh* I know what's happening here. The algorithm that GHC uses to infer constraints for `* -> *`-kinded things is co-opted from the `DeriveFunctor` algorithm, which doesn't know how to deal with argument types like `Either a a` (since it expects that last type parameter `a` to only ever be used as the very last type in a type application). If you tried to derive a `Functor` instance for `data Foo a = Foo (Either a a)`, it'd give a proper error, since GHC has [http://git.haskell.org/ghc.git/blob/613d745523f181991f6f916bbe58082b7970f7e6:/compiler/typecheck/TcDeriv.hs#l1487 checks] specifically for derived `Functor` instances. On the other hand, there aren't any checks like that for things that are derived in general with `DeriveAnyClass`, so it falls through to [http://git.haskell.org/ghc.git/blob/0676e68cf5fe8696f1f760fef0f35dba14db1104:/compiler/typecheck/TcGenDeriv.hs#l1665 some code] which throws a GHC panic. Urk. There are two ways we can proceed here. One thing we can do is to put these same checks for `Functor` in place for all `DeriveAnyClass`-derived typeclasses. That would eliminate the GHC panic, but it would simply replace one error message with another. Another approach, which Simon suggests in [https://mail.haskell.org/pipermail/ghc-devs/2016-June/012276.html this ghc-devs thread], is to instead adopt a different strategy for inferring constraints for `DeriveAnyClass`-derived things. Instead of using the `DeriveFunctor` algorithm, we'd collect all of the constraints given by the default signatures of the typeclass, and then simplify as needed. It should be noted that even with the second approach, you still wouldn't be able to derive an `Eq1` instance for `data Foo a = Foo (Either a a)`, since you can't eta-reduce the last type variable. But you would be allowed to derive more things with `DeriveAnyClass` than you could before. A similar problem popped up in #12144, except that uses the last type variable in a contravariant position (another thing which the `DeriveFunctor` algorithm chokes on). Even though this ticket is technically a duplicate of #12144, I'll keep this one open, since it's of a somewhat different nature and provides another nice test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 14:19:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 14:19:20 -0000 Subject: [GHC] #12144: GHC panic when using DeriveAnyClass with functor-like class and datatype with a type variable in a contravariant position In-Reply-To: <050.fd4ffb113813480ae17d2da8461f3f40@haskell.org> References: <050.fd4ffb113813480ae17d2da8461f3f40@haskell.org> Message-ID: <065.7b84420d99c931a8a5b232f727eef1bc@haskell.org> #12144: GHC panic when using DeriveAnyClass with functor-like class and datatype with a type variable in a contravariant position -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #5462, #7346, | Differential Rev(s): #12423 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #5462, #7346 => #5462, #7346, #12423 Comment: See also #12423, which throws a very similar panic (but for a slightly more sensible reason). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 14:20:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 14:20:14 -0000 Subject: [GHC] #12165: Multiple pattern type signatures accepted In-Reply-To: <047.0e810b3c040e7f9c575b82495a00aef7@haskell.org> References: <047.0e810b3c040e7f9c575b82495a00aef7@haskell.org> Message-ID: <062.609934d0dbacaef68aadbadadb6cfe7a@haskell.org> #12165: Multiple pattern type signatures accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: seraphime Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | PatternSynonyms, newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2361 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * version: 8.0.1 => 8.1 * resolution: => fixed * milestone: 8.0.2 => 8.2.1 Comment: Never mind; #11727 (which allows multiple signatures to begin with) wasn't yet fixed in 8.0.1 so this issue isn't even present. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 14:53:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 14:53:49 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.f6365cf9c2c145c83e4a91293737efdc@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): mpickering, I'm a bit confused too why `foo 5 'a'` itself doesn't typecheck, but that's not how `lens` is using this style of code. The way `lens` is using it, it's closer in style to something like this: {{{#!hs bar :: Foo a => a -> a bar = foo 5 }}} Now `bar 'a'` will typecheck. Similarly, if you want a more complete `lens`-based piece of code to test against, you can use the following: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Lens where indexing :: Indexable Int p => ((a -> Indexing f b) -> s -> Indexing f t) -> p a (f b) -> s -> f t indexing l iafb s = snd $ runIndexing (l (\a -> Indexing (\i -> i `seq` (i + 1, indexed ia fb i a))) s) 0 newtype Indexing f a = Indexing { runIndexing :: Int -> (Int, f a) } instance Functor f => Functor (Indexing f) where fmap f (Indexing m) = Indexing $ \i -> case m i of (j, x) -> (j, fmap f x) instance Applicative f => Applicative (Indexing f) where pure x = Indexing $ \i -> (i, pure x) Indexing mf <*> Indexing ma = Indexing $ \i -> case mf i of (j, ff) -> case ma j of ~(k, fa) -> (k, ff <*> fa) type IndexedTraversal i s t a b = forall p f. (Indexable i p, Applicative f) => p a (f b) -> s -> f t class Conjoined p where conjoined :: ((p ~ (->)) => q (a -> b) r) -> q (p a b) r -> q (p a b) r conjoined _ r = r class Conjoined p => Indexable i p where indexed :: p a b -> i -> a -> b --------------------------------------------------------------------- newtype Indexed i a b = Indexed { runIndexed :: i -> a -> b } -- You'll need to comment out the instance below to typecheck on HEAD instance Conjoined (Indexed i) --------------------------------------------------------------------- -- This now typechecks: traversed :: Traversable f => IndexedTraversal Int (f a) (f b) a b traversed = conjoined traverse (indexing traverse) }}} ----- The fact that `foo 5 'a'` doesn't typecheck might be part of the bug. As Edward mentioned above, I suspect that we are too eagerly discharging an obligation somewhere, and that explains: 1. Why `foo 5 'a'` doesn't typecheck but `bar 'a'` does 2. Why a manually implemented `instance Foo Char where foo _ a = a` typechecks but a default `instance Foo Char` doesn't But these are just my suspicions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:16 -0000 Subject: [GHC] #12134: PowerPC 64-bit: Foreign functions with more than 8 float parameters broken In-Reply-To: <047.b2f90e1cc5508bb649499a3ffa202a40@haskell.org> References: <047.b2f90e1cc5508bb649499a3ffa202a40@haskell.org> Message-ID: <062.49e8c3dd80f78438c5615a9f014d2afa@haskell.org> #12134: PowerPC 64-bit: Foreign functions with more than 8 float parameters broken -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: ccall Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | ffi/should_run/T12134 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2327 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7f373fb1b9aea45db94f04267427c5629b73f25c/ghc" 7f373fb1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7f373fb1b9aea45db94f04267427c5629b73f25c" PPC NCG: Fix float parameter passing on 64-bit. On Linux 64-bit PowerPC the first 13 floating point parameters are passed in registers. We only passed the first 8 floating point params. The alignment of a floating point single precision value in ELF v1.9 is the second word of a doubleword. For ELF v2 we support only little endian and the least significant word of a doubleword is the first word, so no special handling is required. Add a regression test. Test Plan: validate on powerpc Linux and AIX Reviewers: erikd, hvr, austin, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2327 GHC Trac Issues: #12134 (cherry picked from commit 2897be77123bf31cad1c60dd5560eba7f2f021ce) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:16 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.78bba92621f4246af31b017c898f21d6@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"498009a904a1e8910f9e0e527f6eb6c8073c8a76/ghc" 498009a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="498009a904a1e8910f9e0e527f6eb6c8073c8a76" Second attempt to fix sizeExpr Summary: Background: * sizeExpr was calculating expressions like ((e `cast` T) x) wrongly * Fixing it caused regressions in compile performance, and one nofib program (k-nucleotide) I managed to fix the source of the compiler regressions. I think it was due to traceTc not being inlined, which I fixed in a more robust way by putting an export list on TcRnMonad. The k-nucleotide regression is more difficult. I don't think anything is actually going wrong, but this program has been highly tuned and is quite sensitive to changing in inlining behaviour. I managed to recover most of the performance by manual lambda-lifting which makes it a bit less fragile, but the end result was a bit slower. I don't think this is disastrous, the program is pretty horrible to begin with and we could probably make a faster one by starting from scratch. Test Plan: validate, nofib Reviewers: simonpj, bgamari, niteria, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2338 GHC Trac Issues: #11564 (cherry picked from commit a47b62cb36853d03c77ef63b3208b3d869fb687e) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:16 -0000 Subject: [GHC] #12067: warn-unused-imports does not detect coersions In-Reply-To: <047.e234196f4d28c1786926628389b4a6f1@haskell.org> References: <047.e234196f4d28c1786926628389b4a6f1@haskell.org> Message-ID: <062.20745061b00face5488af0ef93e681fd@haskell.org> #12067: warn-unused-imports does not detect coersions -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_compile/T12067 Blocked By: | Blocking: Related Tickets: #10347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6c28f24aa8202f79db49b85b815011703d647fd9/ghc" 6c28f24/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c28f24aa8202f79db49b85b815011703d647fd9" Deal correctly with unused imports for 'coerce' We only do newtype unwrapping for Coercible constraints if the newtype's data constructor is in scope. We were trying to record the fact that the data constructor was thereby 'used', so that an import statement would not be flagged as unnecsssary (by -Wunused-imports). But the code was simply wrong. It was wrong because it assumed that only one level of unwrapping happened, whereas tcTopNormaliseNewTypeTF_maybe actually unwraps multiple layers. So we need to return a /list/ of data constructors that are used. This entailed a bit of refactoring, as usual. Fixes Trac #12067 (cherry picked from commit 23b80ac41cc945cea0fc6ff9ade6b4be8aa81b7f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:16 -0000 Subject: [GHC] #11974: `default` declaration doesn't allow higher-kinded types In-Reply-To: <047.2c4be3a4c34290389efa6f45ff0342fe@haskell.org> References: <047.2c4be3a4c34290389efa6f45ff0342fe@haskell.org> Message-ID: <062.3a78dfe1f47f3f2bdec2dccc2492ffd3@haskell.org> #11974: `default` declaration doesn't allow higher-kinded types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11974, | typecheck/should_fail/T11974b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2136 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"37bfc6c91f02f6696aee875fbcc8acd0f7a6317b/ghc" 37bfc6c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37bfc6c91f02f6696aee875fbcc8acd0f7a6317b" Fix #11974 by adding a more smarts to TcDefaults. Test cases: typecheck/should_compile/T11974 typecheck/should_fail/T11974b (cherry picked from commit 9a34bf1985035858ece043bf38b47b6ff4b88efb) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:16 -0000 Subject: [GHC] #12242: panic with complicated type/kind/class expressions In-Reply-To: <053.4658ba704f77806da8153e92cef2d64a@haskell.org> References: <053.4658ba704f77806da8153e92cef2d64a@haskell.org> Message-ID: <068.db4908290e08a2763235595b0ad8306d@haskell.org> #12242: panic with complicated type/kind/class expressions -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ba9dd63ad8e3498268db24ab66bcae002a9d5120/ghc" ba9dd63a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ba9dd63ad8e3498268db24ab66bcae002a9d5120" Fix pretty-printer for IfaceCo As Trac #12242 showed, there was a missing case in the pretty printer for IfaceCo. I've refactored it so that the pattern-match ovelap checker will spot it next time. (cherry picked from commit 24194a6aed950ed4c3733e3c582abf8a15d98ffd) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:16 -0000 Subject: [GHC] #12354: Word foldl' isn't optimized as well as Int foldl' In-Reply-To: <045.bac6bcbeca1cabd22823ab5f537d5cc8@haskell.org> References: <045.bac6bcbeca1cabd22823ab5f537d5cc8@haskell.org> Message-ID: <060.baec797bc1b2ada7dcdb6549d20094d8@haskell.org> #12354: Word foldl' isn't optimized as well as Int foldl' -------------------------------------+------------------------------------- Reporter: kjslag | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2376 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f26e58bfcad4155d5e2cefcaba5408f0466bfb5e/ghc" f26e58b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f26e58bfcad4155d5e2cefcaba5408f0466bfb5e" Enum: Ensure that operations on Word fuse Test Plan: Validate, verify fusion Reviewers: austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2376 GHC Trac Issues: #12354 (cherry picked from commit 0bd7c4b4240a27d4e26290741394b31b48db7671) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:17 -0000 Subject: [GHC] #12227: regression: out of memory with -O2 -ddump-hi on a complex INLINE function In-Reply-To: <046.5eb6cdc259c89a5a386fca350cf30507@haskell.org> References: <046.5eb6cdc259c89a5a386fca350cf30507@haskell.org> Message-ID: <061.9f1706e160f4426964cccd64942e6358@haskell.org> #12227: regression: out of memory with -O2 -ddump-hi on a complex INLINE function -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T12227 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2397 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2756af87aebee769ffca959adc4b9dc607a49fdb/ghc" 2756af8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2756af87aebee769ffca959adc4b9dc607a49fdb" Pretty: remove a harmful $! (#12227) This is backport of [1] for GHC's copy of Pretty. See Note [Differences between libraries/pretty and compiler/utils/Pretty.hs]. [1] http://git.haskell.org/packages/pretty.git/commit/bbe9270c5f849a5bb74c9166a5f4202cfb0dba22 https://github.com/haskell/pretty/issues/32 https://github.com/haskell/pretty/pull/35 Reviewers: bgamari, austin Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D2397 GHC Trac Issues: #12227 (cherry picked from commit 89a8be71a3715c948cebcb19ac81f84da0e6270e) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:17 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311632=3A_Data=2EChar_repeated_readL?= =?utf-8?q?itChar_barfs_on_output_from_show_=22=C3=B31=22?= In-Reply-To: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> References: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> Message-ID: <064.915e150ae8c6df5bf6c5091907145e2d@haskell.org> #11632: Data.Char repeated readLitChar barfs on output from show "ó1" -------------------------------------+------------------------------------- Reporter: inversemot | Owner: kgupta Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: readLitChar Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2391 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1c53ac17ee8716ec07d782079462f4218d8f0606/ghc" 1c53ac17/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1c53ac17ee8716ec07d782079462f4218d8f0606" Bugfix for bug 11632: `readLitChar` should consume null characters Test Plan: The tests have been included. This change deals with a relatively minor edge case and should not break unrelated functionality. Reviewers: thomie, #core_libraries_committee, ekmett, bgamari Reviewed By: #core_libraries_committee, ekmett, bgamari Subscribers: bgamari, ekmett Differential Revision: https://phabricator.haskell.org/D2391 GHC Trac Issues: #11632 (cherry picked from commit 0f0cdb6827803015a9a3924fdafaef8dbcde048f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:17 -0000 Subject: [GHC] #12403: Template Haskell boxes unboxed tuple types when reifying them In-Reply-To: <050.3278a8386bb0a4b6b9320911f2b0a639@haskell.org> References: <050.3278a8386bb0a4b6b9320911f2b0a639@haskell.org> Message-ID: <065.9bcd39bbadf493639dd974a73d3ce3ba@haskell.org> #12403: Template Haskell boxes unboxed tuple types when reifying them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T12403 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2405 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3470f82fbd7039f9957761c5a12988fd558d6cb8/ghc" 3470f82f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3470f82fbd7039f9957761c5a12988fd558d6cb8" Fix Template Haskell reification of unboxed tuple types Summary: Previously, Template Haskell reified unboxed tuple types as boxed tuples with twice the appropriate arity. Fixes #12403. Test Plan: make test TEST=T12403 Reviewers: hvr, goldfire, austin, bgamari Reviewed By: goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2405 GHC Trac Issues: #12403 (cherry picked from commit 514c4a4741f3881672f1ccc1fe6d08a5d596bb87) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:17 -0000 Subject: [GHC] #12128: ghci cause panic on 8.0.1 In-Reply-To: <043.d0d8e98d01cc863c9b0e7ff6db6baf83@haskell.org> References: <043.d0d8e98d01cc863c9b0e7ff6db6baf83@haskell.org> Message-ID: <058.ce8c4dabff854d7a4df0e31352e2100b@haskell.org> #12128: ghci cause panic on 8.0.1 -------------------------------------+------------------------------------- Reporter: zxtx | Owner: seraphime Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2374 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a0c9685e654f2b4bec90321e261d70b90022e546/ghc" a0c9685e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a0c9685e654f2b4bec90321e261d70b90022e546" Fix bytecode generator panic This fixes #12128. The bug was introduced in 1c9fd3f1c5522372fcaf250c805b959e8090a62c. Test Plan: ./validate Reviewers: simonmar, austin, hvr, simonpj, bgamari Reviewed By: bgamari Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2374 GHC Trac Issues: #12128 (cherry picked from commit 8de6e13f9ef784750e502955fcb38d4a7e179727) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:17 -0000 Subject: [GHC] #12072: GHC panic on type wildcard in left-hand side of data family In-Reply-To: <047.e584aa3b910eba55b26f4ea236a6c9a5@haskell.org> References: <047.e584aa3b910eba55b26f4ea236a6c9a5@haskell.org> Message-ID: <062.ab94f9fe0f7da5a38bee2974adc0683b@haskell.org> #12072: GHC panic on type wildcard in left-hand side of data family -------------------------------------+------------------------------------- Reporter: andreash | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6b583745e63b1489312bb37218028fa8ab2fbbf8/ghc" 6b583745/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6b583745e63b1489312bb37218028fa8ab2fbbf8" Improve documentation for type wildcards This docmentation improvement was triggered by Trac #12072 (cherry picked from commit f9e90bcb202b164189d71535eafbb39577682ff2) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:17 -0000 Subject: [GHC] #12399: DeriveFunctor fail In-Reply-To: <043.b1fcb56ccca9ba47ddb9663057b5be5a@haskell.org> References: <043.b1fcb56ccca9ba47ddb9663057b5be5a@haskell.org> Message-ID: <058.884db3c25a6739c76f6ebc2bd632c645@haskell.org> #12399: DeriveFunctor fail -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T12399 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2404 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1f862acbd7d38b28a205002cded4f7b8824262e5/ghc" 1f862acb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f862acbd7d38b28a205002cded4f7b8824262e5" Make DeriveFunctor work with unboxed tuples Summary: Unboxed tuples have `RuntimeRep` arguments which `-XDeriveFunctor` was mistaking for actual data constructor arguments. As a result, a derived `Functor` instance for a datatype that contained an unboxed tuple would generate twice as many arguments as it needed for an unboxed tuple pattern match or expression. The solution is to simply put `dropRuntimeRepArgs` in the right place. Fixes #12399. Test Plan: ./validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, osa1 Differential Revision: https://phabricator.haskell.org/D2404 GHC Trac Issues: #12399 (cherry picked from commit 3fa3fe8a9a8afa67829e12efa5d25b76e58a185a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:17 -0000 Subject: [GHC] #12365: Update documentation for partial type signatures In-Reply-To: <047.cbfa181c69d689f1b05c74fd008c67ae@haskell.org> References: <047.cbfa181c69d689f1b05c74fd008c67ae@haskell.org> Message-ID: <062.566873d5cf8265542aa9b188d707998b@haskell.org> #12365: Update documentation for partial type signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: thomasw Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2413 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e59121a5555a95911849605606f2076eba70c004/ghc" e59121a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e59121a5555a95911849605606f2076eba70c004" Update docs for partial type signatures (#12365) * Update the sample error messages. The messages have been reworded and reformatted since GHC 7.10. * Mention `TypeApplications` in "Where can they occur?" * The name of a named wild card is no longer used in the name of a resulting type variable. Before: `_foo` => `w_foo`, now: `_foo` => `t` or `a`. Test Plan: generate the users guide Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2413 GHC Trac Issues: #12365 (cherry picked from commit 627c767b8e5587de52086d8891d7f7aabf6fa49f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:04:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:04:17 -0000 Subject: [GHC] #12424: RTS stats show wrong productivity. In-Reply-To: <048.dd6f8ee273b20f973d503ab841f85657@haskell.org> References: <048.dd6f8ee273b20f973d503ab841f85657@haskell.org> Message-ID: <063.9d824c712e299d522bb8dc55954a90ea@haskell.org> #12424: RTS stats show wrong productivity. -----------------------------------+-------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"7885a51b460f064e164b8a690b9c8da45b654049/ghc" 7885a51/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7885a51b460f064e164b8a690b9c8da45b654049" Fix productivity calculation (#12424) (cherry picked from commit 1783011726a355ac7647246699d43bc7d8b6d9f1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:07:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:07:47 -0000 Subject: [GHC] #12403: Template Haskell boxes unboxed tuple types when reifying them In-Reply-To: <050.3278a8386bb0a4b6b9320911f2b0a639@haskell.org> References: <050.3278a8386bb0a4b6b9320911f2b0a639@haskell.org> Message-ID: <065.ff3f9456c4af1b2f528b8f2224a3bffe@haskell.org> #12403: Template Haskell boxes unboxed tuple types when reifying them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T12403 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2405 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.0.2 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:10:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:10:19 -0000 Subject: [GHC] #12403: Template Haskell boxes unboxed tuple types when reifying them In-Reply-To: <050.3278a8386bb0a4b6b9320911f2b0a639@haskell.org> References: <050.3278a8386bb0a4b6b9320911f2b0a639@haskell.org> Message-ID: <065.683ed617015b85093456fa7620dd1416@haskell.org> #12403: Template Haskell boxes unboxed tuple types when reifying them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: th/T12403 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2405 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3219220db283aa09396fc5fd7fe1668ecbe7a512/ghc" 3219220d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3219220db283aa09396fc5fd7fe1668ecbe7a512" Revert "Fix Template Haskell reification of unboxed tuple types" This reverts commit 3470f82fbd7039f9957761c5a12988fd558d6cb8 which we decided not to merge afterall. See #12403. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:10:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:10:30 -0000 Subject: [GHC] #12513: Template Haskell boxes singleton unboxed tuples when splicing them In-Reply-To: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> References: <050.cfe3a939f3f76e4e1c7676c9f25e0c6b@haskell.org> Message-ID: <065.209d8cbdfc8df521f0e021f252f9919b@haskell.org> #12513: Template Haskell boxes singleton unboxed tuples when splicing them -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: th/T12513 Blocked By: | Blocking: Related Tickets: #5332 | Differential Rev(s): Phab:D2462 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.0.2 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:13:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:13:48 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.defcb66c0d9f7ddb3d13c1b583233076@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Currently {{{ foo :: (Char ~ Int => Int) -> a -> a foo _ a2 = a2 }}} gives a similar message. Is that reasonable? The argument to `foo` can't be called. Instance decls are a bit different because you can change the type signature. Eg here is a simpler example {{{ class C a where foo :: (a~Int) => a -> a instance C Bool where foo = undefined }}} The instance decl is rejected, by both GHC 7.10 and HEAD. But of course there's nothing you can do about it. `foo` can't be called, but it needs something for the method `foo`. (It works when you leave out the definition of `foo` altogether, but I think only by accident.) What we need is NOT to complain about inconsistent 'givens' when typechecking instance methods. And certainly not to fail. Would that serve? It would sadly mean that inaccessible code somewhere deep in the body of an instance method wouldn't be reported, but maybe that's a lesser evil. I have not followed all this stuff about `Conjoined`. Is it all the same question? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:43:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:43:25 -0000 Subject: [GHC] #12371: Error message, room for improvement In-Reply-To: <051.4451bd27ef0d80311d9b31d3cc46b800@haskell.org> References: <051.4451bd27ef0d80311d9b31d3cc46b800@haskell.org> Message-ID: <066.9db65c0b318669efee68ea259f59f53a@haskell.org> #12371: Error message, room for improvement -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 02415404ab26a5f12dffd9c98f2a923dbdde2329. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:44:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:44:18 -0000 Subject: [GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows In-Reply-To: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> References: <050.675e99e0c3128be1426b83f1c6310ea3@haskell.org> Message-ID: <065.670bd97fde398d4ca76b7a314d2cd674@haskell.org> #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as 4f6960bff673525ba399f769e1e585c0475c8ca9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:45:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:45:14 -0000 Subject: [GHC] #11947: GHC mistakenly warns about type defaulting in the presence of -XTypeApplications In-Reply-To: <050.0e20687f88786e027fcc8003b550a84a@haskell.org> References: <050.0e20687f88786e027fcc8003b550a84a@haskell.org> Message-ID: <065.d637692e2308832f82783b4540994f1e@haskell.org> #11947: GHC mistakenly warns about type defaulting in the presence of -XTypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_compile/T11947 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as 7a69acc846e19562a0e07f8f5f9a5c01f8084e83. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:46:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:46:05 -0000 Subject: [GHC] #11941: stage restriction mentioned when an identifier is out of scope In-Reply-To: <045.43c65ddae49310b99f4cdd2fca2af7ea@haskell.org> References: <045.43c65ddae49310b99f4cdd2fca2af7ea@haskell.org> Message-ID: <060.29f485802ab7de5501fefcb69e1ca941@haskell.org> #11941: stage restriction mentioned when an identifier is out of scope -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T11941 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 8405c2edddd0cc76c748b109d99f096c33d1dc50. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:46:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:46:45 -0000 Subject: [GHC] #11976: Error message mentions impredicative polymorphism In-Reply-To: <051.4851271d9a01683dfc42210ca66e777c@haskell.org> References: <051.4851271d9a01683dfc42210ca66e777c@haskell.org> Message-ID: <066.c34c3c81731706e8e7794bf3785b58fb@haskell.org> #11976: Error message mentions impredicative polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: partial- | sigs/should_fail/T11976 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 7a69acc846e19562a0e07f8f5f9a5c01f8084e83. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:47:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:47:58 -0000 Subject: [GHC] #11821: Internal error: not in scope during type checking, but it passed the renamer In-Reply-To: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> References: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> Message-ID: <061.715c6ee7b5cbfbbdc3eecb85ff0bb4ce@haskell.org> #11821: Internal error: not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11821 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2146 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as ced7cc010785df5968d15b24703d8f01328a82ba. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:48:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:48:17 -0000 Subject: [GHC] #11484: Type synonym using -XTypeInType can't be spliced with TH In-Reply-To: <050.31117dc14e8cb137c4aa49635eca3d7d@haskell.org> References: <050.31117dc14e8cb137c4aa49635eca3d7d@haskell.org> Message-ID: <065.efa20d2e6e58dbff3e75d0a95dacafa4@haskell.org> #11484: Type synonym using -XTypeInType can't be spliced with TH -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1-rc1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T11484 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2146 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged test to `ghc-8.0` as 999428588c2eb20f66b7dc1a1021aeee759e1df2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:49:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:49:27 -0000 Subject: [GHC] #11833: GHC can't derive instance of polykinded typeclass for newtype that requires a class constraint In-Reply-To: <050.cb2ddf7ed167c7a185a18760753b8ced@haskell.org> References: <050.cb2ddf7ed167c7a185a18760753b8ced@haskell.org> Message-ID: <065.f6b05546ddfe5d2fb8a5362a351fca48@haskell.org> #11833: GHC can't derive instance of polykinded typeclass for newtype that requires a class constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8865, #11837 | Differential Rev(s): Phab:D2112 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as 9cf69d33102aeae925c59d0ccc43a983f1c93081. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:50:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:50:14 -0000 Subject: [GHC] #12474: Regression: Syntax error in -ddump-minimal-imports for records in GHC 8.0 In-Reply-To: <042.a524b4a6c3164cd796982501b5b54c85@haskell.org> References: <042.a524b4a6c3164cd796982501b5b54c85@haskell.org> Message-ID: <057.d375b369cee3b9d6bef27c22b7908379@haskell.org> #12474: Regression: Syntax error in -ddump-minimal-imports for records in GHC 8.0 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 1d46fd5e4897301f3def5267e46e7d07fb85590b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:50:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:50:58 -0000 Subject: [GHC] #11837: GHC fails to unify kinds when deriving polykinded typeclass instance for polykinded newtype In-Reply-To: <050.9f83a773e0afc4665e5b1a4fa16ad903@haskell.org> References: <050.9f83a773e0afc4665e5b1a4fa16ad903@haskell.org> Message-ID: <065.637a62b5db26572e38c933ba49dbf831@haskell.org> #11837: GHC fails to unify kinds when deriving polykinded typeclass instance for polykinded newtype -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8865, #11833 | Differential Rev(s): Phab:D2117 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as ee4c5833b363bbea7a381766d4e11d5ff4737c22. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:51:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:51:33 -0000 Subject: [GHC] #12041: GHC panics on "print_equality ~" In-Reply-To: <051.f878e9e3434ca62afd20bb52b1f57643@haskell.org> References: <051.f878e9e3434ca62afd20bb52b1f57643@haskell.org> Message-ID: <066.95177b57bc39c287db22bb950188a711@haskell.org> #12041: GHC panics on "print_equality ~" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T12041 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as e9f29008ed5ab4d368138f04338e93dee2713257. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:53:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:53:05 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311825=3A_Pretty_printer_doesn=27t_d?= =?utf-8?q?isplay_functional_dependency_with_=E2=80=98=E2=86=92?= =?utf-8?b?4oCZ?= In-Reply-To: <051.0bf8a13abb59676639134e7a6349fbd1@haskell.org> References: <051.0bf8a13abb59676639134e7a6349fbd1@haskell.org> Message-ID: <066.22f4201301f5cf7e4259394cf29d5b3c@haskell.org> #11825: Pretty printer doesn't display functional dependency with ‘→’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 7.10.3 Resolution: fixed | Keywords: unicode, | UnicodeSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2243 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 38036f0d3f0a3776e8aba561f4572a426bb29ee4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:53:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:53:57 -0000 Subject: [GHC] #11960: GHC parallel build failure during "make" In-Reply-To: <047.ec2cf2a2fa93a6c771ea2f164f8f5768@haskell.org> References: <047.ec2cf2a2fa93a6c771ea2f164f8f5768@haskell.org> Message-ID: <062.ef35264f56951c67135d17a365fa9f92@haskell.org> #11960: GHC parallel build failure during "make" -------------------------------------+------------------------------------- Reporter: ilovezfs | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.1-rc3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:6 merged to `ghc-8.0` as 13ae3e4ae2101f63a6919d983941b09943511310. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:54:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:54:33 -0000 Subject: [GHC] #12118: Testsuite driver does not normalise platform-dependent .stdout/stderr files In-Reply-To: <045.c01df6ed03b6b610e1e1edc82dace2e3@haskell.org> References: <045.c01df6ed03b6b610e1e1edc82dace2e3@haskell.org> Message-ID: <060.8d8e258e58428d1d0f300a23c5c07e40@haskell.org> #12118: Testsuite driver does not normalise platform-dependent .stdout/stderr files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2267 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 43eef4353790d1311b29cff28b23cd2e006e633b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 15:56:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 15:56:14 -0000 Subject: [GHC] #12115: CoreLint error in safe program In-Reply-To: <043.b37b5ed016135a00f96e08c4966051af@haskell.org> References: <043.b37b5ed016135a00f96e08c4966051af@haskell.org> Message-ID: <058.d65bbf73e7d81b683c7483c8e7a0d5de@haskell.org> #12115: CoreLint error in safe program -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | codegen/should_compile/T12115 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * milestone: => 8.0.2 Comment: comment:1 merged to `ghc-8.0` as 9ddb9338aa052ef06849c8d6cd8846916d7b2f23 and comment:6 as e9c5ca8aa750b1583f19da195e1e7268ac4a35ff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:03:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:03:22 -0000 Subject: [GHC] #12536: Clarify commentary surrounding unboxed tuples and kind invariant Message-ID: <046.5d66ff923c4bce65944c07731dc3778b@haskell.org> #12536: Clarify commentary surrounding unboxed tuples and kind invariant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ticket:12115#comment:8 notes that there are a few inconsistencies in the comments describing these areas. Simon, could you have a look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:03:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:03:29 -0000 Subject: [GHC] #12536: Clarify commentary surrounding unboxed tuples and kind invariant In-Reply-To: <046.5d66ff923c4bce65944c07731dc3778b@haskell.org> References: <046.5d66ff923c4bce65944c07731dc3778b@haskell.org> Message-ID: <061.3cf2e022f592fff258edc4714877f256@haskell.org> #12536: Clarify commentary surrounding unboxed tuples and kind invariant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonpj Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:03:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:03:51 -0000 Subject: [GHC] #12115: CoreLint error in safe program In-Reply-To: <043.b37b5ed016135a00f96e08c4966051af@haskell.org> References: <043.b37b5ed016135a00f96e08c4966051af@haskell.org> Message-ID: <058.894a364d98b3ac3bac77a552fd33ff3d@haskell.org> #12115: CoreLint error in safe program -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | codegen/should_compile/T12115 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Opened #12536 to track the task of addressing comment:8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:04:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:04:49 -0000 Subject: [GHC] #12147: GHC's Linker Should Support Relocation Type 42 In-Reply-To: <047.ee524e8a3a880d3ebda2e9e3ef5885d0@haskell.org> References: <047.ee524e8a3a880d3ebda2e9e3ef5885d0@haskell.org> Message-ID: <062.7f71304597470496af082a3e7f10f2b6@haskell.org> #12147: GHC's Linker Should Support Relocation Type 42 -------------------------------------+------------------------------------- Reporter: gershomb | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2303 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:8 merged to `ghc-8.0` as efc7ef67d3fe2064dc8f40e73d88026d57bd836f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:05:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:05:32 -0000 Subject: [GHC] #12064: tcIfaceGlobal error with existentially quantified types In-Reply-To: <045.3f2e9cf37ca8869e1da5dbbed8082702@haskell.org> References: <045.3f2e9cf37ca8869e1da5dbbed8082702@haskell.org> Message-ID: <060.f1a6257d518db91d09494d3c13d0f0f2@haskell.org> #12064: tcIfaceGlobal error with existentially quantified types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2221 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 479e0bce4729b84eea6baa29ceee30dc5f99806b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:06:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:06:15 -0000 Subject: [GHC] #12182: Sparks for CAFs get GC'd too eagerly In-Reply-To: <047.45f2d67458e580b5736cda4a08ffccdf@haskell.org> References: <047.45f2d67458e580b5736cda4a08ffccdf@haskell.org> Message-ID: <062.50034ccb13e3b4568c957ef456ab94e7@haskell.org> #12182: Sparks for CAFs get GC'd too eagerly -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 381d451f67e8aecb39bd08db2182ee93138f7ea7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:07:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:07:19 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.48e71c065f7dedd0996a1c1a956c25e6@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => * status: merge => new Comment: Merged comment:41 to `ghc-8.0` as 1c310133bbea168356e86aa38771f0da0d1315af. Reopening as there is likely more to be done here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:07:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:07:55 -0000 Subject: [GHC] #12134: PowerPC 64-bit: Foreign functions with more than 8 float parameters broken In-Reply-To: <047.b2f90e1cc5508bb649499a3ffa202a40@haskell.org> References: <047.b2f90e1cc5508bb649499a3ffa202a40@haskell.org> Message-ID: <062.de777ac7070490d953ee6168f8fb14a8@haskell.org> #12134: PowerPC 64-bit: Foreign functions with more than 8 float parameters broken -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 8.0.1 Resolution: fixed | Keywords: ccall Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | ffi/should_run/T12134 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2327 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:08:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:08:25 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.ac8ace1110bc3738380c741ee37a4cb5@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I think there is morally a difference between {{{#!hs class Foo a where foo :: (a ~ Int => a) -> a -> a }}} and your example which is more like {{{#!hs class Foo a where foo :: (a ~ Int) => a -> a -> a }}} in terms of if we should reject things once we know `a ~ Char`, and that hence `a ~ Int` can never happen. In the former you're given two arguments, one of which requires you to provide something impossible to use, and so simply cant be used, while in the latter you're required to implement a contradiction when you go to write `instance Foo Char`. Notice the polarity of the equality constraint. In the former it is in positive position. In the latter it is in negative position as usual. Finding a contradiction in negative position fits with Richard's intuition about if we should complain, but in positive position it simply means that argument is inaccessible, which is perfectly okay. Someone might pass it in in a more polymorphic setting where they don't know if the constraint could be satisfied or not, until the instance for Foo is selected, which is what is happening here. Today I usually hack around the latter by passing an explicit Dict for the constraint, so that I have the option to bring it into scope or not, and can carefully avoid GHC prematurely detonating upon discovering the contradiction {{{#!hs class Foo a where foo :: Dict (a ~ Int) -> a -> a -> a }}} but until now I haven't had to hack around it for the former -- and the explicit Dict-based solutions are much clunkier to both write, and for users to use in practice. (We used to use this approach to implement ex falso quodlibet in the `constraints` package, but now we just use `Any` directly as an uninhabitable initial `Constraint`.) > Currently {{{#!hs foo :: (Char ~ Int => Int) -> a -> a foo _ a2 = a2 }}} > gives a similar message. Is that reasonable? The argument to foo can't be called. I'd personally think that that should be allowed, as silly as it looks in this very concrete case. `foo` itself doesn't care about the argument at all. The burden of complaining about the impossibility of what we can see locally would be `Int ~ Char` should fall on type checking the argument passed to `foo` at the call site, not to `foo`, and at that call site it may or may not be impossible as it may not know the `Int` part of the equation there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:08:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:08:45 -0000 Subject: [GHC] #12217: PowerPC NCG: Remove TOC save for calls. In-Reply-To: <047.9e933c12a40c44141b6563372c17d615@haskell.org> References: <047.9e933c12a40c44141b6563372c17d615@haskell.org> Message-ID: <062.738f84b5ed61797adcde25577fb45376@haskell.org> #12217: PowerPC NCG: Remove TOC save for calls. -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2328 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as 929c5c5fce455b2cc15015246938e9048d4a9686. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:10:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:10:07 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.a884cc23234252962ccf21bd603f6103@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): That said, I certainly wouldn't complain if both of those things started type checking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:10:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:10:51 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.5a065955e215a61c64af1a73a9942b21@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1900 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * version: 8.1 => 8.0.1 * resolution: => fixed * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:15:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:15:26 -0000 Subject: [GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym In-Reply-To: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> References: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> Message-ID: <060.07e602724facedbc1ff2d778af8663bb@haskell.org> #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:16:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:16:31 -0000 Subject: [GHC] #11974: `default` declaration doesn't allow higher-kinded types In-Reply-To: <047.2c4be3a4c34290389efa6f45ff0342fe@haskell.org> References: <047.2c4be3a4c34290389efa6f45ff0342fe@haskell.org> Message-ID: <062.081ac2fc0f97e537c7c5f50b04d30be0@haskell.org> #11974: `default` declaration doesn't allow higher-kinded types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11974, | typecheck/should_fail/T11974b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2136 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:16:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:16:40 -0000 Subject: [GHC] #11974: `default` declaration doesn't allow higher-kinded types In-Reply-To: <047.2c4be3a4c34290389efa6f45ff0342fe@haskell.org> References: <047.2c4be3a4c34290389efa6f45ff0342fe@haskell.org> Message-ID: <062.a9fb4a2ff91ba9213229eb0d35d1cf14@haskell.org> #11974: `default` declaration doesn't allow higher-kinded types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11974, | typecheck/should_fail/T11974b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2136 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.1 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:17:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:17:12 -0000 Subject: [GHC] #12067: warn-unused-imports does not detect coercions (was: warn-unused-imports does not detect coersions) In-Reply-To: <047.e234196f4d28c1786926628389b4a6f1@haskell.org> References: <047.e234196f4d28c1786926628389b4a6f1@haskell.org> Message-ID: <062.e5547016c46391c09101ad183d0aa171@haskell.org> #12067: warn-unused-imports does not detect coercions -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_compile/T12067 Blocked By: | Blocking: Related Tickets: #10347 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:17:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:17:31 -0000 Subject: [GHC] #12242: panic with complicated type/kind/class expressions In-Reply-To: <053.4658ba704f77806da8153e92cef2d64a@haskell.org> References: <053.4658ba704f77806da8153e92cef2d64a@haskell.org> Message-ID: <068.c59291e66d7ccd9626b780b2ba6ae9ad@haskell.org> #12242: panic with complicated type/kind/class expressions -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:18:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:18:07 -0000 Subject: [GHC] #7679: Regression in -fregs-graph performance In-Reply-To: <047.9e26897513125de7441d596a4b30ee54@haskell.org> References: <047.9e26897513125de7441d596a4b30ee54@haskell.org> Message-ID: <062.c7c5c1e5308282f99b00d470992641d0@haskell.org> #7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.2 Component: Compiler (NCG) | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 3ae474d18251d4e9184bf5d6cbce6ac86fdd46c1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:18:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:18:42 -0000 Subject: [GHC] #12194: ghc-pkg, package database path containing a trailing slash, and ${pkgroot} In-Reply-To: <047.2cca590f8c35da860a7f7b15269f9a76@haskell.org> References: <047.2cca590f8c35da860a7f7b15269f9a76@haskell.org> Message-ID: <062.852722dbd4ba6e3f2958c56e2760f7ca@haskell.org> #12194: ghc-pkg, package database path containing a trailing slash, and ${pkgroot} -------------------------------------+------------------------------------- Reporter: dudebout | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: ghc-pkg | Version: 8.0.1 Resolution: fixed | Keywords: pkgroot Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2336 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as f3bca8f124f0f2d5e26dac083b1fe2d3ad69242a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:19:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:19:28 -0000 Subject: [GHC] #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le Message-ID: <048.e821713d1c06a4d751fa396103744323@haskell.org> #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le ---------------------------------+------------------------------------- Reporter: michelmno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+------------------------------------- as detailed in attached log below the initial failure is a reported Segmentation Fault and if adding debuginfo rpms then reported failure is a ghc: panic for mkFastStringWith -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:20:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:20:14 -0000 Subject: [GHC] #12354: Word foldl' isn't optimized as well as Int foldl' In-Reply-To: <045.bac6bcbeca1cabd22823ab5f537d5cc8@haskell.org> References: <045.bac6bcbeca1cabd22823ab5f537d5cc8@haskell.org> Message-ID: <060.de3a98632dee56b47579773d4ee76889@haskell.org> #12354: Word foldl' isn't optimized as well as Int foldl' -------------------------------------+------------------------------------- Reporter: kjslag | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2376 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:21:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:21:01 -0000 Subject: [GHC] #12195: RTS GetTime.c is broken on Darwins that include clock_gettime In-Reply-To: <049.daef56b071de7a0b4dee3129f5dcf900@haskell.org> References: <049.daef56b071de7a0b4dee3129f5dcf900@haskell.org> Message-ID: <064.384cda2887eecca2d4fa7ecebadcda6b@haskell.org> #12195: RTS GetTime.c is broken on Darwins that include clock_gettime -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0 ` as a0f1809742160ca0c07778f91f3e2a8ea147c0a4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:21:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:21:21 -0000 Subject: [GHC] #12227: regression: out of memory with -O2 -ddump-hi on a complex INLINE function In-Reply-To: <046.5eb6cdc259c89a5a386fca350cf30507@haskell.org> References: <046.5eb6cdc259c89a5a386fca350cf30507@haskell.org> Message-ID: <061.be8a444d1c872939a80a27545811accb@haskell.org> #12227: regression: out of memory with -O2 -ddump-hi on a complex INLINE function -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T12227 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2397 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:21:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:21:24 -0000 Subject: [GHC] #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.6599325d0c8addd2096e553966c8a9b4@haskell.org> #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le -------------------------------------+--------------------------------- Reporter: michelmno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+--------------------------------- Changes (by michelmno): * Attachment "ghc_opengl_twppc64le3_build_failure.log.gz" added. ghc_opengl_twppc64le3_build_failure.log.gz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:21:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:21:47 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311632=3A_Data=2EChar_repeated_readL?= =?utf-8?q?itChar_barfs_on_output_from_show_=22=C3=B31=22?= In-Reply-To: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> References: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> Message-ID: <064.88027e2b73de30b638c5528449322d46@haskell.org> #11632: Data.Char repeated readLitChar barfs on output from show "ó1" -------------------------------------+------------------------------------- Reporter: inversemot | Owner: kgupta Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Core Libraries | Version: 7.10.3 Resolution: fixed | Keywords: newcomer Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: readLitChar Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2391 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:22:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:22:59 -0000 Subject: [GHC] #12399: DeriveFunctor fail In-Reply-To: <043.b1fcb56ccca9ba47ddb9663057b5be5a@haskell.org> References: <043.b1fcb56ccca9ba47ddb9663057b5be5a@haskell.org> Message-ID: <058.5105f6f8d8f759e925fe625ae0bb8430@haskell.org> #12399: DeriveFunctor fail -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T12399 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:23:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:23:04 -0000 Subject: [GHC] #12399: DeriveFunctor fail In-Reply-To: <043.b1fcb56ccca9ba47ddb9663057b5be5a@haskell.org> References: <043.b1fcb56ccca9ba47ddb9663057b5be5a@haskell.org> Message-ID: <058.5a7409ee75954cdd55f560b18ea7919d@haskell.org> #12399: DeriveFunctor fail -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T12399 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.1 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:23:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:23:43 -0000 Subject: [GHC] #12128: ghci cause panic on 8.0.1 In-Reply-To: <043.d0d8e98d01cc863c9b0e7ff6db6baf83@haskell.org> References: <043.d0d8e98d01cc863c9b0e7ff6db6baf83@haskell.org> Message-ID: <058.91bda4468e714ec5deec47b04a647843@haskell.org> #12128: ghci cause panic on 8.0.1 -------------------------------------+------------------------------------- Reporter: zxtx | Owner: seraphime Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2374 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:24:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:24:01 -0000 Subject: [GHC] #12365: Update documentation for partial type signatures In-Reply-To: <047.cbfa181c69d689f1b05c74fd008c67ae@haskell.org> References: <047.cbfa181c69d689f1b05c74fd008c67ae@haskell.org> Message-ID: <062.c85109182f5108188901534cdacaa068@haskell.org> #12365: Update documentation for partial type signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: thomasw Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2413 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:24:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:24:14 -0000 Subject: [GHC] #12424: RTS stats show wrong productivity. In-Reply-To: <048.dd6f8ee273b20f973d503ab841f85657@haskell.org> References: <048.dd6f8ee273b20f973d503ab841f85657@haskell.org> Message-ID: <063.cbd43c2346d6cdd6d85c403fe7ee81d4@haskell.org> #12424: RTS stats show wrong productivity. -----------------------------------+-------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:25:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:25:07 -0000 Subject: [GHC] #12368: Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation In-Reply-To: <046.2b784c018fc4a62b657688676ee901f3@haskell.org> References: <046.2b784c018fc4a62b657688676ee901f3@haskell.org> Message-ID: <061.45774eae56cef06bfd0926651a536031@haskell.org> #12368: Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2392 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"8d92b88df7c1c04606c8a9e12c1d4bee65c990e4/ghc" 8d92b88/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d92b88df7c1c04606c8a9e12c1d4bee65c990e4" DmdAnal: Add a final, safe iteration this fixes #12368. It also refactors dmdFix a bit, removes some redundancies (such as passing around an strictness signature right next to an id, when that id is guaranteed to have been annotated with that strictness signature). Note that when fixed-point iteration does not terminate, we conservatively delete their strictness signatures (set them to nopSig). But this loses the information on how its strict free variables are used! Lazily used variables already escape via lazy_fvs. We ensure that in the case of an aborted fixed-point iteration, also the strict variables are put there (with a conservative demand of topDmd). Differential Revision: https://phabricator.haskell.org/D2392 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:25:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:25:07 -0000 Subject: [GHC] #12435: Turn "No alternatives for a case scrutinee not known to diverge for sure" into a warning In-Reply-To: <046.86fe10487270419d402270c6ee8b1e23@haskell.org> References: <046.86fe10487270419d402270c6ee8b1e23@haskell.org> Message-ID: <061.5750ab4dd3fdce50cb7ca3e6f3044187@haskell.org> #12435: Turn "No alternatives for a case scrutinee not known to diverge for sure" into a warning -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"ec7fcfdda7f4655f4cc4399d1b3f4bc2543809db/ghc" ec7fcfd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ec7fcfdda7f4655f4cc4399d1b3f4bc2543809db" Degrade "case scrutinee not known to diverge for sure" Lint error to warning as proposed in #12435, as it easily gets in the way of development when it reports false positives. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:37:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:37:00 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.8e34d567939147c2dc6dc203f12ca7cd@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2430, Wiki Page: | Phab:D2441 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9f1b6de8b3f788730fa5e2206fb709400299be7c/ghc" 9f1b6de8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9f1b6de8b3f788730fa5e2206fb709400299be7c" Fix to thread migration Summary: If we had 2 threads on the run queue, say [A,B], and B is bound to the current Task, then we would fail to migrate any threads. This fixes it so that we would migrate A in that case. This will help parallelism a bit in programs that have lots of bound threads. Test Plan: Test program in #12419, which is actually not a great program but it does behave a bit better after this change. Reviewers: ezyang, niteria, bgamari, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2430 GHC Trac Issues: #12419 (cherry picked from commit 988ad8ba8e709eff3cea59728e481bb269fa6185) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:37:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:37:00 -0000 Subject: [GHC] #12208: double free or corruption (TEST=T5644 WAY=threaded1) In-Reply-To: <045.fd652ba7dc4466c42b741d91145f0f7f@haskell.org> References: <045.fd652ba7dc4466c42b741d91145f0f7f@haskell.org> Message-ID: <060.34f90445b876116ef34bb177b5db79f4@haskell.org> #12208: double free or corruption (TEST=T5644 WAY=threaded1) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"eb40deb73215971b5e745cc7cc454124b7ac5250/ghc" eb40deb7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb40deb73215971b5e745cc7cc454124b7ac5250" Fix double-free in T5644 (#12208) (cherry picked from commit e7e42c838e32ef1e05daf04b0b6afb62ffc4ec97) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:37:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:37:00 -0000 Subject: [GHC] #12062: Parallel make with -j0 and hs-boot leads to floating point exception In-Reply-To: <045.f05741a711c24d381cb39c4a23db2a0e@haskell.org> References: <045.f05741a711c24d381cb39c4a23db2a0e@haskell.org> Message-ID: <060.45f9a5a40b6336aca58f2fedb9418038@haskell.org> #12062: Parallel make with -j0 and hs-boot leads to floating point exception -------------------------------------+------------------------------------- Reporter: ezyang | Owner: petercommand Type: bug | Status: merge Priority: low | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1-rc2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2415 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6f804c249bf4ca9b8b3b63796fc36c0ec69a936b/ghc" 6f804c24/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6f804c249bf4ca9b8b3b63796fc36c0ec69a936b" check that the number of parallel build is greater than 0 Fixes #12062. Reviewers: bgamari, thomie, austin, simonmar Reviewed By: bgamari, thomie, simonmar Subscribers: simonmar, thomie Differential Revision: https://phabricator.haskell.org/D2415 GHC Trac Issues: #12062 (cherry picked from commit f09d65474ed042360999cb88221d65b07bfb4b5f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:37:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:37:00 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.2e8fb724af75c2c722cb5b38f171f66d@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2430, Wiki Page: | Phab:D2441 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"13ff3423e058a409b035acce5c1448237885ac84/ghc" 13ff3423/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13ff3423e058a409b035acce5c1448237885ac84" Another try to get thread migration right Summary: This is surprisingly tricky. There were linked list bugs in the previous version (D2430) that showed up as a test failure in setnumcapabilities001 (that's a great stress test!). This new version uses a different strategy that doesn't suffer from the problem that @ezyang pointed out in D2430. We now pre-calculate how many threads to keep for this capability, and then migrate any surplus threads off the front of the queue, taking care to account for threads that can't be migrated. Test Plan: 1. setnumcapabilities001 stress test with sanity checking (+RTS -DS) turned on: ``` cd testsuite/tests/concurrent/should_run make TEST=setnumcapabilities001 WAY=threaded1 EXTRA_HC_OPTS=-with- rtsopts=-DS CLEANUP=0 while true; do ./setnumcapabilities001.run/setnumcapabilities001 4 9 2000 || break; done ``` 2. The test case from #12419 Reviewers: niteria, ezyang, rwbarton, austin, bgamari, erikd Subscribers: thomie, ezyang Differential Revision: https://phabricator.haskell.org/D2441 GHC Trac Issues: #12419 (cherry picked from commit 89fa4e968f47cfb42d0dc33fc3bfffdce31d850e) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:37:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:37:00 -0000 Subject: [GHC] #12484: Missing pattern synonym signatures gives incorrect fix In-Reply-To: <044.a1aab187eadc781630dbc7d467492c17@haskell.org> References: <044.a1aab187eadc781630dbc7d467492c17@haskell.org> Message-ID: <059.10c19c4b0f8f77d6fe5f0691feb9edd1@haskell.org> #12484: Missing pattern synonym signatures gives incorrect fix -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11053 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ca58946e7b3ac32785ef073e0e4daeece31dfd70/ghc" ca58946e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ca58946e7b3ac32785ef073e0e4daeece31dfd70" Improve missing-sig warning Fixes Trac #12484 (cherry picked from commit ac0e11252af149f085e2262200b7a1638b4a1553) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:37:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:37:00 -0000 Subject: [GHC] #12489: undefined in view pattern inside pattern synonym causes GHC to panic In-Reply-To: <043.13b77b21ce220facef2dc94f07499681@haskell.org> References: <043.13b77b21ce220facef2dc94f07499681@haskell.org> Message-ID: <058.7b9e50e16382353144c1ed18bc631c9a@haskell.org> #12489: undefined in view pattern inside pattern synonym causes GHC to panic -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | patsyn/should_compile/T12489 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"829b9682969a5dabd3a75b82864c48c2e6a19ee8/ghc" 829b9682/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="829b9682969a5dabd3a75b82864c48c2e6a19ee8" Keep the bindings local during defaultCallStacks defaultCallStacks generates evidence bindings for call stacks, but wasn't setting the binding site correctly. As a result they were simply discarded in the case of pattern synonyms, giving rise to Trac #12489. The fix is easy; and I added an ASSERT to catch the error earlier. (cherry picked from commit f352e5cd7bb629fe0ca3b913bfbe7bee43d62f3a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:37:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:37:00 -0000 Subject: [GHC] #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages In-Reply-To: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> References: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> Message-ID: <059.1b695eaabf0f132c9812e9d968f51908@haskell.org> #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages -------------------------------------+------------------------------------- Reporter: ertes | Owner: ak3n Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_fail/T12406 Blocked By: | Blocking: Related Tickets: #12170 | Differential Rev(s): Phab:D2451 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6071ecf4ff7501c70456c1448fa2f78e91bc8078/ghc" 6071ecf4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6071ecf4ff7501c70456c1448fa2f78e91bc8078" Not-in-scope variables are always errors This fixes Trac #12406. A not-in-scope error shoudl be an error even if you have -fdefer-typed-holes. (cherry picked from commit efc0372a157eadeee58bbada77c64d53590e04af) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:37:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:37:00 -0000 Subject: [GHC] #12038: Shutdown interacts badly with requestSync() In-Reply-To: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> References: <047.55986d4d6d0cb4f4e54545fae8ff67a3@haskell.org> Message-ID: <062.5ebf7b0fce953a3d28f35ab4c36f3874@haskell.org> #12038: Shutdown interacts badly with requestSync() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2f319609ef0ebffc46aad7f4ad14d5c26750e3ba/ghc" 2f31960/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f319609ef0ebffc46aad7f4ad14d5c26750e3ba" Fix ASSERT failure and re-enable setnumcapabilities001 The assertion failure was fairly benign, I think, but this fixes it. I've been running the test repeatedly for the last 30 mins and it hasn't triggered. There are other problems exposed by this test (see #12038), but I've worked around those in the test itself for now. I also copied the relevant bits of the parallel library here so that we don't need parallel for the test to run. (cherry picked from commit cfc5df43a7789832a2789e517d8270650cc31b7f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:40:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:40:51 -0000 Subject: [GHC] #12419: Scheduling bug with forkOS + MVar In-Reply-To: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> References: <050.3157bd68c480bed634d3591e7003b69b@haskell.org> Message-ID: <065.c832971815f3b33cff8d1468c8f7b3b3@haskell.org> #12419: Scheduling bug with forkOS + MVar -------------------------------------+------------------------------------- Reporter: luisgabriel | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: forkOS; | scheduler Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2430, Wiki Page: | Phab:D2441 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:41:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:41:13 -0000 Subject: [GHC] #12062: Parallel make with -j0 and hs-boot leads to floating point exception In-Reply-To: <045.f05741a711c24d381cb39c4a23db2a0e@haskell.org> References: <045.f05741a711c24d381cb39c4a23db2a0e@haskell.org> Message-ID: <060.2aadcf3bd54fbe78e59761556d410dbc@haskell.org> #12062: Parallel make with -j0 and hs-boot leads to floating point exception -------------------------------------+------------------------------------- Reporter: ezyang | Owner: petercommand Type: bug | Status: closed Priority: low | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1-rc2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2415 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:41:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:41:31 -0000 Subject: [GHC] #12484: Missing pattern synonym signatures gives incorrect fix In-Reply-To: <044.a1aab187eadc781630dbc7d467492c17@haskell.org> References: <044.a1aab187eadc781630dbc7d467492c17@haskell.org> Message-ID: <059.1ac75b7c01bcf003978c0aa5c2feecfe@haskell.org> #12484: Missing pattern synonym signatures gives incorrect fix -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11053 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:41:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:41:51 -0000 Subject: [GHC] #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages In-Reply-To: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> References: <044.c9551a60b09d198ee5f397948d731bf8@haskell.org> Message-ID: <059.2252da5369c0b6dd76efe9a2952fda76@haskell.org> #12406: New not-in-scope behaviour + deferred typed holes = disappearing error messages -------------------------------------+------------------------------------- Reporter: ertes | Owner: ak3n Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_fail/T12406 Blocked By: | Blocking: Related Tickets: #12170 | Differential Rev(s): Phab:D2451 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:42:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:42:24 -0000 Subject: [GHC] #12489: undefined in view pattern inside pattern synonym causes GHC to panic In-Reply-To: <043.13b77b21ce220facef2dc94f07499681@haskell.org> References: <043.13b77b21ce220facef2dc94f07499681@haskell.org> Message-ID: <058.ac4668fe261c5900e401765326ad9a8e@haskell.org> #12489: undefined in view pattern inside pattern synonym causes GHC to panic -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | patsyn/should_compile/T12489 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * version: 8.1 => 8.0.1 * resolution: => fixed * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:51:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:51:12 -0000 Subject: [GHC] #12077: DYNAMIC_GHC_PROGRAMS=NO: T8761 is failing (Make pattern synonyms work with Template Haskell) In-Reply-To: <045.60294a744526480b093ee47fef543bec@haskell.org> References: <045.60294a744526480b093ee47fef543bec@haskell.org> Message-ID: <060.9d6d4930a72c995d0e18be48de910ae7@haskell.org> #12077: DYNAMIC_GHC_PROGRAMS=NO: T8761 is failing (Make pattern synonyms work with Template Haskell) -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T8761 Blocked By: | Blocking: Related Tickets: #8761 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * version: 8.0.1 => 8.1 * resolution: => fixed * milestone: 8.0.2 => 8.2.1 Comment: This test doesn't exist on `ghc-8.0` as TH support for pattern synonyms (#8761) wasn't yet merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:52:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:52:47 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.dac7f1802ce4101fa6bde920864a058c@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ​Phab:D2216 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): [research.microsoft.com/en-us/um/...f/promotion-tldi12-sub.pdf Giving Haskell a Promotion]: {{{#!hs data Mu :: forall k. ((k -> Type) -> (k -> Type)) -> (k -> Type) where Roll :: f (Mu f) a -> Mu f a data VecF :: Type -> (Nat -> Type) -> (Nat -> Type) where VFNil :: VecF a f Zero VFCons :: a -> f n -> VecF a f (Succ n) }}} Applying `type Vec a n = Mu (VecF a) n` instantiates `k` to `Nat` in `Mu`, so this should work: {{{ >>> :kind Mu Mu :: ((k -> Type) -> k -> Type) -> k -> Type >>> :kind Mu @Nat Mu @Nat :: ((Nat -> Type) -> Nat -> Type) -> Nat -> Type >>> :kind forall a. Mu @Nat (VecF a) forall a. Mu @Nat (VecF a) :: Nat -> Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 16:53:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 16:53:45 -0000 Subject: [GHC] #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable In-Reply-To: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> References: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> Message-ID: <065.b65d72ac5bcecb4d5e952cd353788375@haskell.org> #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: T12031 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2316 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Phyx, do you think you could rebase comment:6 onto the `ghc-8.0` branch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 17:10:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 17:10:52 -0000 Subject: [GHC] #12175: Instance resolution regression In-Reply-To: <047.eebbfe30afafd756d0e37026c57d7434@haskell.org> References: <047.eebbfe30afafd756d0e37026c57d7434@haskell.org> Message-ID: <062.d83864c0d12acb1ec96b600207e2341e@haskell.org> #12175: Instance resolution regression -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T12175 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Indeed this appears to be fixed in `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 17:18:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 17:18:16 -0000 Subject: [GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym In-Reply-To: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> References: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> Message-ID: <060.2fe517a6f7d9c1ae614438966dbed6df@haskell.org> #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 17:24:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 17:24:28 -0000 Subject: [GHC] #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 In-Reply-To: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> References: <046.16fee1c0ad28881e1f272636dfd13b83@haskell.org> Message-ID: <061.91ee0185c0579136d36cc0ec07e47200@haskell.org> #11443: SPECIALIZE pragma does not work + compilation times regression in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => closed * resolution: => wontfix Comment: I'm going to close this for now. Danilo2, if you can test with 8.0.1 then feel free to reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 17:27:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 17:27:58 -0000 Subject: [GHC] #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV In-Reply-To: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> References: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> Message-ID: <060.51261a9a70c0d7d8eb1649465d05bdba@haskell.org> #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV ---------------------------------+---------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4820 | Differential Rev(s): Phab:D2174 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): erikd, any update on these additional tests? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 17:29:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 17:29:29 -0000 Subject: [GHC] #12019: Profiling option -hb is not thread safe In-Reply-To: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> References: <044.c916057b5b621f461c24cd1e505f507d@haskell.org> Message-ID: <059.a5f278784b45729a02f5895390e8cdec@haskell.org> #12019: Profiling option -hb is not thread safe -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978, #12009 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): We should at least try to disable it except at `-N1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 19:16:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 19:16:44 -0000 Subject: [GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym In-Reply-To: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> References: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> Message-ID: <060.f8fc63e928ee4545d1b761b2ab1fa629@haskell.org> #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 19:46:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 19:46:56 -0000 Subject: [GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym In-Reply-To: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> References: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> Message-ID: <060.4628d892014cb732d87d510440b44eb3@haskell.org> #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I don't think this is a great idea. The specification about what can appear on the RHS is currently very simple, it just has to be a pattern. The rules for turning this pattern into an expression are also very simple and rely on the fact that a lot of pattern syntax looks like the corresponding expression. Allowing this change complicates things, firstly in the parser, `Vec (x : unVec xs)` is not valid pattern syntax currently. Secondly, the rules for how to perform the inversion require more thought. Looking at Simon's example, I have to think a bit about what should happen.. it seems the corresponding expression should be `Vec (x : Vec xs)` but I'm still not sure that is right! Perhaps the rule is as simple as replace the function with it's inverse but it seems ad-hoc to me. I do have other lingering concerns that the way we designed the feature, the most useful constructs are the least supported. I'm referring to the fact that all interesting uses are explicitly bidirectional pattern synonyms which require view patterns. Such definitions tend to be quite noisy to define -- something more like views would have made things cleaner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 20:02:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 20:02:51 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.8341c753d783bf52a26eecd8da908635@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I also apologise. Like Richard, I missed the fact that the constraint was appearing in the positive position. Sorry for all the confusion! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 20:12:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 20:12:46 -0000 Subject: [GHC] #12538: Incorrect uses of overlapping instances and data families sends GHC into loop Message-ID: <043.73b9606c82869f13ef2cf5bbad585344@haskell.org> #12538: Incorrect uses of overlapping instances and data families sends GHC into loop -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sorry for the lack of descriptive title, as I can't nail down the source of this specific bug. This is the minimal example to trigger the loop: {{{#!hs {-# LANGUAGE CPP #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Main where import GHC.TypeLits import GHC.Types data Tagged t a = Tagged a type family Tag a where Tag (Tagged t a) = Tagged t a Tag a = Tagged Int a class (r ~ Tag a) => TagImpl a r | a -> r where tag :: a -> r instance {-# OVERLAPPING #-} (r ~ Tag (Tagged t a)) => TagImpl (Tagged t a) r where tag = id #ifdef WRONG instance {-# OVERLAPPING #-} (r ~ Tagged t a, r ~ Tag a) => TagImpl a r where #else instance {-# OVERLAPPING #-} (r ~ Tagged Int a, r ~ Tag a) => TagImpl a r where #endif tag = Tagged @Int data family DF x data instance DF (Tagged t a) = DF (Tagged t a) class ToDF a b | a -> b where df :: a -> b #ifdef WRONG instance (TagImpl a a', b ~ DF a') => ToDF a b where #else instance (TagImpl a (Tagged t a'), b ~ DF (Tagged t a')) => ToDF a b where #endif df = DF . tag main :: IO () main = pure () }}} When compiled with `-DWRONG`, it causes GHC (both 8.0.1 and HEAD at 20160823) to loop: {{{ $ ghc --version && ghc -fno-code Main.hs -DWRONG The Glorious Glasgow Haskell Compilation System, version 8.1.20160823 [1 of 1] Compiling Main ( Main.hs, nothing ) (loops indefinitely...) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 20:17:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 20:17:53 -0000 Subject: [GHC] #12538: Incorrect usage of overlapping instances and data families sends GHC into loop (was: Incorrect uses of overlapping instances and data families sends GHC into loop) In-Reply-To: <043.73b9606c82869f13ef2cf5bbad585344@haskell.org> References: <043.73b9606c82869f13ef2cf5bbad585344@haskell.org> Message-ID: <058.14eb1f5985040812fa92be0ad37ead9a@haskell.org> #12538: Incorrect usage of overlapping instances and data families sends GHC into loop -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 20:23:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 20:23:04 -0000 Subject: [GHC] #12538: Incorrect usage of overlapping instances and data families sends GHC into loop In-Reply-To: <043.73b9606c82869f13ef2cf5bbad585344@haskell.org> References: <043.73b9606c82869f13ef2cf5bbad585344@haskell.org> Message-ID: <058.addab7d411a3b9c9add29f0590b5a3b4@haskell.org> #12538: Incorrect usage of overlapping instances and data families sends GHC into loop -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by pkmx: @@ -1,2 +1,2 @@ - Sorry for the lack of descriptive title, as I can't nail down the source - of this specific bug. This is the minimal example to trigger the loop: + Sorry for the lack of descriptive title as I can't nail down the source of + the bug. This is the minimal example to trigger the loop: @@ -14,3 +14,0 @@ - - import GHC.TypeLits - import GHC.Types New description: Sorry for the lack of descriptive title as I can't nail down the source of the bug. This is the minimal example to trigger the loop: {{{#!hs {-# LANGUAGE CPP #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Main where data Tagged t a = Tagged a type family Tag a where Tag (Tagged t a) = Tagged t a Tag a = Tagged Int a class (r ~ Tag a) => TagImpl a r | a -> r where tag :: a -> r instance {-# OVERLAPPING #-} (r ~ Tag (Tagged t a)) => TagImpl (Tagged t a) r where tag = id #ifdef WRONG instance {-# OVERLAPPING #-} (r ~ Tagged t a, r ~ Tag a) => TagImpl a r where #else instance {-# OVERLAPPING #-} (r ~ Tagged Int a, r ~ Tag a) => TagImpl a r where #endif tag = Tagged @Int data family DF x data instance DF (Tagged t a) = DF (Tagged t a) class ToDF a b | a -> b where df :: a -> b #ifdef WRONG instance (TagImpl a a', b ~ DF a') => ToDF a b where #else instance (TagImpl a (Tagged t a'), b ~ DF (Tagged t a')) => ToDF a b where #endif df = DF . tag main :: IO () main = pure () }}} When compiled with `-DWRONG`, it causes GHC (both 8.0.1 and HEAD at 20160823) to loop: {{{ $ ghc --version && ghc -fno-code Main.hs -DWRONG The Glorious Glasgow Haskell Compilation System, version 8.1.20160823 [1 of 1] Compiling Main ( Main.hs, nothing ) (loops indefinitely...) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 20:24:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 20:24:03 -0000 Subject: [GHC] #12539: Possible typo causes Stack and Cabal installs to fail Message-ID: <046.addee2c026228d83f37e1e76899d7fc7@haskell.org> #12539: Possible typo causes Stack and Cabal installs to fail -------------------------------------+------------------------------------- Reporter: ConorIA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I have been trying to use https://github.com/thriqon/pandoc-docker or to add pandoc to https://github.com/mitchty/alpine-ghc. However, in both cases, install commands are running into an issue with the '-nopie' flag passed to GCC. The gist of the error thrown when using wither Cabal or Stack is: {{{ : Warning: Couldn't figure out linker information! Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc. gcc: error: unrecognized command line option '-nopie'; did you mean '-no- pie'? ) }}} I am not sure where the error is, as I am really a non-expert. But the gcc linking option is "-no-pie", so if there is indeed an option "-nopie" being passed, it seems like it is a typo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 22:00:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 22:00:14 -0000 Subject: [GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym In-Reply-To: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> References: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> Message-ID: <060.53ab411dfe90dc39085bec06f6d0db3a@haskell.org> #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great or not, it's pretty simple. Adding newtype patterns on the left is really quite tricky. It took me 15 mins to grok. As to the parser, it parses patterns as expressions, and then converts them to patterns. Then the patsyn code converst it back (for bidirectional). So maybe we should leave it as an expression! The rule is still simple: to use it as an expression, just use the exression. To use it as a pattern, just treat `unVec e` as the view pattern `(Vec -> e)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 22:09:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 22:09:48 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.fa2dd8d5bfe4fb259e687f6bef440edb@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree with your reasoning, but it's quite painful to implement the positive/negative distinction (given the way the constraint solver works). Anything is possible, but this all seems a bit exotic, so I'm inclined to look for a simple solution. I think it would be simple to: * Not complain about inaccessible code in instance methods Would that do? Currently GHC tries to do co/contra checking for subsumption checking. If we just used equality on the LHS of arrow, I think the negative/positive problem would disappear. Which is an intesting strike in favour of that approach. That would mean that this would fail: {{{ f :: (Int -> Int) -> Int g :: (forall a. a-> a) -> Int g = f }}} On the other hand, with the same signatures {{{ g x = f x }}} would succeed. The current co/contra subsumption is clever, but tricky... eg every foray into impredicative polymorphism gives up on it. Maybe we should give up on it now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 22:16:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 22:16:06 -0000 Subject: [GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym In-Reply-To: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> References: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> Message-ID: <060.8fb981596ad15dcdc77dfc176f0f9e09@haskell.org> #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It seems like quite a big change to me to specify the expression rather than the pattern. It also raises questions in the case of explicitly bidirectional pattern synonyms, do you specify two expressions? One which gets actually converted to a pattern and one which actually gets used in expressions? What about for implicitly bidirectional pattern synonyms do we still specify an expression on the RHS? Still quite tricky with some details to be worked out! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 22:28:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 22:28:10 -0000 Subject: [GHC] #12540: RFC: Allow not quantifying every top-level quantifiee Message-ID: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> #12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Minor nuisance, does this happen to anyone else? Currently Haskell has an all-nothing policy on quantified type variables, either you quantify none or all (fine, let's ignore non-prenex quantification `foo :: a -> forall b. b -> a`). Can we have a top-level quantification of only a subset of the free variables? Say I'm working on a function {{{#!hs reflected :: forall s m a. (Applicative m, Reifies s a) => TaggedT s m a }}} and I need to make ''s'' a scoped type variable, I always accidentally write {{{#!hs reflected :: forall s. (Applicative m, Reifies s a) => TaggedT s m a reflected = TagT . pure . reflect $ (Proxy :: Proxy s) }}} This causes GHC to complain that the other types — ''m'', ''a'' — are not in scope so and I have to add the remaining quantifiees I don't really care about (may have long names as well). It could be worse (''dramatization'') {{{#!hs ipartsOf :: forall i p f s t a. (Indexable [i] p, Functor f) => Traversing (Indexed i) f s t a a -> Over p f s t [a] [a] ipartsOf l = conjoined (\f s -> let b = inline l sell s in outs b <$> f (wins b)) (\f s -> let b = inline l sell s; (is, as) = unzip (pins b) in outs b <$> indexed f (is :: [i]) as) appendAssocAxiom :: forall p q r as bs cs. p as -> q bs -> r cs -> Dict ((as ++ (bs ++ cs)) ~ ((as ++ bs) ++ cs)) appendAssocAxiom _ _ _ = unsafeCoerce (Dict :: Dict (as ~ as)) }}} It would be nice to be nice to only have to specify the type one is interested in: {{{#!hs ipartsOf :: forall i. (Indexable [i] p, Functor f) => Traversing (Indexed i) f s t a a -> Over p f s t [a] [a] appendAssocAxiom :: forall as. p as -> q bs -> r cs -> Dict ((as ++ (bs ++ cs)) ~ ((as ++ bs) ++ cs)) }}} and have the others chosen in some way. This is not just useful for writing, but it makes it easier to read: If I see a type `forall i p f s t a. ...` any of them may appear in the function body, if I see a type `forall i. ...` I know only one is. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 22:33:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 22:33:54 -0000 Subject: [GHC] #12540: RFC: Allow not quantifying every top-level quantifiee In-Reply-To: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> References: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> Message-ID: <066.e5bf54edf6d6fd111a7cc9bf641f4ff2@haskell.org> #12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I also regularly do this! Seems like a sensible suggestion to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 22:43:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 22:43:18 -0000 Subject: [GHC] #12540: RFC: Allow not quantifying every top-level quantifiee In-Reply-To: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> References: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> Message-ID: <066.937175b70b665db35ea9d0825d777476@haskell.org> #12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -11,1 +11,1 @@ - reflected :: forall s m a. (Applicative m, Reifies s a) => TaggedT s m a + reflected :: (Applicative m, Reifies s a) => TaggedT s m a New description: Minor nuisance, does this happen to anyone else? Currently Haskell has an all-nothing policy on quantified type variables, either you quantify none or all (fine, let's ignore non-prenex quantification `foo :: a -> forall b. b -> a`). Can we have a top-level quantification of only a subset of the free variables? Say I'm working on a function {{{#!hs reflected :: (Applicative m, Reifies s a) => TaggedT s m a }}} and I need to make ''s'' a scoped type variable, I always accidentally write {{{#!hs reflected :: forall s. (Applicative m, Reifies s a) => TaggedT s m a reflected = TagT . pure . reflect $ (Proxy :: Proxy s) }}} This causes GHC to complain that the other types — ''m'', ''a'' — are not in scope so and I have to add the remaining quantifiees I don't really care about (may have long names as well). It could be worse (''dramatization'') {{{#!hs ipartsOf :: forall i p f s t a. (Indexable [i] p, Functor f) => Traversing (Indexed i) f s t a a -> Over p f s t [a] [a] ipartsOf l = conjoined (\f s -> let b = inline l sell s in outs b <$> f (wins b)) (\f s -> let b = inline l sell s; (is, as) = unzip (pins b) in outs b <$> indexed f (is :: [i]) as) appendAssocAxiom :: forall p q r as bs cs. p as -> q bs -> r cs -> Dict ((as ++ (bs ++ cs)) ~ ((as ++ bs) ++ cs)) appendAssocAxiom _ _ _ = unsafeCoerce (Dict :: Dict (as ~ as)) }}} It would be nice to be nice to only have to specify the type one is interested in: {{{#!hs ipartsOf :: forall i. (Indexable [i] p, Functor f) => Traversing (Indexed i) f s t a a -> Over p f s t [a] [a] appendAssocAxiom :: forall as. p as -> q bs -> r cs -> Dict ((as ++ (bs ++ cs)) ~ ((as ++ bs) ++ cs)) }}} and have the others chosen in some way. This is not just useful for writing, but it makes it easier to read: If I see a type `forall i p f s t a. ...` any of them may appear in the function body, if I see a type `forall i. ...` I know only one is. Thoughts? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 23:37:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 23:37:04 -0000 Subject: [GHC] #12539: Possible typo causes Stack and Cabal installs to fail In-Reply-To: <046.addee2c026228d83f37e1e76899d7fc7@haskell.org> References: <046.addee2c026228d83f37e1e76899d7fc7@haskell.org> Message-ID: <061.3eca1d33d6bd2d7b14f5ff25df8d9012@haskell.org> #12539: Possible typo causes Stack and Cabal installs to fail -------------------------------------+------------------------------------- Reporter: ConorIA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Could you paste both (1) the invocation of GHC with all the flags being given, and (2) the command line flags passed to ld which are causing it to break? (1) should be possible by passing `-v` to Cabal/Stack, and (2) should be possible by passing `-v` to GHC (you might need a higher level of verbosity than this.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 23:46:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 23:46:20 -0000 Subject: [GHC] #12423: Panic with DeriveAnyClass In-Reply-To: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> References: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> Message-ID: <061.1b89817e91e70db576428417779c76a1@haskell.org> #12423: Panic with DeriveAnyClass -------------------------------------+------------------------------------- Reporter: knrafto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12144 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: GenericDeriving => Generics -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 25 23:53:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Aug 2016 23:53:10 -0000 Subject: [GHC] #12423: Panic with DeriveAnyClass In-Reply-To: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> References: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> Message-ID: <061.63aae6f0025edbc1c6c98a9b6106172b@haskell.org> #12423: Panic with DeriveAnyClass -------------------------------------+------------------------------------- Reporter: knrafto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12144 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I apologize, comment:3 is wrong in stating that you can't derive an `Eq1` instance for `Foo`. It is most certainly possible to–after all, you can create the following instance! {{{#!hs instance Eq1 Foo }}} That eta-reduction stuff was me confusing the details of `DeriveAnyClass` with other deriving mechanisms, like `GeneralizedNewtypeDeriving` and `DeriveFunctor`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 01:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 01:02:18 -0000 Subject: [GHC] #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable In-Reply-To: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> References: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> Message-ID: <065.5a2ba6c10786b2b2877e66170adffdec@haskell.org> #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: T12031 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2316 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @bgamari, Sure, no problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 01:27:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 01:27:19 -0000 Subject: [GHC] #12541: RFC: Implicit parentheses in GHCi Message-ID: <051.0f37f2ad7849c53a6b8e734049b8e9ca@haskell.org> #12541: RFC: Implicit parentheses in GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've been making a few tickets lately that aren't technical but small things that would streamline my interactive experience. Please close if this is not the place for it. ''Caveat lector'': long and boring read ahead. = Code = {{{#!hs data Op = Add | Mul deriving Show data Exp = Op Op | Lit Int | Exp :$ Exp deriving Show infixl :$ }}} = Motivation = I often want to see the “progression” of applying an operator to arguments one by one. There are several ways of doing this: {{{#!hs >>> :t (:$) >>> :t (Op Add :$) >>> :t Op Add :$ Lit 10 }}} {{{#!hs >>> :t (:$) >>> :t (Op Add :$) >>> :t (Op Add :$) (Lit 10) }}} {{{#!hs >>> :t (:$) >>> :t (:$) (Op Add) >>> :t (:$) (Op Add) (Lit 10) }}} {{{#!hs >>> :t (:$) >>> :t (:$) (Op Add) >>> :t Op Add :$ Lit 10 }}} Look at all of those parentheses! Every step adds or removes (or requires navigation around) parentheses. = `tl;dr`: this is annoying to type = I'm writing this out in full not just because I get a sick joy out of it but to hammer the point home. === First example === We wrap `:$` in parentheses, navigate around them to make a section and then remove them: {{{#!hs >>> >>> :t (:$)␣ -- C-m >>> -- C-p >>> :t (:$)␣ -- C-a >>> ␣:t (:$) -- C-f, C-f, C-f, C-f >>> :t (␣:$) >>> :t (Op Add ␣:$) -- C-m >>> -- C-p >>> :t (Op Add :$)␣ -- C-h >>> :t (Op Add :$␣ >>> :t (Op Add :$ Lit 10 -- C-a >>> ␣:t (Op Add :$ Lit 10 -- C-f, C-f, C-f >>> :t ␣(Op Add :$ Lit 10 -- C-d >>> :t ␣Op Add :$ Lit 10 }}} === Second example === We wrap `:$` in parentheses, navigate around them to make a section and then wrap the argument in parentheses: {{{#!hs >>> >>> :t (:$)␣ -- C-m >>> -- C-p >>> :t (:$)␣ -- C-a >>> ␣:t (:$) -- C-f, C-f, C-f, C-f >>> :t (␣:$) >>> :t (Op Add ␣:$) -- C-m >>> -- C-p >>> :t (Op Add :$)␣ >>> :t (Op Add :$) (Lit 10)␣ }}} === Third example === Wrap everything in parentheses, on a good day I will remember that the arguments need parentheses: {{{#!hs >>> >>> :t (:$)␣ -- C-m >>> -- C-p >>> :t (:$)␣ >>> :t (:$) (Op Add)␣ -- C-m >>> -- C-p >>> :t (:$) (Op Add)␣ >>> :t (:$) (Op Add) (Lit 10)␣ }}} ((On every other day I will forget that `Op Add` is an application and write..)) {{{#!hs >>> :t (:$)␣ >>> :t (:$) Add␣ -- M-b >>> :t (:$) ␣Add >>> :t (:$) (Op ␣Add -- C-e >>> :t (:$) (Op Add␣ >>> :t (:$) (Op Add)␣ }}} === Fourth example === Wrap operator and argument, remove both pairs of parentheses: {{{#!hs >>> >>> :t (:$)␣ -- C-m >>> -- C-p >>> :t (:$)␣ >>> :t (:$) (Op Add)␣ -- C-m >>> -- C-p >>> :t (:$) (Op Add)␣ -- C-a >>> ␣:t (:$) (Op Add) -- C-f, C-f, C-f >>> :t ␣(:$) (Op Add) -- C-d, C-d, ... >>> :t ␣Op Add) -- C-e >>> :t Op Add)␣ -- C-h >>> :t Op Add␣ >>> :t Op Add :$ Lit 10␣ }}} = Proposal = Long story short this involves a lot of manipulation of terms (deleting/rewriting, cutting/pasting), jumping around and adding or removing parentheses. My proposal is to make GHCi a bit smarter in how it accepts operators and sections, to a first approximation it would be as if there were implicit `'(' ++ cmd ++ ')'` around the command. Let's see how I picture this would work: {{{#!hs >>> :t :$ >>> :t Op Add :$ >>> :t Op Add :$ Lit 10 }}} This may feel disconcerting since this is not valid syntax for operators or sections, but I think it would be fine. For example both `:info :$` and `:info (:$)` work. This would take me a lot less time to write! No parentheses and minimal jumping around. This would make it very simple to get the right section of an operator: {{{#!hs >>> :t >>= >>> :t >>= id }}} and could be extended to work with infix functions as well, I would probably use `flip` a whole lot less: {{{#!hs >>> :t `take` -- ^ probably shouldn't work, but allows for less skipping >>> :t `take` "wabalabadubdub" >>> :t 10 `take` "wabalabadubdub" }}} The reason why I said “to a first approximation” is that `:$) (Op Add` should obviously not be valid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 01:55:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 01:55:37 -0000 Subject: [GHC] #12542: Unexpected failure.. (bug?) Message-ID: <051.118151a24a444e5249d83b4904c5e148@haskell.org> #12542: Unexpected failure.. (bug?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From [http://www.cse.chalmers.se/~emax/documents/axelsson2012generic- slides.pdf A Generic Abstract Syntax Model for Embedded Languages]([http://www.cse.chalmers.se/~emax/documents/axelsson2012generic.pdf paper]) {{{#!hs infixr :-> infixl 1 :$ data Full a data a :-> b data AST dom sig where Sym :: dom sig -> AST dom sig (:$) :: AST dom (a :-> sig) -> AST dom (Full a) -> AST dom sig class Binding dom where viewVar :: dom a -> Maybe Integer viewBnd :: dom (a :-> b) -> Maybe Integer freeVars :: Binding dom => AST dom a -> [Integer] freeVars = \case Sym (a -> Just v) -> [v] Sym (b -> Just v) :$ body -> undefined where (a, _) = (viewVar, undefined) (_, b) = (undefined, viewBnd) }}} and so does {{{#!hs where a = viewVar b = viewBnd }}} but {{{#!hs where (a, b) = (viewVar, viewBnd) }}} yields {{{ tSvp.hs:20:5-31: error: … • Could not deduce (Binding dom0) from the context: Binding dom bound by the type signature for: freeVars :: Binding dom => AST dom a -> [Integer] at /tmp/tSvp.hs:14:1-49 or from: Binding dom2 bound by the inferred type for ‘a’: Binding dom2 => dom2 a1 -> Maybe Integer at /tmp/tSvp.hs:20:5-31 The type variable ‘dom0’ is ambiguous • When checking that the inferred type a :: forall k k1 (dom :: * -> *) a (dom1 :: * -> *) (a1 :: k) (b :: k1). (Binding dom1, Binding dom) => dom a -> Maybe Integer is as general as its inferred signature a :: forall (dom :: * -> *) a. Binding dom => dom a -> Maybe Integer In an equation for ‘freeVars’: freeVars = \case { Sym (a -> Just v) -> [v] Sym (b -> Just v) :$ body -> undefined } where (a, b) = (viewVar, viewBnd) tSvp.hs:20:5-31: error: … • Could not deduce (Binding dom1) from the context: Binding dom bound by the type signature for: freeVars :: Binding dom => AST dom a -> [Integer] at /tmp/tSvp.hs:14:1-49 or from: Binding dom2 bound by the inferred type for ‘b’: Binding dom2 => dom2 (a1 :-> b) -> Maybe Integer at /tmp/tSvp.hs:20:5-31 The type variable ‘dom1’ is ambiguous • When checking that the inferred type b :: forall k k1 (dom :: * -> *) a (dom1 :: * -> *) (a1 :: k) (b :: k1). (Binding dom1, Binding dom) => dom1 (a1 :-> b) -> Maybe Integer is as general as its inferred signature b :: forall k k1 (dom :: * -> *) (a :: k) (b :: k1). Binding dom => dom (a :-> b) -> Maybe Integer In an equation for ‘freeVars’: freeVars = \case { Sym (a -> Just v) -> [v] Sym (b -> Just v) :$ body -> undefined } where (a, b) = (viewVar, viewBnd) Compilation failed. }}} Is this intentional? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 01:56:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 01:56:06 -0000 Subject: [GHC] #12542: Unexpected failure.. (bug?) In-Reply-To: <051.118151a24a444e5249d83b4904c5e148@haskell.org> References: <051.118151a24a444e5249d83b4904c5e148@haskell.org> Message-ID: <066.a1c4f1ecc940b90b23fd40f47557a81c@haskell.org> #12542: Unexpected failure.. (bug?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -2,2 +2,2 @@ - slides.pdf A Generic Abstract Syntax Model for Embedded - Languages]([http://www.cse.chalmers.se/~emax/documents/axelsson2012generic.pdf + slides.pdf A Generic Abstract Syntax Model for Embedded Languages] + ([http://www.cse.chalmers.se/~emax/documents/axelsson2012generic.pdf @@ -30,1 +30,1 @@ - and so does + works, and so does New description: From [http://www.cse.chalmers.se/~emax/documents/axelsson2012generic- slides.pdf A Generic Abstract Syntax Model for Embedded Languages] ([http://www.cse.chalmers.se/~emax/documents/axelsson2012generic.pdf paper]) {{{#!hs infixr :-> infixl 1 :$ data Full a data a :-> b data AST dom sig where Sym :: dom sig -> AST dom sig (:$) :: AST dom (a :-> sig) -> AST dom (Full a) -> AST dom sig class Binding dom where viewVar :: dom a -> Maybe Integer viewBnd :: dom (a :-> b) -> Maybe Integer freeVars :: Binding dom => AST dom a -> [Integer] freeVars = \case Sym (a -> Just v) -> [v] Sym (b -> Just v) :$ body -> undefined where (a, _) = (viewVar, undefined) (_, b) = (undefined, viewBnd) }}} works, and so does {{{#!hs where a = viewVar b = viewBnd }}} but {{{#!hs where (a, b) = (viewVar, viewBnd) }}} yields {{{ tSvp.hs:20:5-31: error: … • Could not deduce (Binding dom0) from the context: Binding dom bound by the type signature for: freeVars :: Binding dom => AST dom a -> [Integer] at /tmp/tSvp.hs:14:1-49 or from: Binding dom2 bound by the inferred type for ‘a’: Binding dom2 => dom2 a1 -> Maybe Integer at /tmp/tSvp.hs:20:5-31 The type variable ‘dom0’ is ambiguous • When checking that the inferred type a :: forall k k1 (dom :: * -> *) a (dom1 :: * -> *) (a1 :: k) (b :: k1). (Binding dom1, Binding dom) => dom a -> Maybe Integer is as general as its inferred signature a :: forall (dom :: * -> *) a. Binding dom => dom a -> Maybe Integer In an equation for ‘freeVars’: freeVars = \case { Sym (a -> Just v) -> [v] Sym (b -> Just v) :$ body -> undefined } where (a, b) = (viewVar, viewBnd) tSvp.hs:20:5-31: error: … • Could not deduce (Binding dom1) from the context: Binding dom bound by the type signature for: freeVars :: Binding dom => AST dom a -> [Integer] at /tmp/tSvp.hs:14:1-49 or from: Binding dom2 bound by the inferred type for ‘b’: Binding dom2 => dom2 (a1 :-> b) -> Maybe Integer at /tmp/tSvp.hs:20:5-31 The type variable ‘dom1’ is ambiguous • When checking that the inferred type b :: forall k k1 (dom :: * -> *) a (dom1 :: * -> *) (a1 :: k) (b :: k1). (Binding dom1, Binding dom) => dom1 (a1 :-> b) -> Maybe Integer is as general as its inferred signature b :: forall k k1 (dom :: * -> *) (a :: k) (b :: k1). Binding dom => dom (a :-> b) -> Maybe Integer In an equation for ‘freeVars’: freeVars = \case { Sym (a -> Just v) -> [v] Sym (b -> Just v) :$ body -> undefined } where (a, b) = (viewVar, viewBnd) Compilation failed. }}} Is this intentional? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 04:19:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 04:19:35 -0000 Subject: [GHC] #12539: Possible typo causes Stack and Cabal installs to fail In-Reply-To: <046.addee2c026228d83f37e1e76899d7fc7@haskell.org> References: <046.addee2c026228d83f37e1e76899d7fc7@haskell.org> Message-ID: <061.8a136fae426ffdcf58318ef416b190d3@haskell.org> #12539: Possible typo causes Stack and Cabal installs to fail -------------------------------------+------------------------------------- Reporter: ConorIA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ConorIA): * Attachment "stackerror.log" added. log of the stack error -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 04:29:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 04:29:11 -0000 Subject: [GHC] #12539: Possible typo causes Stack and Cabal installs to fail In-Reply-To: <046.addee2c026228d83f37e1e76899d7fc7@haskell.org> References: <046.addee2c026228d83f37e1e76899d7fc7@haskell.org> Message-ID: <061.917b35baef80a151f05b79ffaa016507@haskell.org> #12539: Possible typo causes Stack and Cabal installs to fail -------------------------------------+------------------------------------- Reporter: ConorIA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ConorIA): I think that this issue may have been a porting error. I hadn't realized that ​https://github.com/thriqon/pandoc-docker was using an older port (7.10), which the porter has deprecated. In fact, if I use cabal install on https://github.com/mitchty/alpine-ghc (which uses 8.1), then the install works perfectly. The stack commands are failing on the latter (I've attached a log of the errors). I consider the issue resolved insofar as I was able to install pandoc on an alpine docker image. If nothing stands out in the attached log, I'll go ahead and mark this as resolved or invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 04:38:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 04:38:25 -0000 Subject: [GHC] #12539: Possible typo causes Stack and Cabal installs to fail In-Reply-To: <046.addee2c026228d83f37e1e76899d7fc7@haskell.org> References: <046.addee2c026228d83f37e1e76899d7fc7@haskell.org> Message-ID: <061.9f48cc8d76617c875655d394df5d5036@haskell.org> #12539: Possible typo causes Stack and Cabal installs to fail -------------------------------------+------------------------------------- Reporter: ConorIA | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => invalid Comment: In GHC's source code, we pass no_pie, not nopie. So yeah, let's mark this invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 06:55:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 06:55:28 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.ffd9f3862abb8e74b0d2051ed111a631@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: | daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) Comment: Am I right that for `div` and `mod` this is just waiting to be implemented (in PrelRules)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 07:25:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 07:25:15 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.18bf92eca391f610546410b90d28db8e@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: | daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Looks like it! I'd look carefully at comment:19 and its links. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 07:43:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 07:43:25 -0000 Subject: [GHC] #12542: Unexpected failure.. (bug?) In-Reply-To: <051.118151a24a444e5249d83b4904c5e148@haskell.org> References: <051.118151a24a444e5249d83b4904c5e148@haskell.org> Message-ID: <066.744be6e082ce91cbb829b51f992a238f@haskell.org> #12542: Unexpected failure.. (bug?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oddly all three work for me, in HEAD and the 8.0 branch, and GHC 8.0.1. Are you sure you've put in the right code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 07:45:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 07:45:20 -0000 Subject: [GHC] #12540: RFC: Allow not quantifying every top-level quantifiee In-Reply-To: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> References: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> Message-ID: <066.e3c54d95e18e562ce1d9c964835aeb65@haskell.org> #12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've often wondered about this too. We could simply change the behaviour to always over quantify over un- mentioned tyvars. That gives * Same behaviour when no `forall` * Same behaviour when you specify all variables * But accepts some extra programs. Adding a flag to control it seems overkill. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 09:58:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 09:58:43 -0000 Subject: [GHC] #12542: Unexpected failure.. (bug?) In-Reply-To: <051.118151a24a444e5249d83b4904c5e148@haskell.org> References: <051.118151a24a444e5249d83b4904c5e148@haskell.org> Message-ID: <066.cdfc99d89f6757aa1cc15e96143e5fe2@haskell.org> #12542: Unexpected failure.. (bug?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Ah! It has something to do with the extensions I enabled in my `.ghci`: With {{{#!hs {-# Language GADTs,LambdaCase,TypeOperators,ViewPatterns #-} }}} it compiles just fine, but it fails when I add {{{#!hs {-# Language GADTs,LambdaCase,TypeOperators,ViewPatterns,NoMonomorphismRestriction #-} }}}s -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 10:03:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 10:03:29 -0000 Subject: [GHC] #12542: Unexpected failure.. (bug?) In-Reply-To: <051.118151a24a444e5249d83b4904c5e148@haskell.org> References: <051.118151a24a444e5249d83b4904c5e148@haskell.org> Message-ID: <066.d5ae4ddc51028e2bb52996c1355762be@haskell.org> #12542: Unexpected failure.. (bug?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): With {{{#!hs {-# Language GADTs,LambdaCase,TypeOperators,ViewPatterns,ScopedTypeVariables#-} {-# Language TypeApplications #-} infixr :-> infixl 1 :$ data Full a data a :-> b data AST dom sig where Sym :: dom sig -> AST dom sig (:$) :: AST dom (a :-> sig) -> AST dom (Full a) -> AST dom sig class Binding dom where viewVar :: dom a -> Maybe Integer viewBnd :: dom (a :-> b) -> Maybe Integer freeVars :: forall dom a. Binding dom => AST dom a -> [Integer] freeVars = \case Sym (a -> Just v) -> [v] Sym (b -> Just v) :$ body -> undefined where (a, b) = (viewVar @dom, undefined) }}} it also gives the error {{{ /tmp/tPYo.hs:20:8: error: • Couldn't match expected type ‘dom (a1 :-> a) -> Maybe t1’ with actual type ‘t0’ because type variable ‘a1’ would escape its scope This (rigid, skolem) type variable is bound by a pattern with constructor: :$ :: forall (dom :: * -> *) sig a. AST dom (a :-> sig) -> AST dom (Full a) -> AST dom sig, in a case alternative at /tmp/tPYo.hs:20:3-27 • In the pattern: b -> Just v In the pattern: Sym (b -> Just v) In the pattern: Sym (b -> Just v) :$ body • Relevant bindings include a :: dom a -> Maybe Integer (bound at /tmp/tPYo.hs:23:6) b :: t0 (bound at /tmp/tPYo.hs:23:9) freeVars :: AST dom a -> [Integer] (bound at /tmp/tPYo.hs:18:1) Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 10:09:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 10:09:05 -0000 Subject: [GHC] #12540: RFC: Allow not quantifying every top-level quantifiee In-Reply-To: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> References: <051.1956280adad0090e4523e93fefe0fc52@haskell.org> Message-ID: <066.632840eaad370617229e9f7f7e80c10f@haskell.org> #12540: RFC: Allow not quantifying every top-level quantifiee -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Ah that would do just fine, the only downside is that it makes it less explicit if a type variable is scoped (seeing a top-level `forall` is a decent indicator that something in the body needs it) but it sounds good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 10:19:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 10:19:57 -0000 Subject: [GHC] #11442: Segfault when showing (undefined :: Type) In-Reply-To: <051.c5b767158a0c3cf928d9331c284d3b58@haskell.org> References: <051.c5b767158a0c3cf928d9331c284d3b58@haskell.org> Message-ID: <066.c287661adf37bc46d7056eee10abebd7@haskell.org> #11442: Segfault when showing (undefined :: Type) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -1,3 +1,3 @@ - This [https://ghc.haskell.org/trac/ghc/ticket/11311?replyto=3#comment:3 - comment] made me wonder about the relationship between `Void` and `Type`, - `id :: Void -> Void` and `id :: Type -> Type`: + This [https://ghc.haskell.org/trac/ghc/ticket/11311#comment:3 comment] + made me wonder about the relationship between `Void` and `Type`, `id :: + Void -> Void` and `id :: Type -> Type`: New description: This [https://ghc.haskell.org/trac/ghc/ticket/11311#comment:3 comment] made me wonder about the relationship between `Void` and `Type`, `id :: Void -> Void` and `id :: Type -> Type`: https://ghc.haskell.org/trac/ghc/ticket/11311?replyto=3#comment:3 {{{#!hs {-# LANGUAGE TypeSynonymInstances, FlexibleInstances #- import Data.Kind (Type) instance Show Type where show _ = "..." main = print (undefined :: Type) }}} running gives: {{{ $ runghc --version runghc 8.1.20160113 $ runghc -ignore-dot-ghci Segfault.hs Segmentation fault (core dumped) }}} Verbose log attached. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 10:49:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 10:49:23 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.ee401af44c3d3b25cc42d5fac80ac036@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): An extended version of the `Eq` example, {{{#!hs class Eq a where type Logic a (==) :: a -> a -> Logic a instance Eq b => Eq (a -> b) where type Logic (a -> b) = a -> Logic b (==) :: (a -> b) -> (a -> b) -> (a -> Logic b) (f == @(a->b) g) x = f x == @b g x }}} Yuck ugly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 13:55:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 13:55:58 -0000 Subject: [GHC] #12542: Unexpected failure.. (bug?) In-Reply-To: <051.118151a24a444e5249d83b4904c5e148@haskell.org> References: <051.118151a24a444e5249d83b4904c5e148@haskell.org> Message-ID: <066.2521c505b0e9f2d94b14b97afa672caa@haskell.org> #12542: Unexpected failure.. (bug?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah now I see. The offending where clause is equivalent to this: {{{ where t = (viewVar, vewBnd) a = case t of (a,b) -> a b = case t of (a,b) -> b }}} What type does `t` get? {{{ t :: forall d1 d2 a1 a2 b2. Binding d1, Binding d2) => (d1 a1 -> Maybe Integer, d2 (Fun a2 b2) -> Maybe Integer) }}} Now when we call `t` in the RHS of `a` we get the error message you see, because nothing fixes `d2` and hence we can't resolve `Binding d2` even though it is not in fact used. This doesn't arise when there is just one variable; try the same desugaring and you'll see. The monomorphism restriction means that we don't attempt to generalise over `Binding d1` etc, so none of this happens. I agree that this is perplexing, but I don't really know how to improve it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 14:02:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 14:02:59 -0000 Subject: [GHC] #12125: Field accessors unnecessarily kept alive In-Reply-To: <043.0981b0708581432c190c561d66c8ba25@haskell.org> References: <043.0981b0708581432c190c561d66c8ba25@haskell.org> Message-ID: <058.9e892f536f47bc38eca0fa56c2b9b384@haskell.org> #12125: Field accessors unnecessarily kept alive -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2270 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 9d9eaeca03e138e0b35351c9401c832996398641. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 14:08:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 14:08:28 -0000 Subject: [GHC] #12401: GHC panic! Template variable unbound in rewrite rule In-Reply-To: <048.bb29ad43ef422a099b000889adb7e842@haskell.org> References: <048.bb29ad43ef422a099b000889adb7e842@haskell.org> Message-ID: <063.bd722019f191f45f6042e7facb41a246@haskell.org> #12401: GHC panic! Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Indeed this appears to be fixed in `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 14:12:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 14:12:45 -0000 Subject: [GHC] #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable In-Reply-To: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> References: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> Message-ID: <065.c73ec16165eae24729d3f2978298f33f@haskell.org> #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: T12031 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2316 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Phyx, I gave merging comment:6 a shot with 38497a2317b015249c96d03c2c3df97fffdc6929. It would be great if you could just test it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 14:13:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 14:13:35 -0000 Subject: [GHC] #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV In-Reply-To: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> References: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> Message-ID: <060.b64672d31c3cfa5cde04cd86dd19bd4b@haskell.org> #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV ---------------------------------+---------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4820 | Differential Rev(s): Phab:D2174 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): comment:12 merged to `ghc-8.0` as 57e707821be933c673927426b001b1cdd83de3ac. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 14:14:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 14:14:00 -0000 Subject: [GHC] #12407: Template Haskell thinks an unboxed tuple name is illegal to splice in In-Reply-To: <050.5a490ad0e0e78330be7bea8026596050@haskell.org> References: <050.5a490ad0e0e78330be7bea8026596050@haskell.org> Message-ID: <065.d7b83246903d2ecd259f2f7f38c58833@haskell.org> #12407: Template Haskell thinks an unboxed tuple name is illegal to splice in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T12407 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2410 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 422ed83c210e83acbd8f6b64ba725964d726f10a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 14:23:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 14:23:22 -0000 Subject: [GHC] #10963: Beginner-targeted language extension In-Reply-To: <045.cc74d15b01a49696436fbbb3b560b576@haskell.org> References: <045.cc74d15b01a49696436fbbb3b560b576@haskell.org> Message-ID: <060.499a87f75f43f00bbbc94f1f89418655@haskell.org> #10963: Beginner-targeted language extension -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature request | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T10963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2136 Wiki Page: | [wiki:Design/GHCi/Type] | -------------------------------------+------------------------------------- Comment (by bgamari): goldfire, I'd be okay with including this in 8.0.2 given that it certainly makes users lives easier. That being said, the merge isn't exactly straightforward. Would you like to try your hand at cherry-picking it onto `ghc-8.0`? If not I'll probably punt on it since there seems to be a number of non-trivial conflicts in `TcSimplify`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 14:38:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 14:38:45 -0000 Subject: [GHC] #10547: feature request: expanding type synonyms in error messages In-Reply-To: <043.c20ed6dece31f72a0d7c2a22033dd48e@haskell.org> References: <043.c20ed6dece31f72a0d7c2a22033dd48e@haskell.org> Message-ID: <058.6d70505554abef7f489396343e069c9f@haskell.org> #10547: feature request: expanding type synonyms in error messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: closed Priority: low | Milestone: 8.0.2 Component: Compiler (Type | Version: checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/ExpandSynsFail1,2,3,4 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1016, Wiki Page: | Phab:D2198 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 5c6e25f4cee5f53d4a6f4f20e6da63a65b4a1c17. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 16:35:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 16:35:57 -0000 Subject: [GHC] #12531: Holes should be representation-polymorphic In-Reply-To: <044.38d412e29e728e7d1a4333b441265291@haskell.org> References: <044.38d412e29e728e7d1a4333b441265291@haskell.org> Message-ID: <059.cd50bef2e0df344004326b0c65f71722@haskell.org> #12531: Holes should be representation-polymorphic -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ae66f356fb0dbf79dab1074d71275904c448b329/ghc" ae66f35/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae66f356fb0dbf79dab1074d71275904c448b329" Allow typed holes to be levity-polymorphic This one-line change fixes Trac #12531. Hooray. Simple, non-invasive; can merge to 8.0.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 16:35:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 16:35:57 -0000 Subject: [GHC] #12531: Holes should be representation-polymorphic In-Reply-To: <044.38d412e29e728e7d1a4333b441265291@haskell.org> References: <044.38d412e29e728e7d1a4333b441265291@haskell.org> Message-ID: <059.40e50269830a5f18059144a320b64133@haskell.org> #12531: Holes should be representation-polymorphic -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0050aff22ba04baca732bf5124002417ab667f8a/ghc" 0050aff2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0050aff22ba04baca732bf5124002417ab667f8a" Fix scoping of type variables in instances This fixes Trac #12531: class Foo x where foo :: forall a . x a -> x a default foo :: forall b . x b -> x b foo x = go where go :: x b go = undefined We want 'b' to scope over the code for 'foo', but we were using 'a' instead. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 16:39:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 16:39:04 -0000 Subject: [GHC] #12531: Holes should be representation-polymorphic In-Reply-To: <044.38d412e29e728e7d1a4333b441265291@haskell.org> References: <044.38d412e29e728e7d1a4333b441265291@haskell.org> Message-ID: <059.37d78e1669fe4d8a6533d798d259e6fe@haskell.org> #12531: Holes should be representation-polymorphic -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature request | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: partial- | sigs/should_compile/T12531 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => partial-sigs/should_compile/T12531 Comment: We could merge this too I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 16:40:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 16:40:40 -0000 Subject: [GHC] #12533: Internal error using redundant forall with default signature In-Reply-To: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> References: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> Message-ID: <060.8bab07facd9f585ce0de920ea9e535db@haskell.org> #12533: Internal error using redundant forall with default signature -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | rename/should_compile/T12533 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => rename/should_compile/T12533 Comment: In [changeset:"0050aff22ba04baca732bf5124002417ab667f8a/ghc" 0050aff2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0050aff22ba04baca732bf5124002417ab667f8a" Fix scoping of type variables in instances This fixes Trac #12531: class Foo x where foo :: forall a . x a -> x a default foo :: forall b . x b -> x b foo x = go where go :: x b go = undefined We want 'b' to scope over the code for 'foo', but we were using 'a' instead. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 16:42:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 16:42:00 -0000 Subject: [GHC] #12533: Internal error using redundant forall with default signature In-Reply-To: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> References: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> Message-ID: <060.1548c2e0127646a317e2507c4eac38a4@haskell.org> #12533: Internal error using redundant forall with default signature -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | rename/should_compile/T12533 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I put the wrong ticket number in the commit message. The full commit is {{{ commit 0050aff22ba04baca732bf5124002417ab667f8a Author: Simon Peyton Jones Date: Fri Aug 26 17:32:42 2016 +0100 Fix scoping of type variables in instances This fixes Trac #12531: class Foo x where foo :: forall a . x a -> x a default foo :: forall b . x b -> x b foo x = go where go :: x b go = undefined We want 'b' to scope over the code for 'foo', but we were using 'a' instead. compiler/hsSyn/HsUtils.hs | 29 ++++++++++++++++++++++++++++- compiler/rename/RnBinds.hs | 31 ++++++++++++++----------------- compiler/typecheck/TcClassDcl.hs | 36 ++++++++++++++++++++++-------------- compiler/typecheck/TcInstDcls.hs | 6 +++--- testsuite/tests/rename/should_compile/T12533.hs | 10 ++++++++++ testsuite/tests/rename/should_compile/all.T | 1 + 6 files changed, 78 insertions(+), 35 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 16:42:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 16:42:30 -0000 Subject: [GHC] #12533: Internal error using redundant forall with default signature In-Reply-To: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> References: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> Message-ID: <060.fc08b7fd4697b13597c6507f728869a9@haskell.org> #12533: Internal error using redundant forall with default signature -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | rename/should_compile/T12533 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Probably could merge too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 17:37:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 17:37:39 -0000 Subject: [GHC] #12543: Warning for duplicate language extensions Message-ID: <047.82837c22fa9c331cedf1cd5276561d99@haskell.org> #12543: Warning for duplicate language extensions -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I recently discovered that `-XRebindableSyntax` implies `-XNoImplicitPrelude`. Since I frequently listed both extensions at the top of my file with a `LANGUAGE` pragma, this knowledge allowed me to remove many superfluous `-XNoImplicitPrelude` pragmas. I wouldn't be surprised if there are other unused/implied pragmas floating around in my code. It would be nice to have a warning when two pragmas are explicitly listed, but one implies the other. The warning format could closely follow the warning for #9939. For example: `{-# LANGUAGE NoImplicitPrelude, RebindableSyntax #-}` would produce the warning {{{ Main.hs:1:1: warning: [-Wredundant-pragmas] • Redundant pragmas: RebindableSyntax => NoImplicitPrelude • In the language pragmas: {-# LANGUAGE NoImplicitPrelude, RebindableSyntax #-} }}} Although it might be harder (impossible?) to detect, it would also be nice if there was a similar warning for unused pragmas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 17:41:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 17:41:16 -0000 Subject: [GHC] #12544: Improved warning for redundant-constraints Message-ID: <047.6d8f37b71d007d9ffdb66d7219aad289@haskell.org> #12544: Improved warning for redundant-constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, {{{ foo :: (Num a, Integral a) => a -> a foo = id }}} produces the warning {{{ Main.hs:1:1: warning: [-Wredundant-constraints] • Redundant constraints: (Num a, Integral a) • In the type signature for: foo :: (Num a, Integral a) => a -> a }}} Since GHC can detect there is a redundancy, it would be nice it also told me which constraint was redundant. In #9939, I suggested that the warning include something to the effect of `(Num a) is implied by (Integral a)`. Lets make this as easy for the user as possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 17:41:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 17:41:36 -0000 Subject: [GHC] #12544: Improved warning for redundant-constraints In-Reply-To: <047.6d8f37b71d007d9ffdb66d7219aad289@haskell.org> References: <047.6d8f37b71d007d9ffdb66d7219aad289@haskell.org> Message-ID: <062.eb0041f919857010bac144bde772b72c@haskell.org> #12544: Improved warning for redundant-constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9939 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * related: => 9939 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 17:41:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 17:41:58 -0000 Subject: [GHC] #12544: Improved warning for redundant-constraints In-Reply-To: <047.6d8f37b71d007d9ffdb66d7219aad289@haskell.org> References: <047.6d8f37b71d007d9ffdb66d7219aad289@haskell.org> Message-ID: <062.ab65749bbc6b550fc96dad153f7d95dc@haskell.org> #12544: Improved warning for redundant-constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9939 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * related: 9939 => #9939 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 17:57:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 17:57:08 -0000 Subject: [GHC] #12533: Internal error using redundant forall with default signature In-Reply-To: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> References: <045.595e5404bf8098078d913eaa178e5fd2@haskell.org> Message-ID: <060.435cc1f0c49943e50840b7f26f42272d@haskell.org> #12533: Internal error using redundant forall with default signature -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | rename/should_compile/T12533 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): That was fast! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 18:00:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 18:00:34 -0000 Subject: [GHC] #12544: Improved warning for redundant-constraints In-Reply-To: <047.6d8f37b71d007d9ffdb66d7219aad289@haskell.org> References: <047.6d8f37b71d007d9ffdb66d7219aad289@haskell.org> Message-ID: <062.3cfc56a476b465d8869ba0bda5de369d@haskell.org> #12544: Improved warning for redundant-constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9939 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think this already happens. {{{ foo :: (Num a, Integral a) => a -> a foo = (1 +) }}} gives the warning {{{ testtc.hs:1:1: warning: [-Wredundant-constraints] • Redundant constraint: Num a • In the type signature for: foo :: (Num a, Integral a) => a -> a }}} Both constraints are listed in your example as neither is used in the body of the function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 18:10:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 18:10:27 -0000 Subject: [GHC] #12544: Improved warning for redundant-constraints In-Reply-To: <047.6d8f37b71d007d9ffdb66d7219aad289@haskell.org> References: <047.6d8f37b71d007d9ffdb66d7219aad289@haskell.org> Message-ID: <062.c7c753b87de474ba21ad1bdeafe15797@haskell.org> #12544: Improved warning for redundant-constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9939 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * status: new => closed * resolution: => invalid Comment: Ah, that makes sense. Thanks mpickering! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 18:51:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 18:51:22 -0000 Subject: [GHC] #12542: Unexpected failure.. (bug?) In-Reply-To: <051.118151a24a444e5249d83b4904c5e148@haskell.org> References: <051.118151a24a444e5249d83b4904c5e148@haskell.org> Message-ID: <066.6aaf7e61f2d92d6e8a27eb8632d1567b@haskell.org> #12542: Unexpected failure.. (bug?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): It may be fine as it is, but my intuition says I should be able to change {{{#!hs where a = xx b = yy }}} to {{{#!hs where (a, b) = (xx, yy) }}} Does it make any sense to treat/desugar `(a, b) = (xx, yy)` bindings as `x = xx; b = yy` or does that open a separate can of worms? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 19:40:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 19:40:56 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) Message-ID: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After upgrading to GHC 8.0.1 I've noticed that compilation time of one of my libraries got unacceptably long. Please find the attached test case. Here are some numbers from my machine: {{{ $ time ~/Prefixes/ghc-7.10.3/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs <> real 0m20.160s user 0m19.937s sys 0m0.197s $ time ~/Prefixes/ghc-8.0.1/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs <> real 2m10.195s user 2m9.773s sys 0m0.400s }}} Both versions are the official Debian 8 x86_64 binaries from haskell.org. I also compiled the git master and unfortunately it is affected as well. It is worth mentioning that turning off optimization makes the problem disappear: {{{ $ time ~/Prefixes/ghc-8.0.1/bin/ghc -O0 -c -Rghc-timing TypeList.hs Regression.hs <> real 0m3.593s user 0m3.507s sys 0m0.073s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 19:41:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 19:41:35 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) In-Reply-To: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> References: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> Message-ID: <072.5068e057a98767a57880ea77f7ac3618@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mikhail.vorozhtsov): * Attachment "TypeList.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 19:41:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 19:41:51 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) In-Reply-To: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> References: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> Message-ID: <072.c07ca36c6d24791407d25698ceca88fb@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mikhail.vorozhtsov): * Attachment "Regression.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 20:24:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 20:24:06 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.efac1d55c124c59c72b5c33d301238aa@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rcook): * testcase: => /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 20:29:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 20:29:12 -0000 Subject: [GHC] #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures Message-ID: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the following program: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE FlexibleInstances #-} import Control.Monad.Reader newtype AppM a = AppM (ReaderT Int IO a) deriving (Functor, Applicative, Monad, MonadReader) }}} The `MonadReader` deriving declaration should be `MonadReader Int`. GHC produces the following error message: {{{ • Expecting one more argument to ‘MonadReader’ Expected kind ‘* -> Constraint’, but ‘MonadReader’ has kind ‘* -> (* -> *) -> Constraint’ • In the newtype declaration for ‘AppM’ }}} This error message is confusing to me. The kind of `MonadReader` is `* -> (* -> *) -> Constraint`, as the error message states, which makes sense. However, the error message states that it expects kind `* -> Constraint`, despite the fact that `MonadReader Int` is actually of kind `(* -> *) -> Constraint`. ,,(This description is adapted from [http://stackoverflow.com/q/39172590/465378 this Stack Overflow question].),, -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 20:31:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 20:31:46 -0000 Subject: [GHC] #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures In-Reply-To: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> References: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> Message-ID: <065.5e0dcdb68f14b443187297e42d5d3eed@haskell.org> #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by lexi.lambda: @@ -3,1 +3,1 @@ - {{{ + {{{#!haskell New description: Given the following program: {{{#!haskell {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE FlexibleInstances #-} import Control.Monad.Reader newtype AppM a = AppM (ReaderT Int IO a) deriving (Functor, Applicative, Monad, MonadReader) }}} The `MonadReader` deriving declaration should be `MonadReader Int`. GHC produces the following error message: {{{ • Expecting one more argument to ‘MonadReader’ Expected kind ‘* -> Constraint’, but ‘MonadReader’ has kind ‘* -> (* -> *) -> Constraint’ • In the newtype declaration for ‘AppM’ }}} This error message is confusing to me. The kind of `MonadReader` is `* -> (* -> *) -> Constraint`, as the error message states, which makes sense. However, the error message states that it expects kind `* -> Constraint`, despite the fact that `MonadReader Int` is actually of kind `(* -> *) -> Constraint`. ,,(This description is adapted from [http://stackoverflow.com/q/39172590/465378 this Stack Overflow question].),, -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 21:18:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 21:18:57 -0000 Subject: [GHC] #12542: Unexpected failure.. (bug?) In-Reply-To: <051.118151a24a444e5249d83b4904c5e148@haskell.org> References: <051.118151a24a444e5249d83b4904c5e148@haskell.org> Message-ID: <066.78b7149a4a396114875b4edf4a2c4c8f@haskell.org> #12542: Unexpected failure.. (bug?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It would just be another strange special case. What about {{{ (a,b) = id (xx, yy) }}} Does not sound attractive to me -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 22:08:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 22:08:05 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.807f9ebd864f4c6872e99478e80907ec@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It seems that you have a patch Richard? Could you possibly submit it to phabricator for review if it fixes the issue you are facing? Thank you for the reproduction steps but they are too involved to be really useful to find the issue. A reproduction should ideally be one invocation of `ghc` rather than relying on lots of external tools and libraries like stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 22:10:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 22:10:36 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) In-Reply-To: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> References: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> Message-ID: <072.d99e56dff0c898ac377c6fd708c5de2c@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Thanks for the great test case! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 22:11:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 22:11:53 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.f9b41f4a5f2cfb4623a2d2ebf9a92845@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2477 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D2477 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 22:13:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 22:13:16 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.5cf383d461ea47bbb34ecd6991890916@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2477 Wiki Page: | Phab:D2478 -------------------------------------+------------------------------------- Changes (by rcook): * differential: Phab:D2477 => Phab:D2477 Phab:D2478 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 22:14:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 22:14:22 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.914edface36a02dacbca1ff83fca257d@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2477 Wiki Page: | Phab:D2478 -------------------------------------+------------------------------------- Comment (by rcook): Phab:D2477 adds a test case under `testsuite/tess/hsc2hs`. Phab:D2478 is a fix for the bug located under `utils/hsc2hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 22:14:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 22:14:35 -0000 Subject: [GHC] #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV In-Reply-To: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> References: <045.e7ec8175631a08659d1526a914fb3334@haskell.org> Message-ID: <060.af934ea8f7b4ba6b5b9827d0d1466fb3@haskell.org> #11978: running a profiled build of shake test suite with rts args +RTS -hb -N10 triggers SIGSEGV ---------------------------------+---------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4820 | Differential Rev(s): Phab:D2174 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by erikd): I remember writing that. Let me see if I can find them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 26 23:34:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Aug 2016 23:34:31 -0000 Subject: [GHC] #12542: Unexpected failure.. (bug?) In-Reply-To: <051.118151a24a444e5249d83b4904c5e148@haskell.org> References: <051.118151a24a444e5249d83b4904c5e148@haskell.org> Message-ID: <066.caefe9130d279b718321d239f94214a4@haskell.org> #12542: Unexpected failure.. (bug?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Good point -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 04:27:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 04:27:50 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.2912842ccad4721ca7cd298d6d13a0ce@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): http://yav.github.io/publications/improving-smt-types.pdf > == 3.1 Implication Constraints == > During type inference, GHC uses ''implication constraints'', which do not appear in Haskell source code directly. An implication constraint is, roughly, of the form `G ⇒ W`, where `W` is a collection of constraints that need to be discharged, and `G` are assumptions that may be used while discarding `W`. In the GHC source code, the constraints in `G` are referred to as ''given constraints'', while the ones in `W` are known as wanted constraints. The intuition behind an implication constraint is that `W` contains the constraints that were collected while checking a program fragment, while `G` contains local assumptions that are available only in this particular piece of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 10:03:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 10:03:49 -0000 Subject: [GHC] #5834: Allow both INLINE and INLINABLE for the same function In-Reply-To: <041.9dc4c9ae5d423bac79723696e9524f18@haskell.org> References: <041.9dc4c9ae5d423bac79723696e9524f18@haskell.org> Message-ID: <056.fbbf84010f84bc17aa185779cead0786@haskell.org> #5834: Allow both INLINE and INLINABLE for the same function -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 11:43:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 11:43:00 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) In-Reply-To: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> References: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> Message-ID: <072.6ea65c33fe97efdc7aabb23be6448fe0@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mikhail.vorozhtsov): The results of putting `NOINLINE` on `elemWitness`: {{{ $ time ~/Prefixes/ghc-7.10.3/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs <> real 0m5.092s user 0m4.983s sys 0m0.097s $ time ~/Prefixes/ghc-8.0.1/bin/ghc -O -c -Rghc-timing TypeList.hs Regression.hs <> real 0m23.988s user 0m23.747s sys 0m0.190s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 12:27:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 12:27:40 -0000 Subject: [GHC] #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone Message-ID: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a `ForeignPtr` `fptr32` with a C finalizer and a `Concurrent.ForeignPtr` with a finalizer that needs to access `fptr32`. Unfortunately, accessing `fptr32` from the concurrent finalizer does not assert that `fptr32` is still alive. Consider the following program: {{{#!hs {-# LANGUAGE ForeignFunctionInterface #-} module Main where import qualified Foreign.Concurrent as FC import Foreign.Storable (peek) import Foreign.ForeignPtr (ForeignPtr, withForeignPtr, newForeignPtr) import Foreign.Ptr (Ptr, FunPtr, nullPtr) import Control.Monad (void) import Data.Word (Word32) import System.Mem (performGC) foreign import ccall safe "create" create :: IO (Ptr Word32) foreign import ccall safe "&delete" delete :: FunPtr (Ptr Word32 -> IO ()) makeForeignPtr :: IO () -> IO (ForeignPtr ()) makeForeignPtr final = FC.newForeignPtr nullPtr final finalizer :: ForeignPtr Word32 -> IO () finalizer fptr = do withForeignPtr fptr $ \ptr -> print =<< peek ptr main :: IO () main = do fptr32 <- newForeignPtr delete =<< create void $ makeForeignPtr (finalizer fptr32) performGC }}} and {{{#!c #include "stdio.h" #include "stdlib.h" #include "stdint.h" uint32_t *create () { uint32_t *ptr = malloc(sizeof(uint32_t)); printf ("create %lx\n", (unsigned long int)ptr); *ptr = 23; return ptr; } void delete (uint32_t *ptr) { printf ("delete %lx\n", (unsigned long int)ptr); *ptr = 42; free(ptr); } }}} It emits: {{{ create 2685dc0 delete 2685dc0 0 }}} If it would be correct, it would print `23` instead of `0` and it would print the number before `delete`. Is this a bug or a feature? If it is a feature, how do I get what I need? I know that the documentation says that we must not use `touchForeignPtr` for enforcing a particular order of running finalizers, but I thought that `withForeignPtr`/`touchForeignPtr` pretty clearly state that the `ForeignPtr` must be alive in `finalizer`. I cannot see an abuse here. Actually, this is a simplified version from an example that is even worse: In the original code, `create` is the LLVM-JIT creating code for a finalizer, `delete` frees the function code and `finalizer` runs the LLVM generated finalizer code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 12:28:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 12:28:12 -0000 Subject: [GHC] #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone In-Reply-To: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> References: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> Message-ID: <061.2a7fbc2fc6097f0d2b0e2e7e8983c313@haskell.org> #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * Attachment "GarbageCollection.hs" added. main Haskell program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 12:28:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 12:28:35 -0000 Subject: [GHC] #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone In-Reply-To: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> References: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> Message-ID: <061.84fdcf755377293de15bfd76b9ce344a@haskell.org> #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * Attachment "GarbageCollectionC.c" added. additional C code -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 13:36:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 13:36:32 -0000 Subject: [GHC] #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures In-Reply-To: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> References: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> Message-ID: <065.6936d1cab558c823a4d5b00e860faa8c@haskell.org> #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Looks like it tries to unify `k -> Constrant ~ * -> (* -> *) -> Constraint`. It zonks `k ~ *` and then fails with `(* -> *) -> Constraint ~ Constraint`, and the `k = *` leaks into the error message -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 15:43:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 15:43:06 -0000 Subject: [GHC] #12495: GHC's configure script detects MADV_FREE when it shouldn't In-Reply-To: <044.997e9b75dfddfee0f98aa3aabfdabed9@haskell.org> References: <044.997e9b75dfddfee0f98aa3aabfdabed9@haskell.org> Message-ID: <059.ebe0b4d2d92705f539c8c651676cd552@haskell.org> #12495: GHC's configure script detects MADV_FREE when it shouldn't -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: MADV_FREE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 15:47:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 15:47:04 -0000 Subject: [GHC] #12177: Relevant bindings includes shadowed bindings In-Reply-To: <045.0e76a562090c9d87371f445f74b8515d@haskell.org> References: <045.0e76a562090c9d87371f445f74b8515d@haskell.org> Message-ID: <060.7de249fcf525593a084086b0b7510344@haskell.org> #12177: Relevant bindings includes shadowed bindings -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12177 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2434 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => merge * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 15:58:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 15:58:59 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.869fa3e181852442509b3fb39c2bc44e@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2477 Wiki Page: | Phab:D2478 -------------------------------------+------------------------------------- Description changed by rcook: @@ -25,1 +25,1 @@ - * Add the line `c-source-files: src/Main.c` to the `executable inlinecbug` + * Add the line `c-sources: src/Main.c` to the `executable inlinecbug` New description: Repro steps: * Install Stack on a ''Windows'' development machine. * Create new simple project with `stack new inlinecbug simple`. * Rename `src/Main.hs` to `src/Main.hsc` in the `inlinecbug` project directory. * Build project with `stack build` and run with `stack exec inlinecbug` to verify that hsc2hs works correctly. * Replace content of `src/Main.hsc` with following: {{{#!hs {-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE TemplateHaskell #-} import qualified Language.C.Inline as C C.include "" main :: IO () main = do x <- [C.exp| double{ cos(1) } |] print x }}} * In `inlinecbug.cabal` add `inline-c` to the `build-depends` section of `executable inlinecbug`. * Add the line `c-sources: src/Main.c` to the `executable inlinecbug` section. * Rebuild with `stack build`. Build will fail with a linker error referring to a undefined reference to an `inline_c_main...` function. List the files in the root directory of the project and you'll see that inline-c has generated a file with the name `srcMain.c`: i.e. the backslashes in the Windows path have been removed. Building under Linux generates the C output file with the correct, expected path of `src/Main.c` and the program will compile, link and run as expected. See also: https://github.com/fpco/inline-c/issues/50 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 16:30:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 16:30:53 -0000 Subject: [GHC] #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures In-Reply-To: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> References: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> Message-ID: <065.2545f0414584fde55ceb6d0bb08c9f0f@haskell.org> #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * owner: => mniip -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 17:25:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 17:25:50 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) In-Reply-To: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> References: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> Message-ID: <072.f33bb51e9e014034d8eaa5d45abc790f@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 17:48:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 17:48:56 -0000 Subject: [GHC] #12497: Make runtime linker be able to find POSIX functions under their deprecated name. In-Reply-To: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> References: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> Message-ID: <059.d60784e0df57e67befcb28fb02c0e1f7@haskell.org> #12497: Make runtime linker be able to find POSIX functions under their deprecated name. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): +1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 19:21:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 19:21:17 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) In-Reply-To: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> References: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> Message-ID: <072.5d4d7aed5bc339cad404b7b81edb4cf1@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The interface file produced by both versions is absolutely huge (17mb). A very large number of coercions are generated by the instance declarations in Regression.hs. Interestingly, one way to improve the performance is marking `elemWitness` as inlinable.. This stops the unfoldings being optimised but it doesn't bring performance to the same level as omitting unfoldings completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 19:31:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 19:31:15 -0000 Subject: [GHC] #10083: ghc: panic! (the 'impossible' happened) In-Reply-To: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> References: <047.98ab68675b5fd7aadd4f473d218b6ef3@haskell.org> Message-ID: <062.42448013df78233676aa30ee24118a4c@haskell.org> #10083: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: hedayaty | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2210 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 8.0.2 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 19:42:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 19:42:09 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.051e8022f8952f988e99fb616f8a66e5@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: dterei (added) * keywords: => SafeHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 19:44:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 19:44:25 -0000 Subject: [GHC] #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy In-Reply-To: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> References: <044.94c832277c0d3da40b463d4c3e319a93@haskell.org> Message-ID: <059.a8fa6df8a551f42e477255382e3b9fdf@haskell.org> #12511: template-haskell's Language.Haskell.Syntax module should be Trustworthy -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: SafeHaskell, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => SafeHaskell, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 21:58:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 21:58:18 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.eeb2319e2365accabdb8cb2c7769e0d1@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): gridaphobe: I was investigating a report of some (other) compile time regression (I don't remember which ticket or which program). I tried to find a small reproducible example, deleting as much code as possible, and replacing function bodies with `undefined`. I then noticed something fishy was going on with `undefined` itself, and came up with the above example. So the above example doesn't look anything like the original program I was investigating. == Constant factor performance degradation == The measurements presented in the description make it seem like 7.10.3 took `O(1)` seconds to compile the program (where `n` is the number of guards), while 8.0.1 took `O(n)` seconds. This is not the case: **both versions of GHC need `O(n)` time.** Running the program from the description a bit longer: 7.10.3: {{{ N clauses : time (s) 10 : 1.39 20 : 0.28 40 : 0.30 80 : 0.28 160 : 0.36 320 : 0.39 640 : 0.53 1280 : 0.74 2560 : 1.17 5120 : 2.11 10240 : 4.21 20480 : 8.18 40960 : 17.15 }}} So we're should really just be looking at constant factor performance differences. == Timing results == Time (s) to compile the program with 1000 `bool = f` clauses with different versions of undefined and error: ||= bool/f= =||= ghc-7.10.3 =||= ghc-8.0.1 =|| || old undefined || 0.6 || 0.8 || || new undefined || 0.6 || 18 || || myUndef :: a; myUndef = old undefined || 2.0 || 2.1 || || myUndef :: a; myUndef = new undefined || 2.0 || 4.2 || || old error || 6 || 6.5 || || new error || 6 || 5 || === Quotes === > the CallStack-free variant [`myUndef :: a`] behaves just like the old undefined No, it is still 5x slower (4.2 vs 0.8 seconds). > if I [..] use the *old* error instead of undefined, I get a similar behavior to the *new* undefined No. 8.0.1 still takes 3x longer to compile the (new) `undefined` than it is to compile the (old or new) `error` (18 vs 5-6 seconds). > When we remove the CallStacks from undefined, GHC manages to optimize away the entire set of guards! Hmm, maybe the whole example is flawed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 22:22:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 22:22:15 -0000 Subject: [GHC] #12516: Preprocessing: no way to portably use stringize and string concatenation In-Reply-To: <047.d2338b23eeeda984fa4982226d5ecfbe@haskell.org> References: <047.d2338b23eeeda984fa4982226d5ecfbe@haskell.org> Message-ID: <062.33db46941a1c9d6022648740502ee4ab@haskell.org> #12516: Preprocessing: no way to portably use stringize and string concatenation -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Fwiw: in ticket:9399#comment:10 rwbarton also noticed that clang's traditional mode doesn't support stringification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 22:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 22:26:51 -0000 Subject: [GHC] #12460: Solaris linker does not recognize option --gc-sections In-Reply-To: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> References: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> Message-ID: <060.be5c5e68a6f9a8574a31c2db778b463f@haskell.org> #12460: Solaris linker does not recognize option --gc-sections -------------------------------------+------------------------------------- Reporter: herzen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Solaris | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): `git grep gc-sections` only returns one hit (and a comment). In `compiler/main/DriverPipeline.hs:`: {{{ ++ (if sLdIsGnuLd mySettings then ["-Wl,--gc-sections"] else []) }}} This code was added in 4a32bf925b8aba7885d9c745769fe84a10979a53 (#8405). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 22:29:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 22:29:11 -0000 Subject: [GHC] #12116: No easy way to add cost-centre to top-levels In-Reply-To: <043.6b04c4666f71935c9beabebf233c1a73@haskell.org> References: <043.6b04c4666f71935c9beabebf233c1a73@haskell.org> Message-ID: <058.d38fe5f79e3d10498a4690392df91602@haskell.org> #12116: No easy way to add cost-centre to top-levels -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/toplevel_scc_1 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2407 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => profiling/should_run/toplevel_scc_1 * status: merge => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 22:30:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 22:30:26 -0000 Subject: [GHC] #12519: Rendered Haddock for Eq and Ord are missing class methods In-Reply-To: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> References: <046.74700778a2c1306e7d3f3f88764453b2@haskell.org> Message-ID: <061.e76afa89399dbe970f3683a0377a474b@haskell.org> #12519: Rendered Haddock for Eq and Ord are missing class methods -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 22:36:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 22:36:08 -0000 Subject: [GHC] #12521: Thread blocked indefinitely in an MVar operation In-Reply-To: <053.f0da307ad87f1df98e8d5b92884f7e14@haskell.org> References: <053.f0da307ad87f1df98e8d5b92884f7e14@haskell.org> Message-ID: <068.91f92bab708b99f9602b43e6654328c0@haskell.org> #12521: Thread blocked indefinitely in an MVar operation -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded Comment: * Which OS are you on? * I am not able to reproduce the `invalid character` exception with 7.8.4 or higher. Can you try? * What is `chcp`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 23:02:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 23:02:47 -0000 Subject: [GHC] #12478: Template Haskell support for unboxed sums In-Reply-To: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> References: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> Message-ID: <065.396ec79de0f8412917b79bc2f3304558@haskell.org> #12478: Template Haskell support for unboxed sums -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.1 Resolution: fixed | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/T12478_{1,2,3,4} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2448 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * testcase: => th/T12478_{1,2,3,4} * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 27 23:36:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Aug 2016 23:36:51 -0000 Subject: [GHC] #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable In-Reply-To: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> References: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> Message-ID: <065.bc02fef9a656ea9db4fcce41e32aa8a7@haskell.org> #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: T12031 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2316 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @bgamari, you need to merge ae7e9cb574801954c7769c210829b06193fa72ea as well as this fixes the Ticky format specifiers. Currently that GHC-8.0 branch doesn't build with validate settings due to it. Also the following need to be applied {{{ diff --git a/rts/Linker.c b/rts/Linker.c index 8e00b92..82a37c8 100644 --- a/rts/Linker.c +++ b/rts/Linker.c @@ -4102,13 +4102,13 @@ ocGetNames_PEi386 ( ObjectCode* oc ) if (globalBssSize > 0) { bss = stgCallocBytes(1, globalBssSize, "ocGetNames_PEi386(non-anonymous bss)"); - addSection(§ions[oc->n_sections-1], + addSection(&oc->sections[oc->n_sections-1], SECTIONKIND_RWDATA, SECTION_MALLOC, bss, globalBssSize, 0, 0, 0); IF_DEBUG(linker, debugBelch("bss @ %p %" FMT_Word "\n", bss, globalBssSize)); addProddableBlock(oc, bss, globalBssSize); } else { - addSection(§ions[oc->n_sections-1], + addSection(&oc->sections[oc->n_sections-1], SECTIONKIND_OTHER, SECTION_NOMEM, NULL, 0, 0, 0, 0); } }}} This will make It compile, but the test isn't giving any output, have to look into that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 02:48:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 02:48:49 -0000 Subject: [GHC] #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures In-Reply-To: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> References: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> Message-ID: <065.3f1cd6233340feb27901e85e73bd818a@haskell.org> #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Apparently it is a historical convention that expected/actual error messages are zonked, so in a sense the error is not "incorrect". I believe I have an alternative solution for this though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 04:16:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 04:16:58 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.587ad51bf70aef9a63457e5bbd225f1a@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rcook): * differential: Phab:D2477 Phab:D2478 => Phab:D2478 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 04:24:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 04:24:03 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.b3ad684b86a5f069a0806ec22abe9e20@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rcook): @mpickering: Here's a more compact repro case: {{{#!hs $ cat T12504/path/to/T12504.hsc module Main (main) where main :: IO () main = putStrLn "hello world" $ '/c/src/ghc/inplace/bin/hsc2hs.exe' T12504/path/to/T12504.hsc $ cat T12504/path/to/T12504.hs {-# LINE 1 "T12504\path\to\T12504.hsc" #-} module Main (main) where {-# LINE 2 "T12504\path\to\T12504.hsc" #-} main :: IO () main = putStrLn "hello world" }}} Notice that the backslashes in the paths are not escaped properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 08:48:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 08:48:42 -0000 Subject: [GHC] #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable In-Reply-To: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> References: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> Message-ID: <065.12becdd3971df5e94e44c4fa52e0d63d@haskell.org> #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: T12031 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2316 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @bgamari, With those changes above it works. Test doesn't pass because ` TEST_HC_OPTS_INTERACTIVE` isn't defined in the teststuite of that version. If you want to make it pass, do: {{{ diff --git a/testsuite/tests/rts/T12031/Makefile b/testsuite/tests/rts/T12031/Makefile index 0a94206..72b34cc 100644 --- a/testsuite/tests/rts/T12031/Makefile +++ b/testsuite/tests/rts/T12031/Makefile @@ -5,4 +5,4 @@ include $(TOP)/mk/test.mk T12031: '$(TEST_HC)' -c bar.c -o bar.o '$(TEST_HC)' -c baz.c -o baz.o - echo bar | '$(TEST_HC)' $(TEST_HC_OPTS_INTERACTIVE) bar.o baz.o ExternBug.hs + echo bar | '$(TEST_HC)' $(TEST_HC_OPTS) --interactive -v0 -ignore- dot-ghci -fno-ghci-history bar.o baz.o ExternBug.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 09:39:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 09:39:56 -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.b084247ae00deaa8d213c0705aeb8669@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * Attachment "synth.bash" added. synth.bash - perfectly parallel workload for ghc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 09:58:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 09:58:39 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.ca30dcbac4905fa5726e5830dc699868@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): How about this: {{{ runghc [runghc flags] module|filename [GHC flags] [-- [program args]] }}} Clarification: * `runghc -package ..` would be an error, because `-package` is not a runghc flag, nor is it a valid module or filename. Note that GHC doesn't even support filenames starting with a dash (try `ghc -hello.hs`), so I don't understand why the following hack even exists: {{{ pastArgs :: String -> Bool -- You can use -- to mark the end of the flags, in case you need to use -- a file called -foo.hs for some reason. You almost certainly shouldn't, -- though. pastArgs "--" = True pastArgs ('-':_) = False pastArgs _ = True }}} * `"--"` is no longer overloaded. It just separates the GHC flags from the program arguments, and to pass program arguments you //have to// use `"--"`. This is an improvement, because currently you might think that `-v` in `runghc hello.hs -v` is a GHC flag, while it is actually a program arguments (and might silently get ignored). * `--ghc-arg` can be deprecated * Your example would become: `runghc hello.hs -package text-1.2.2.1` Are there any drawbacks to this approach (other than also breaking backward compatibility)? Fwiw: currenly, your example can also be solved without `--ghc-arg` using: `runghc -package=text-1.2.2.1 hello.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 10:43:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 10:43:18 -0000 Subject: [GHC] #12435: Turn "No alternatives for a case scrutinee not known to diverge for sure" into a warning In-Reply-To: <046.86fe10487270419d402270c6ee8b1e23@haskell.org> References: <046.86fe10487270419d402270c6ee8b1e23@haskell.org> Message-ID: <061.824466264cc81bfc90d125e3bc725d92@haskell.org> #12435: Turn "No alternatives for a case scrutinee not known to diverge for sure" into a warning -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 11:49:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 11:49:18 -0000 Subject: [GHC] #10963: Beginner-targeted language extension In-Reply-To: <045.cc74d15b01a49696436fbbb3b560b576@haskell.org> References: <045.cc74d15b01a49696436fbbb3b560b576@haskell.org> Message-ID: <060.a1f22679b1307a649600383a74c25ab3@haskell.org> #10963: Beginner-targeted language extension -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature request | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T10963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2136 Wiki Page: | [wiki:Design/GHCi/Type] | -------------------------------------+------------------------------------- Comment (by thomie): From [wiki:WorkingConventions/Releases#Minorreleases]: [Minor releases] do not add or remove any features, or include new major versions of libraries. They only fix bugs and performance issues in the previous release on that branch. I'd prefer we stick to this rule. It minimizes the chance of //introducing// bugs in the stable branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 13:07:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 13:07:09 -0000 Subject: [GHC] #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable In-Reply-To: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> References: <050.daa1dfd7fb3e8ebf751c2100561e30c6@haskell.org> Message-ID: <065.3fe7c1445fbd2370e7849be19f29fd0d@haskell.org> #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: T12031 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2316 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Perhaps apply this commit: bdc555885b8898684549eca70053c9ce0ec7fa39 {{{ Author: Thomas Miedema Date: Wed May 25 13:01:42 2016 +0200 Testsuite: introduce TEST_HC_OPTS_INTERACTIVE (#11468) Refactoring only. }}} Or define `TEST_HC_OPTS_INTERACTIVE = $(TEST_HC_OPTS) --interactive -v0 -ignore-dot-ghci` in `testsuite/mk/test.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 13:10:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 13:10:40 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.6896d45b6f2e6176a49be40c8596d222@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): This approach looks clever at the first glance. But then: * As you noted in the end - the program name is absent in the stdin case * Usually Haskell programs (e.g. `ghc hello.hs -package text`) can specify options anywhere i.e. before or after the arguments. So designating before and after for different purposes could still be confusing because of the usual conventions being different. > your example can also be solved without --ghc-arg using: runghc -package=text-1.2.2.1 hello.hs. I never thought about that. That's pretty nifty for current state of affairs. Yet another way. Big problem with having too many ways to do that same thing is discoverability and retention. I did not even know that ghc accepts arguments that way as well. I just looked into the man page, it is not mentioned. Could not find it in the users guide as well on a quick look in the `Using GHC` section. All of the users guide lists flags in the `-package text` convention, so that's what sticks. If I cannot easily find this and it is optional then it does not exist for me, it does not matter, its tribal knowledge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 13:19:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 13:19:36 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.fd09b926d9161924c7c487f592a265e8@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): > Note that GHC doesn't even support filenames starting with a dash Yeah, I had tried this earlier and wondered why do we have this if ghc does not support it, but I ignored it (maybe in future ghc might support that). Now I think we should just get rid of it to keep the code and documentation simple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 15:38:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 15:38:26 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.1b5e50bbde531db6a415d4d58939a316@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: bgamari => Comment: Unassigning, to make this ticket show up on the [wiki:Newcomers] page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 15:53:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 15:53:13 -0000 Subject: [GHC] #12548: Exported pattern synonyms does not mark top-level bindings in RHS as used Message-ID: <043.97f0b3892f5aded29e0cb9f0f5c452d4@haskell.org> #12548: Exported pattern synonyms does not mark top-level bindings in RHS as used -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Foo (pattern P) where x :: Int x = 0 pattern P :: Int pattern P <- _ where P = x }}} gives: {{{ Foo.hs:6:1: warning: [-Wunused-top-binds] Defined but not used: ‘x’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 18:27:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 18:27:20 -0000 Subject: [GHC] #12458: Segfault in GHCi runtime type reconstruction In-Reply-To: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> References: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> Message-ID: <059.f3c8d73c1171e53e43329890e6f4a01a@haskell.org> #12458: Segfault in GHCi runtime type reconstruction -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: | ghci.debugger/scripts/T12458 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2439 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => ghci.debugger/scripts/T12458 * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 18:29:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 18:29:10 -0000 Subject: [GHC] #12548: Exported pattern synonyms does not mark top-level bindings in RHS as used In-Reply-To: <043.97f0b3892f5aded29e0cb9f0f5c452d4@haskell.org> References: <043.97f0b3892f5aded29e0cb9f0f5c452d4@haskell.org> Message-ID: <058.868fa1e84a6834d0b4cfcca71a035131@haskell.org> #12548: Exported pattern synonyms does not mark top-level bindings in RHS as used -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms, newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: PatternSynonyms => PatternSynonyms, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 18:32:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 18:32:22 -0000 Subject: [GHC] #12368: Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation In-Reply-To: <046.2b784c018fc4a62b657688676ee901f3@haskell.org> References: <046.2b784c018fc4a62b657688676ee901f3@haskell.org> Message-ID: <061.b6cfd9966eebc9eae89ac1c7d036a139@haskell.org> #12368: Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | stranal/should_run/{T12368,T12368a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2392 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => stranal/should_run/{T12368,T12368a} Comment: What should be the status of this ticket? (merge, close, new, patch?) And which milestone should it have? (8.0.2 or 8.2.1?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 20:26:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 20:26:25 -0000 Subject: [GHC] #12030: GHCi Proposal: Display (Data.Kind.)Type instead of * In-Reply-To: <051.b7378bd56fec6afa8a8403e249c2a583@haskell.org> References: <051.b7378bd56fec6afa8a8403e249c2a583@haskell.org> Message-ID: <066.838cec76c2b401e962cc2f4472ed4097@haskell.org> #12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): Comments by Richard Eisenberg (goldfire), copied from [https://ghc.haskell.org/trac/ghc/ticket/12029]: > * `*` is not (yet) deprecated. While I did work with the larger community to come up with the name `Type`, I don't recall getting specific support for deprecating `*`. I do think this is a good direction of travel, but I don't think we should do this without more of a community mandate. > > * There are no kind synonyms in GHC 7.10 or below. Thus, according to the [https://prime.haskell.org/wiki/Libraries/3-Release-Policy three- release policy] (which isn't a formal operating policy of GHC, I don't think) we should wait until 8.4 before starting to deprecate `*`. > > * If the community agrees on moving away from `*`, we could add warnings about `*` to `-Wcompat`. > > * If the community agrees on moving away from `*`, we could also start changing the pretty-printer to use `Type` instead of `*`. This is not to be done lightly, however. There are several issues here: > - Blogs, textbooks, etc., have used `*` for a long time. Furthermore, kinds are hard for newcomers to understand. Changing GHC's output will make this harder. > - Until 8.4 comes out, it will be hard for a library author to discover that `*` is the right way to spell `Type` that is compatible with three releases. > - The use of `*` as a kind is enshrined in the Haskell Reports. These Reports do not specify the error/warning behavior of a compiler, and so this change is not exactly a deviation from a standard. But it continues to make GHC seem as if it's drifting away from the standard with little remorse. > > * I personally think we should wait at least 5-6 years before formally disposing of `*`. I will create a proposal in [https://github.com/ghc-proposals/ghc- proposals] in the near future to start a conversation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 20:27:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 20:27:01 -0000 Subject: [GHC] #12030: GHCi Proposal: Display (Data.Kind.)Type instead of * In-Reply-To: <051.b7378bd56fec6afa8a8403e249c2a583@haskell.org> References: <051.b7378bd56fec6afa8a8403e249c2a583@haskell.org> Message-ID: <066.25304f1b8bb02b59dd10973e83f6bb86@haskell.org> #12030: GHCi Proposal: Display (Data.Kind.)Type instead of * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: johnleo Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * owner: => johnleo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 20:38:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 20:38:10 -0000 Subject: [GHC] #12368: Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation In-Reply-To: <046.2b784c018fc4a62b657688676ee901f3@haskell.org> References: <046.2b784c018fc4a62b657688676ee901f3@haskell.org> Message-ID: <061.de32af5b94fc5d7fd587567977bb5de2@haskell.org> #12368: Demand Analyzer: Cunnig plan not adhered to with aborting fixpoint interation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | stranal/should_run/{T12368,T12368a} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2392 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Sorry for forgetting to close the trac tickets. It should be close. The bug is mostly theoretically and not observed in the wild, so this should not be backported, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 20:39:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 20:39:09 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" Message-ID: <046.93c629409627bd964a188fb34004cca8@haskell.org> #12549: Panic on ":t datatypeName" --------------------------------------+--------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- Reproduction: {{{#!hs GHCi, version 8.1.20160826: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/leo/.ghci Prelude> :m + GHC.Generics :m + GHC.Generics Prelude GHC.Generics> :t datatypeName :t datatypeName ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160826 for x86_64-apple-darwin): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:2094:44 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2122:17 in ghc:TyCoRep substTy, called at compiler/typecheck/TcMType.hs:793:24 in ghc:TcMType in_scope InScope {k1_a1X8} tenv [a1X0 :-> k1_a1X8[tau:3]] cenv [] tys [k_a1X4[tau:3] → (k1_a1X0 → *) → k1_a1X0 → ★] cos [] needInScope [a1X4 :-> k_a1X4[tau:3]] 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 Aug 28 20:41:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 20:41:05 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.38806940eab0fe50fa8d462505db725a@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): My .ghci file, in case it is relevant: {{{ :set -fprint-explicit-foralls :set -fprint-explicit-kinds :set -fprint-unicode-syntax :set -XUnicodeSyntax }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 20:45:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 20:45:33 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.33577601ff6f9941bfb38dcb737150f8@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by johnleo): * version: 8.0.1 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 20:52:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 20:52:38 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.17c00a3ccc83f9411095bb0549677fa5@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Does not reproduce in 8.0.1. Behavior in 8.0.1 is the following: {{{#!hs :t datatypeName datatypeName ∷ ∀ {d} {t ∷ ★ → (* → *) → ★ → ★} {f ∷ * → *} {a}. Datatype ★ d ⇒ t d f a → [Char] }}} Note the inconsistent `*` and `★`. I was trying this out in 8.1 since I'd seen this behavior in 8.0.1 and intended to create a bug for it and fix it. I haven't made any changes to the 8.1 code. It looks like someone else had already been playing in this area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 20:54:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 20:54:24 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.fec78d7da568e510b0c83aeb71ad8f99@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Description changed by johnleo: @@ -3,1 +3,1 @@ - {{{#!hs + {{{ New description: Reproduction: {{{ GHCi, version 8.1.20160826: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/leo/.ghci Prelude> :m + GHC.Generics :m + GHC.Generics Prelude GHC.Generics> :t datatypeName :t datatypeName ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160826 for x86_64-apple-darwin): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:2094:44 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2122:17 in ghc:TyCoRep substTy, called at compiler/typecheck/TcMType.hs:793:24 in ghc:TcMType in_scope InScope {k1_a1X8} tenv [a1X0 :-> k1_a1X8[tau:3]] cenv [] tys [k_a1X4[tau:3] → (k1_a1X0 → *) → k1_a1X0 → ★] cos [] needInScope [a1X4 :-> k_a1X4[tau:3]] 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 Aug 28 21:12:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 21:12:06 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds Message-ID: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> #12550: Inconsistent unicode display for kinds --------------------------------------+--------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- With `:set -fprint-unicode-syntax`, the kind `*` should always be printed as `★`. However the output is extremely inconsistent. Here are a few examples from ghci, and I will add more as I run across them. {{{ :t fmap fmap ∷ ∀ {f ∷ ★ → ★} {a} {b}. Functor f ⇒ (a → b) → f a → f b :i fmap class Functor (f ∷ * → *) where fmap ∷ forall a b. (a → b) → f a → f b :k Functor Functor ∷ (★ → ★) → Constraint :m + GHC.Generics :i Functor -- (among other output) instance ∀ (f ∷ * → ★). Functor f ⇒ Functor (Rec1 f) -- Defined in ‘GHC.Generics’ instance Functor Par1 -- Defined in ‘GHC.Generics’ instance ∀ i (c ∷ Meta) (f ∷ * → ★). Functor f ⇒ Functor (M1 i c f) -- Defined in ‘GHC.Generics’ instance ∀ i c. Functor (K1 i c) -- Defined in ‘GHC.Generics’ instance ∀ (f ∷ * → ★) (g ∷ * → *). (Functor f, Functor g) ⇒ Functor (f :.: g) -- Defined in ‘GHC.Generics’ instance ∀ (f ∷ * → ★) (g ∷ * → ★). (Functor f, Functor g) ⇒ Functor (f :+: g) -- Defined in ‘GHC.Generics’ instance ∀ (f ∷ * → ★) (g ∷ * → ★). (Functor f, Functor g) ⇒ Functor (f :*: g) -- Defined in ‘GHC.Generics’ :t datatypeName datatypeName ∷ ∀ {d} {t ∷ ★ → (* → *) → ★ → ★} {f ∷ * → *} {a}. Datatype ★ d ⇒ t d f a → [Char] :i datatypeName class Datatype k (d ∷ k) where datatypeName ∷ forall {k1} (t ∷ k → (* → *) → k1 → *) (f ∷ * → *) (a ∷ k1). t d f a → [Char] ... -- Defined in ‘GHC.Generics’ }}} Note that `:t datatypeName` causes a panic in 8.1; I have filed a separate bug [https://ghc.haskell.org/trac/ghc/ticket/12549] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 21:15:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 21:15:51 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.ba8ee2fe9f68c771de243f1220ae05aa@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by mpickering): It's possible that the panic also happens in 8.0.1 because it is caused by an assertion failure. Assertions are not turned on in the released builds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 21:18:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 21:18:13 -0000 Subject: [GHC] #12029: Notify user to import * from Data.Kind with TypeInType on In-Reply-To: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> References: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> Message-ID: <066.9b475cda8f630c4f41cad864f193984d@haskell.org> #12029: Notify user to import * from Data.Kind with TypeInType on -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): I have copied Richard's comments about deprecating `*` into [https://ghc.haskell.org/trac/ghc/ticket/12030]. I have also created [https://ghc.haskell.org/trac/ghc/ticket/12550] for the work to fix display of `*` when unicode is set. I agree with Richard's arguments to not change the behavior of either `:k *` or `:i *` for now, and am closing this feature request. If Iceland Jack or anyone else feels very passionately about it, feel free to reopen with additional justification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 21:19:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 21:19:34 -0000 Subject: [GHC] #12029: Notify user to import * from Data.Kind with TypeInType on In-Reply-To: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> References: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> Message-ID: <066.1639bc8a7ef633106a9102d394383444@haskell.org> #12029: Notify user to import * from Data.Kind with TypeInType on -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: johnleo Type: feature request | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * owner: => johnleo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 21:20:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 21:20:01 -0000 Subject: [GHC] #12029: Notify user to import * from Data.Kind with TypeInType on In-Reply-To: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> References: <051.cab193afa0e611bf75b1dd6c73bcab4d@haskell.org> Message-ID: <066.66651953e31dfde94a332ffe8ffbe082@haskell.org> #12029: Notify user to import * from Data.Kind with TypeInType on -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: johnleo Type: feature request | Status: closed Priority: lowest | Milestone: Component: GHCi | Version: 8.1 Resolution: wontfix | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 21:26:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 21:26:31 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.41cb3466c617bc766dfdd53b584935e5@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Replying to [comment:5 mpickering]: > It's possible that the panic also happens in 8.0.1 because it is caused by an assertion failure. Assertions are not turned on in the released builds. Thanks, I didn't know that. Here's an example of a function from Generics which also has strange unicode display behavior, but which does not cause a panic in 8.1: {{{ :t (:*:) (:*:) ∷ ∀ {g ∷ ★ → *} {p} {f ∷ ★ → *}. f p → g p → (:*:) ★ f g p }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 21:31:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 21:31:53 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.5ad7feaa8769ecf3bf72a63023a77204@haskell.org> #12550: Inconsistent unicode display for kinds ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Description changed by johnleo: @@ -12,0 +12,1 @@ + -- (note that forall is also not displayed properly as ∀ here) New description: With `:set -fprint-unicode-syntax`, the kind `*` should always be printed as `★`. However the output is extremely inconsistent. Here are a few examples from ghci, and I will add more as I run across them. {{{ :t fmap fmap ∷ ∀ {f ∷ ★ → ★} {a} {b}. Functor f ⇒ (a → b) → f a → f b :i fmap class Functor (f ∷ * → *) where fmap ∷ forall a b. (a → b) → f a → f b -- (note that forall is also not displayed properly as ∀ here) :k Functor Functor ∷ (★ → ★) → Constraint :m + GHC.Generics :i Functor -- (among other output) instance ∀ (f ∷ * → ★). Functor f ⇒ Functor (Rec1 f) -- Defined in ‘GHC.Generics’ instance Functor Par1 -- Defined in ‘GHC.Generics’ instance ∀ i (c ∷ Meta) (f ∷ * → ★). Functor f ⇒ Functor (M1 i c f) -- Defined in ‘GHC.Generics’ instance ∀ i c. Functor (K1 i c) -- Defined in ‘GHC.Generics’ instance ∀ (f ∷ * → ★) (g ∷ * → *). (Functor f, Functor g) ⇒ Functor (f :.: g) -- Defined in ‘GHC.Generics’ instance ∀ (f ∷ * → ★) (g ∷ * → ★). (Functor f, Functor g) ⇒ Functor (f :+: g) -- Defined in ‘GHC.Generics’ instance ∀ (f ∷ * → ★) (g ∷ * → ★). (Functor f, Functor g) ⇒ Functor (f :*: g) -- Defined in ‘GHC.Generics’ :t datatypeName datatypeName ∷ ∀ {d} {t ∷ ★ → (* → *) → ★ → ★} {f ∷ * → *} {a}. Datatype ★ d ⇒ t d f a → [Char] :i datatypeName class Datatype k (d ∷ k) where datatypeName ∷ forall {k1} (t ∷ k → (* → *) → k1 → *) (f ∷ * → *) (a ∷ k1). t d f a → [Char] ... -- Defined in ‘GHC.Generics’ }}} Note that `:t datatypeName` causes a panic in 8.1; I have filed a separate bug [https://ghc.haskell.org/trac/ghc/ticket/12549] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 21:32:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 21:32:06 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.f962f4489e6495e84989e92349b5e09e@haskell.org> #12550: Inconsistent unicode display for kinds ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by johnleo): * owner: => johnleo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 21:36:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 21:36:22 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.d6b7d24a16def5436ee515db446439a6@haskell.org> #12550: Inconsistent unicode display for kinds ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Description changed by johnleo: @@ -54,0 +54,4 @@ + + :t (:*:) + (:*:) ∷ ∀ {g ∷ ★ → *} {p} {f ∷ ★ → *}. f p → g p → (:*:) ★ f g p + -- Note that ★ and * are reversed from what :i displays! New description: With `:set -fprint-unicode-syntax`, the kind `*` should always be printed as `★`. However the output is extremely inconsistent. Here are a few examples from ghci, and I will add more as I run across them. {{{ :t fmap fmap ∷ ∀ {f ∷ ★ → ★} {a} {b}. Functor f ⇒ (a → b) → f a → f b :i fmap class Functor (f ∷ * → *) where fmap ∷ forall a b. (a → b) → f a → f b -- (note that forall is also not displayed properly as ∀ here) :k Functor Functor ∷ (★ → ★) → Constraint :m + GHC.Generics :i Functor -- (among other output) instance ∀ (f ∷ * → ★). Functor f ⇒ Functor (Rec1 f) -- Defined in ‘GHC.Generics’ instance Functor Par1 -- Defined in ‘GHC.Generics’ instance ∀ i (c ∷ Meta) (f ∷ * → ★). Functor f ⇒ Functor (M1 i c f) -- Defined in ‘GHC.Generics’ instance ∀ i c. Functor (K1 i c) -- Defined in ‘GHC.Generics’ instance ∀ (f ∷ * → ★) (g ∷ * → *). (Functor f, Functor g) ⇒ Functor (f :.: g) -- Defined in ‘GHC.Generics’ instance ∀ (f ∷ * → ★) (g ∷ * → ★). (Functor f, Functor g) ⇒ Functor (f :+: g) -- Defined in ‘GHC.Generics’ instance ∀ (f ∷ * → ★) (g ∷ * → ★). (Functor f, Functor g) ⇒ Functor (f :*: g) -- Defined in ‘GHC.Generics’ :t datatypeName datatypeName ∷ ∀ {d} {t ∷ ★ → (* → *) → ★ → ★} {f ∷ * → *} {a}. Datatype ★ d ⇒ t d f a → [Char] :i datatypeName class Datatype k (d ∷ k) where datatypeName ∷ forall {k1} (t ∷ k → (* → *) → k1 → *) (f ∷ * → *) (a ∷ k1). t d f a → [Char] ... -- Defined in ‘GHC.Generics’ :t (:*:) (:*:) ∷ ∀ {g ∷ ★ → *} {p} {f ∷ ★ → *}. f p → g p → (:*:) ★ f g p -- Note that ★ and * are reversed from what :i displays! }}} Note that `:t datatypeName` causes a panic in 8.1; I have filed a separate bug [https://ghc.haskell.org/trac/ghc/ticket/12549] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 22:43:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 22:43:43 -0000 Subject: [GHC] #4239: -ddump-minimal-imports vs. type operators In-Reply-To: <046.6d817d321031413c0ab6d8874d8ae7ab@haskell.org> References: <046.6d817d321031413c0ab6d8874d8ae7ab@haskell.org> Message-ID: <061.0b8cf17cbcc873bfdcad56573963187b@haskell.org> #4239: -ddump-minimal-imports vs. type operators -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4239 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2480 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D2480 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 28 23:05:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Aug 2016 23:05:12 -0000 Subject: [GHC] #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures In-Reply-To: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> References: <050.185d2d0a1b9239bf35fc1b4d95f3a583@haskell.org> Message-ID: <065.6f4c1732d56cd9020b5edff2952018f3@haskell.org> #12546: GeneralizedNewtypeDeriving produces error messages with incorrect kind signatures -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: mniip Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2484 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D2484 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 06:56:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 06:56:37 -0000 Subject: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2. In-Reply-To: <046.611e1011b849d674524f2ee05d864a89@haskell.org> References: <046.611e1011b849d674524f2ee05d864a89@haskell.org> Message-ID: <061.c7eb1ce1f2e0e7c57cd81a847e6fb581@haskell.org> #5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: akio Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2486 Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * owner: daniel.is.fischer => akio * differential: => Phab:D2486 Comment: I implemented rules for `div` and `mod`. I decided not to do anything with Euclidean division because (1) the rules I added are valid for the current semantics (floor division) as well as for Euclidean division, and (2) I believe that changing the semantics of `div` and `mod` is a much bigger change and should be discussed separately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 07:16:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 07:16:11 -0000 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@haskell.org> References: <047.1e9bce153303809272446b6c0aede02d@haskell.org> Message-ID: <062.b90509fc61c7977d9cc6a1ab11c3621d@haskell.org> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | nofib/spectral/calendar Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 07:45:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 07:45:44 -0000 Subject: [GHC] #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone In-Reply-To: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> References: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> Message-ID: <061.feab335754da04bf6e76eae383a1656e@haskell.org> #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * type: bug => feature request Comment: Currently all `ForeignPtrs` that are unreachable get finalized at the same time. This is how it's intended to work. We *could* refine it so that a finalizer from a `Concurrent.ForeignPtr` can keep a C `ForeignPtr` alive. It would mean processing the two kinds of weak pointers in separate batches (and possibly keeping them in separate lists, I'm not sure). Note that this is a special case, and is different from saying that a finalizer from any dead `ForeignPtr` can keep any other `ForeignPtr` alive. It's not clear to me how you'd define a sensible semantics in that case (consider a `ForeignPtr` that refers to itself from its finalizer, or two `ForeignPtr`s that refer to each other from their finalizers). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 08:27:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 08:27:41 -0000 Subject: [GHC] #11598: Cache coercion kinds and roles In-Reply-To: <047.56bbfff0d86db02c37b25ddc698d48a1@haskell.org> References: <047.56bbfff0d86db02c37b25ddc698d48a1@haskell.org> Message-ID: <062.d2e5c80040466bdf7d3297215921cd70@haskell.org> #11598: Cache coercion kinds and roles -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8095 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -13,0 +13,4 @@ + + This would make #8095 much easier. + + See also #11735. New description: Because we never inspect the structure of a coercion, it is easy to cache coercions' kinds and role at the top level, using something like this: {{{ data Coercion = MkCoercion { coercionKind :: Pair Type , coercionRole :: Role , coercionRep :: CoercionRep } data CoercionRep = -- the long, recursive datatype we have now }}} In the process, various role and type information currently stored in the recursive structure could be dropped. This would make #8095 much easier. See also #11735. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 08:28:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 08:28:07 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.4db497379d9235bae23b7e0bdc59b287@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): see #11598, which is closely related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 08:29:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 08:29:18 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) In-Reply-To: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> References: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> Message-ID: <072.7030c1fb7bcc5cd0f9f16fa87350326d@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Several points here * We don't yet know why 8.0 is worse than 7.10. That would e helpful. * The coercions record a proof of all the list manipulations involved. It's not surprising that they can get big. What is surprising is why they are bigger with 8.0 * GHC includes a "coercion optimiser" `OptCoercion.hs`, which tries to shrink a big coercion to a smaller but equivalent coercion. It's possible that 8.0 is somehow missing a crucial optimisation that fires in 7.10. * We also have a plan, recorded in Trac #8095, to discard coercions altogether. But neither Richard or I have found time to execute on that plan. See also #11598 Bottom line: more insight into what is going on would be really helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 09:28:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 09:28:48 -0000 Subject: [GHC] #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone In-Reply-To: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> References: <046.7dd68988f91b9dafc45fe77e204597d9@haskell.org> Message-ID: <061.c6b9dd072e76b9050c26643ebf5eb1e8@haskell.org> #12547: Concurrent.ForeignPtr needs to access a C-ForeignPtr, but this is already gone -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): I have to add that I do not really need `Concurrent.ForeignPtr`. It allowed me to call `touchForeignPtr` and I hoped that this would solve my problem. Since it does not work we may forget about `Concurrent.ForeignPtr` and look for a solution using entirely C `ForeignPtr`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 13:35:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 13:35:06 -0000 Subject: [GHC] #11565: Restore code to handle '-fmax-worker-args' flag In-Reply-To: <045.9d241621de87bb494a516e9874327ca7@haskell.org> References: <045.9d241621de87bb494a516e9874327ca7@haskell.org> Message-ID: <060.db9473cb9f614472088f169915ac67f3@haskell.org> #11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Current motivating example to fix it is DynFlags example itself. I was profiling perf build of GHC and noticed a function that pushes whole DynFlags from stack to heap. This small piece of code emits 10 pages of mov instructions. https://git.haskell.org/ghc.git/blob/HEAD:/compiler/nativeGen/AsmCodeGen.hs#l1109 {{{#!hs 1086 cmmExprNative :: ReferenceKind -> CmmExpr -> CmmOptM CmmExpr 1087 cmmExprNative referenceKind expr = do 1088 dflags <- getDynFlags 1089 let platform = targetPlatform dflags 1090 arch = platformArch platform 1091 case expr of ... 1106 CmmLit (CmmLabel lbl) 1107 -> do 1108 cmmMakeDynamicReference dflags referenceKind lbl ... }}} {{{ │ cmmExprNative :: ReferenceKind -> CmmExpr -> CmmOptM CmmExpr │ cmmExprNative referenceKind expr = do 0,11 │ cmp $0x3,%rax │ ↑ jb 3ceb930 │ -- we must convert block Ids to CLabels here, because we │ -- might have to do the PIC transformation. Hence we must │ -- not modify BlockIds beyond this point. │ │ CmmLit (CmmLabel lbl) │ -> do 2,02 │ add $0x890,%r12 │ cmp 0x358(%r13),%r12 │ ↑ ja 3cf456f 0,16 │ mov 0x7(%rbx),%rax 0,59 │ lea ghc_DynFlags_DynFlags_con_info,%rbx 0,05 │ mov %rbx,-0x888(%r12) 3,41 │18e9: mov 0x50(%rsp),%rbx 0,05 │ mov %rbx,-0x880(%r12) 0,32 │ mov 0x58(%rsp),%r14 │ mov %r14,-0x878(%r12) │ mov 0x60(%rsp),%rbx │ mov %rbx,-0x870(%r12) 0,05 │ mov 0x68(%rsp),%r14 │ mov %r14,-0x868(%r12) │ mov 0x70(%rsp),%rbx │ mov %rbx,-0x860(%r12) │ mov 0x78(%rsp),%r14 0,11 │ mov %r14,-0x858(%r12) 0,05 │ mov 0x80(%rsp),%rbx │ mov %rbx,-0x850(%r12) 0,05 │ mov 0x88(%rsp),%r14 │ mov %r14,-0x848(%r12) │ mov 0x90(%rsp),%rbx │ mov %rbx,-0x840(%r12) 0,05 │ mov 0x98(%rsp),%r14 0,05 │ mov %r14,-0x838(%r12) 0,11 │ mov 0xa0(%rsp),%rbx │ mov %rbx,-0x830(%r12) │ mov 0xa8(%rsp),%r14 │ mov %r14,-0x828(%r12) 0,05 │ mov 0xb0(%rsp),%rbx │ mov %rbx,-0x820(%r12) │ mov 0xb8(%rsp),%r14 ... }}} On x86_64 register mapping is: '''%r12%''' - heap, '''%rsp''' - machine SP. The suspiction is worker/wrapper optimisation that moves huge 140-field record '''DynFlags''' from heap to stack even its not mutated. Looking at the AsmCodeGen.hs with -ddump-worker-wrapper {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -g -Wall -this-unit-id ghc-8.1 -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/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP- DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id array-0.5.1.1 -package-id base-4.9.0.0 -package-id binary-0.8.3.0 -package-id bytestring-0.10.8.1 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id ghc-boot-8.1 -package-id ghci-8.1 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 -package-id process-1.4.2.0 -package-id template-haskell-2.11.0.0 -package-id time-1.6.0.1 -package-id transformers-0.5.2.0 -package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O2 -no-user-package-db -rtsopts -Wnoncanonical-monad- instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/nativeGen/AsmCodeGen.hs -o compiler/stage2/build/AsmCodeGen.o -dyno compiler/stage2/build/AsmCodeGen.dyn_o -ddump-worker-wrapper }}} there is a few places with functions with huge arity-140. One of the first places picked at random: '''dumpIfSet_dyn''' accepts a lot of separate arguments. {{{ case dflags_ab5I of { DynFlags ww1_al11 ww2_al12 ww3_al13 ww4_al14 ww5_al15 ww6_al16 [Dmd=] ww7_al17 ww8_al18 ww9_al19 ww10_al1a ww11_al1b ww12_al1c ww13_al1d ww14_al1e ww15_al1f ww16_al1g ww17_al1h ww18_al1i ww19_al1j ww20_al1k ww21_al1l ww22_al1m ww23_al1n ww24_al1o ww25_al1p ww26_al1q ww27_al1r ww28_al1s ww29_al1t ww30_al1u ww31_al1v ww32_al1w ww33_al1x ww34_al1y ww35_al1z ww36_al1A ww37_al1B ww38_al1C ww39_al1D ww40_al1E ww41_al1F ww42_al1G ww43_al1H ww44_al1I ww45_al1J ww46_al1K ww47_al1L ww48_al1M ww49_al1N ww50_al1O ww51_al1P ww52_al1Q ww53_al1R ww54_al1S ww55_al1T ww56_al1U ww57_al1V ww58_al1W ww59_al1X ww60_al1Y ww61_al1Z ww62_al20 ww63_al21 ww64_al22 ww65_al23 ww66_al24 ww67_al25 ww68_al26 ww69_al27 ww70_al28 ww71_al29 ww72_al2a ww73_al2b ww74_al2c ww75_al2d ww76_al2e ww77_al2f ww78_al2g ww79_al2h ww80_al2i ww81_al2j ww82_al2k ww83_al2l ww84_al2m [Dmd=] ww85_al2n [Dmd=] ww86_al2o ww87_al2p ww88_al2q ww89_al2r ww90_al2s ww91_al2t ww92_al2u ww93_al2v ww94_al2w ww95_al2x ww96_al2y ww97_al2z ww98_al2A ww99_al2B ww100_al2C ww101_al2D ww102_al2E ww103_al2F ww104_al2G ww105_al2H ww106_al2I ww107_al2J ww108_al2K ww109_al2L ww110_al2M ww111_al2N ww112_al2O ww113_al2P ww114_al2Q ww115_al2R ww116_al2S [Dmd=] ww117_al2T ww118_al2U ww119_al2V ww120_al2W ww121_al2X ww122_al2Y ww123_al2Z ww124_al30 ww125_al31 ww126_al32 ww127_al33 ww128_al34 ww129_al35 ww130_al36 ww131_al37 ww132_al38 ww133_al39 ww134_al3a ww135_al3b ww136_al3c -> ErrUtils.$wdumpIfSet_dyn ww1_al11 ww2_al12 ww3_al13 ww4_al14 ww5_al15 ww6_al16 ww7_al17 ww8_al18 ww9_al19 ww10_al1a ww11_al1b ww12_al1c ww13_al1d ww14_al1e ww15_al1f ww16_al1g ww17_al1h ww18_al1i ww19_al1j ww20_al1k ... }}} I'll try to craft small example that demonstrates the blowup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 13:49:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 13:49:29 -0000 Subject: [GHC] #12530: Template Haskell support for TypeApplications In-Reply-To: <050.0f7e72af0d2d64a3645c78721f01e356@haskell.org> References: <050.0f7e72af0d2d64a3645c78721f01e356@haskell.org> Message-ID: <065.988dd5bb9b21ec3d497ab05508a2eb5e@haskell.org> #12530: Template Haskell support for TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2472 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"983f6609b68bf4cef0a5c94cd5568673cab3a6cf/ghc" 983f6609/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="983f6609b68bf4cef0a5c94cd5568673cab3a6cf" Template Haskell support for TypeApplications Summary: Fixes #12530. Test Plan: make test TEST=12530 Reviewers: austin, bgamari, hvr, goldfire Reviewed By: goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2472 GHC Trac Issues: #12530 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 13:51:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 13:51:36 -0000 Subject: [GHC] #12530: Template Haskell support for TypeApplications In-Reply-To: <050.0f7e72af0d2d64a3645c78721f01e356@haskell.org> References: <050.0f7e72af0d2d64a3645c78721f01e356@haskell.org> Message-ID: <065.d7f842fa8e28ced1d97759647a87237e@haskell.org> #12530: Template Haskell support for TypeApplications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T12530 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2472 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => th/T12530 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 15:23:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 15:23:50 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) In-Reply-To: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> References: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> Message-ID: <072.662c0ba9d461150a59eb17c40ecb5a06@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mikhail.vorozhtsov): Here are some numbers from `-v4` logs: {{{ $ grep -E '(=====|^Result|coercions)' out-7_10.log | grep -v 'RHS size' | head -40 ==================== Parser ==================== ==================== Source Statistics ==================== ==================== Occurrence analysis ==================== ==================== Desugar (after optimization) ==================== Result size of Desugar (after optimization) = {terms: 2,144, types: 128,368, coercions: 415,496} ==================== Occurrence analysis ==================== Result size of Simplifier iteration=1 = {terms: 3,200, types: 173,424, coercions: 415,528} ==================== Occurrence analysis ==================== Result size of Simplifier = {terms: 3,200, types: 173,424, coercions: 415,528} ==================== Specialise ==================== Result size of Specialise = {terms: 12,416, types: 658,320, coercions: 455,704} ==================== FloatOut stats: ==================== Result size of Float out(FOS {Lam = Just 0, = {terms: 13,472, types: 739,808, coercions: 455,704} ==================== Occurrence analysis ==================== Result size of Simplifier iteration=1 = {terms: 30,336, types: 1,848,096, coercions: 6,417,128} ==================== Occurrence analysis ==================== Result size of Simplifier = {terms: 30,336, types: 1,848,096, coercions: 6,417,128} ==================== Occurrence analysis ==================== Result size of Simplifier = {terms: 30,336, types: 1,848,096, coercions: 6,417,128} ==================== Occurrence analysis ==================== Result size of Simplifier = {terms: 30,336, types: 1,848,096, coercions: 6,417,128} Result size of Float inwards = {terms: 30,336, types: 1,848,096, coercions: 6,417,128} ==================== Called arity analysis ==================== Result size of Called arity analysis = {terms: 30,336, types: 1,848,096, coercions: 6,417,128} ==================== Occurrence analysis ==================== }}} for 7.10.3 versus {{{ $ grep -E '(=====|^Result|coercions)' out-8_0.log | grep -v 'RHS size' | head -40 ==================== Parser ==================== ==================== Source Statistics ==================== ==================== Occurrence analysis ==================== ==================== Desugar (after optimization) ==================== Result size of Desugar (after optimization) = {terms: 3,835, types: 147,262, coercions: 549,848} ==================== Occurrence analysis ==================== Result size of Simplifier iteration=1 = {terms: 4,897, types: 161,681, coercions: 549,849} ==================== Occurrence analysis ==================== Result size of Simplifier = {terms: 4,897, types: 161,681, coercions: 549,849} ==================== Specialise ==================== Result size of Specialise = {terms: 17,793, types: 899,977, coercions: 3,094,577} ==================== FloatOut stats: ==================== Result size of Float out(FOS {Lam = Just 0, = {terms: 20,769, types: 1,109,785, coercions: 3,094,577} ==================== Occurrence analysis ==================== Result size of Simplifier iteration=1 = {terms: 16,553, types: 871,953, coercions: 2,232,281} ==================== Occurrence analysis ==================== Result size of Simplifier = {terms: 16,429, types: 864,761, coercions: 2,184,448} ==================== Occurrence analysis ==================== Result size of Simplifier = {terms: 16,429, types: 864,761, coercions: 2,184,448} ==================== Occurrence analysis ==================== Result size of Simplifier iteration=1 = {terms: 87,357, types: 4,366,893, coercions: 10,008,352} ==================== Occurrence analysis ==================== Result size of Simplifier = {terms: 87,357, types: 4,366,893, coercions: 10,008,352} Result size of Float inwards = {terms: 87,357, types: 4,366,893, coercions: 10,008,352} ==================== Called arity analysis ==================== Result size of Called arity analysis = {terms: 87,357, types: 4,366,893, coercions: 10,008,352} ==================== Occurrence analysis ==================== }}} for 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 15:26:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 15:26:36 -0000 Subject: [GHC] #11565: Restore code to handle '-fmax-worker-args' flag In-Reply-To: <045.9d241621de87bb494a516e9874327ca7@haskell.org> References: <045.9d241621de87bb494a516e9874327ca7@haskell.org> Message-ID: <060.b561ca0a3337dc36395084ee33d9fe35@haskell.org> #11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): And '''dumpIfSet_dyn''' (used across the GHC including AsmCodegen) is exported as a 141-ary function (along with 5-ary function): {{{#!hs $ inplace/bin/ghc-stage1 --show-iface compiler/stage2/build/ErrUtils.dyn_hi ... 31b85108354ff085ace45a61abe9a220 $wdumpIfSet_dyn :: GhcMode -> GhcLink -> HscTarget -> Settings -> SigOf -> Int -> Int -> Int -> Int ... -> SDoc -> State# RealWorld -> (# State# RealWorld, () #) {- Arity: 140, Strictness: < L,U> , Inline: [0] -} ... dumpIfSet_dyn :: DynFlags -> DumpFlag -> String -> SDoc -> IO () {- Arity: 5, Strictness: , Unfolding: InlineRule (0, True, True) dumpIfSet_dyn1 `cast` (_R ->_R _R ->_R _R ->_R _R ->_R Sym (N:IO[0] <()>_R)) -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 18:47:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 18:47:14 -0000 Subject: [GHC] #10963: Beginner-targeted language extension In-Reply-To: <045.cc74d15b01a49696436fbbb3b560b576@haskell.org> References: <045.cc74d15b01a49696436fbbb3b560b576@haskell.org> Message-ID: <060.9553e7e962258cea1a0a22c163149022@haskell.org> #10963: Beginner-targeted language extension -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T10963 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2136 Wiki Page: | [wiki:Design/GHCi/Type] | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.0.2 => 8.2.1 Comment: I'm fine with that. Let's bump this off to 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 18:48:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 18:48:04 -0000 Subject: [GHC] #11975: New GHCi command to print out the type of an expression without instantiating In-Reply-To: <047.e04c32cf521defebb6ebe9369a8011c1@haskell.org> References: <047.e04c32cf521defebb6ebe9369a8011c1@haskell.org> Message-ID: <062.62476c607405eafce5738f0a3e75ca41@haskell.org> #11975: New GHCi command to print out the type of an expression without instantiating -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11975 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2136 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.0.2 => 8.2.1 Comment: We're going to bump this off to 8.2.1 per ticket:10963#comment:25. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 19:01:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 19:01:30 -0000 Subject: [GHC] #12531: Holes should be representation-polymorphic In-Reply-To: <044.38d412e29e728e7d1a4333b441265291@haskell.org> References: <044.38d412e29e728e7d1a4333b441265291@haskell.org> Message-ID: <059.e73eeac815dafe7272918d00507a860d@haskell.org> #12531: Holes should be representation-polymorphic -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature request | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: partial- | sigs/should_compile/T12531 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed, I'm fine with merging this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 19:11:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 19:11:00 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.555280b22aca160d0cd17bddc9946338@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dterei): * owner: => dterei Comment: Thanks for the report. This is definitely a bug, I'll take a look shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 20:02:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 20:02:24 -0000 Subject: [GHC] #12413: Compact regions support needs some discussion in the release notes In-Reply-To: <046.9aceaa22b70735e95693c6721c17ff03@haskell.org> References: <046.9aceaa22b70735e95693c6721c17ff03@haskell.org> Message-ID: <061.94cf3a2b4da775c7231c45f5291c01b8@haskell.org> #12413: Compact regions support needs some discussion in the release notes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Documentation | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.0.1 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 20:20:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 20:20:59 -0000 Subject: [GHC] #12164: Type signatures in patterns not (yet) handled by Template Haskell In-Reply-To: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> References: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> Message-ID: <060.b1e3ca167dcd3c23109ad3c98cb1c592@haskell.org> #12164: Type signatures in patterns not (yet) handled by Template Haskell -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2490 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mikhail.vorozhtsov): * differential: => Phab:D2490 Comment: Needed this for my DSL, so I wrote a partial (for type signatures without type variables) patch: Phab:D2490 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 20:29:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 20:29:26 -0000 Subject: [GHC] #12178: Allow inline pragmas on pattern synonyms In-Reply-To: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> References: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> Message-ID: <064.4957fc3aa8c586da2988e98d86c213d7@haskell.org> #12178: Allow inline pragmas on pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 20:35:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 20:35:51 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.0cda6c5f33a47c84dc737e0c68c3476a@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed there does appear to be some sort of loop here. `-ddump-inlinings` shows long repeated runs of, {{{ ... Inlining done: Control.Monad.Trans.State.Lazy.$fMonadStateT1 Inlining done: Control.Monad.Trans.State.Lazy.$fMonadStateT_$c>>= Inlining done: GHC.Base.$ Inlining done: Control.Monad.Trans.State.Lazy.runStateT Inlining done: Control.Monad.Trans.State.Lazy.runStateT1 Inlining done: Control.Monad.Trans.State.Lazy.runStateT Inlining done: Control.Monad.Trans.State.Lazy.runStateT1 Inlining done: GHC.Base.liftM Inlining done: Control.Monad.Trans.State.Lazy.$fMonadStateT_$creturn ... }}} These runs are punctuated by runs of, {{{ ... Inlining done: GHC.Base.$fApplicativeMaybe_$sliftM ... }}} The runs appear to get longer as the simplifier progresses. It indeed seems plausible that all of these bindings have INLINE pragmas attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 20:37:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 20:37:40 -0000 Subject: [GHC] #12482: Infinite compilation time when using wrongly ordered constraints In-Reply-To: <046.385955bbc36fdf0c78384562d17bec02@haskell.org> References: <046.385955bbc36fdf0c78384562d17bec02@haskell.org> Message-ID: <061.262279ad08aed95a57247adf7b060652@haskell.org> #12482: Infinite compilation time when using wrongly ordered constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Indeed a small program reproducing the issue would be quite helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 20:45:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 20:45:06 -0000 Subject: [GHC] #12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4 In-Reply-To: <047.3cd5b94812ad80cfce971203d7137096@haskell.org> References: <047.3cd5b94812ad80cfce971203d7137096@haskell.org> Message-ID: <062.6dda5c97b833611f390cfcea087c7508@haskell.org> #12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4 -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: goldfire (added) Comment: Adding Richard as this is his area of expertise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 20:54:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 20:54:20 -0000 Subject: [GHC] #12395: Misleading GHCi errors when package is installed In-Reply-To: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> References: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> Message-ID: <062.c157610cd2a6fac12af67861b20d108a@haskell.org> #12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11536 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: ezyang (added) Comment: Hmm, ezyang do you have any idea of what might be happening here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 20:58:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 20:58:53 -0000 Subject: [GHC] #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes In-Reply-To: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> References: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> Message-ID: <064.a257dd7252ebc01e5c5551b3d0a01915@haskell.org> #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ak3n Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10569, #12156, | Differential Rev(s): Phab:D2458 #12406 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:00:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:00:59 -0000 Subject: [GHC] #12174: Recursive use of type-in-type results in infinite loop In-Reply-To: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> References: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> Message-ID: <060.24042e78547be2349a2cf57b5bcd9674@haskell.org> #12174: Recursive use of type-in-type results in infinite loop -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: goldfire (added) Comment: CCing goldfire who will hopefully have some ideas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:04:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:04:33 -0000 Subject: [GHC] #12198: Stack fails to compile using GHC 8.0.1 on MacOS 10.12 In-Reply-To: <049.04d5c9fc808542b550f790907cac702a@haskell.org> References: <049.04d5c9fc808542b550f790907cac702a@haskell.org> Message-ID: <064.737dc19aa3e16fb5d5a1bc183f18fca4@haskell.org> #12198: Stack fails to compile using GHC 8.0.1 on MacOS 10.12 -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Is this reproducible? It sounds like the `dylib` may be corrupted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:07:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:07:16 -0000 Subject: [GHC] #12395: Misleading GHCi errors when package is installed In-Reply-To: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> References: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> Message-ID: <062.cb4a6db419ffc6fc9b5415d9edee9603@haskell.org> #12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11536 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I think the answer is, "You shouldn't use cabal install, full stop. But you *especially* shouldn't use it on code you are editing and recompiling." Here's what's happening: 1. When you cabal install the package, it gets added to the user package database. This means that if you run ghci without any flags, all of the modules from this package are available for import. 2. When you ghci Main.hs, it first looks to see if there's a local B.hs. There is none, so then it looks to see if any exposed packages in the databases its using (including the user one) have B. The one that cabal install'ed is there, so it uses that! And so now you have two versions of A in scope: one that came from the cabal install'ed package, and one that was locally interpreted by bytecode. I think GHC's error messages here could be a lot better. But that's what's happening. If you unregister the installed package (ghc-pkg unregister) you'll stop picking up the installed copy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:09:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:09:12 -0000 Subject: [GHC] #12198: Stack fails to compile using GHC 8.0.1 on MacOS 10.12 In-Reply-To: <049.04d5c9fc808542b550f790907cac702a@haskell.org> References: <049.04d5c9fc808542b550f790907cac702a@haskell.org> Message-ID: <064.f0f34a5250ba6541f11d4171503fcbcd@haskell.org> #12198: Stack fails to compile using GHC 8.0.1 on MacOS 10.12 -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:2 bgamari]: > Is this reproducible? It sounds like the `dylib` may be corrupted. Never mind; corruption actually isn't likely. It sounds like there are simply too many "load commands". Is it possible that the you compiled `libghc` with `-split-sections`? It would be helpful to get a dump of `libghc_44.dylib`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:10:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:10:57 -0000 Subject: [GHC] #12201: Wrong instance selection with overlapping instance in a superclass In-Reply-To: <045.8161628fc6b893165b02a8d6ec3bacef@haskell.org> References: <045.8161628fc6b893165b02a8d6ec3bacef@haskell.org> Message-ID: <060.9c6dc2752a231dd20fb94e883de875f3@haskell.org> #12201: Wrong instance selection with overlapping instance in a superclass -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: Closing since there appears to be no better ideas on the table. Feel free to re-open if you have a better alternative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:18:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:18:35 -0000 Subject: [GHC] #12206: No exposed API to get full text of ErrMsg In-Reply-To: <042.f7207806b1b651d6481b5d2408abd0fe@haskell.org> References: <042.f7207806b1b651d6481b5d2408abd0fe@haskell.org> Message-ID: <057.727c5bf6969e292c8555330663cd3755@haskell.org> #12206: No exposed API to get full text of ErrMsg -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2491 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2491 * milestone: => 8.0.2 Comment: bit, does Phab:D2491 look okay to you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:18:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:18:49 -0000 Subject: [GHC] #12395: Misleading GHCi errors when package is installed In-Reply-To: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> References: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> Message-ID: <062.099f04c2d5e84d77e688e815fb6e9e0e@haskell.org> #12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11536 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): My current workflow requires using `cabal install`, and I'm not aware of another option (though I'm open to suggestions. I'm not sure if this problem occurs with stack or not, but either way stack still doesn't have an LTS resolver for GHC 8.0.) I wrote a library, and also a separate program which depends on that library. Thus the library must be cabal- installed to build the second program (this is true even if I use `add- source` in cabal). Then when I go back to make changes to the library, the error above can occur. Note that in this workflow, it is never necessary to `ghc-pkg unregister` the library: if I build with cabal, it detects the changed source and automatically rebuilds/installs, and if I use ghci it uses the source code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:21:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:21:00 -0000 Subject: [GHC] #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" In-Reply-To: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> References: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> Message-ID: <060.5ca106ffa31b5aae631b799946acf9c1@haskell.org> #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 Comment: Phyx, do you think you'll have time to submit a patch for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:24:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:24:11 -0000 Subject: [GHC] #12223: Get rid of extra_files.py In-Reply-To: <045.25e222aea78531eb17d022751cfc2f2d@haskell.org> References: <045.25e222aea78531eb17d022751cfc2f2d@haskell.org> Message-ID: <060.bbfebe30f14e7f35cc98bf280a04ca74@haskell.org> #12223: Get rid of extra_files.py -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => task * milestone: => 8.2.1 Comment: I appreciate you waiting for fix this thomie! Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:29:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:29:58 -0000 Subject: [GHC] #12349: Parallel make should interleave output if it means we can report an error earlier In-Reply-To: <045.f033b19a8971b46e03b9e6bbbfc1bd94@haskell.org> References: <045.f033b19a8971b46e03b9e6bbbfc1bd94@haskell.org> Message-ID: <060.9450c1ebe3c17c21f63183eac84f1e09@haskell.org> #12349: Parallel make should interleave output if it means we can report an error earlier -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:30:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:30:00 -0000 Subject: [GHC] #12395: Misleading GHCi errors when package is installed In-Reply-To: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> References: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> Message-ID: <062.d7e02e6a00bad0649267e9d2b28e9efc@haskell.org> #12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11536 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Try using `cabal new-build` (http://blog.ezyang.com/2016/05/announcing- cabal-new-build-nix-style-local-builds/), it's designed *exactly* for your use-case. Actually, sandboxes should have also worked, but sandboxes are buggy and you should use new-build instead. I know that GHCi picks up local modules, and so it is just in the particular case you've reported here that things work poorly (missing local module). But it is hard to see how we can behave differently. On workaround for this particular case is to set `exposed: False` in your Cabal file, so that it is NOT pulled in by default when you invoke GHCi. Maybe that's good enough for you, if you don't want to use new-build? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:30:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:30:56 -0000 Subject: [GHC] #12372: bug: documentation for Control.Monad.guard not useful after AMP In-Reply-To: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> References: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> Message-ID: <058.b2eb07b97b99c2ed7aa62c2ef4b61492@haskell.org> #12372: bug: documentation for Control.Monad.guard not useful after AMP -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: ntc2, any word on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:31:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:31:17 -0000 Subject: [GHC] #12386: Infinite loop when showing type family error In-Reply-To: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> References: <047.61d384525fef8c0da8d7346e45b629d6@haskell.org> Message-ID: <062.d589fc7d8e27af54f58c90af75e0f7cd@haskell.org> #12386: Infinite loop when showing type family error -------------------------------------+------------------------------------- Reporter: elliottt | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Simon, what ever happened here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:36:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:36:06 -0000 Subject: [GHC] #12396: Panic when specializing in another module In-Reply-To: <047.cfbab0d2aaad50ebf39c103bee8948e0@haskell.org> References: <047.cfbab0d2aaad50ebf39c103bee8948e0@haskell.org> Message-ID: <062.e599ca5a8d2b0065392269d4dc7bcd59@haskell.org> #12396: Panic when specializing in another module -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: Bumping in priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:39:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:39:51 -0000 Subject: [GHC] #12395: Misleading GHCi errors when package is installed In-Reply-To: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> References: <047.ba2be8af6e35ce15a9e6f8ef5ab4b38f@haskell.org> Message-ID: <062.22312127b1daa51951e9cb79bf223352@haskell.org> #12395: Misleading GHCi errors when package is installed -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11536 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): For the record, I was using a (common) sandbox for the library and the other program. In addition to cabal `new-build` and setting `expose: False`, another solution that should work would be to use `-hide-package mylib` when invoking GHCi. This results in a semi-reasonable error: {{{ Failed to load interface for ‘’ It is a member of the hidden package ‘mylib-0.0.0.1’. Use -v to see a list of the files searched for. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:42:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:42:44 -0000 Subject: [GHC] #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' In-Reply-To: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> References: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> Message-ID: <061.0e0ae4dab699bbc04c7e3ba00e852e55@haskell.org> #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2492 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2492 Comment: DanielG, how does Phab:D2492 look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:43:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:43:23 -0000 Subject: [GHC] #12409: Unboxed tuples have no type representations In-Reply-To: <046.32a785a6183ec0ab7732a4ef59760aa4@haskell.org> References: <046.32a785a6183ec0ab7732a4ef59760aa4@haskell.org> Message-ID: <061.f2c8ecd92708564444088aa2cec749db@haskell.org> #12409: Unboxed tuples have no type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 11736 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: Sadly this won't make it for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:45:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:45:26 -0000 Subject: [GHC] #12411: GHC panic on TypeApplications + TemplateHaskell In-Reply-To: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> References: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> Message-ID: <066.de7410b3d607510b362b97716ac985dc@haskell.org> #12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: goldfire (added) * failure: None/Unknown => Compile-time crash Comment: Bringing in Richard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:47:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:47:49 -0000 Subject: [GHC] #12416: Some GCC versions warn about failed inlines In-Reply-To: <046.adef2f266c45a6c2f2bf6b2786766339@haskell.org> References: <046.adef2f266c45a6c2f2bf6b2786766339@haskell.org> Message-ID: <061.995b1ecad81939826e76392c89b4533c@haskell.org> #12416: Some GCC versions warn about failed inlines -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:52:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:52:35 -0000 Subject: [GHC] #12421: TestEquality and TestCoercion documentation is confusing In-Reply-To: <045.c655c505ffcb7aac601fde4e2ee18aac@haskell.org> References: <045.c655c505ffcb7aac601fde4e2ee18aac@haskell.org> Message-ID: <060.18e9040ba4307bcb1b317d5e8259b0ee@haskell.org> #12421: TestEquality and TestCoercion documentation is confusing -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Feel free to suggest a changed wording. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:54:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:54:50 -0000 Subject: [GHC] #12423: Panic with DeriveAnyClass In-Reply-To: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> References: <046.3f0136ae8585d6c3b1d74fb4b6476513@haskell.org> Message-ID: <061.15427dd26271706504bb6a22c59d5937@haskell.org> #12423: Panic with DeriveAnyClass -------------------------------------+------------------------------------- Reporter: knrafto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12144 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:56:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:56:20 -0000 Subject: [GHC] #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) In-Reply-To: <048.d4deec05c6f31ed2d01747b4defade16@haskell.org> References: <048.d4deec05c6f31ed2d01747b4defade16@haskell.org> Message-ID: <063.173b1c619cdf47a1c05d715ecbff1693@haskell.org> #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 21:56:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 21:56:38 -0000 Subject: [GHC] #12439: DeriveDataTypeable - deriving Data for several type constructor applications In-Reply-To: <048.ddc69e4fd5a90cb2d727e0e34d26bd92@haskell.org> References: <048.ddc69e4fd5a90cb2d727e0e34d26bd92@haskell.org> Message-ID: <063.b28aa8221a9859fe2663db6dda65bcb9@haskell.org> #12439: DeriveDataTypeable - deriving Data for several type constructor applications -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 22:00:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 22:00:20 -0000 Subject: [GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary In-Reply-To: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> References: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> Message-ID: <060.dce04a32c481a8cc6b9d13bdd5c3caa6@haskell.org> #12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomers * failure: None/Unknown => Incorrect warning at compile-time @@ -1,1 +1,1 @@ - {{{ + {{{#!hs @@ -6,0 +6,1 @@ + @@ -9,0 +10,1 @@ + New description: {{{#!hs -- Y.hs-boot {-# LANGUAGE ScopedTypeVariables #-} module Y where f :: forall a b. (a, b) -- YY.hs module YY where import {-# SOURCE #-} Y -- Y.hs {-# LANGUAGE ScopedTypeVariables #-} module Y where import YY f :: forall b a. (a, b) f = undefined }}} I get the following unhelpful error: {{{ ezyang at sabre:~$ ghc-8.0 --make Y.hs -fforce-recomp [1 of 3] Compiling Y[boot] ( Y.hs-boot, Y.o-boot ) [2 of 3] Compiling YY ( YY.hs, YY.o ) [3 of 3] Compiling Y ( Y.hs, Y.o ) Y.hs-boot:3:1: error: Identifier ‘f’ has conflicting definitions in the module and its hs-boot file Main module: f :: (a, b) Boot file: f :: (a, b) The two types are different }}} Yes this example is purposely shooting itself in the foot, but in the wild I encountered an un-annotated type which inferred a different quantifier ordering than what I expected, and I subsequently spent a while puzzling over the error message. `-fprint-explicit-foralls` is a sufficient workaround. -- Comment: I think this would be a reasonable thing for a newcomer to knock off. Just check whether the two types are equivalent up to quantifiers and render them with quantifiers if so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 22:00:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 22:00:33 -0000 Subject: [GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary In-Reply-To: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> References: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> Message-ID: <060.c9199e633e29b7b5dadb3a14431df334@haskell.org> #12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: newcomers => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 22:11:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 22:11:01 -0000 Subject: [GHC] #12443: DEFAULT_TMPDIR is documented, but doesn't exist In-Reply-To: <047.edde35b3f67cb5f9ea6388079fa88a02@haskell.org> References: <047.edde35b3f67cb5f9ea6388079fa88a02@haskell.org> Message-ID: <062.3b4e392204012660038a67b707520c37@haskell.org> #12443: DEFAULT_TMPDIR is documented, but doesn't exist -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2493 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2493 Comment: See Phab:D2493. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 22:17:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 22:17:22 -0000 Subject: [GHC] #12433: GHCi produces incorrect results when evaluating with compiled code In-Reply-To: <047.882472dc094976fa082efbe928facde9@haskell.org> References: <047.882472dc094976fa082efbe928facde9@haskell.org> Message-ID: <062.7e6bdb71d4eb3c418edb53ecb758f198@haskell.org> #12433: GHCi produces incorrect results when evaluating with compiled code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ghci, dynamic | linking, compiled code Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 22:20:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 22:20:58 -0000 Subject: [GHC] #12446: Doesn't suggest TypeApplications when `~` used prefix In-Reply-To: <051.fbdff3a41aaa6fb6f877bb677e6f69a8@haskell.org> References: <051.fbdff3a41aaa6fb6f877bb677e6f69a8@haskell.org> Message-ID: <066.7232229ed9cc2c1d63e7db5ad82282de@haskell.org> #12446: Doesn't suggest TypeApplications when `~` used prefix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I suspect the problem is that `~` simply isn't a valid constructor lexeme. For instance, {{{ λ> import Lexeme λ> import FastString λ> isLexCon $ fsLit "~" False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 22:23:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 22:23:02 -0000 Subject: [GHC] #12447: Pretty-printing of equality `~` without parentheses In-Reply-To: <051.dba18f323b8c18d3270065a172f0294e@haskell.org> References: <051.dba18f323b8c18d3270065a172f0294e@haskell.org> Message-ID: <066.7c8f31560902c138970bd5a1b3d0f448@haskell.org> #12447: Pretty-printing of equality `~` without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This is likely something to fix in #11660. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 22:25:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 22:25:27 -0000 Subject: [GHC] #12448: Allow partial application of bidirectional pattern synonyms In-Reply-To: <051.59eb353dccca81d445cc47281fa0f4a1@haskell.org> References: <051.59eb353dccca81d445cc47281fa0f4a1@haskell.org> Message-ID: <066.20d78dc88b54974220bda0fc5e13a0f7@haskell.org> #12448: Allow partial application of bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 22:57:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 22:57:10 -0000 Subject: [GHC] #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure In-Reply-To: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> References: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> Message-ID: <064.50666ddbde4e51029a5e4277cd756027@haskell.org> #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, there is actually a TODO in the code describing this exact shortcoming. See `isReturnApp` in `RnExpr` (https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/rename/RnExpr.hs#L1774) I believe that the problem is that the `Applicative` do desugaring happens in the renamer, where we are unable to lookup whether `return` should be the normal `Control.Monad.return` or some rebound alternative. It's not clear to me how to best fix this short of moving the `Applicative` do implementation to the typechecker, but I'll make sure Simon Marlow knows about this when we next meet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:01:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:01:10 -0000 Subject: [GHC] #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' In-Reply-To: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> References: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> Message-ID: <061.01bd5829e747447edb64494e2d5815b6@haskell.org> #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2492 Wiki Page: | -------------------------------------+------------------------------------- Comment (by DanielG): Perfect, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:04:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:04:29 -0000 Subject: [GHC] #12491: ghc-iserv pattern match failure with no command line arguments In-Reply-To: <044.f85efc3f55eac6e07bb4aa316e8edafc@haskell.org> References: <044.f85efc3f55eac6e07bb4aa316e8edafc@haskell.org> Message-ID: <059.637a753eee5ce36ff17a264576acb6d1@haskell.org> #12491: ghc-iserv pattern match failure with no command line arguments -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2494 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2494 * version: 8.1 => 8.0.1 * milestone: => 8.0.2 Comment: See Phab:D2494 for a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:07:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:07:34 -0000 Subject: [GHC] #12521: Thread blocked indefinitely in an MVar operation In-Reply-To: <053.f0da307ad87f1df98e8d5b92884f7e14@haskell.org> References: <053.f0da307ad87f1df98e8d5b92884f7e14@haskell.org> Message-ID: <068.9f87eb11d5c1a26d347c7c2946a28b44@haskell.org> #12521: Thread blocked indefinitely in an MVar operation -------------------------------------+------------------------------------- Reporter: SwiftsNamesake | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by SwiftsNamesake): * I'm using Windows 10. * chcp is a windows command which changes the active code page I was trying to print Unicode characters. I launched the Windows console (cmd), started GHCi, ran that putStrLn- snippet and (obviously) got an exception. I don't remember exactly but I must've terminated GHCi (:q), changed the code page and then restarted GHCi to try again (in quick succesion). I remember the commands from cmd and GHCi being 'interleaved' (ie. things I started typing into the CMD appeared inside GHCi later on). It's possible that it's really CMD which is at fault but I decided to report it anyway since I was asked to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:14:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:14:39 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse In-Reply-To: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> References: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> Message-ID: <066.56ad0503928cb1de8b2fd2fab7bdd36c@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: orf Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: adamgundry (added) Comment: Hmm, is this an interaction that you anticipated, Adam? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:15:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:15:20 -0000 Subject: [GHC] #12460: Solaris linker does not recognize option --gc-sections In-Reply-To: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> References: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> Message-ID: <060.78dc72de30284a872d55f32f31640457@haskell.org> #12460: Solaris linker does not recognize option --gc-sections -------------------------------------+------------------------------------- Reporter: herzen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Solaris | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -3,0 +3,1 @@ + {{{ @@ -4,0 +5,1 @@ + }}} @@ -7,1 +9,1 @@ - + {{{ @@ -148,0 +150,1 @@ + }}} New description: Linking helloworld.hs fails with the error {{{ ld: fatal: unrecognized option '--' }}} If gcc is called by hand to link with "-Wl,--gc-sections" removed, the link succeeds. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 $ uname -a SunOS diotima 5.11 11.3 i86pc i386 i86pc $ gcc --version gcc (GCC) 4.9.3 $ cat helloworld.hs main = putStrLn "hello, world" $ ghc -c helloworld.hs $ ghc -v -keep-tmp-files -o helloworld helloworld.o Glasgow Haskell Compiler, Version 8.0.1, stage 2 booted by GHC version 7.10.1 Using binary package database: /usr/lib/ghc-8.0.1/package.conf.d/package.cache loading package database /usr/lib/ghc-8.0.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.0.1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Created temporary directory: /tmp/ghc5103_0 *** C Compiler: gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /tmp/ghc5103_0/ghc_1.c -o /tmp/ghc5103_0/ghc_2.o -I/usr/lib/ghc-8.0.1/include *** Linker: gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -o helloworld -Wl ,--gc-sections helloworld.o -L/usr/lib/ghc-8.0.1/base-4.9.0.0 -L/usr/lib/ghc-8.0.1/integer-gmp-1.0.0.1 -L/usr/lib/ -L/usr/lib/ghc-8.0.1 /ghc-prim-0.5.0.0 -L/usr/lib/ghc-8.0.1/rts /tmp/ghc5103_0/ghc_2.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.9.0.0 -lHSinteger-gmp-1.0.0.1 -lHSghc-prim-0.5.0.0 -lHSrts -lCffi -lgmp -lm -lrt -ldl ld: fatal: unrecognized option '--' ld: fatal: use the '-z help' option for usage information collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) $ gcc -U__i686 -fno-stack-protector -DTABLES_NEXT_TO_CODE -o helloworld helloworld.o -L/usr/lib/ghc-8.0.1/base-4.9.0.0 -L/usr/lib/ghc-8.0.1 /integer-gmp-1.0.0.1 -L/usr/lib/ -L/usr/lib/ghc-8.0.1/ghc-prim-0.5.0.0 -L/usr/lib/ghc-8.0.1/rts /tmp/ghc5103_0/ghc_2.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.9.0.0 -lHSinteger-gmp-1.0.0.1 -lHSghc-prim-0.5.0.0 -lHSrts -lCffi -lgmp -lm -lrt -ldl $ ./helloworld hello, world }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:16:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:16:42 -0000 Subject: [GHC] #12460: Solaris linker does not recognize option --gc-sections In-Reply-To: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> References: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> Message-ID: <060.1487dac206d6f83d2ca0aa7c67a91042@haskell.org> #12460: Solaris linker does not recognize option --gc-sections -------------------------------------+------------------------------------- Reporter: herzen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Solaris | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): herzen, where does your `ld` come from? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:21:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:21:42 -0000 Subject: [GHC] #12468: GADTs don't refine hole types In-Reply-To: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> References: <055.f67fa6b9e7cbd9e09e13c8ec333032b0@haskell.org> Message-ID: <070.c7b75ef1f11fa2db7f182fe5d0d0073c@haskell.org> #12468: GADTs don't refine hole types -------------------------------------+------------------------------------- Reporter: benjamin.hodgson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:32:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:32:06 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.017ca5985f5eb0ac948e21910dcd646f@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2495 Comment: rrnewton, is Phab:D2495 what you were looking for, perhaps? It's just a guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:32:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:32:41 -0000 Subject: [GHC] #12471: Weirdness when using fromIntegral in quosiquoter In-Reply-To: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> References: <051.5d7c5d0366ccac94ebc11240e54514a7@haskell.org> Message-ID: <066.d6d4b8e76747464b7e96c5b3b4d32a78@haskell.org> #12471: Weirdness when using fromIntegral in quosiquoter -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:34:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:34:35 -0000 Subject: [GHC] #12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies In-Reply-To: <044.06f71dc396e1085735f13966136f6b82@haskell.org> References: <044.06f71dc396e1085735f13966136f6b82@haskell.org> Message-ID: <059.7f2560e6b42c1478552bbfc56b3a8284@haskell.org> #12473: Ambiguous type var with DefaultSignatures and FunctionalDependencies -------------------------------------+------------------------------------- Reporter: dylex | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.0.2 Comment: Indeed this appears to work with 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:37:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:37:29 -0000 Subject: [GHC] #12475: GHCi no longer handles stdin being closed gracefully In-Reply-To: <049.ca21f0f7906ff6f7363978996c951710@haskell.org> References: <049.ca21f0f7906ff6f7363978996c951710@haskell.org> Message-ID: <064.de1db0db4f3614d20e1b53be5d81ddb4@haskell.org> #12475: GHCi no longer handles stdin being closed gracefully -------------------------------------+------------------------------------- Reporter: rowanblush | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, I really don't know what changed here but indeed I can reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:38:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:38:38 -0000 Subject: [GHC] #12476: Error building HList In-Reply-To: <055.28ab9fc1ee273486170008eb9c974eb4@haskell.org> References: <055.28ab9fc1ee273486170008eb9c974eb4@haskell.org> Message-ID: <070.897788059476bc23c45bde34fb942598@haskell.org> #12476: Error building HList -------------------------------------+------------------------------------- Reporter: DanielWaterworth | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 Comment: The fix for #12242 has been merged to `ghc-8.0` but I still need to check whether this is now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:39:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:39:14 -0000 Subject: [GHC] #12477: Allow left sectioning and tuple sectioning of types In-Reply-To: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> References: <051.a3e3ad9a7787217d8b2dc59fff787593@haskell.org> Message-ID: <066.d6412be82f60b6c987f347c202a7e4ec@haskell.org> #12477: Allow left sectioning and tuple sectioning of types -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:41:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:41:07 -0000 Subject: [GHC] #12198: Stack fails to compile using GHC 8.0.1 on MacOS 10.12 In-Reply-To: <049.04d5c9fc808542b550f790907cac702a@haskell.org> References: <049.04d5c9fc808542b550f790907cac702a@haskell.org> Message-ID: <064.c25d0307e2cb327e1d775df44969a12d@haskell.org> #12198: Stack fails to compile using GHC 8.0.1 on MacOS 10.12 -------------------------------------+------------------------------------- Reporter: mistydemeo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => closed * resolution: => duplicate * related: => #12479 Comment: I believe this may be a duplicate of #12479. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:41:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:41:09 -0000 Subject: [GHC] #12433: GHCi produces incorrect results when evaluating with compiled code In-Reply-To: <047.882472dc094976fa082efbe928facde9@haskell.org> References: <047.882472dc094976fa082efbe928facde9@haskell.org> Message-ID: <062.6d64cb8a6b3b639dbcb70d856415b4e0@haskell.org> #12433: GHCi produces incorrect results when evaluating with compiled code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ghci, dynamic | linking, compiled code Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Looks like it never got mentioned here, but this was going to be fixed by #11758, but the patch there caused problems on Windows and had to be reverted. It's probably an easy enough fix here if we just ignore ticket #11758. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:42:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:42:02 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.03e42ce47a2a42b3642f23d0fde2315d@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra beta 4 -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Is it possible that your `libghc` is built with `-split-sections`? It sounds like we are producing too many sections for Darwin's linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:48:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:48:41 -0000 Subject: [GHC] #12483: Improve parse error message on indentation mistake In-Reply-To: <047.316a1198ea6bc5cfdac014b84c3e6cd9@haskell.org> References: <047.316a1198ea6bc5cfdac014b84c3e6cd9@haskell.org> Message-ID: <062.61e232a49c6c44590a13e7e46bf61ce1@haskell.org> #12483: Improve parse error message on indentation mistake -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: Other => Incorrect warning at compile-time * type: bug => feature request Comment: Indeed these are frustratingly poor errors. I remember encountering this exact thing when I was learning the language. Improving this would require that someone take some time to think about how you can robustly catch this issue in the parser without introducing too much complexity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:51:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:51:15 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.3c92d179d0ce5e30c9d026a7a1bc426b@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.2 Comment: Any word on a fix, niteria? It would be nice to get the fix in to 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:53:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:53:44 -0000 Subject: [GHC] #11758: Drop x86_64 binutils <2.17 hack In-Reply-To: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> References: <046.4526d91ede8d490bc5daf7dd1af1ee5c@haskell.org> Message-ID: <061.78957d06eec2d2025350e08feccfa5b8@haskell.org> #11758: Drop x86_64 binutils <2.17 hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: avd Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 8.0.1-rc2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12433 | Differential Rev(s): Phab:D2426 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:57:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:57:41 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.0b724500f81f12001e793af8971d77bd@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari * priority: normal => high Comment: I'll be adding this one to my queue. Thanks deech. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 29 23:59:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Aug 2016 23:59:40 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.b066a1f76e6b1851ca2c52dc9fe658f2@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: jstolarek (added) Comment: Given that `TypeFamilyDependencies` are involved I'm ccing Jan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 00:00:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 00:00:55 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.bbd757f8ade447ac5a589122f19dc876@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by deech: @@ -21,0 +21,1 @@ + - `cabal install c2hs New description: This bug is entirely reproducible but unfortunately takes some setup. I don't have a minimal example. The regression is happening in FLTKHS (https://github.com/deech/fltkhs), the Haskell bindings to the FLTK(http://fltk.org) toolkit, and in particular to this GUI (https://github.com/deech/fltkhs/blob/master/images /tree-complex-windows.png). In GHC 7.8, it taks 5-9 seconds to compile and link in 7.10.3, that goes up to 12-15 seconds and finally in GHC 8 it shoots up to 45 seconds. While these numbers come from my i7, 16GB RAM Linux laptop, the compile time regression is proportionally reproducible across machines and operating systems. Here are the steps to reproduce it * Install FLTK Please follow the instructions here (https://github.com/deech/fltkhs #linux-and-bsd) but only the first set which is about installing FLTK 1.3. * Clone the repo with the offending application: `git clone https://github.com/deech/fltkhs-fluid-demos` * Build the application and reproduce the problem: - `cabal install fltkhs` - `cabal install c2hs - At the root of the repo do `cabal build fltkhs-fluid-tree` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 00:01:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 00:01:10 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.83a64ef77a92c6de35c8295abffb10b4@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by deech: @@ -21,1 +21,1 @@ - - `cabal install c2hs + - `cabal install c2hs` New description: This bug is entirely reproducible but unfortunately takes some setup. I don't have a minimal example. The regression is happening in FLTKHS (https://github.com/deech/fltkhs), the Haskell bindings to the FLTK(http://fltk.org) toolkit, and in particular to this GUI (https://github.com/deech/fltkhs/blob/master/images /tree-complex-windows.png). In GHC 7.8, it taks 5-9 seconds to compile and link in 7.10.3, that goes up to 12-15 seconds and finally in GHC 8 it shoots up to 45 seconds. While these numbers come from my i7, 16GB RAM Linux laptop, the compile time regression is proportionally reproducible across machines and operating systems. Here are the steps to reproduce it * Install FLTK Please follow the instructions here (https://github.com/deech/fltkhs #linux-and-bsd) but only the first set which is about installing FLTK 1.3. * Clone the repo with the offending application: `git clone https://github.com/deech/fltkhs-fluid-demos` * Build the application and reproduce the problem: - `cabal install fltkhs` - `cabal install c2hs` - At the root of the repo do `cabal build fltkhs-fluid-tree` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 00:01:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 00:01:34 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.6804d21a3328265930aa585db6ff9bd6@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by deech): Replying to [comment:3 bgamari]: > I'll be adding this one to my queue. Thanks deech. Great. Let me know if I can help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 00:04:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 00:04:31 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.e8bae3a27e8091c3b4c9a0d45a6e3f50@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by deech: @@ -20,0 +20,1 @@ + - `cabal install c2hs` @@ -21,1 +22,0 @@ - - `cabal install c2hs` New description: This bug is entirely reproducible but unfortunately takes some setup. I don't have a minimal example. The regression is happening in FLTKHS (https://github.com/deech/fltkhs), the Haskell bindings to the FLTK(http://fltk.org) toolkit, and in particular to this GUI (https://github.com/deech/fltkhs/blob/master/images /tree-complex-windows.png). In GHC 7.8, it taks 5-9 seconds to compile and link in 7.10.3, that goes up to 12-15 seconds and finally in GHC 8 it shoots up to 45 seconds. While these numbers come from my i7, 16GB RAM Linux laptop, the compile time regression is proportionally reproducible across machines and operating systems. Here are the steps to reproduce it * Install FLTK Please follow the instructions here (https://github.com/deech/fltkhs #linux-and-bsd) but only the first set which is about installing FLTK 1.3. * Clone the repo with the offending application: `git clone https://github.com/deech/fltkhs-fluid-demos` * Build the application and reproduce the problem: - `cabal install c2hs` - `cabal install fltkhs` - At the root of the repo do `cabal build fltkhs-fluid-tree` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 00:27:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 00:27:16 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse In-Reply-To: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> References: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> Message-ID: <066.b8956e01adcd873aa584be559d0d86f5@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: orf Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): We should probably just say this is working as intended: `(#` is a single token under `UnboxedTuples`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 00:48:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 00:48:31 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.ecde7d6edd250e04a25526eafeff112b@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450 Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Sorry, I wanted to get in on this, but I ended up locally reverting the patch that broke it. I can't make any promises about fixing it this week, as I have some responsibilities that take priority over this this week. I want to get this fixed, but with the 8.0.2 coming soon I want to set the expectations straight. Is revert an option here for 8.0.2? It looks like the patch caused a bigger problem than it fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 01:48:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 01:48:35 -0000 Subject: [GHC] #12551: Make type indices take local constraints into account in type instance declaration Message-ID: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> #12551: Make type indices take local constraints into account in type instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given {{{#!hs infixl 1 :$ infixr :-> data Sig x where Full :: a -> Sig a (:->) :: a -> b -> Sig a data AST dom a where Sym :: dom a -> AST dom a (:$) :: AST dom (a:->b) -> AST dom (Full a) -> AST dom b class Syntactic a dom | a -> dom where type Rep a desugar :: a -> AST dom (Full (Rep a)) sugar :: AST dom (Full (Rep a)) -> a }}} I want to be able to define the trivial instance for `Syntactic (AST dom (Full a))`: {{{#!hs instance Syntactic (AST dom (Full a)) dom where type Rep (AST dom (Full a)) = a desugar, sugar :: AST dom (Full a) -> AST dom (Full a) desugar = id sugar = id }}} This should be the only `Syntactic` instance for `AST _ _` so I would like to apply the [http://chrisdone.com/posts/haskell-constraint-trick ‘constraint’ trick] ([https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70 #blog-reddit-constraint-trick-for-instances link]) but I cannot use the `Rep` instance as before: {{{#!hs -- • Type indexes must match class instance head -- Found ‘AST dom ('Full a)’ but expected ‘AST dom full_a’ -- • In the type instance declaration for ‘Rep’ -- In the instance declaration for ‘Syntactic (AST dom full_a) dom’ instance full_a ~ Full a => Syntactic (AST dom full_a) dom where type Rep (AST dom (Full a)) = a }}} Maybe this could be accepted, given that `full_a ~ Full a`, therefore the instance head is equal to `AST dom (Full a)`? My current workaround is using a type family {{{#!hs type family Edrú a where Edrú (Full a) = a instance full_a ~ Full a => Syntactic (AST dom full_a) dom where type Rep (AST dom full_a) = Edrú full_a desugar, sugar :: AST dom (Full a) -> AST dom (Full a) desugar = id sugar = id }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 02:04:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 02:04:55 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse In-Reply-To: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> References: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> Message-ID: <066.b38fc64772a4f9de45180c4415b66e82@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: orf Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I bumped into this because I have `UnboxedTuples` enabled in my ''.ghci'' but in a future where `OverloadedLabels` are ubiquitous a user cannot use unboxed tuples without modifying every parenthesised label in the module first: potentially resulting in large diffs, potentially going against the style of the project (or style guide). Not a huge concern but definitely raises an eyebrow ---- This could of course be ameliorated by ''local'' language pragmas ;) think about it (local `Strict`, `RebindableSyntax`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 02:28:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 02:28:06 -0000 Subject: [GHC] #12551: Make type indices take local constraints into account in type instance declaration In-Reply-To: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> References: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> Message-ID: <066.5c3c471f4b36425051ee1e4ca4a78a58@haskell.org> #12551: Make type indices take local constraints into account in type instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Simplified example {{{#!hs infixr :-> data Sig x where Full :: a -> Sig a (:->) :: a -> b -> Sig a data Exp a where Lit :: Int -> Exp (Full Int) Add :: Exp (Int :-> Int :-> Full Int) class Syntactic a where type Rep a desugar :: a -> Exp (Full (Rep a)) sugar :: Exp (Full (Rep a)) -> a instance Syntactic (Exp (Full a)) where type Rep (Exp (Full a)) = a desugar, sugar :: Exp (Full a) -> Exp (Full a) desugar = id sugar = id }}} ---- I would like this to compile {{{#!hs instance a' ~ Full a => Syntactic (Exp a') where type Rep (Exp (Full a)) = a }}} and/or {{{#!hs instance a' ~ Full a => Syntactic (Exp a') where type Rep (Exp a') = a }}} and/or {{{#!hs instance a' ~ Full a => Syntactic (Exp a') where type Rep (Exp _) = a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 02:49:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 02:49:49 -0000 Subject: [GHC] #12551: Make type indices take local constraints into account in type instance declaration In-Reply-To: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> References: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> Message-ID: <066.7ee8dd9add3e333ed3f3aa1ebbc83ee7@haskell.org> #12551: Make type indices take local constraints into account in type instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -7,2 +7,2 @@ - Full :: a -> Sig a - (:->) :: a -> b -> Sig a + Full :: a -> Sig a + (:->) :: a -> Sig a -> Sig a New description: Given {{{#!hs infixl 1 :$ infixr :-> data Sig x where Full :: a -> Sig a (:->) :: a -> Sig a -> Sig a data AST dom a where Sym :: dom a -> AST dom a (:$) :: AST dom (a:->b) -> AST dom (Full a) -> AST dom b class Syntactic a dom | a -> dom where type Rep a desugar :: a -> AST dom (Full (Rep a)) sugar :: AST dom (Full (Rep a)) -> a }}} I want to be able to define the trivial instance for `Syntactic (AST dom (Full a))`: {{{#!hs instance Syntactic (AST dom (Full a)) dom where type Rep (AST dom (Full a)) = a desugar, sugar :: AST dom (Full a) -> AST dom (Full a) desugar = id sugar = id }}} This should be the only `Syntactic` instance for `AST _ _` so I would like to apply the [http://chrisdone.com/posts/haskell-constraint-trick ‘constraint’ trick] ([https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70 #blog-reddit-constraint-trick-for-instances link]) but I cannot use the `Rep` instance as before: {{{#!hs -- • Type indexes must match class instance head -- Found ‘AST dom ('Full a)’ but expected ‘AST dom full_a’ -- • In the type instance declaration for ‘Rep’ -- In the instance declaration for ‘Syntactic (AST dom full_a) dom’ instance full_a ~ Full a => Syntactic (AST dom full_a) dom where type Rep (AST dom (Full a)) = a }}} Maybe this could be accepted, given that `full_a ~ Full a`, therefore the instance head is equal to `AST dom (Full a)`? My current workaround is using a type family {{{#!hs type family Edrú a where Edrú (Full a) = a instance full_a ~ Full a => Syntactic (AST dom full_a) dom where type Rep (AST dom full_a) = Edrú full_a desugar, sugar :: AST dom (Full a) -> AST dom (Full a) desugar = id sugar = id }}} -- Comment (by Iceland_jack): Replying to [ticket:12551 Iceland_jack]: > Given > > {{{#!hs > infixl 1 :$ > infixr :-> > data Sig x where > Full :: a -> Sig a > (:->) :: a -> b -> Sig a > > data AST dom a where > Sym :: dom a -> AST dom a > (:$) :: AST dom (a:->b) -> AST dom (Full a) -> AST dom b > > class Syntactic a dom | a -> dom where > type Rep a > desugar :: a -> AST dom (Full (Rep a)) > sugar :: AST dom (Full (Rep a)) -> a > }}} > > I want to be able to define the trivial instance for `Syntactic (AST dom (Full a))`: > > {{{#!hs > instance Syntactic (AST dom (Full a)) dom where > type Rep (AST dom (Full a)) = a > desugar, sugar :: AST dom (Full a) -> AST dom (Full a) > desugar = id > sugar = id > }}} > > This should be the only `Syntactic` instance for `AST _ _` so I would like to apply the [http://chrisdone.com/posts/haskell-constraint-trick ‘constraint’ trick] ([https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70 #blog-reddit-constraint-trick-for-instances link]) but I cannot use the `Rep` instance as before: > > {{{#!hs > -- • Type indexes must match class instance head > -- Found ‘AST dom ('Full a)’ but expected ‘AST dom full_a’ > -- • In the type instance declaration for ‘Rep’ > -- In the instance declaration for ‘Syntactic (AST dom full_a) dom’ > > instance full_a ~ Full a => Syntactic (AST dom full_a) dom where > type Rep (AST dom (Full a)) = a > }}} > > Maybe this could be accepted, given that `full_a ~ Full a`, therefore the instance head is equal to `AST dom (Full a)`? > > My current workaround is using a type family > > {{{#!hs > type family > Edrú a where > Edrú (Full a) = a > > instance full_a ~ Full a => Syntactic (AST dom full_a) dom where > type Rep (AST dom full_a) = Edrú full_a > desugar, sugar :: AST dom (Full a) -> AST dom (Full a) > desugar = id > sugar = id > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 03:37:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 03:37:21 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.887f5f97bb02a4a54ddccb8e93dc264a@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by acfoltzer): In light of Ben's last call for 8.0.2 patches, would it be feasible to get one together in time to remove the warning from `-Wall`? It seems like we reached a tentative decision to do so. I'd be happy to take a look myself, but if time is of the essence I might not be able to get a development environment up and running quickly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 03:55:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 03:55:59 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.77362825426fef66e5f02bc2845d7847@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Sorry, this fell off my radar after niteria said that he was going to fix it. If you revert this patch, bootstrapping will break, so that's probably not a good idea. Let me see if I can fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 05:47:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 05:47:43 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.311d096484efbfa7414bbd87ec1fb7e0@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): A few things: First, niteria, I'm curious why you need top be able to pass the package databases out of order. If I understand correctly, neither Stack nor Cabal use the databases this way. Indeed, when I wrote this patch, I assumed the databases would be in the right order because that's how shadowing works: later databases shadow earlier ones. Second, it's impossible to do ABI sanity checking in the way it is done today if I can't assume things are in the right order. When the db order was assumed to be specified correctly, I could assume all references to p-0.1-xxx refer to the topmost package with this IPID in the Stack; if the ABIs mismatch then I should remove everyone below me. But if there might be a reference to that particular package in a later package database, this assumption doesn't hold. Assuming that we DO want databases to be specified in any order (do we?!) here's what I think we should do: We NEVER remove packages because something got shadowed. Either the shadower is ABI compatible (in which case we never need to eliminate anything), OR we immediately error (because we have no idea which ones to eliminate.) I don't know if this brings back enough shadowing to fix bootstrapping though; will have to test. #12518 seems related; it also requests that we error on shadowing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 06:40:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 06:40:38 -0000 Subject: [GHC] #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" In-Reply-To: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> References: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> Message-ID: <060.69aca2f4aa5b625d1e0f25176f72a334@haskell.org> #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Sure, I'll submit one this week. I'm probably just going to allow the use of the deprecated functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 06:41:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 06:41:14 -0000 Subject: [GHC] #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" In-Reply-To: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> References: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> Message-ID: <060.5bb36f921f77a2b8deafce67a8b408d4@haskell.org> #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 06:42:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 06:42:19 -0000 Subject: [GHC] #12497: Make runtime linker be able to find POSIX functions under their deprecated name. In-Reply-To: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> References: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> Message-ID: <059.239fee6fe2d007bef05766eba4fcfbbb@haskell.org> #12497: Make runtime linker be able to find POSIX functions under their deprecated name. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- * related: => #12209 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 06:43:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 06:43:32 -0000 Subject: [GHC] #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" In-Reply-To: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> References: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> Message-ID: <060.0c1674198ad01747c5d2aeb89e15172c@haskell.org> #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12497 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #12497 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 07:21:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 07:21:31 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse In-Reply-To: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> References: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> Message-ID: <066.789935e87c6f1d53edcbea4ae17aa7d1@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: orf Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): No, I hadn't considered the interaction with unboxed tuple syntax. It is a bit awkward, but the lexical syntax is sufficiently crowded that I doubt we will be able to do better, and we already have similar annoyances involving `.hsc` files. I suppose we could add a sentence to the manual pointing out the conflict and encouraging a style in which overloaded labels are preceded by a space (even when in parentheses). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 09:25:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 09:25:16 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.e5c1e69ac58b5b3573f3c3326f63fde4@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 09:59:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 09:59:37 -0000 Subject: [GHC] #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym In-Reply-To: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> References: <045.348cf0e479494ae96f59732a5dfa8fc1@haskell.org> Message-ID: <060.4d856e5ceee88d319b4de66bd988fbdb@haskell.org> #12203: Allow constructors on LHS of (implicit) bidirectional pattern synonym -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 10:14:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 10:14:07 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.ef94d3a096371d4489e617a155b19ab7@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450 Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): > First, niteria, I'm curious why you need top be able to pass the package databases out of order. If I understand correctly, neither Stack nor Cabal use the databases this way. I don't use Stack or Cabal to build the packages. I can't do that because I'm building packages needed to build `cabal-install`. The way the packages are built is with `Setup.hs` and a separate `package.db` for each package. The scripts I have would need some additional logic to pass the `-package-db` flags in dependency order. Once I get past that obstacle I'm not sure if Buck or Bazel do any dependency sorting on `-package-db` flags. Putting this constraint on every build system sounds suboptimal to me. > Indeed, when I wrote this patch, I assumed the databases would be in the right order because that's how shadowing works: later databases shadow earlier ones. This is an undocumented change in behaviour in the very least. The manual didn't state that they can be in any order, but also didn't put any constraints on order. People trying to integrate this into their build systems will have no idea that this is the requirement. > Second, it's impossible to do ABI sanity checking in the way it is done today if I can't assume things are in the right order. When the db order was assumed to be specified correctly, I could assume all references to p-0.1-xxx refer to the topmost package with this IPID in the Stack; if the ABIs mismatch then I should remove everyone below me. But if there might be a reference to that particular package in a later package database, this assumption doesn't hold. This sounds like an implementation detail informing the specification. Is there a fundamental reason why the flags have to be ordered? > Assuming that we DO want databases to be specified in any order (do we?!) here's what I think we should do: We NEVER remove packages because something got shadowed. Either the shadower is ABI compatible (in which case we never need to eliminate anything), OR we immediately error (because we have no idea which ones to eliminate.) I don't know if this brings back enough shadowing to fix bootstrapping though; will have to test. I'm not familiar with package shadowing and also don't know how it fixes bootstrapping. Your patch doesn't explain it either. If you could explain maybe it would move this issue forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 10:56:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 10:56:02 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.883ef912f9183b9fa8883c639b078f4f@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): OK. So the way I'll structure this is first describe some workarounds to work with the current behavior, and then assuming those workarounds don't work / are undesirable I'll try to comment on how we can make this work. > The way the packages are built is with Setup.hs and a separate package.db for each package. One thing you can do in this situation is use ghc-pkg recache to create a merged package database and pass that off to GHC. So you'd swizzle all the text files into a directory, make the db, and you'd be off to the races. > This is an undocumented change in behaviour in the very least. The manual didn't state that they can be in any order, but also didn't put any constraints on order. To be fair, the manual does state that package databases are ordered, and that packages closer to the top will shadow those below them (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html #package-databases). It doesn't explicitly state that every substack should be well-formed, but this is a constraint that `ghc-pkg` checks (if you're not forcing it to register). (FWIW, Harendrar posted a Diff https://phabricator.haskell.org/D2464 which should improve the docs here further.) > This sounds like an implementation detail informing the specification. Is there a fundamental reason why the flags have to be ordered? OK, let me explain the shadowing situation in more detail, and also how the package database handling has changed in the recent few releases. There is a very important correctness constraint GHC enforces on the package databases that it reads in, which is there should not be two distinct packages with the same "key" (what constitutes a key has changed over time). This is pretty important because if two unit ids are equal, GHC assumes they are type equal: if there are two distinct packages (which could define totally types and functions) with the same key, GHC will mix them up and generate code that almost certainly will segfault. In GHC 7.8 and earlier, the key was just the package name plus version. So it was not that uncommon to have two package databases which defined the same package name and version. To keep things safe, GHC shadowed packages, throwing out packages with any conflicting source package IDs. Every package was also associated with an installed package id, which was derived directly off of the ABI of a package. When two installed package ids coincided, it was always safe to pick one (the later one) because the coinciding installed package id meant that the ABIs matched, so there'd be no problem reusing it. OK, so this business where you can't have two packages with the same source package ID was the source of Cabal hell (cabal-install was not clever enough to put every package in a separate db) so in 7.10 we introduced "package keys", which were a bit more fine-grained than source package ids and what we used for type equality, linker symbols, etc. IPIDs continued to be derived off ABI hashes. Package keys didn't really necessitate any changes in how shadowing worked, since there still was a separate notion for IPIDs. At some point in the GHC 8.0 release cycle, SPJ was wondering why we need package keys and IPIDs. At the same time, work on cabal new-build was afoot, which eschewed the use of ABI hashes for IPIDs (since they couldn't be computed before we actually built the package; new-build needs to compute the IDs ahead of time so that it can determine if the particular build it needs is already built.) So in GHC 8.0 we unified IPIDs and package keys. OK, and now we get to the set of commits which broke database for you. So, when IPIDs don't track ABI hashes anymore, it's a bit more difficult to say what ABI a package depends on: after all, we record dependencies as IPIDs, not ABIs (maybe we should have recorded ABIs of the deps!) So, I needed to find a new algorithm which: 1. Maintained the safety invariant, that we never tried to load two distinct packages with the same IPID (previously package key, previously source package id), and never used the wrong copy of the package with a package that was compiled with a different package 2. Preserved the old shadowing behavior when the IPID conflicted when two package databases merged together--we need to prefer the latest one (I didn't want to implement this but bootstrapping stopped working without this. I believe the issue is that the distributed boot libraries with GHC don't come with hashes, so when we rebuild those libraries to boot, we end up picking the same name. Better use the new one!) 3. Preserved the old behavior where if you were ABI-compatible, you could override a package from the earlier database as long as the ABIs matched, without breaking a pile of packages. So... I sinned, and assumed that as we added databases to our stack, the database would continue to be well-formed. Which has ruined your day! Having written this, I don't think my suggested fix will keep GHC bootstrapping as it is today. It's a bit unavoidable: if the build system picks a deterministic id for a boot library, if you then immediately bootstrap with that GHC, it will pick the *same* id. So you *need* some form of shadowing. Maybe what you just want is another mode for GHC to make it process package databases differently? (This is why #12518 seems relevant.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 11:19:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 11:19:06 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.aeecf686731f099f42d6fd9bbf1b0f75@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 12:28:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 12:28:12 -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.61430be9eeb43876cf380323aab4e700@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"a5d26f26d33bc04f31eaff50b7d633444192b4cb/ghc" a5d26f2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a5d26f26d33bc04f31eaff50b7d633444192b4cb" rts: enable parallel GC scan of large (32M+) allocation area Parallel GC does not scan large allocation area (-A) effectively as it does not do work stealing from nursery by default. That leads to large imbalance when only one of threads overflows allocation area: most of GC threads finish quickly (as there is not much to collect) and sit idle waiting while single GC thread finishes scan of single allocation area for that thread. The patch enables work stealing for (equivalent of -qb0) allocation area of -A32M or higher. Tested on a highlighting-kate package from Trac #9221 On 8-core machine the difference is around 5% faster of wall-clock time. On 24-core VM the speedup is 20%. Signed-off-by: Sergei Trofimovich Test Plan: measured wall time and GC parallelism on highlighting-kate build Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2483 GHC Trac Issues: #9221 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 12:28:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 12:28:12 -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.12f39dcf7d8734009a84e6210fc7e521@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"9d175605e52fd0d85f2548896358d96ee441c7e4/ghc" 9d175605/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9d175605e52fd0d85f2548896358d96ee441c7e4" GhcMake: limit Capability count to CPU count in parallel mode In Trac #9221 one of problems using high --jobs= is amount of mutator (or GC) threads we crate. We use userspace spinning-and-yielding (see ACQUIRE_SPIN_LOCK) to acess work stealing queues. In case of N-worker-threads > N-CPUs fraction of time when thread holding spin lock gets descheduled by kernel increases. That causes other threads to waste CPU time before giving up CPU. Signed-off-by: Sergei Trofimovich Test Plan: ghc --make -j8 and -j80 have comparable sys time on a 8-core system. Reviewers: austin, gintas, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2482 GHC Trac Issues: #9221 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 13:35:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 13:35:13 -0000 Subject: [GHC] #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.07ba1cc429e173a10d4718eec42723e8@haskell.org> #12537: ghc-openGL build Segmentation Fault for openSUSE ppc64le ---------------------------------------+--------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+--------------------------------- Changes (by trommler): * owner: => trommler * failure: None/Unknown => Compile-time crash Comment: This could be #12469. I am going to check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:05:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:05:52 -0000 Subject: [GHC] #12531: Holes should be representation-polymorphic In-Reply-To: <044.38d412e29e728e7d1a4333b441265291@haskell.org> References: <044.38d412e29e728e7d1a4333b441265291@haskell.org> Message-ID: <059.9906083be207835aa423af237f9065fb@haskell.org> #12531: Holes should be representation-polymorphic -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature request | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: partial- | sigs/should_compile/T12531 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:06:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:06:42 -0000 Subject: [GHC] #12100: GHC 8.0.1 build segmentation fault in haddock In-Reply-To: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> References: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> Message-ID: <062.bbf2ce5a950d8a66b5cc368d924135bb@haskell.org> #12100: GHC 8.0.1 build segmentation fault in haddock -------------------------------------+------------------------------------- Reporter: ilovezfs | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11744, #11951 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can anyone else reproduce this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:12:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:12:20 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.b0cab7e20d30f1172151c34feefa2856@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: 8.0.2 => 8.2.1 Comment: I am in the middle of an upheaval of the constraint solver that fixes this among other things. But the change is too big to put in the 8.0.2 branch. So I suggest we re-milestone for 8.2, and treat this as something to work- around with 8.0.2. The workaround is simple, as comment:11 says: a type signature seems to do the job. I think it's a fluke that it worked before. Is that acceptable? I think it'll be hard to fix in 8.0.2. Yell if that'd be really bad for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:14:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:14:46 -0000 Subject: [GHC] #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure In-Reply-To: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> References: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> Message-ID: <064.9f08bbd32dd018723298f78d81b39032@haskell.org> #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): My proposed solution here would be to lookup the `Name` of `return` in the environment and compare against it in `isReturnApp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:29:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:29:34 -0000 Subject: [GHC] #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) In-Reply-To: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> References: <057.9aecaec89b7fd255565e55bac0801cc6@haskell.org> Message-ID: <072.5dbe5bae25ba7a91964281f19da186b4@haskell.org> #12545: Compilation time/space regression in GHC 8.0/8.1 (search in type-level lists and -O) -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This, to me, does not look like a cut-and-dried type-level issue. Note that the number of ''terms'' is much greater in 8.0. And the ratio of coercions to terms is ''lower'' in 8.0 than 7.10. It looks like the occurrence analysis in 8.0 is to blame for the blowup in terms... whereas that same pass in 7.10 caused more of a blowup in coercions. Weird. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:50:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:50:57 -0000 Subject: [GHC] #12164: Type signatures in patterns not (yet) handled by Template Haskell In-Reply-To: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> References: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> Message-ID: <060.9be1ec25d2c81b74448ee929fdf8f049@haskell.org> #12164: Type signatures in patterns not (yet) handled by Template Haskell -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I imagine without scoped type variables, this wouldn't be so hard. With them might be more challenging. Does your use-case require binding variables in the pattern type signature? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:52:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:52:34 -0000 Subject: [GHC] #12174: Recursive use of type-in-type results in infinite loop In-Reply-To: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> References: <045.2665904adc758f845f81e0f23fca2cbf@haskell.org> Message-ID: <060.e816980a0deb61eb4df86722ea6f4c22@haskell.org> #12174: Recursive use of type-in-type results in infinite loop -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes -- I expect to take a look at this in my bug sweep, which will hopefully start next week or so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:52:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:52:38 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.c9c9a12c6bd98c5edd703c8be8ec1a59@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:54:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:54:22 -0000 Subject: [GHC] #12411: GHC panic on TypeApplications + TemplateHaskell In-Reply-To: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> References: <051.e143c87e78ab86ca3c4b0272288715fe@haskell.org> Message-ID: <066.7e67ada917bb795db3381a7afe0ef256@haskell.org> #12411: GHC panic on TypeApplications + TemplateHaskell -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I will take a look in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:55:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:55:29 -0000 Subject: [GHC] #12220: TypeApplications and DefaultSignatures - problems deducing type variables. In-Reply-To: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> References: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> Message-ID: <062.eaf6625b7fc9f3637c3584a5d9891008@haskell.org> #12220: TypeApplications and DefaultSignatures - problems deducing type variables. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | DefaultSignatures, TypeApplications Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | generics/T12220 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Does anyone care if this doesn't make it into 8.0.1? If it goes in, we'll have to fix #12466 too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:56:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:56:37 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.a811c12b77cb4c4954c5e55df82f6f41@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -31,0 +31,3 @@ + + The reason HEAD fails to compile `lens`, but GHC 8.0.1 works, is because + the fix for #12220 is in HEAD, but not in 8.0.1. New description: The following compiles with GHC 8.0.1 and earlier, but not with GHC HEAD: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where class Foo a where foo :: (a ~ Int => Int) -> a -> a foo _ a2 = a2 instance Foo Char }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:10: error: • Couldn't match type ‘Char’ with ‘Int’ Inaccessible code in a type expected by the context: Char ~ Int => Int • In the expression: Bug.$dmfoo @Char In an equation for ‘foo’: foo = Bug.$dmfoo @Char In the instance declaration for ‘Foo Char’ }}} This causes `lens-4.14` to [https://github.com/ekmett/lens/issues/667 fail to build] with GHC HEAD. The reason HEAD fails to compile `lens`, but GHC 8.0.1 works, is because the fix for #12220 is in HEAD, but not in 8.0.1. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 14:59:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 14:59:46 -0000 Subject: [GHC] #12446: Doesn't suggest TypeApplications when `~` used prefix In-Reply-To: <051.fbdff3a41aaa6fb6f877bb677e6f69a8@haskell.org> References: <051.fbdff3a41aaa6fb6f877bb677e6f69a8@haskell.org> Message-ID: <066.527c7566089882c9ede1856a659a46c0@haskell.org> #12446: Doesn't suggest TypeApplications when `~` used prefix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => TypeApplications -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 15:05:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 15:05:26 -0000 Subject: [GHC] #12551: Make type indices take local constraints into account in type instance declaration In-Reply-To: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> References: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> Message-ID: <066.0a9b1c3cd767507e6c66752d8d2b97be@haskell.org> #12551: Make type indices take local constraints into account in type instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): What you wish to do was possible previously (7.8? 7.6?) but it caused quite a bit of complication in processing associated type instances. Simon proposed restricting the syntax of associated type instances to require that the instances be defined over precisely the types in the head of the class instance. No one objected. So he made the change. Your "workaround" is precisely the way to do what you want. It is a bit frustrating in this particular case, where what you want is "obviously" correct, but I don't quite think it's worth restoring the old, complicated implementation of associated types here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 15:55:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 15:55:39 -0000 Subject: [GHC] #12552: Merge OpenBSD linking fix Message-ID: <046.ddb51184ed227251f413950292617386@haskell.org> #12552: Merge OpenBSD linking fix -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Merge f9aa996f0af59f32dc7b1528ff78be41413a9c27 to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 15:55:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 15:55:47 -0000 Subject: [GHC] #12552: Merge OpenBSD linking fix In-Reply-To: <046.ddb51184ed227251f413950292617386@haskell.org> References: <046.ddb51184ed227251f413950292617386@haskell.org> Message-ID: <061.69a981fb00cf9872cd01cf64c9587fcd@haskell.org> #12552: Merge OpenBSD linking fix -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 15:57:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 15:57:34 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.6b06cc4d7378985430164a83467f58fc@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * related: 10634 => #10634 Comment: I am ok with defering the solution to 8.2. These simulated injective type functions seem to be a constant source of trouble. How do other people cope with them? Are they all using real injective type functions instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 16:00:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 16:00:55 -0000 Subject: [GHC] #12552: Merge OpenBSD fixes (was: Merge OpenBSD linking fix) In-Reply-To: <046.ddb51184ed227251f413950292617386@haskell.org> References: <046.ddb51184ed227251f413950292617386@haskell.org> Message-ID: <061.fe5ad41991a9d65d02b5a6bfc2ceccab@haskell.org> #12552: Merge OpenBSD fixes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -1,1 +1,4 @@ - Merge f9aa996f0af59f32dc7b1528ff78be41413a9c27 to `ghc-8.0`. + Merge the following to `ghc-8.0`, + * f9aa996f0af59f32dc7b1528ff78be41413a9c27 + * ffd4029c5bc581ac749f5cdc3d8e085c80add585 + * 3551e622ab3a833589a069b473a4dfb3f171e5b8 New description: Merge the following to `ghc-8.0`, * f9aa996f0af59f32dc7b1528ff78be41413a9c27 * ffd4029c5bc581ac749f5cdc3d8e085c80add585 * 3551e622ab3a833589a069b473a4dfb3f171e5b8 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 16:03:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 16:03:43 -0000 Subject: [GHC] #12552: Merge OpenBSD fixes In-Reply-To: <046.ddb51184ed227251f413950292617386@haskell.org> References: <046.ddb51184ed227251f413950292617386@haskell.org> Message-ID: <061.50d2d9e37a381c443a30d87e52e39800@haskell.org> #12552: Merge OpenBSD fixes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: merge Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -3,2 +3,0 @@ - * ffd4029c5bc581ac749f5cdc3d8e085c80add585 - * 3551e622ab3a833589a069b473a4dfb3f171e5b8 New description: Merge the following to `ghc-8.0`, * f9aa996f0af59f32dc7b1528ff78be41413a9c27 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 16:32:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 16:32:32 -0000 Subject: [GHC] #12551: Make type indices take local constraints into account in type instance declaration In-Reply-To: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> References: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> Message-ID: <066.84c0ca090655631d2f29587ba2d9cb03@haskell.org> #12551: Make type indices take local constraints into account in type instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I vaguely remember that discussion. That's fine, I will add the [https://gist.github.com/Icelandjack/5afdaa32f41adf3204ef9025d9da2a70#workaround workaround]. Could this be mentioned in the error message? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 16:44:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 16:44:27 -0000 Subject: [GHC] #12551: Make type indices take local constraints into account in type instance declaration In-Reply-To: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> References: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> Message-ID: <066.3c40b08d21d2fad7f3fa65fdf01d7e9a@haskell.org> #12551: Make type indices take local constraints into account in type instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I think it should. Might you add it? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 16:57:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 16:57:39 -0000 Subject: [GHC] #12551: Make type indices take local constraints into account in type instance declaration In-Reply-To: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> References: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> Message-ID: <066.d44e7f2ec5f5d5e545ab82a55afead4c@haskell.org> #12551: Make type indices take local constraints into account in type instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): [https://www.youtube.com/watch?v=BD4nUQZaGNc What do I look like, a guy who's not lazy?] ---- I will :D -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 16:59:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 16:59:38 -0000 Subject: [GHC] #12551: Make type indices take local constraints into account in type instance declaration In-Reply-To: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> References: <051.a9a4d639ea5cda59107b9682b32a78a7@haskell.org> Message-ID: <066.a82e95e85592fb907bba171793d0ef7c@haskell.org> #12551: Make type indices take local constraints into account in type instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * owner: => Iceland_jack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 17:36:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 17:36:57 -0000 Subject: [GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context In-Reply-To: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> References: <050.af39f1a579b983c8d383ae5b1f963e25@haskell.org> Message-ID: <065.50dc56fb4b7f65f963561bdc0ac696f1@haskell.org> #12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Possibly related, should this complain or is it up to the caller to use it with a `Monoid A` instance in scope {{{#!hs import Control.Monad.Writer data A = A a :: MonadWriter A m => m () a = tell A }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 17:53:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 17:53:24 -0000 Subject: [GHC] #12460: Solaris linker does not recognize option --gc-sections In-Reply-To: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> References: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> Message-ID: <060.6221950c697af86985f1a07d38bba1fe@haskell.org> #12460: Solaris linker does not recognize option --gc-sections -------------------------------------+------------------------------------- Reporter: herzen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Solaris | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by herzen): Replying to [comment:4 bgamari]: > herzen, where does your `ld` come from? Presumably it's not a gnu ld Oops, I didn't know about "ghc --info". Yes, it turns out that the ld that was being used was gnu ld. When I change that to Solaris's ld (/usr/bin/ld), the behavior I reported as a bug goes away. My mistake was to assume that the option --with-ld passed to ./configure has no effect, because I was dealing with a prebuilt binary of ghc, as opposed to building it myself. I was packaging the prebuilt binary using Solaris's build system called pkgbuild, which is derived from rpmbuild. The way we use that build system is by having a PATH in which /usr/gnu/bin is in front of /usr/bin; that is why gnu ld was getting picked up instead of Solaris ld. The spec file I was working with, which was written by someone else and actually built ghc, supplied --with-ld=/usr/bin/ld to ./configure, but I deleted that, because I didn't think it made a difference for what I was doing, as I said. It was sloppy of me to file a bug report instead of making sure that Solaris ld was being used, as I had assumed. I could paste what "ghc --info" produces, but I don't think there's any point now. '''kgardas''' noted above that he makes his builds on Solaris 11.2. I will go on investigating whether I run into problems with his builds on 11.3. (I have set up a Solaris 11.2 system, in case I need to compare what happens between the two Solaris releases.) Thank you very much for your suggestion. I should have thought of that myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 18:06:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 18:06:07 -0000 Subject: [GHC] #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure In-Reply-To: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> References: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> Message-ID: <064.3035adac8b2675987ab70c0c549c48ee@haskell.org> #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AaronFriel): Please permit me some additional questions, I would like to know more about the compiler internals. I think I see why you might want to do this in the type checker, to make sure that `return` or `pure` has the right type before performing the transformation? If so, I don't know how important that is, but with `RebindableSyntax` and `ApplicativeDo` I would assume the user is saying, "I know what I'm doing and I want the transformation to be assumed to be lawful." And, as the `ApplicativeDo` desugaring will still contain `join` or `return` in many cases, incorrectly typed `pure` and `return` definitions ought to cause a compiler error sooner or later. Does that line up with your thoughts? When you say "`Name` of `return`", do you mean in case `return` has been aliased by the user? Does `Name` then correspond to what I would call the fully qualified name, e.g.: `Control.Monad.foo`? If I understand your solution correctly, will any top-level `return` or `pure` permit the desugaring I wrote? (Duplicated here.) {{{#!hs fPure m = do a <- m b <- m pure (a, b) -- to: fPure m = My.(<*>) (My.fmap (\a b -> (a, b)) m) m }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 18:24:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 18:24:42 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration Message-ID: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Old code: {{{#!hs data Full :: Type -> Type data AST :: (Type -> Type) -> (Type -> Type) -- ASTF :: (Type -> Type) -> (Type -> Type) type ASTF dom a = AST dom (Full a) class Syntactic a where type Domain a :: Type -> Type type Internal a :: Type desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} ---- New code with richer kinds {{{#!hs data Sig a = Full a | a :-> Sig a data AST :: (Sig a -> Type) -> (Sig a -> Type) data Sig a = Full a | a :-> Sig a -- ASTF :: (Sig a -> Type) -> (a -> Type) type ASTF dom a = AST dom (Full a) class Syntactic a where type Domain a :: Sig Type -> Type type Internal a :: Type desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} As the type of `ASTF` hints at it could accept arguments of kind `Sig a -> Type` and `a`. I would like to reference the variable `a` from the kind of `Domain` in the kind of `Internal`, but this fails: {{{#!hs -- • Kind variable ‘u’ is implicitly bound in datatype -- ‘Internal’, but does not appear as the kind of any -- of its type variables. Perhaps you meant -- to bind it (with TypeInType) explicitly somewhere? -- Type variables with inferred kinds: a -- • In the class declaration for ‘Syntactic’ class Syntactic a where type Domain a :: Sig u -> Type type Internal a :: u desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} ---- Should the `u` in the kind of `Domain a` be quantified over (which makes this compile)? {{{#!hs type Domain a :: forall k. Sig k -> Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 18:26:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 18:26:14 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration In-Reply-To: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> References: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> Message-ID: <066.74c7938df77672f00ccf7fedb654df10@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -65,0 +65,2 @@ + + **Edit**: This doesn't work. New description: Old code: {{{#!hs data Full :: Type -> Type data AST :: (Type -> Type) -> (Type -> Type) -- ASTF :: (Type -> Type) -> (Type -> Type) type ASTF dom a = AST dom (Full a) class Syntactic a where type Domain a :: Type -> Type type Internal a :: Type desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} ---- New code with richer kinds {{{#!hs data Sig a = Full a | a :-> Sig a data AST :: (Sig a -> Type) -> (Sig a -> Type) data Sig a = Full a | a :-> Sig a -- ASTF :: (Sig a -> Type) -> (a -> Type) type ASTF dom a = AST dom (Full a) class Syntactic a where type Domain a :: Sig Type -> Type type Internal a :: Type desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} As the type of `ASTF` hints at it could accept arguments of kind `Sig a -> Type` and `a`. I would like to reference the variable `a` from the kind of `Domain` in the kind of `Internal`, but this fails: {{{#!hs -- • Kind variable ‘u’ is implicitly bound in datatype -- ‘Internal’, but does not appear as the kind of any -- of its type variables. Perhaps you meant -- to bind it (with TypeInType) explicitly somewhere? -- Type variables with inferred kinds: a -- • In the class declaration for ‘Syntactic’ class Syntactic a where type Domain a :: Sig u -> Type type Internal a :: u desugar :: a -> ASTF (Domain a) (Internal a) sugar :: ASTF (Domain a) (Internal a) -> a }}} ---- Should the `u` in the kind of `Domain a` be quantified over (which makes this compile)? {{{#!hs type Domain a :: forall k. Sig k -> Type }}} **Edit**: This doesn't work. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 18:33:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 18:33:04 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration In-Reply-To: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> References: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> Message-ID: <066.485dbb167135b242b2bd225468227cba@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): If I constrain the types `Domain a :: Sig Type -> Type`, `Internal a :: Type` this fails {{{#!hs -- • Expected kind ‘Sig Type -> Type’, -- but ‘dom’ has kind ‘Sig a -> Type’ -- • In the type ‘dom’ -- In the type instance declaration for ‘Domain’ -- In the instance declaration for ‘Syntactic (AST dom (Full a))’ -- -- • Expected a type, but ‘a1’ has kind ‘a’ -- • In the type ‘a’ -- In the type instance declaration for ‘Internal’ -- In the instance declaration for ‘Syntactic (AST dom (Full a))’ instance Syntactic (AST dom (Full a)) where type Domain (AST dom (Full a)) = dom type Internal (AST dom (Full a)) = a }}} and I have to restrict the kind of `AST` to {{{#!hs data AST :: (Sig Type -> Type) -> (Sig Type -> Type) where }}} Boo! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 18:34:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 18:34:20 -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.ed2270330ef71087aa5c2fe7a1d60091@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Very cool work! Do we want to limit the number of capabilities to the number of hyper threaded cores or the number of physical cores? Likewise, another opportunity for improvement might be seeing about making sure the capabilities (when CPU pining is enabled for the rts) are spread out maximally across the available CPU cores? I believe this or a similar issue was discussed / observed by Ryan Yates / fryguybob previously but I'm not sure if we had worked out a portable way to decide this or not -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 18:40:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 18:40:51 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration In-Reply-To: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> References: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> Message-ID: <066.c848bdca1227cd034050009320b7eafd@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): It seems to work by ''un-''associating them from `Syntactic` {{{#!hs type family Domain a :: Sig u -> Type type instance Domain (AST dom (Full a)) = dom type family Internal (a :: Type) :: k type instance Internal (AST dom (Full a)) = a }}} and `instance Syntactic (AST dom (Full a))` compiles. Is there some way to get them to compile while associated? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 18:45:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 18:45:39 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration In-Reply-To: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> References: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> Message-ID: <066.5eba107aae445ca10dc641adf7c5cd0a@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => TypeInType Comment: I don't understand the code you're posting, but `Internal` looks OK to me. It should be accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 19:52:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 19:52:01 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration In-Reply-To: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> References: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> Message-ID: <066.7769b8f63a13dd7514f11ceda412f8f7@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Interesting! this works {{{#!hs class Syntactic a where type Domain a :: Sig u -> Type type Internal a :: u a :: Proxy (Domain a) b :: Proxy (Internal a) -- c :: AST (Domain a) (Full (Internal a)) }}} but for some reason the method `c` breaks it. ---- Functional dependencies solve this, but they change the API in a way that doesn't work for me: {{{#!hs class Syntactic a (dom :: Sig u -> Type) | a -> dom where type Internal a :: u desugar :: ASTF dom (Internal a) -> a sugar :: a -> ASTF dom (Internal a) instance Syntactic (AST dom (Full a)) dom where type Internal (AST dom (Full a)) = a desugar = id sugar = id }}} ---- Here is another workaround, it's not perfect (need to recover `Domain`, `Internal`) but it's a start {{{#!hs class Syntactic a where type DomainInternal a :: Type desugar :: DomainInternal a -> a sugar :: a -> DomainInternal a instance Syntactic (AST dom (Full a)) where type DomainInternal (AST dom (Full a)) = AST dom (Full a) desugar x = x sugar x = x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 20:13:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 20:13:26 -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.7bb358a8ee0108b6ef7ca87ee951b880@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): [warning: not a NUMA expert] Tl;DR: I think it depends on what exactly we hit as a bottleneck. I have a suspiction we saturate RAM bandwidth, not CPU ability to retire instructions due to hyperthreads. Basically GHC does too many non-local references and one of the ways to speed GHC up is either insrease memory locality or decrease HEAP usage. Long version: For a while I tried to figure out why exactly I don't see perfect scaling of '''ghc --make''' on my box. It's easy to see/compare with '''synth.bash +RTS -A256M -RTS''' benchmark ran with '''-j1''' / '''-j''' options. I don't have hard evidence but I suspect bottleneck is not due to hyperthreads/real core execution engines but due to RAM bandwidth limit on CPU-to-memory path. One of the hints is '''perf stat''': {{{ $ perf stat -e cache-references,cache- misses,cycles,instructions,branches,faults,migrations,mem-loads,mem-stores ./synth.bash -j +RTS -sstderr -A256M -qb0 -RTS Performance counter stats for './synth.bash -j +RTS -sstderr -A256M -qb0 -RTS': 3 248 577 545 cache-references (28,64%) 740 590 736 cache-misses # 22,797 % of all cache refs (42,93%) 390 025 361 812 cycles (57,18%) 171 496 925 132 instructions # 0,44 insn per cycle (71,45%) 33 736 976 296 branches (71,47%) 1 061 039 faults 1 524 migrations 67 895 mem-loads (71,42%) 27 652 025 890 mem-stores (14,27%) 15,131608490 seconds time elapsed }}} 22% of all cache refs are misses. A huge number. I think it dominates performance (assuming memory access is ~100 times slower than CPU cache access), but I have no hard evidence :) I have 4 cores with x2 hyperthreads each and get best performance from -j8, not -j4 as one would expect from hyperthreads inctruction retirement: -j1: 55s; -j4: 18s; -j6: 15s; j8: 14.2s; -j10: 15.0s {{{ ./synth.bash -j +RTS -sstderr -A256M -qb0 -RTS 66,769,724,456 bytes allocated in the heap 1,658,350,288 bytes copied during GC 127,385,728 bytes maximum residency (5 sample(s)) 1,722,080 bytes maximum slop 2389 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 31 colls, 31 par 6.535s 0.831s 0.0268s 0.0579s Gen 1 5 colls, 4 par 1.677s 0.225s 0.0449s 0.0687s Parallel GC work balance: 80.03% (serial 0%, perfect 100%) TASKS: 21 (1 bound, 20 peak workers (20 total), using -N8) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.002s ( 0.002s elapsed) MUT time 87.599s ( 12.868s elapsed) GC time 8.212s ( 1.056s elapsed) EXIT time 0.013s ( 0.015s elapsed) Total time 95.841s ( 13.942s elapsed) Alloc rate 762,222,437 bytes per MUT second Productivity 91.4% of total user, 92.4% of total elapsed gc_alloc_block_sync: 83395 whitehole_spin: 0 gen[0].sync: 280927 gen[1].sync: 134537 real 0m14.070s user 1m44.835s sys 0m2.899s }}} I've noticed that building GHC with '''-fno-worker-wrapper -fno-spec- constr''' makes GHC 4% faster (-j8) (memory allocations is 7% less, a bug #11565 is likely at fault) which also hints at memory throughput as a bottleneck. The conclusion: AFAIU, thus to make most of GHC we should strive for amount of active threads capable of saturating all the memory IO channels the machine has (but not much more). '''perf bench mem all''' suggests RAM bandwidth performance is in range of 2-32GB/s depending how bad workload is. I would assume GHC workload is very non- linear (and thus bad). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 20:24:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 20:24:45 -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.2b15aa57036919a07fd9c70a017db372@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): Would people agree that we should not have spinlocks in the system without some back-off strategy? E.g. switch to sleeping/blocking after some number of iterations. Even a constant upper bound could reign in worst case behaviors. Apparently OS's provide some notion of "adaptive lock" that has other nice features, e.g.: http://stackoverflow.com/questions/19863734/what-is- pthread-mutex-adaptive-np -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 20:49:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 20:49:54 -0000 Subject: [GHC] #12553: Reference kind in a type instance declaration defined in another instance declaration In-Reply-To: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> References: <051.3d64cef357f996714639ad9f91cd8122@haskell.org> Message-ID: <066.2a97ab376234e7cb01927930f1e38bad@haskell.org> #12553: Reference kind in a type instance declaration defined in another instance declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard says > but `Internal` looks OK to me. It should be accepted. Alas Jack has posted no fewer than four different declarations of `Internal`, so I'm not sure which one(s) you think should be accepted. Jack, what kind do you WANT `Internal` to have? For example, in the one that works: {{{ type family Domain a :: Sig u -> Type type family Internal (a :: Type) :: k }}} I believe we get {{{ Domain :: forall (u :: Type). Type -> Sig u -> Type Internal :: forall (k :: Type). Type -> k }}} Now when writing them in associated form we have {{{ class Syntactic a where type Domain a :: Sig u -> Type type Internal a :: u }}} and this should not really be different. I think it shoudl be accepted. But I do have a question: should we get {{{ Domain :: Type -> forall u. Sig u -> Type or Domain :: forall u. Type -> Sig u -> Type }}} and does it matter at use sites? Richard The same question arises with class methods. Given {{{ class C a where op :: forall b. Ord b => b -> a -> a }}} do we get {{{ op :: forall a. C a => forall b. Ord b => b -> a -> a or op :: forall a b. (C a, Ord b) => b -> a -> a }}} Answer: wer get the former. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 20:52:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 20:52:34 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.4f76baadb01a2734d4719b7963c58066@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rrnewton): That looks like the right kind of thing, but it needs to be conditional -- only on the ARM backend. We wouldn't want to slow down x86. Ideally, it would only apply in `-threaded` mode to boot, but my current understanding is that we only make the distinction at the final link phase (which runtime to link), not as a different "way" during compilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:15:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:15:14 -0000 Subject: [GHC] #12554: Testsuite exibits large amount of framework failures Message-ID: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> #12554: Testsuite exibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've tried this on multiple computers and they all have the same issue. I get around 400 testsuite failures with the error: {{{ r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run T11680 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11680.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run T11797 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11797.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run T10734 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10734.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run T11345 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11345.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run T10820 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T10820.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run T11484 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11484.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run T9022 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T9022.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run T12130 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12130.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run T8761 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T8761.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run T12407 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12407.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run T11463 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T11463.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run T12478_4 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_4.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run T12478_3 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12478_3.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run T12513 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12513.run') r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run T12530 [ext-interp] ([Error 183] Cannot create a file when that file already exists: 'r:/temp/ghctest-0u4c8o/test spaces/./th/T12530.run') }}} What they all have in common is that they are all using the latest MSYS2 and tools: {{{ Tamar at Squid MINGW64 ~/ghc $ python3 --version Python 3.5.2 Tamar at Squid MINGW64 ~/ghc $ uname -a MINGW64_NT-10.0 Kino 2.5.2(0.297/5/3) 2016-07-15 08:31 x86_64 Msys }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:17:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:17:49 -0000 Subject: [GHC] #12555: bindist configure checks involving the compiler are broken Message-ID: <047.7189f40da15e886bf03f5db082f36b80@haskell.org> #12555: bindist configure checks involving the compiler are broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit 6554dc60304bbd4b2edb93be7e1658bff237e067 added this code to `distrib/configure.ac.in`: {{{ BinDistNeedsLibdw=@HaveLibdw@ if test "x$BinDistNeedsLibdw" = "xyes" ; then AC_CHECK_LIB(dw, dwfl_attach_state, [HaveLibdw=YES], [AC_MSG_ERROR([Binary distribution was built with libdw support but target system doesn't have supported libdw version (needs at least 0.158)])] )]; fi }}} It occurs before any other autoconf command involving the compiler. So apparently the expansion of `AC_CHECK_LIB` includes the code responsible for checking how to invoke the compiler, checking the object file suffix, etc. (Yes, this is a crazy way to do it.) Since the official bindist has `BinDistNeedsLibdw=NO`, none of that code ever actually runs. Later (in `FPTOOLS_SET_HASKELL_PLATFORM_VARS`) the configure script uses ` AC_COMPILE_IFELSE` to check for features of the compiler like non- executable stack support, but these checks are broken because autoconf never actually determined basic information about the compiler. So the 8.0.1 bindist produces binaries with executable stacks, which is a problem on some systems. It would be better anyways to move this `AC_CHECK_LIB` later in `distrib/configure.ac.in`, to after where we select flags to be used when invoking the compiler. There are also some other bugs in this code: there is an extra `];` and the correct value of `BinDistNeedsLibdw` is `YES` (not `yes`) so the code currently can never run anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:31:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:31:49 -0000 Subject: [GHC] #12433: GHCi produces incorrect results when evaluating with compiled code In-Reply-To: <047.882472dc094976fa082efbe928facde9@haskell.org> References: <047.882472dc094976fa082efbe928facde9@haskell.org> Message-ID: <062.be58ca5ded0bf3829ee0fda7e7cab7b0@haskell.org> #12433: GHCi produces incorrect results when evaluating with compiled code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: ghci, dynamic | linking, compiled code Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 8.0.2 Comment: Can we fix this in 8.0.2? Reid, it looks as if you know what is going on.. I'll milestone it for 8.0.2 so we don't forget. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:33:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:33:18 -0000 Subject: [GHC] #12555: bindist configure checks involving the compiler are broken In-Reply-To: <047.7189f40da15e886bf03f5db082f36b80@haskell.org> References: <047.7189f40da15e886bf03f5db082f36b80@haskell.org> Message-ID: <062.c3fd392ff5f2d6a9986ba63b7fff1328@haskell.org> #12555: bindist configure checks involving the compiler are broken -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:42:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:42:14 -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.0c52c2b334ec4eb47f72a6dc788be883@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Replying to [comment:61 slyfox]: > [warning: not a NUMA expert] > > Tl;DR: > > I think it depends on what exactly we hit as a bottleneck. > > I have a suspiction we saturate RAM bandwidth, not CPU ability > to retire instructions due to hyperthreads. Basically GHC does > too many non-local references and one of the ways to speed GHC > up is either insrease memory locality or decrease HEAP usage. That's exactly why I'm wondering if hyper threading is messing with us! Each pair of hyper thread cores shares the same l1 l2 cache, so if we're memory limited that might be Triggering a higher rate of cache thrash? Also in some cases when capabilities numbers are below the number of cores I think we pin two capabitilties to the same physical core needlessly. I need to dig up those references and revisit that though :) > > Long version: > > For a while I tried to figure out why exactly I don't see > perfect scaling of '''ghc --make''' on my box. > > It's easy to see/compare with '''synth.bash +RTS -A256M -RTS''' benchmark ran with '''-j1''' / '''-j''' options. > > I don't have hard evidence but I suspect bottleneck is not due to > hyperthreads/real core execution engines but due to RAM > bandwidth limit on CPU-to-memory path. One of the hints > is '''perf stat''': > > {{{ > $ perf stat -e cache-references,cache- misses,cycles,instructions,branches,faults,migrations,mem-loads,mem-stores ./synth.bash -j +RTS -sstderr -A256M -qb0 -RTS > > Performance counter stats for './synth.bash -j +RTS -sstderr -A256M -qb0 -RTS': > > 3 248 577 545 cache-references (28,64%) > 740 590 736 cache-misses # 22,797 % of all cache refs (42,93%) > 390 025 361 812 cycles (57,18%) > 171 496 925 132 instructions # 0,44 insn per cycle (71,45%) > 33 736 976 296 branches (71,47%) > 1 061 039 faults > 1 524 migrations > 67 895 mem-loads (71,42%) > 27 652 025 890 mem-stores (14,27%) > > 15,131608490 seconds time elapsed > }}} > > 22% of all cache refs are misses. A huge number. I think it dominates performance > (assuming memory access is ~100 times slower than CPU cache access), but I have no > hard evidence :) > > I have 4 cores with x2 hyperthreads each and get best performance from -j8, > not -j4 as one would expect from hyperthreads inctruction retirement: > > -j1: 55s; -j4: 18s; -j6: 15s; j8: 14.2s; -j10: 15.0s > > {{{ > ./synth.bash -j +RTS -sstderr -A256M -qb0 -RTS > > 66,769,724,456 bytes allocated in the heap > 1,658,350,288 bytes copied during GC > 127,385,728 bytes maximum residency (5 sample(s)) > 1,722,080 bytes maximum slop > 2389 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max pause > Gen 0 31 colls, 31 par 6.535s 0.831s 0.0268s 0.0579s > Gen 1 5 colls, 4 par 1.677s 0.225s 0.0449s 0.0687s > > Parallel GC work balance: 80.03% (serial 0%, perfect 100%) > > TASKS: 21 (1 bound, 20 peak workers (20 total), using -N8) > > SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) > > INIT time 0.002s ( 0.002s elapsed) > MUT time 87.599s ( 12.868s elapsed) > GC time 8.212s ( 1.056s elapsed) > EXIT time 0.013s ( 0.015s elapsed) > Total time 95.841s ( 13.942s elapsed) > > Alloc rate 762,222,437 bytes per MUT second > > Productivity 91.4% of total user, 92.4% of total elapsed > > gc_alloc_block_sync: 83395 > whitehole_spin: 0 > gen[0].sync: 280927 > gen[1].sync: 134537 > > real 0m14.070s > user 1m44.835s > sys 0m2.899s > }}} > > I've noticed that building GHC with '''-fno-worker-wrapper -fno-spec- constr''' > makes GHC 4% faster (-j8) (memory allocations is 7% less, a bug #11565 is likely > at fault) which also hints at memory throughput as a bottleneck. > > The conclusion: > > AFAIU, thus to make most of GHC we should strive for amount of active threads > capable of saturating all the memory IO channels the machine has (but not much more). > > '''perf bench mem all''' suggests RAM bandwidth performance is in range of 2-32GB/s > depending how bad workload is. I would assume GHC workload is very non- linear (and thus bad). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:44:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:44:03 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.cafede4e0618f1ee6be1a17c0cbdae51@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest * milestone: => 8.0.2 Comment: In comment:26 I suggest taking it out of `-Wall`. That is simple and low risk. If it's causing pain having it in, let's just do that. Ben: can you execute? If we consider putting it into `-Wall` as a bug, this is a bug-fix :-). I'll milestone as 8.0.2/highest to make sure it gets done. More elaborate solutions could be possible (see thread above), but not for 8.0.2. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:44:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:44:12 -0000 Subject: [GHC] #12177: Relevant bindings includes shadowed bindings In-Reply-To: <045.0e76a562090c9d87371f445f74b8515d@haskell.org> References: <045.0e76a562090c9d87371f445f74b8515d@haskell.org> Message-ID: <060.d28c6782b1f736212e423e1093b8e8e2@haskell.org> #12177: Relevant bindings includes shadowed bindings -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12177 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2434 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:44:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:44:33 -0000 Subject: [GHC] #12177: Relevant bindings includes shadowed bindings In-Reply-To: <045.0e76a562090c9d87371f445f74b8515d@haskell.org> References: <045.0e76a562090c9d87371f445f74b8515d@haskell.org> Message-ID: <060.3232e50c3aeded9921cb416330bb60e4@haskell.org> #12177: Relevant bindings includes shadowed bindings -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12177 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2434 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as 88b781283b728f72f2fcbae82037dd3d7f407e7a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:44:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:44:50 -0000 Subject: [GHC] #12458: Segfault in GHCi runtime type reconstruction In-Reply-To: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> References: <044.1a228f3c83a7b3775ff24f8d399a0f8e@haskell.org> Message-ID: <059.477c2adfb1ed2ab0551e17240f5ed555@haskell.org> #12458: Segfault in GHCi runtime type reconstruction -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: | ghci.debugger/scripts/T12458 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2439 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 54413fd1b004def92d629e85499caef53832d8ee. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:45:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:45:14 -0000 Subject: [GHC] #12531: Holes should be representation-polymorphic In-Reply-To: <044.38d412e29e728e7d1a4333b441265291@haskell.org> References: <044.38d412e29e728e7d1a4333b441265291@haskell.org> Message-ID: <059.9af86025c630e2e0e01523916ed85c2c@haskell.org> #12531: Holes should be representation-polymorphic -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: partial- | sigs/should_compile/T12531 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as f4ac734d754e2d4399525038e8a4dd4a841ce8af. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:45:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:45:56 -0000 Subject: [GHC] #11832: Allow reify to yield types in the current declaration group In-Reply-To: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> References: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> Message-ID: <071.afcc39c3d202ee8145fd57e8cbaf82f0@haskell.org> #11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: merge Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 7.10.3 Resolution: fixed | Keywords: reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2286 Wiki Page: | TemplateHaskell/Reify | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge * milestone: => 8.0.2 Comment: Merged to `ghc-8.0` as 8d63419478074728eb03082787ea51d498b3e62e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:47:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:47:03 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse In-Reply-To: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> References: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> Message-ID: <066.32507e79953c9d3d25cbd5cc33c9c937@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: orf Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes -- a note in the manual would be hugely helpful. Might you send a patch? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:47:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:47:27 -0000 Subject: [GHC] #12552: Merge OpenBSD fixes In-Reply-To: <046.ddb51184ed227251f413950292617386@haskell.org> References: <046.ddb51184ed227251f413950292617386@haskell.org> Message-ID: <061.416200b7aaeb71643bea6742a570bc85@haskell.org> #12552: Merge OpenBSD fixes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 5370f3cb40aaf758f39b4b0db8b38dce68fd57aa. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:47:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:47:37 -0000 Subject: [GHC] #12164: Type signatures in patterns not (yet) handled by Template Haskell In-Reply-To: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> References: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> Message-ID: <060.2d1e04a5e8da040ecd1898dbb5a5a168@haskell.org> #12164: Type signatures in patterns not (yet) handled by Template Haskell -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mikhail.vorozhtsov): No, I only need type constructors. It looks like this: {{{ defState "Name" [| \(var1 :: TypeName1, "A state variable") \(var2 :: TypeName2, "Another one") -> BEHAVIOR |] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 21:52:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 21:52:17 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.e9d4c19415c795b10fce589eec3ed691@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): Phab:D2498 #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by acfoltzer): * differential: => Phab:D2498 Comment: I've just added a patch for 8.0.2. I definitely agree that we want more elaborate solutions in the future, or at least ways to recover the parts of the warning that don't cause as many folks pain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 30 22:49:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Aug 2016 22:49:41 -0000 Subject: [GHC] #12460: Solaris linker does not recognize option --gc-sections In-Reply-To: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> References: <045.abfcefdcb4bfd292101edf063441ba85@haskell.org> Message-ID: <060.b6b3089838a82c8586d9930757b2905b@haskell.org> #12460: Solaris linker does not recognize option --gc-sections -------------------------------------+------------------------------------- Reporter: herzen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: invalid | Keywords: Operating System: Solaris | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: > Oops, I didn't know about "ghc --info". Yes, it turns out that the ld that was being used was gnu ld. When I change that to Solaris's ld (/usr/bin/ld), the behavior I reported as a bug goes away. Great! > It was sloppy of me to file a bug report instead of making sure that Solaris ld was being used, as I had assumed. Not a problem, you can't think of everything. I'm glad we were able to resolve it without code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 03:46:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 03:46:32 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.2bdfa1559cf0735588243be8291540cc@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 06:09:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 06:09:12 -0000 Subject: [GHC] #12372: bug: documentation for Control.Monad.guard not useful after AMP In-Reply-To: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> References: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> Message-ID: <058.23e77645d4b4c53488d277c9c2a6ce8d@haskell.org> #12372: bug: documentation for Control.Monad.guard not useful after AMP -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ntc2): Replying to [comment:4 bgamari]: > ntc2, any word on this? So, I'm only familiar with `MonadPlus` examples. E.g. {{{ safeDivision :: (Eq a, Fractional a, MonadPlus m) => a -> a -> m a safeDivison n d = do guard (d /= 0) return (n / d) ghci> safeDivision 3 0 :: Maybe Double Nothing ghci> safeDivision 3 2 :: Maybe Double Just 1.5 }}} Now, it turns out I can also write that example using `Alternative`, i.e. {{{ safeDivisionA :: (Eq a, Fractional a, Alternative f) => a -> a -> f a safeDivisionA n d = guard (d /= 0) *> pure (n / d) ghci> safeDivisionA 3 0 :: Maybe Double Nothing ghci> safeDivisionA 3 2 :: Maybe Double Just 1.5 }}} but the default `Alternatives` I know are exactly the `MonadPlus` types, i.e. `[]` and `Maybe`, so I don't see what I've gained here (and in practice I think I'd just use `Maybe` here). So, I think a `MonadPlus` example like `safeDivision` would be useful. An example that only makes use of the weaker `Alternative` assumption might also be useful, but I don't have one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 06:44:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 06:44:16 -0000 Subject: [GHC] #12497: Make runtime linker be able to find POSIX functions under their deprecated name. In-Reply-To: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> References: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> Message-ID: <059.3cdb571b9ede928082aed33f9fff07f8@haskell.org> #12497: Make runtime linker be able to find POSIX functions under their deprecated name. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12209 | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2478 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 06:44:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 06:44:34 -0000 Subject: [GHC] #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" In-Reply-To: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> References: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> Message-ID: <060.107b7f4f4beea44e89327c04cc6ce38f@haskell.org> #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12497 | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2478 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 06:45:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 06:45:01 -0000 Subject: [GHC] #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs In-Reply-To: <041.fe13b79f3753d34e58ed0cb274b335c2@haskell.org> References: <041.fe13b79f3753d34e58ed0cb274b335c2@haskell.org> Message-ID: <056.cfd0e9699b84214ba59362d03a5ff2b8@haskell.org> #12496: GHCi reports unknown symbols in Win32 when linking C and C++ libs -------------------------------------+------------------------------------- Reporter: pl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHC rejects | Test Case: valid program | Blocked By: | Blocking: Related Tickets: #11072 | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: => Phab:D2478 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 07:24:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 07:24:44 -0000 Subject: [GHC] #12459: UnboxedTuple makes overloaded labels fail to parse In-Reply-To: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> References: <051.745b174e20ab003dc64bbb283a6e3867@haskell.org> Message-ID: <066.6058f4b1ea005aba53c646e1e6a18a4f@haskell.org> #12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: orf Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: => adamgundry * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 08:39:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 08:39:58 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.cfef07c1474c8aca8efb5d056c4f0cea@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): Phab:D2498 #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 09:53:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 09:53:12 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.4f880c63e8d8d2ffae57c8df4192217f@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): `MO_WriteBarrier` compiles to no code on x86, but it prevents writes from being reordered by earlier optimisations, which is exactly what we want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 10:03:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 10:03:58 -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.38eabf3d9ce96644b87cfa79e6b186cf@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): GHC has a `+RTS --numa` option that you might want to try. Memory bandwidth *might* be a scaling issue, it depends a lot on what hardware you're using (how many memory channels, are they populated with DIMMs?). You could always verify this by comparing the scaling that you get with N independent GHC processes vs. `ghc -jN`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 10:38:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 10:38:27 -0000 Subject: [GHC] #11565: Restore code to handle '-fmax-worker-args' flag In-Reply-To: <045.9d241621de87bb494a516e9874327ca7@haskell.org> References: <045.9d241621de87bb494a516e9874327ca7@haskell.org> Message-ID: <060.52d49262b3b947e1c9c928fa8b126d59@haskell.org> #11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Here comes minimal example for one direction: heap to stack. The trigger is a function with many USED record fields: show in this case. In case of DynFlags it's a full (or large) subset of fields used in various GHC subsystems. {{{#!hs -- A.hs module A(D) where -- like DynFlgs in GHC data D = D { f_00, f_01, f_02, f_03, f_04 , f_10, f_11, f_12, f_13, f_14 , f_20, f_21, f_22, f_23, f_24 , f_30, f_31, f_32, f_33, f_34 , f_40, f_41, f_42, f_43, f_44 , f_50, f_51, f_52, f_53, f_54 , g_00, g_01, g_02, g_03, g_04 , g_10, g_11, g_12, g_13, g_14 , g_20, g_21, g_22, g_23, g_24 , g_30, g_31, g_32, g_33, g_34 , g_40, g_41, g_42, g_43, g_44 , g_50, g_51, g_52, g_53, g_54 , h_00, h_01, h_02, h_03, h_04 , h_10, h_11, h_12, h_13, h_14 , h_20, h_21, h_22, h_23, h_24 , h_30, h_31, h_32, h_33, h_34 , h_40, h_41, h_42, h_43, h_44 , h_50, h_51, h_52, h_53, h_54 , i_00, i_01, i_02, i_03, i_04 , i_10, i_11, i_12, i_13, i_14 , i_20, i_21, i_22, i_23, i_24 , i_30, i_31, i_32, i_33, i_34 , i_40, i_41, i_42, i_43, i_44 , i_50, i_51, i_52, i_53, i_54 :: Int } deriving Show }}} {{{#!hs -- B.hs module B (tiny_foo) where import qualified A tiny_foo :: A.D -> Bool tiny_foo d = null (show d) }}} Let's look at the size of module B on '''-O0''' and '''-O1''' while A is compiled -O2: '''-O0''', no unboxing happens. {{{#!hs $ ghc -c -O2 A.hs && ghc -c -O0 B.hs -ddump-stg -fforce-recomp compilation IS NOT required ==================== STG syntax: ==================== $trModule1_r3JD :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] = NO_CCS GHC.Types.TrNameS! ["main"#]; $trModule2_r3P0 :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] = NO_CCS GHC.Types.TrNameS! ["B"#]; B.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] = NO_CCS GHC.Types.Module! [$trModule1_r3JD $trModule2_r3P0]; B.tiny_foo :: A.D -> GHC.Types.Bool [GblId, Arity=1, Str=DmdType, Unf=OtherCon []] = \r srt:SRT:[r30 :-> A.$fShowD, rAj :-> Data.Foldable.$fFoldable[]] [d_s3P4] let { sat_s3P5 [Occ=Once] :: [GHC.Types.Char] [LclId, Str=DmdType] = \u srt:SRT:[r30 :-> A.$fShowD] [] GHC.Show.show A.$fShowD d_s3P4; } in Data.Foldable.null Data.Foldable.$fFoldable[] sat_s3P5; }}} '''-O1''', unboxing hapened: {{{#!hs $ ghc -c -O2 A.hs && ghc -c -O1 B.hs -ddump-stg -fforce-recomp compilation IS NOT required ==================== STG syntax: ==================== B.$trModule2 :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Str=DmdType m1, Unf=OtherCon []] = NO_CCS GHC.Types.TrNameS! ["main"#]; B.$trModule1 :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Str=DmdType m1, Unf=OtherCon []] = NO_CCS GHC.Types.TrNameS! ["B"#]; B.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs, Str=DmdType m, Unf=OtherCon []] = NO_CCS GHC.Types.Module! [B.$trModule2 B.$trModule1]; B.$wtiny_foo [InlPrag=[0]] :: GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Int ... -> GHC.Types.Int -> GHC.Types.Bool [GblId, Arity=120, Str=DmdType , Unf=OtherCon []] = \r srt:SRT:[r3a :-> A.$w$cshowsPrec] [ww_s47S ww1_s47T ww2_s47U ww3_s47V ww4_s47W ww5_s47X ww6_s47Y ... ww115_s49J ww116_s49K ww117_s49L ww118_s49M ww119_s49N] case A.$w$cshowsPrec 0# ww_s47S ww1_s47T ww2_s47U ww3_s47V ww4_s47W ww5_s47X ww6_s47Y ww7_s47Z ww8_s480 ww9_s481 ww10_s482 ww11_s483 ww12_s484 ww13_s485 ... ww117_s49L ww118_s49M ww119_s49N GHC.Types.[] of _ [Occ=Dead] { [] -> GHC.Types.True []; : _ [Occ=Dead] _ [Occ=Dead] -> GHC.Types.False []; }; B.tiny_foo [InlPrag=INLINE[0]] :: A.D -> GHC.Types.Bool [GblId, Arity=1, Str=DmdType , Unf=OtherCon []] = \r srt:SRT:[r47O :-> B.$wtiny_foo] [w_s49R] case w_s49R of _ [Occ=Dead] { A.D ww1_s49T [Occ=Once] ww2_s49U [Occ=Once] ww3_s49V [Occ=Once] ww4_s49W [Occ=Once] ww5_s49X [Occ=Once] ... ww118_s4bM [Occ=Once] ww119_s4bN [Occ=Once] ww120_s4bO [Occ=Once] -> B.$wtiny_foo ww1_s49T ww2_s49U ww3_s49V ww4_s49W ww5_s49X ww6_s49Y ww7_s49Z ww8_s4a0 ww9_s4a1 ww10_s4a2 ww11_s4a3 ww12_s4a4 ww13_s4a5 ww14_s4a6 ww15_s4a7 ww16_s4a8 }}} This causes a lot of 'mov' instructions from heap to stack to be generated at each callsite. In this case it's 9 pages: {{{#!hs $ ghc -c -O2 A.hs && ghc -c -O1 B.hs -ddump-asm -fforce-recomp ... movq %rbx,856(%rbp) movq 880(%rbp),%rbx movq %rbx,864(%rbp) movq 888(%rbp),%rbx movq %rbx,872(%rbp) movq 896(%rbp),%rbx movq %rbx,880(%rbp) movq 904(%rbp),%rbx movq %rbx,888(%rbp) movq %rax,896(%rbp) movq $GHC.Types.[]_closure+1,904(%rbp) addq $-24,%rbp jmp A.$w$cshowsPrec_info }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 13:38:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 13:38:22 -0000 Subject: [GHC] #11565: Restore code to handle '-fmax-worker-args' flag In-Reply-To: <045.9d241621de87bb494a516e9874327ca7@haskell.org> References: <045.9d241621de87bb494a516e9874327ca7@haskell.org> Message-ID: <060.bbac5344b71d45173f2c7cbc9eecde07@haskell.org> #11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, it's bad for worker/wrapper to generate a worker function with a vast number of arguments. Some limit in the worker/wrapper generator would be a Good Thing. Should not be too hard. Unlike the old days, we don't need to trim the strictness signature. In the old days, the strictness signature was used by importing modules to generate an appropriate wrapper; but now the wrapper is conveyed by an ordinary inlining. So there is just one place the choice is made, namely when generating the worker/wrapper split. I can advise if someone wants to try this Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 15:44:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 15:44: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.ecde391a73c29ef9ccd6749b2bda27e1@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Used the following GNUMakefile for '''./synth.bash''' to compare separate processes: {{{ OBJECTS := $(patsubst %.hs,%.o,$(wildcard src/*.hs)) all: $(OBJECTS) src/%.o: src/%.hs ~/dev/git/ghc-perf/inplace/bin/ghc-stage2 -c +RTS -A256M -RTS $< -o $@ clean: $(RM) $(OBJECTS) .PHONY: clean }}} CPU topology: {{{ $ lstopo-no-graphics Machine (30GB) Socket L#0 + L3 L#0 (8192KB) L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 PU L#0 (P#0) PU L#1 (P#4) L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 PU L#2 (P#1) PU L#3 (P#5) L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 PU L#4 (P#2) PU L#5 (P#6) L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 PU L#6 (P#3) PU L#7 (P#7) $ numactl -H available: 1 nodes (0) node 0 cpus: 0 1 2 3 4 5 6 7 node 0 size: 31122 MB node 0 free: 28003 MB node distances: node 0 0: 10 }}} Separate processes: {{{ $ make clean; time make -j1 real 1m2.561s user 0m56.523s sys 0m5.560s $ make clean; time taskset --cpu-list 0-3 make -j4 real 0m18.756s user 1m7.758s sys 0m6.460s $ make clean; time make -j4 real 0m18.936s user 1m7.549s sys 0m6.857s $ make clean; time make -j6 real 0m17.365s user 1m32.107s sys 0m9.155s $ make clean; time make -j8 real 0m15.964s user 1m52.058s sys 0m9.929s }}} The speedup compared to -j1 is almost exactly 4x, but it happens on -j higher than 4 as well. Using CPU affinity makes things better on -j4. {{{ $ ./synth.bash -j1 +RTS -sstderr -A256M -qb0 -RTS real 0m51.702s user 0m50.840s sys 0m0.844s $ ./synth.bash -j4 +RTS -sstderr -A256M -qb0 -RTS real 0m17.526s user 1m6.978s sys 0m1.412s $ ./synth.bash -j4 +RTS -sstderr -A256M -qb0 -qa -RTS real 0m17.007s user 1m4.867s sys 0m1.508s $ ./synth.bash -j8 +RTS -sstderr -A256M -qb0 -RTS real 0m13.829s user 1m44.295s sys 0m2.669s $ ./synth.bash -j8 +RTS -sstderr -A256M -qb0 -qa -RTS real 0m14.597s user 1m43.145s sys 0m3.285s }}} The speedup compared to -j1 is around 3.5x, also happens on -j higher than 4. Using CPU affinity makes things worse on -j4. In absolute times '''ghc --make -j''' is slightly better that separate processes due to less startup(?) overhead. But something else slowly creeps up and we don't see 4x factor. It's more visible on 24-core VM, will post in a few minutes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 16:28:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 16:28:01 -0000 Subject: [GHC] #12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4 In-Reply-To: <047.3cd5b94812ad80cfce971203d7137096@haskell.org> References: <047.3cd5b94812ad80cfce971203d7137096@haskell.org> Message-ID: <062.db86f737a7ff49d8ece2c85f462f5542@haskell.org> #12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4 -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Maybe a consequence of kind and type arguments being treated uniformly in GHC's Core language now? Yes, probably. Writing the kind argument in we get {{{ instance (HasDimension (Proxy * d)) => Demotable (Dimensional Int d) where }}} and now indeed the bit before the arrow doesn't look smaller than the thing after. I think the solution here is to use `UndecideableInstances`. One could wonder about some kind-aware size metric might be better --- but I don't know what it would be. I'm inclined to say "wont-fix"; but if someone has a better size-metric proposal, go propose it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 16:36:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 16:36:01 -0000 Subject: [GHC] #12522: GHC 8.0.1 hangs, looping forever in type-checker In-Reply-To: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> References: <046.7b65bda9390cb2d1644aa94d81bc696e@haskell.org> Message-ID: <061.125fc3d02612d412b1e9744a7a0234b5@haskell.org> #12522: GHC 8.0.1 hangs, looping forever in type-checker -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Surprising. I was expecting that GHC will hang on a black-hole but this indeed looks like an infinite loop in the type checker. I'm afraid Simon or Richard will have to take a look at this. Oh, and `f` need not be a part of a type class. It can be a standalone function with undefined definition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 16:51:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 16:51:07 -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.67c3c5021a56ba65f06431589dd54e33@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): 24-core VM. CPU topology: {{{ $ lstopo-no-graphics Machine (118GB) Package L#0 + L3 L#0 (30MB) L2 L#0 (256KB) + L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 PU L#0 (P#0) PU L#1 (P#1) L2 L#1 (256KB) + L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 PU L#2 (P#2) PU L#3 (P#3) L2 L#2 (256KB) + L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 PU L#4 (P#4) PU L#5 (P#5) L2 L#3 (256KB) + L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 PU L#6 (P#6) PU L#7 (P#7) L2 L#4 (256KB) + L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4 PU L#8 (P#8) PU L#9 (P#9) L2 L#5 (256KB) + L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5 PU L#10 (P#10) PU L#11 (P#11) L2 L#6 (256KB) + L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6 PU L#12 (P#12) PU L#13 (P#13) L2 L#7 (256KB) + L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7 PU L#14 (P#14) PU L#15 (P#15) L2 L#8 (256KB) + L1d L#8 (32KB) + L1i L#8 (32KB) + Core L#8 PU L#16 (P#16) PU L#17 (P#17) L2 L#9 (256KB) + L1d L#9 (32KB) + L1i L#9 (32KB) + Core L#9 PU L#18 (P#18) PU L#19 (P#19) L2 L#10 (256KB) + L1d L#10 (32KB) + L1i L#10 (32KB) + Core L#10 PU L#20 (P#20) PU L#21 (P#21) L2 L#11 (256KB) + L1d L#11 (32KB) + L1i L#11 (32KB) + Core L#11 PU L#22 (P#22) PU L#23 (P#23) $ numactl -H available: 1 nodes (0) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 node 0 size: 120881 MB node 0 free: 120192 MB node distances: node 0 0: 10 }}} (I would not trust numactl output). Separate processes: {{{ $ make clean; time make -j1 real 1m33.147s user 1m20.836s sys 0m11.556s $ make clean; time make -j10 real 0m11.275s user 1m29.800s sys 0m12.856s $ make clean; time make -j12 real 0m10.537s user 1m36.276s sys 0m16.948s $ make clean; time make -j14 real 0m9.117s user 1m39.132s sys 0m18.332s $ make clean; time make -j20 real 0m8.498s user 2m7.064s sys 0m17.912s $ make clean; time make -j22 real 0m7.468s user 2m9.808s sys 0m18.592s $ make clean; time make -j24 real 0m7.336s user 2m15.936s sys 0m19.004s $ make clean; time make -j26 real 0m7.433s user 2m17.612s sys 0m19.648s $ make clean; time make -j28 real 0m7.554s user 2m17.760s sys 0m19.564s $ make clean; time make -j30 real 0m7.563s user 2m16.776s sys 0m21.104s }}} Numbers are jumping slightly from run to run but the gist is best performance is around -j24, not -j12. Single process: {{{ $ ./synth.bash -j1 +RTS -sstderr -A256M -qb0 -RTS real 1m15.214s user 1m14.060s sys 0m0.984s $ ./synth.bash -j8 +RTS -sstderr -A256M -qb0 -RTS real 0m11.275s user 1m21.708s sys 0m2.912s $ ./synth.bash -j10 +RTS -sstderr -A256M -qb0 -RTS real 0m10.279s user 1m25.184s sys 0m3.664s $ ./synth.bash -j12 +RTS -sstderr -A256M -qb0 -RTS real 0m9.605s user 1m32.688s sys 0m4.292s $ ./synth.bash -j14 +RTS -sstderr -A256M -qb0 -RTS real 0m9.144s user 1m40.288s sys 0m4.964s $ ./synth.bash -j16 +RTS -sstderr -A256M -qb0 -RTS real 0m10.003s user 1m51.916s sys 0m6.604s $ ./synth.bash -j20 +RTS -sstderr -A256M -qb0 -RTS real 0m10.215s user 2m7.924s sys 0m8.208s $ ./synth.bash -j22 +RTS -sstderr -A256M -qb0 -RTS real 0m10.483s user 2m13.440s sys 0m10.456s $ ./synth.bash -j24 +RTS -sstderr -A256M -qb0 -RTS real 0m10.985s user 2m18.028s sys 0m10.780s $ ./synth.bash -j32 +RTS -sstderr -A256M -qb0 -RTS real 0m12.636s user 2m32.312s sys 0m14.508s }}} Here we see best numbers around -j12 and those are worse than multiprocess run. From '''perf record''' it's not very clear what happens. I'll try to get a 64-core VM next week and see if the effect will be visible there much better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:18:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:18:58 -0000 Subject: [GHC] #12517: Simplify runghc command line options In-Reply-To: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> References: <047.25090793b7ae3d8bda213d279284c8da@haskell.org> Message-ID: <062.4b5dac923e69a692e981616cc7e07547@haskell.org> #12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Resolution: | Keywords: runghc Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d168c41a231cd92ca993e0bdd621cf554694df1c/ghc" d168c41a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d168c41a231cd92ca993e0bdd621cf554694df1c" Fix and complete runghc documentation Reviewers: austin, thomie, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D2463 GHC Trac Issues: #12517 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:18:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:18:58 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.1725c6a35a7b6913cfa05feac5676ec4@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2473 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a25bf2673d0f6db5f454619ddf91f974cace4e8b/ghc" a25bf267/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a25bf2673d0f6db5f454619ddf91f974cace4e8b" Tag pointers in interpreted constructors Instead of stg_interp_constr_entry there are now 7 functions (one for each value of the tag bits) that tag the constructor pointer before returning. This is consistent with compiled constructors' entry code, and expectations that compiled code places on compiled constructors. The iserv protocol is extended with an extra field that explains what pointer tag the constructor should use. Test Plan: Added tests for #12523 Reviewers: erikd, bgamari, hvr, austin, simonmar Reviewed By: simonmar Subscribers: osa1, thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D2473 GHC Trac Issues: #12523 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:18:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:18:58 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.797dd726f671742c99d3a6e3ed8b7a6e@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2ee1db60ab29258fa9f8ab820f778bd0bb7f87a4/ghc" 2ee1db60/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2ee1db60ab29258fa9f8ab820f778bd0bb7f87a4" Fixes #12504: Double-escape paths used to build call to hsc_line In outHsLine, paths passed to construct invocations of hsc_line must be escaped twice in order to generate a properly escaped string literal that will end up in the eventual LINE pragma emitted by this code. This is especially important on Windows paths, where backslashes would otherwise be treated as C escape sequences and result in the incorrect Windows paths. Adds test case to verify that hsc2hs properly escapes file paths in LINE pragmas Updates the hsc2hs submodule. See https://ghc.haskell.org/trac/ghc/ticket/12504 Reviewers: erikd, hvr, austin, bgamari, Phyx Reviewed By: erikd, Phyx Subscribers: thomie, Phyx, mpickering Differential Revision: https://phabricator.haskell.org/D2478 GHC Trac Issues: #12504 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:18:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:18:58 -0000 Subject: [GHC] #12491: ghc-iserv pattern match failure with no command line arguments In-Reply-To: <044.f85efc3f55eac6e07bb4aa316e8edafc@haskell.org> References: <044.f85efc3f55eac6e07bb4aa316e8edafc@haskell.org> Message-ID: <059.dfccdf216713191e420aa784c13164d3@haskell.org> #12491: ghc-iserv pattern match failure with no command line arguments -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2494 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3005fa5313b6d5fd9d4f47192c84e96e94ee7f17/ghc" 3005fa53/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3005fa5313b6d5fd9d4f47192c84e96e94ee7f17" iserv: Show usage message on argument parse failure Test Plan: validate Reviewers: simonmar, erikd, austin Reviewed By: simonmar, erikd Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2494 GHC Trac Issues: #12491 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:18:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:18:58 -0000 Subject: [GHC] #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' In-Reply-To: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> References: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> Message-ID: <061.ba3fb25e881dd7d8eb7652ebc923b30a@haskell.org> #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2492 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0e7492508cefbcabb4cf1398cfb3669edb72db77/ghc" 0e749250/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e7492508cefbcabb4cf1398cfb3669edb72db77" GHC: Expose installSignalHandlers, withCleanupSession Test Plan: Validate Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2492 GHC Trac Issues: #12398 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:18:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:18:58 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.4082dceebd98d9ee4e29348de2a9335d@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d40d6df74a9fca382a84709ac9bc862897fbec18/ghc" d40d6df7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d40d6df74a9fca382a84709ac9bc862897fbec18" StgCmmPrim: Add missing MO_WriteBarrier Test Plan: Good question Reviewers: austin, trommler, simonmar, rrnewton Reviewed By: simonmar Subscribers: RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D2495 GHC Trac Issues: #12469 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:28:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:28:39 -0000 Subject: [GHC] #12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4 In-Reply-To: <047.3cd5b94812ad80cfce971203d7137096@haskell.org> References: <047.3cd5b94812ad80cfce971203d7137096@haskell.org> Message-ID: <062.6c254c85aacc2946c770aff776f2b219@haskell.org> #12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4 -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmcclean): Won't-fix is fine by me. I reported it because I had no idea what was going on and was surprised by the change. In the intervening time we have changed our approach to this part of the code anyway, and as it happens the new code works on GHC 8 without UndecidableInstances anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:29:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:29:26 -0000 Subject: [GHC] #12523: Constructor info tables generated by GHCi don't return tagged pointers In-Reply-To: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> References: <044.e2ab603cd1bb8878339753619a2f3cbb@haskell.org> Message-ID: <059.836de992da81ed2cac281bd0b6c214b7@haskell.org> #12523: Constructor info tables generated by GHCi don't return tagged pointers -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2473 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * version: 8.1 => 7.10.3 * milestone: => 8.0.2 Comment: I suppose we should probably merge this for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:29:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:29:31 -0000 Subject: [GHC] #12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4 In-Reply-To: <047.3cd5b94812ad80cfce971203d7137096@haskell.org> References: <047.3cd5b94812ad80cfce971203d7137096@haskell.org> Message-ID: <062.95cc219993a154315cca16e5dd1c818b@haskell.org> #12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4 -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmcclean): I forgot to add: Thanks very much for investigating this, it's good to know what the cause was. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:30:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:30:17 -0000 Subject: [GHC] #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths In-Reply-To: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> References: <044.0a82e13c70e52fb228d45baee8a94879@haskell.org> Message-ID: <059.edb480d2b7c6e2b9529ffb80a68c6533@haskell.org> #12504: Windows: Using hsc2hs in combination with inline-c generates the .c files with invalid paths -------------------------------------+------------------------------------- Reporter: rcook | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | /testsuite/tests/hsc2hs/T12504/path/to/T12504.hsc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:30:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:30:37 -0000 Subject: [GHC] #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' In-Reply-To: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> References: <046.ae05c9ccdd84834d5d2d4568141d97f7@haskell.org> Message-ID: <061.748c9bf63f564ad210557aada343cd50@haskell.org> #12398: Expose 'withCleanupSession' as a replacement for 'defaultCleanupHandler' -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2492 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:32:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:32:07 -0000 Subject: [GHC] #12491: ghc-iserv pattern match failure with no command line arguments In-Reply-To: <044.f85efc3f55eac6e07bb4aa316e8edafc@haskell.org> References: <044.f85efc3f55eac6e07bb4aa316e8edafc@haskell.org> Message-ID: <059.a10aa333e60ced5d53ca9e7a47ec4dfa@haskell.org> #12491: ghc-iserv pattern match failure with no command line arguments -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2494 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:32:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:32:41 -0000 Subject: [GHC] #12469: Memory fence on writeIORef missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.f4ffd5b953bb3ecbb9d55f212e24aa0f@haskell.org> #12469: Memory fence on writeIORef missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: memory model Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: 8.2.1 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:34:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:34:35 -0000 Subject: [GHC] #12556: `stimes` adds extra power to Semigroup Message-ID: <051.3e20872f4a86540267ac1fdaeb10ec66@haskell.org> #12556: `stimes` adds extra power to Semigroup -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ ghci> stimes 0 (undefined :: [_]) [] }}} ghci> stimes 0 undefined () }}} makes it seem like `stimes 0` has some knowledge about `mempty` from `Monoid` but it has the following type {{{#!hs stimes 0 :: Semigroup a => a -> a }}} Desired behaviour? Given that type (assuming it only has the power of `<>`) I would have assumed this behaviour {{{ ghci> data L a = N | C a (L a) deriving Show ghci> instance Semigroup (L a) where (<>) = undefined ghci| ghci> stimes 0 (undefined :: L _) *** Exception: stimes: positive multiplier expected }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:34:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:34:48 -0000 Subject: [GHC] #12556: `stimes` adds extra power to Semigroup In-Reply-To: <051.3e20872f4a86540267ac1fdaeb10ec66@haskell.org> References: <051.3e20872f4a86540267ac1fdaeb10ec66@haskell.org> Message-ID: <066.ad5cec437ee467818614ccdab8abe79b@haskell.org> #12556: `stimes` adds extra power to Semigroup -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -4,1 +4,1 @@ - }}} + New description: {{{ ghci> stimes 0 (undefined :: [_]) [] ghci> stimes 0 undefined () }}} makes it seem like `stimes 0` has some knowledge about `mempty` from `Monoid` but it has the following type {{{#!hs stimes 0 :: Semigroup a => a -> a }}} Desired behaviour? Given that type (assuming it only has the power of `<>`) I would have assumed this behaviour {{{ ghci> data L a = N | C a (L a) deriving Show ghci> instance Semigroup (L a) where (<>) = undefined ghci| ghci> stimes 0 (undefined :: L _) *** Exception: stimes: positive multiplier expected }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:42:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:42:31 -0000 Subject: [GHC] #12557: Regression in type inference with RankNTypes Message-ID: <047.4bdc475feed13546a7e6196f2864da81@haskell.org> #12557: Regression in type inference with RankNTypes -------------------------------------+------------------------------------- Reporter: slindley | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs foo :: ((forall a.f a) -> f r) -> f r foo g = undefined }}} In GHC 7.10.3: {{{ *Main> :t \g -> foo g \g -> foo g :: ((forall a. f a) -> f r) -> f r }}} In GHC 8.0.1: {{{ *Main> :t \g -> foo g :1:11: error: • Couldn't match expected type ‘(forall a. f a) -> f r’ with actual type ‘t’ ‘t’ is a rigid type variable bound by the inferred type of it :: t -> f r at :1:1 • In the first argument of ‘foo’, namely ‘g’ In the expression: foo g In the expression: \ g -> foo g • Relevant bindings include g :: t (bound at :1:2) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 17:46:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 17:46:15 -0000 Subject: [GHC] #12076: "lazy" leads to undefined reference to `stg_ap_0_upd_info' In-Reply-To: <045.45bfd5a6dee62b13780515de863d4289@haskell.org> References: <045.45bfd5a6dee62b13780515de863d4289@haskell.org> Message-ID: <060.727341fdae5783ed04490107f2c47e27@haskell.org> #12076: "lazy" leads to undefined reference to `stg_ap_0_upd_info' -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2309 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge Comment: Phab:D2471 fixes a performance regression in the `binary-tree` nofib test introduced by comment:6. It was merged to `master` as 83b326cda759cfd4c538595cf38ee23eb81a4c76. It should likely be merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 18:02:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 18:02:02 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures (was: Testsuite exibits large amount of framework failures) In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.09f9038a129ac3ce6a0ee79aacfaeb7a@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 18:20:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 18:20:16 -0000 Subject: [GHC] #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure In-Reply-To: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> References: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> Message-ID: <064.b74d738b0440c1ceda8eaa34bf2e1beb@haskell.org> #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2499 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2499 * milestone: => 8.0.2 Comment: My original concern was that we wouldn't have a environment handy in the renamer to lookup which binding should be used for `return`. As it turns out this concern was ill-founded. I have a fix in Phab:D2499. Happily I think it's even simple enough to include in 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 18:29:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 18:29:18 -0000 Subject: [GHC] #12206: No exposed API to get full text of ErrMsg In-Reply-To: <042.f7207806b1b651d6481b5d2408abd0fe@haskell.org> References: <042.f7207806b1b651d6481b5d2408abd0fe@haskell.org> Message-ID: <057.1874657d28bcfe596ce237283fe603df@haskell.org> #12206: No exposed API to get full text of ErrMsg -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2491 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2d220263f6e5f49139f5571b7a5bc1649cb9ac8c/ghc" 2d22026/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2d220263f6e5f49139f5571b7a5bc1649cb9ac8c" ErrUtils: Expose accessors of ErrDoc and ErrMsg Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2491 GHC Trac Issues: #12206 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 18:29:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 18:29:18 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.c44402a7590a48d41b4d2893058b5b7f@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2450 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a07a3ffa3efda6f7ebe68841e15ef89ac0d313b1/ghc" a07a3ffa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a07a3ffa3efda6f7ebe68841e15ef89ac0d313b1" A failing testcase for T12485 Test Plan: it's just a testcase Reviewers: ezyang, simonmar, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2450 GHC Trac Issues: #12485 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 18:29:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 18:29:18 -0000 Subject: [GHC] #12091: 'Variable not in scope" when using GHCi with `-fobject-code` In-Reply-To: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> References: <045.26ac03692a5d3a787c09461db77dd610@haskell.org> Message-ID: <060.0a62ea3c58cc339ecd1177ff793ca593@haskell.org> #12091: 'Variable not in scope" when using GHCi with `-fobject-code` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7253 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"22259c17c5e3043e5fa5b354f339f9b0d66167db/ghc" 22259c17/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="22259c17c5e3043e5fa5b354f339f9b0d66167db" testsuite: Failing testcase for #12091 Just as it says on the can Test Plan: validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2489 GHC Trac Issues: #12091 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 18:30:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 18:30:14 -0000 Subject: [GHC] #12206: No exposed API to get full text of ErrMsg In-Reply-To: <042.f7207806b1b651d6481b5d2408abd0fe@haskell.org> References: <042.f7207806b1b651d6481b5d2408abd0fe@haskell.org> Message-ID: <057.12390225dd69b6b28d4d6d08e63b0fd3@haskell.org> #12206: No exposed API to get full text of ErrMsg -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2491 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:01:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:01:15 -0000 Subject: [GHC] #12358: Read1/Read2 don't have methods defined in terms of ReadPrec In-Reply-To: <050.f17a87cdce0c0bbe442c6db7afeec481@haskell.org> References: <050.f17a87cdce0c0bbe442c6db7afeec481@haskell.org> Message-ID: <065.732a4d5fd2a9cbb367deb63cb3fb21d8@haskell.org> #12358: Read1/Read2 don't have methods defined in terms of ReadPrec -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2379 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9cfef167dc0b2bfa881c5d9eca38227fbdfd507c/ghc" 9cfef16/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9cfef167dc0b2bfa881c5d9eca38227fbdfd507c" Add Read1/Read2 methods defined in terms of ReadPrec This adds new methods `liftReadList(2)` and `liftReadListPrec(2)` to the `Read1`/`Read2` classes which are defined in terms of `ReadPrec` instead of `ReadS`. This also adds related combinators and changes existing `Read1` and `Read2` instances to be defined in terms of the new methods. Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2379 GHC Trac Issues: #12358 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:01:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:01:15 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.3f873113731f5519ef71eca0c440c0d8@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------- Reporter: jcristovao | Owner: ak3n Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2461 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1ad770f599a00e8f8919f7fcf4cf00800fd4d9ed/ghc" 1ad770f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1ad770f599a00e8f8919f7fcf4cf00800fd4d9ed" Add -flocal-ghci-history flag (#9089). Reviewers: thomie, bgamari, austin Reviewed By: thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2461 GHC Trac Issues: #9089 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:01:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:01:47 -0000 Subject: [GHC] #9089: Local .ghci_history In-Reply-To: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> References: <049.c5741f16d88f0d6e479f942cb828ac24@haskell.org> Message-ID: <064.23ef98accb8aec4ebe7de92a92353879@haskell.org> #9089: Local .ghci_history -------------------------------------+------------------------------------- Reporter: jcristovao | Owner: ak3n Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2461 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:03:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:03:08 -0000 Subject: [GHC] #12358: Read1/Read2 don't have methods defined in terms of ReadPrec In-Reply-To: <050.f17a87cdce0c0bbe442c6db7afeec481@haskell.org> References: <050.f17a87cdce0c0bbe442c6db7afeec481@haskell.org> Message-ID: <065.3e015a0a2e36044d79e6ba68d7a65bb8@haskell.org> #12358: Read1/Read2 don't have methods defined in terms of ReadPrec -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2379 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Ryan, is this something you would like to have in 8.0.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:04:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:04:14 -0000 Subject: [GHC] #12358: Read1/Read2 don't have methods defined in terms of ReadPrec In-Reply-To: <050.f17a87cdce0c0bbe442c6db7afeec481@haskell.org> References: <050.f17a87cdce0c0bbe442c6db7afeec481@haskell.org> Message-ID: <065.e634918415d23d55ccd2dc0fda684c0a@haskell.org> #12358: Read1/Read2 don't have methods defined in terms of ReadPrec -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2379 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): No, this can wait until 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:21:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:21:59 -0000 Subject: [GHC] #12558: GHCi Segmentation fault/access violation in generated code Message-ID: <044.674cfd9113ce879b5a603d01c0e07d10@haskell.org> #12558: GHCi Segmentation fault/access violation in generated code ------------------------------+------------------------------- Reporter: lazac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------+------------------------------- GHCi crashes with the error message `Segmentation fault/access violation in generated code`. The problem arises when trying to use the [https://github.com/haskell-tools/haskell-tools Haskell Tools project] from GHCi. The program can be successfully compiled with the ghc compiler. The cause of this behavior is that there are elements thats type is computed by a type family application. When I changed the representation to eliminate these, the problem was gone. I can turn the problem on and off only by adding an import or removing it. To solve the problem simply comment out the modules that use the information with the complex calculated type, as done in the attached diff. To try out use a minimal program: {{{#!hs module Main where import Language.Haskell.Tools.Refactor main = demoRefactor "" "." "A" }}} Execute the `ghci -package ghc -isrc\ast;src\ast-ghc;sr c\ast-trf;src\ast-ppr;src\ast-gen;src\refactor;src Main` command from the project root. That will search for a simple `A.hs` file in the working directory. A minimalistic module is enough to trigger the problem: {{{#!hs module A where }}} PS: I tried to create a smaller example, but the problem just appears and disappears without "reason" when I try to modify the code. (For example importing a module that is not actually used.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:22:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:22:48 -0000 Subject: [GHC] #12558: GHCi Segmentation fault/access violation in generated code In-Reply-To: <044.674cfd9113ce879b5a603d01c0e07d10@haskell.org> References: <044.674cfd9113ce879b5a603d01c0e07d10@haskell.org> Message-ID: <059.e876d22eee7cbc0131d40624d901beaa@haskell.org> #12558: GHCi Segmentation fault/access violation in generated code -------------------------------+----------------------------- Reporter: lazac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+----------------------------- Changes (by lazac): * Attachment "ghci" added. A diff for the Haskell Tools project that hides the problem -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:24:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:24:27 -0000 Subject: [GHC] #12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4 In-Reply-To: <047.3cd5b94812ad80cfce971203d7137096@haskell.org> References: <047.3cd5b94812ad80cfce971203d7137096@haskell.org> Message-ID: <062.7f1abcf7bc44c25d35b076a77d46f477@haskell.org> #12040: Code that builds on 7.8.4 and 7.10.3 but fails with requiring UndecidableInstances on 8.0.1-rc4 -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: OK -- thanks for raising it though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:31:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:31:02 -0000 Subject: [GHC] #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" In-Reply-To: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> References: <045.975f9511f81812044ea05b78c5c3a0b0@haskell.org> Message-ID: <060.4fbf7f5eec89c70569b7ebec88d0b10e@haskell.org> #12209: Windows: ByteCodeLink can't find labels "lseek" and "write" -------------------------------------+------------------------------------- Reporter: thomie | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: duplicate | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12497 | Differential Rev(s): Phab:D2478 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => duplicate Comment: Let's close this as a duplicate of #12497. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:35:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:35:21 -0000 Subject: [GHC] #11819: Full validation issues for 8.0.1 In-Reply-To: <046.98f1b24d795b2e584c0708ff1e99ff8b@haskell.org> References: <046.98f1b24d795b2e584c0708ff1e99ff8b@haskell.org> Message-ID: <061.1bd944c94c690832591f535e1d3b0c77@haskell.org> #11819: Full validation issues for 8.0.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: highest => high Comment: The commit mentioned in comment:1 has been merged to `ghc-8.0` as a8d0d3eb1e978276b19e4918ec4315f3fd62e0bb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:49:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:49:54 -0000 Subject: [GHC] #12497: Make runtime linker be able to find POSIX functions under their deprecated name. In-Reply-To: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> References: <044.8e1d54783453ea140ec8b110a61bc5b0@haskell.org> Message-ID: <059.c7763274f0a771ae82148b64a934dadf@haskell.org> #12497: Make runtime linker be able to find POSIX functions under their deprecated name. -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12209 | Differential Rev(s): Phab:D2500 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * differential: Phab:D2478 => Phab:D2500 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 19:56:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 19:56:09 -0000 Subject: [GHC] #12521: Thread blocked indefinitely in an MVar operation In-Reply-To: <053.f0da307ad87f1df98e8d5b92884f7e14@haskell.org> References: <053.f0da307ad87f1df98e8d5b92884f7e14@haskell.org> Message-ID: <068.4cb7100a1e6a4c2bdf5ad30ac4960156@haskell.org> #12521: Thread blocked indefinitely in an MVar operation -----------------------------------+-------------------------------------- Reporter: SwiftsNamesake | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by thomie): * os: Unknown/Multiple => Windows Comment: Ok, thank you for the report. If you can reproduce the bug reliably, please let us know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 20:35:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 20:35:08 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.5dc4761f0cdba5aba805a7301e8adc91@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): Phab:D2498 #10100, #10183, #11370 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e9b0bf4ed52114852dbaf6af556514610a895f88/ghc" e9b0bf4e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e9b0bf4ed52114852dbaf6af556514610a895f88" Remove redundant-constraints from -Wall (#10635) Removes -Wredundant-constraints from -Wall, as per the discussion in #10635. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2498 GHC Trac Issues: #10635 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 20:35:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 20:35:08 -0000 Subject: [GHC] #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes In-Reply-To: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> References: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> Message-ID: <064.1b08e96bf49aab1b9b3cfe2bd97c9799@haskell.org> #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ak3n Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10569, #12156, | Differential Rev(s): Phab:D2458 #12406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"75321ffa25ad377fa200485a7d58ad32a87e7d65/ghc" 75321ff/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="75321ffa25ad377fa200485a7d58ad32a87e7d65" Add -fdefer-out-of-scope-variables flag (#12170). Reviewers: simonpj, thomie, austin, bgamari Reviewed By: simonpj, thomie, bgamari Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2458 GHC Trac Issues: #12170 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 20:35:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 20:35:08 -0000 Subject: [GHC] #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure In-Reply-To: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> References: <049.baac46a8af63fc065f6c4c6a1b6f66dc@haskell.org> Message-ID: <064.917a8c6a1adbb6ae533c9b44cd5306fe@haskell.org> #12490: With RebindableSyntax, ApplicativeDo should eliminate return/pure -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2499 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"043604c7232adb698d5008a46d3f29d532acd12d/ghc" 043604c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="043604c7232adb698d5008a46d3f29d532acd12d" RnExpr: Fix ApplicativeDo desugaring with RebindableSyntax We need to compare against the local return and pure, not returnMName and pureAName. Fixes #12490. Test Plan: Validate, add testcase Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2499 GHC Trac Issues: #12490 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 20:37:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 20:37:03 -0000 Subject: [GHC] #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes In-Reply-To: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> References: <049.73087dc6a5aa1aa799f9994d0d1022ff@haskell.org> Message-ID: <064.2ee19be53a10cfb51da05291b30d0a70@haskell.org> #12170: Add flag to control whether out of scope variables should be deferred with -fdefer-typed-holes -------------------------------------+------------------------------------- Reporter: mpickering | Owner: ak3n Type: feature request | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10569, #12156, | Differential Rev(s): Phab:D2458 #12406 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.0.2 Comment: Alright, we can include this in 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 21:02:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 21:02:05 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.fa7cd23ce535a608aca2605d2207ad3a@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 11698 | Blocking: Related Tickets: | Differential Rev(s): Phab:D2104 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Facundo, I noticed that there is an entry for this feature in the 8.0.2 release notes on `master` but the patch is not present on the `ghc-8.0` branch. Did you expect this to go into 8.0.2? While the patch applies fairly easily its size, even if it mostly touches static pointers code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 21:25:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 21:25:22 -0000 Subject: [GHC] #12356: StaticPointers support in GHCi In-Reply-To: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> References: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> Message-ID: <061.8b2f093421521d3490f1c94034a80b06@haskell.org> #12356: StaticPointers support in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12000, #9878 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #12000 => #12000, #9878 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 31 21:47:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Aug 2016 21:47:34 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.c17aae2ceee22bd19a27f28723caa910@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Rev(s): D2502 Wiki Page: | -------------------------------------+------------------------------------- Changes (by prokhorenkov): * differential: => D2502 Comment: May I interest you all with a really ''newcomer-grade'' change? We can just generate "compare" and "<" as usual and express other relations through "<". Like {{{ a > b = b < a a <= b = not $ b < a a >= b = not $ a < b }}} This saves us code for 3 methods out of 5 for a small added cost of extra negation. When the code for "<" is short enough the inliner would make the code as good as can be. Otherwise added negation would be insignificant. Adding new differential rev with the proposed changes. -- Ticket URL: GHC The Glasgow Haskell Compiler