September 2016 - ghc-tickets

[GHC] #10536: Clear up how to turn off dynamic linking in build.mk
by GHC 26 Mar '18

26 Mar '18

#10536: Clear up how to turn off dynamic linking in build.mk -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See https://mail.haskell.org/pipermail/ghc-devs/2014-December/007725.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10536> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11188: Confusing "parse error in pattern" for missing indentation.
by GHC 26 Mar '18

26 Mar '18

#11188: Confusing "parse error in pattern" for missing indentation. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following problem exists at least in ghc 7.4.2 through 7.10.1: {{{#!hs main = do putStrLn "Hello, lots of crap" $ do a <- return 3 -- The following line is mis-indented, the error is incomprehensible c <- do return 5 }}} Error: {{{ <file>:2:3: Parse error in pattern: putStrLn Possibly caused by a missing 'do'? }}} The hint about "missing do" exists from ghc 7.8, but is wrong in this case. Problematic about this bug is that the wrong indentation can be arbitrary many lines from where ghc reports the (totally incomprehensible) error. My original problem is to find the syntax error here: {{{#!hs -- | Type check a function clause. checkClause :: Type -> A.SpineClause -> TCM Clause checkClause t c(a)(A.Clause (A.SpineLHS i x aps withPats) rhs0 wh) = do unless (null withPats) $ do typeError $ UnexpectedWithPatterns withPats traceCall (CheckClause t c) $ do aps <- expandPatternSynonyms aps checkLeftHandSide (CheckPatternShadowing c) (Just x) aps t $ \ (LHSResult delta ps trhs perm) -> do -- Note that we might now be in irrelevant context, -- in case checkLeftHandSide walked over an irrelevant projection pattern. -- As we will be type-checking the @rhs@ in @delta@, but the final -- body should have bindings in the order of the pattern variables, -- we need to apply the permutation to the checked rhs @v@. let mkBody v = foldr (\ x t -> Bind $ Abs x t) b xs where b = Body $ applySubst (renamingR perm) v xs = [ stringToArgName $ "h" ++ show n | n <- [0..permRange perm - 1] ] -- introduce trailing implicits for checking the where decls TelV htel t0 <- telViewUpTo' (-1) (not . visible) $ unArg trhs (body, with) <- do let n = size htel addCtxTel htel $ checkWhere (size delta + n) wh $ -- for the body, we remove the implicits again escapeContext n $ handleRHS aps (unArgs trhs) rhs0 escapeContext (size delta) $ checkWithFunction with reportSDoc "tc.lhs.top" 10 $ escapeContext (size delta) $ vcat [ text "Clause before translation:" , nest 2 $ vcat [ text "delta =" <+> prettyTCM delta , text "perm =" <+> text (show perm) , text "ps =" <+> text (show ps) , text "body =" <+> text (show body) , text "body =" <+> prettyTCM body ] ] return $ Clause { clauseRange = getRange i , clauseTel = killRange delta , clausePerm = perm , namedClausePats = ps , clauseBody = body , clauseType = Just trhs } }}} {{{ src/full/Agda/TypeChecking/Rules/Def.hs:328:5: Parse error in pattern: checkLeftHandSide Possibly caused by a missing 'do'? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11472: Remove CallStack CPP guards in GHC 8.2
by GHC 19 Mar '18

19 Mar '18

#11472: Remove CallStack CPP guards in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 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 7.10.1 didn't support `CallStack`, while its successors did. Yet in post-8.0 `master` (which needs to be buildable with the 7.10 series, including 7.10.1) references to CallStack have begun to sneak in to GHC. The first instance of this was 9d33adb6f352ad4e488067a8756928b3778920e0 but there will likely be more. I've fixed in this instance in Phab:D1812 by adding `#if` guards. These should be removed in GHC 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11472> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12517: Simplify runghc command line options
by GHC 19 Mar '18

19 Mar '18

#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=<arg>` 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=<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: <http://ghc.haskell.org/trac/ghc/ticket/12517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #12498: Support unconventionally named import libraries
by GHC 19 Mar '18

19 Mar '18

#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: <http://ghc.haskell.org/trac/ghc/ticket/12498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12437: 20% regression in max_bytes_used for T1969
by GHC 19 Mar '18

19 Mar '18

#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 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 is 20% worse: {{{ =====> T1969(normal) 1 of 1 [0, 0, 0] cd "./T1969.run" && "/data/users/smarlow/ghc/inplace/test spaces/ghc- stage2" -c T1969.hs -dno-debug-output -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups +RTS -G1 -RTS +RTS -V0 -tT1969.comp.stats --machine-readable -RTS max_bytes_used value is too high: Expected T1969(normal) max_bytes_used: 15017528 +/-15% Lower bound T1969(normal) max_bytes_used: 12764898 Upper bound T1969(normal) max_bytes_used: 17270158 Actual T1969(normal) max_bytes_used: 18071064 Deviation T1969(normal) max_bytes_used: 20.3 % *** unexpected stat test failure for T1969(normal) }}} One of these patches is the culprit, but I can't tell from the build logs because the build was broken between these two points: {{{ commit 6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91 Author: Ömer Sinan Ağacan <omeragacan(a)gmail.com> Bump Haddock submodule commit 8d4760fb7b20682cb5e470b24801301cfbbdce3b Author: Simon Peyton Jones <simonpj(a)microsoft.com> Comments re ApThunks + small refactor in mkRhsClosure commit 9c54185b26922d88e516942aad946f05f707d7ce Author: Simon Peyton Jones <simonpj(a)microsoft.com> Comments + tiny refactor of isNullarySrcDataCon commit a09c0e3e68c96882a1fb392c9dbeea84056bf32f Author: Simon Peyton Jones <simonpj(a)microsoft.com> Comments only commit 714bebff44076061d0a719c4eda2cfd213b7ac3d Author: Ömer Sinan Ağacan <omeragacan(a)gmail.com> Implement unboxed sum primitive type }}} The patch immediately preceding this sequence does not have the failure: https://phabricator.haskell.org/rGHC83e4f49577665278fe08fbaafe2239553f3c448e (follow the link to the build) and the final patch in this sequence *does* have the failure: https://phabricator.haskell.org/rGHC6a4dc891fa7a8024d8f9f03b98ad675ff5fcbd91 (along with an improvement in T9675) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12437> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10933: REMOVED pragma
by GHC 19 Mar '18

19 Mar '18

#10933: REMOVED pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Say I have a function that's been deprecated for some time. Then I remove it. Some clients will still use the now-missing function. It would be nice to give a helpful error message, instead of a "symbol not found" error. I thus propose a `REMOVED` pragma. The syntax is identical to `DEPRECATED`, except for the name of the pragma. Whenever a `REMOVED` function is mentioned, the error message includes the string from the pragma. (This includes trying to define a `REMOVED` class method in an instance.) See Design/DeprecationMechanisms for more info and related efforts. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11092: ApiAnnotations : make annotation for shebang
by GHC 19 Mar '18

19 Mar '18

#11092: ApiAnnotations : make annotation for shebang -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently a valid haskell file can have a first line of the form {{{#!lhs #!/usr/bin/env runhaskell }}} This does not end up as anything that can have an API Annotation, and so gets lost on round tripping. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10640: Document prim-ops
by GHC 19 Mar '18

19 Mar '18

#10640: Document prim-ops -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently documentation is quite scarce for many primops (particularly the BCO operations). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10640> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally
by GHC 19 Mar '18

19 Mar '18

#10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When used as an infix operator, a data constructor is explicitly promoted simply with `'` prefixed, but when used as a prefix operator enclosed between `(` and `)`, it is explicitly promoted only with `'` put before `(`, not before the constructor. On the other hand, messages of GHC and GHCi indicate that a data constructor operator in a prefix form is promoted by putting `'` before the constructor! (as in `forall (k :: BOX) (k :: BOX). (':*)` below.) I believe that this is a matter of parsing. The parser should admit `(':*)` as well as `'(:*)` for the naturalness of the syntax. In a GHCi: {{{#!hs > :set -XDataKinds -XTypeOperators > data a :* b = a :* b > :kind! Int :* Int Int :* Int :: * = Int :* Int > :kind! Int ':* Int Int ':* Int :: * :* * = Int ':* Int > :kind! (:*) (:*) :: * -> * -> * = (:*) > :kind! '(:*) '(:*) :: k -> k1 -> k :* k1 = forall (k :: BOX) (k :: BOX). (':*) > :kind! (':*) <interactive>:1:3: parse error on input ‘:*’ }}} (By the way I assume that Template Haskell quotes (`'function` and `''Type`) are parsed by the same mechanism as the one for the explicit promotion syntax. I hope both styles of quotes for prefix operators will be admitted because currently only the `'(` `''(` style is admitted.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12