October 2015 - ghc-tickets

[GHC] #10993: Bad error message reported when -XBinaryLiterals is not enabled
by GHC 20 Oct '15

20 Oct '15

#10993: Bad error message reported when -XBinaryLiterals is not enabled -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (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: -------------------------------------+------------------------------------- When `-XBinaryLiterals` is not enabled, expressions like `0b10101` is causing this horrible error message: `Not in scope: ‘b10101’`. The reason, as far as I understand, is that lexer is not lexing `0b0101` as a single token when `-XBinaryLiterals` is not enabled. Then the parser is parsing this as an application of `0` to `b0101`. (this can be observed with `-ddump-parsed`) My suggestion: Lexer should always generate a single token for `0b0101`. We don't do `ifExtension binaryLiteralsEnabled` checks in the lexer anymore. We somehow mark generated token as "requires extension: BinaryLiterals"(I don't know if we have the infrastructure for this right now). Then, when the parser sees an integer that requires `-XBinaryLiterals`, checks the flag and reports the error etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #602: Warning Suppression
by GHC 20 Oct '15

20 Oct '15

#602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): And Rust's support reminds me very much of [http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2F… %2Ftask-suppress_warnings.htm Java's]. Both Rust and Java support warning suppression (or, for Rust, generation) based on scopes. Is that reasonable for Haskell? Maybe. We would continue to allow `OPTIONS` to specify flags for the whole file, but we could then also support local flags for definitions (or parts of definitions). The one thing this design wouldn't allow is setting warning suppression for a whole bunch of definitions (but not all). That may be an acceptable tradeoff. While we're thinking about this, it might be reasonable to consider adding arbitrary option-changes locally. (For example, I'd love to be able to turn on `LANGUAGE` pragmas only for part of a file.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/602#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8648: Initialization of C statics broken in threaded runtime
by GHC 20 Oct '15

20 Oct '15

#8648: Initialization of C statics broken in threaded runtime ------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Consider a tiny package `static-value`, consisting of one Haskell file {{{ foreign import ccall unsafe "returnStaticValue" c_returnStaticValue :: IO CInt printStaticValue :: IO () printStaticValue = print =<< c_returnStaticValue }}} and one corresponding C file {{{ static int theStaticValue = 0; int returnStaticValue() { // Modify the static so the C compiler doesn't optimize it away return theStaticValue++; } }}} (test case is attached). If we call `printStaticValue` using the GHC API: {{{ runGhc (Just libdir) $ do flags0 <- getSessionDynFlags void $ setSessionDynFlags flags0 { hscTarget = HscInterpreted , ghcLink = LinkInMemory , ghcMode = CompManager } setContext $ [ IIDecl $ simpleImportDecl $ mkModuleName "StaticValue" ] _ <- runStmt "StaticValue.printStaticValue" RunToCompletion }}} then we see "0", as expected. However, if we compile this code using the threaded runtime, and we wrap the above code in a call to either `forkIO` or `forkOS`, then we see a different value printed (-907777, whatever that value is). Some notes: * I have been unable to reproduce this bug without using GHC as API; in particular, calling `printStaticValue` directly, wrapped in `forkIO` or `forkOS` or not, always works as expected. * If I change the initialization value of `staticValue` from 0 to anything else (say, 1234), we always get the right answer, never the uninitialized value. Presumably this is because non-zero values require some explicit code to be run (and it does get run), while a zero value gets initialized differently (and apparently, that's where the bug is). * I have reproduced this bug in both ghc 7.4 and 7.7.20131227. This ticket is the result of tracking down a problem with calling `createProcess` from within the GHC API, which would cause the parent process to stall. As it turns out, `runProcess.c` (from the `process` library) declares a `static long max_fd = 0`, and in `runInteractiveProcess` checks for this value to be 0, and if it is, does a syscall to figure out what the maximum FD is. But since this static does not get initialized properly (the bug reported in this ticket), it gets left at its (random? but always the same) value (281474975802879), so that the child process proceeds to close rather too many file descriptors (if close_fds was set to True) and the parent stalls. Indeed, changing the initialization to `static long max_fd = -1` (and adjusting the later check for zero accordingly) fixes this (so this is a viable workaround in `process` if we cannot track down the bug in GHC). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8648> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #602: Warning Suppression
by GHC 20 Oct '15

20 Oct '15

#602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One point in the design space that anyone thinking about this should probably be aware of is that taken by [[https://doc.rust- lang.org/stable/reference.html#lint-check-attributes|Rust]] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/602#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10991: Don't permit type variables in the context unless they are in the type
by GHC 20 Oct '15

20 Oct '15

#10991: Don't permit type variables in the context unless they are in the type -------------------------------------+------------------------------------- Reporter: bernalex | Owner: bernalex Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Type checker) | Keywords: | 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 accepts the following: {{{ f :: Eq a => b -> b f b = b }}} This is not valid Haskell 2010[0], so we should not permit it. [0] «The context cx must only contain type variables referenced in t», https://www.haskell.org/report/node/2010/haskellch4.html#x10-660004.1.3 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10991> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10650: Can't define GHCi :def macro with NoImplicitPrelude on
by GHC 20 Oct '15

20 Oct '15

#10650: Can't define GHCi :def macro with NoImplicitPrelude on -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #8640 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHCi is unusually prohibitive in typechecking {{{:def}}} macros when {{{NoImplicitPrelude}}} is enabled. Here's an example to illustrate what I mean: {{{ $ ghci -XNoImplicitPrelude GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help λ> :def pf \str -> Prelude.return Prelude.$ ":! pointfree \"" Prelude.++ str Prelude.++ "\"" <interactive>:1:111: Not in scope: type constructor or class ‘String’ <interactive>:1:121: Not in scope: type constructor or class ‘IO’ <interactive>:1:124: Not in scope: type constructor or class ‘String’ }}} I can understand the functions being out-of-scope when {{{NoImplicitPrelude}}} is on, but the type errors don't make any sense to me, especially since {{{:t}}} seems to pick up on the types just fine: {{{ λ> :t Prelude.return Prelude.return :: GHC.Base.Monad m => a -> m a λ> :t "\"" "\"" :: [GHC.Types.Char] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #602: Warning Suppression
by GHC 19 Oct '15

19 Oct '15

#602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edgar.zhavoronkov): Replying to [comment:23 goldfire]: > This has not been implemented. You're welcome to try to specify this feature concretely and try to put together a patch! > > The specification comes first. :) Wrote some sort of informal specification with couple of use cases https://ghc.haskell.org/trac/ghc/wiki/Design/LocalWarningPragmas -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/602#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10988: Suggest LambdaCase
by GHC 19 Oct '15

19 Oct '15

#10988: Suggest LambdaCase -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (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: -------------------------------------+------------------------------------- When I say {{{#!hs module Bug where foo = \case True -> False False -> True }}} I get {{{ Bug.hs:9:7: error: parse error: naked lambda expression '' }}} We can do far better. Setting priority to high because it's rather embarrassing to let your lambdas run around naked. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10988> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #602: Warning Suppression
by GHC 19 Oct '15

19 Oct '15

#602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This has not been implemented. You're welcome to try to specify this feature concretely and try to put together a patch! The specification comes first. :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/602#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7316: GHC segfaults on ARM
by GHC 19 Oct '15

19 Oct '15

#7316: GHC segfaults on ARM -------------------------------------+------------------------------- Reporter: laney | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: 7623 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7316#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0