February 2018 - ghc-tickets

[GHC] #14805: Allow disabling warnings on a per-block of code basis
by GHC 13 Feb '18

13 Feb '18

#14805: Allow disabling warnings on a per-block of code basis -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 developers frequently want to disable a warning, but not for their whole project. Right now the only way to do that is on a per-file basis. This isn't ideal, because it's a pretty broad brush for what is often a warning you only want to disable in one place. The way other compilers solve this is by allowing you to ignore warnings only between two lines in the code. Here's Clang and GCC: {{{ #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wunused-variable" int a; #pragma clang diagnostic pop }}} {{{ #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wunused-result" write(foo, bar, baz); #pragma GCC diagnostic pop }}} Examples of warnings people may want to ignore only in a certain location: In [https://github.com/yesodweb/yesod/blob/f2b651b69537985c5a2ca378018fd50537c3… /yesod-core/Yesod/Core.hs#L5 yesod-core/yesod/Core.hs], deprecation warnings are disabled for the whole file, but it's not clear what deprecations are trying to be avoided. It's possible that code is no longer relevant. The tests for the `yesod-test` package test a function that yesod-test has deprecated, but still wants to test. Because of this, [https://github.com/yesodweb/yesod/blob/f2b651b69537985c5a2ca378018fd50537c3… /yesod-test/test/main.hs#L1-L2 it ignores all deprecation warnings], when it could be only ignoring them for a few lines. It's pretty easy to find examples of this; just search a repo for `{-# OPTIONS_GHC -fno` and you'll probably find cases where warnings are disabled in a more broad way than is necessary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14805> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14801: Multiple error messages confusing.
by GHC 13 Feb '18

13 Feb '18

#14801: Multiple error messages confusing. -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- More often than not, ghc reports very confusing errors when you use an undefined (lens) variable. The problem is that an undefined identifier generates subsequent type errors, and some of these type errors might be reported before the undefined message. When the error list has hundreds of messages it can be very time consuming to find the real error. Please add an error reporting mode that does not report type errors when there are undefined variables. Here's a sample message: {{{ tests/OneDUram.hs:160:5: error: • Couldn't match type ‘(Vec NumRegFiles (DelayReg.DelayReg 2 OneDUValues) -> f0 (Vec NumRegFiles (DelayReg.DelayReg 2 OneDUValues))) -> OneDUState -> f0 OneDUState’ with ‘Vec n1 a0’ Expected type: Vec n1 a0 Actual type: LensLike' f0 OneDUState (Vec NumRegFiles (DelayReg.DelayReg 2 OneDUValues)) • Probable cause: ‘osRegFileBP’ is applied to too few arguments In the first argument of ‘(^.)’, namely ‘osRegFileBP’ In the first argument of ‘(.~)’, namely ‘osRegFileBP ^. ix 0 . atDelay 1’ In the second argument of ‘(&)’, namely ‘osRegFileBP ^. ix 0 . atDelay 1 .~ fromList (mkTensor val "r0" [8])’ | 160 | & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8]) | ^^^^^^^^^^^ tests/OneDUram.hs:160:23: error: Variable not in scope: atDelay :: Integer -> (LensLike f OneDUState OneDUState b0 (Vec n0 OneDUValue) -> Constant (LensLike f OneDUState OneDUState b0 (Vec n0 OneDUValue)) b'0) -> a0 -> Constant (LensLike f OneDUState OneDUState b0 (Vec n0 OneDUValue)) a0 | 160 | & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8]) | ^^^^^^^ tests/OneDUram.hs:160:36: error: • No instance for (GHC.TypeNats.KnownNat n0) arising from a use of ‘fromList’ • In the second argument of ‘(.~)’, namely ‘fromList (mkTensor val "r0" [8])’ In the second argument of ‘(&)’, namely ‘osRegFileBP ^. ix 0 . atDelay 1 .~ fromList (mkTensor val "r0" [8])’ In the expression: oneDU & osDbgInstrs .~ Just instrs2 & osRegFileBP ^. ix 0 . atDelay 1 .~ fromList (mkTensor val "r0" [8]) | 160 | & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8]) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I only want to see the second message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14801> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14803: Panic during desugaring I think
by GHC 13 Feb '18

13 Feb '18

#14803: Panic during desugaring I think --------------------------------------+--------------------------------- Reporter: justus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: --------------------------------------+--------------------------------- This is the panic message itself {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-apple-darwin): mkOneConFull: Not TyConApp: bndType_aeGK Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/deSugar/Check.hs:976:30 in ghc:Check }}} And these are the options I use to compile: - {{{-Wall}}} - {{{-Wall}}} - {{{-Wcompat}}} - {{{-Wincomplete-record-updates}}} - {{{-Wincomplete-uni-patterns}}} - {{{-Wredundant-constraints}}} This is the file I am trying to compile [https://github.com/ohua-dev/ohua- core/blob/master/src/Ohua/ALang/Passes.hs]. Unfortunately the error message tells me very little about where the error actually occurs, but the {{{bndType}}} variables are generally used in the family of {{{AExpr}}} types defined here [https://github.com/ohua-dev /ohua-core/blob/master/src/Ohua/ALang/Lang.hs#L141]. To get the power of {{{recursion-schemes}}} all expression types are implemented on a variation of the base functor {{{AExprF}}} and then {{{newtype}}}s are used to create individual expression types. If anyone has an idea as to how I could create a minimal example for you guys feel free to tell me and I'll see what I can do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14803> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14802: panic! (the 'impossible' happened)
by GHC 13 Feb '18

13 Feb '18

#14802: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Debugging) | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was debugging and tried to print a matrix but got the following error message: <interactive>:34:21: error:<interactive>: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: a1_IhXR[rt] Has this been fixed in the newer version of ghc? If so, what's the fastest way to update? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14802> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14776: Add equality rule for `eqString`
by GHC 13 Feb '18

13 Feb '18

#14776: Add equality rule for `eqString` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Locally I sometimes have to define a rule {{{ {-# RULES "eqStringEQ" forall x . eqString x x = True #-} }}} in order for "stuck" expressions to evaluate to `True` and for a case expression to be eliminated. Is there is a reason not to include this RULE directly in GHC.Base? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 13 Feb '18

13 Feb '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: merge Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4325 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5889: -fno-prof-count-entries leads to linking errors
by GHC 13 Feb '18

13 Feb '18

#5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4325 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan <omeragacan@…>): In [changeset:"5957405808fe89e9b108dc0bc3cf4b56aec37775/ghc" 5957405/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5957405808fe89e9b108dc0bc3cf4b56aec37775" Collect CCs in CorePrep, including CCs in unfoldings This patch includes two changes: 1. Move cost centre collection from `SCCfinal` to `CorePrep`, to be able to collect cost centres in unfoldings. `CorePrep` drops unfoldings, so that's the latest stage in the compilation pipeline for this. After this change `SCCfinal` no longer collects all cost centres, but it still generates & collects CAF cost centres + updates cost centre stacks of `StgRhsClosure` and `StgRhsCon`s. This fixes #5889. 2. Initialize cost centre stack fields of `StgRhs` in `coreToStg`. With this we no longer need to update cost centre stack fields in `SCCfinal`, so that module is removed. Cost centre initialization explained in Note [Cost-centre initialization plan]. Because with -fcaf-all we need to attach a new cost-centre to each CAF, `coreTopBindToStg` now returns `CollectedCCs`. Test Plan: validate Reviewers: simonpj, bgamari, simonmar Reviewed By: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #5889 Differential Revision: https://phabricator.haskell.org/D4325 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5889#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14781: Incorrect CPU core counts in virtualized environments
by GHC 12 Feb '18

12 Feb '18

#14781: Incorrect CPU core counts in virtualized environments -------------------------------------+------------------------------------- Reporter: rtfeldman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.2 Libraries | 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: -------------------------------------+------------------------------------- To reproduce this bug: 1. Write a program that prints `numCapabilities` (the # of CPU cores the program thinks are available for parallelization) to stdout 2. Run this program in a virtualized environment such as Travis CI to see what it prints Expected output: it prints the number of CPU cores available to the process, which in the case of Travis's virtualized environment is 2. Actual output: it prints the number of *physical* cores on the machine, which in the case of Travis's servers is 32. The real-world consequences of this bug manifest for the compiler for the Elm programming language, which is written in Haskell and compiled with GHC. By default, `elm-make` runs extremely slowly on Travis and Circle CI because it's trying to parallelize across 32 cores when only 2 are actually available to it. For a proof-of-concept for how to correctly detect the number of available cores (as opposed to physical), here is the source code to a Rust library which does so correctly: https://github.com/seanmonstar/num_cpus/blob/master/src/lib.rs - the library distinguishes between "number of CPUs" and "number of physical CPUs," and on Travis it correctly reports 2 for CPUs and 32 for physical. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14781> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14800: -Wincomplete-uni-patterns should not warn about explicitly-marked irrefutable patterns
by GHC 12 Feb '18

12 Feb '18

#14800: -Wincomplete-uni-patterns should not warn about explicitly-marked irrefutable patterns -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 very useful to catch accidentally partial uni-pattern matches: Cons x = someVal However, we explicitly want an irrefutable pattern match: Vector2 0 y = Vector2 0 a `op` Vector2 0 b In this case, it would be really useful to opt out of the warning via: ~(Vector2 0 y) = ... The fact the match is partial is explicit and visible with the ~ syntax, so the warning shouldn't tell us about it. Right now this warning rules out this useful way of opting in to partiality. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14800> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 12 Feb '18

12 Feb '18

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.6.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, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508, DeterministicBuilds | Phab:D4388 -------------------------------------+------------------------------------- Comment (by shlevy): D4388 chips away at more of this, by removing non-determinism in cost centre symbol names (which caused linking errors when doing distributed builds with nix). A unique was replaced with a 0-based index that increments in source location order for a given module, cost centre name, and cost centre type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0