- ghc-tickets - Haskell.org

[GHC] #10081: SIGTERM ignored when process has been detached from terminal
by GHC 12 Mar '15

12 Mar '15

#10081: SIGTERM ignored when process has been detached from terminal -------------------------------------+------------------------------------- Reporter: nakal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.3 libraries/unix | Operating System: FreeBSD Keywords: | Type of failure: Incorrect result Architecture: x86_64 | at runtime (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've tried to write a simple Unix daemon that reacts to signals. Here is the reduced source code sample: {{{#!hs import Control.Concurrent import Control.Monad import System.Exit import System.IO import System.Posix.Signals loop = forever $ threadDelay 1000000 main = do ppid <- myThreadId mapM (\sig -> installHandler sig (Catch $ trap ppid) Nothing) [ lostConnection, keyboardSignal, softwareTermination, openEndedPipe ] loop trap tid = do hPutStrLn stderr "Signal received.\n" throwTo tid ExitSuccess }}} Such daemons usually run in background without a terminal attached. I verified that I can kill the process after being started on the terminal: {{{ > ./daemon Signal received. }}} With: {{{ > killall daemon }}} in other terminal. Other test, when I run it in background: {{{ > ./daemon (press Ctrl+Z) > bg > killall daemon Signal received. }}} This case is also ok. Now the third test which is also OK: {{{ > ./daemon > log 2>&1 (press Ctrl+Z) > bg > exit }}} In second terminal: {{{ > cat log > killall daemon > cat log Signal received. > killall daemon No matching processes belonging to you were found }}} Now the fourth test which is simply without a log file and this one fails: {{{ > ./daemon (press Ctrl+Z) > bg > exit }}} On some other terminal try to kill the process: {{{ > killall xxx > killall xxx > killall xxx > killall -9 xxx > killall xxx No matching processes belonging to you were found }}} Signal 9 (SIGKILL) kills the process hard without the signal trap. That's why it works, of course, but SIGTERM is being ignored for some reason. Maybe I am forgetting something, but in my opinion this should end the process properly, too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10081> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #5108: Allow unicode sub/superscript symbols in both identifiers and operators
by GHC 11 Mar '15

11 Mar '15

#5108: Allow unicode sub/superscript symbols in both identifiers and operators -------------------------------------+------------------------------------- Reporter: | Owner: mikhail.vorozhtsov | Status: infoneeded Type: feature request | Milestone: 7.12.1 Priority: normal | Version: 7.1 Component: Compiler | Keywords: lexer (Parser) | unicode Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): {{{ λ> let ᵤxᵤy = 1 }}} GHC 7.10 follows Unicode standard 7.0, in which `'ᵤ'` (`'\x2b9'`) is in the `ModifierLetter` (Lm) general category, so that will no longer compile. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5108#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3283: Selective disabling of unused bind warnings
by GHC 11 Mar '15

11 Mar '15

#3283: Selective disabling of unused bind warnings -------------------------------------+------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #17 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:3 nomeata]: > It seems to be related to #17. I just came across this one and thought the same thing. Now that #17 is closed can we consider this a duplicate? I know this ticket proposes a separate pragma to mark definitions as used but with new warning flags added by #17 the pragma does not seem like a good idea. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3283#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9122: Make Lint check for bad uses of `unsafeCoerce`
by GHC 11 Mar '15

11 Mar '15

#9122: Make Lint check for bad uses of `unsafeCoerce` ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I think it would be a great idea for Core Lint to check for uses of `unsafeCoerce` that don't obey the rules. It won't catch all cases, of course, but it would have caught #9035. Specficially, look for: * Coercions between lifted and unboxed types * Coercion between unboxed types of different sizes * Coercion between unboxed ints and floats. Would anyone like to make a patch for this? Anything that can be checked by Core Lint, should be checked! I'm afraid I don't know where to look for the reason for the int/float difficulty. I'd write a tiny function that exhibits the unsafe conversion and look the code it generates. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 10 Mar '15

10 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by simonpj): Two thoughts * I'm relaxed about what we choose here. It really matters little; and it's been a long-standing bug in GHC. * You do have a point: that `FlexibleContexts` sounds as if it has to do with type-signature contexts (and it does); and so does `ConstrainedClassMethods`. So perhaps it would be more intuitive to make `FlexibleContexts` imply `ConstrainedClassMethods` than `MultiParamTypeClasses`? But I bet there are packages that use `MultiParamTypeClasses` but not `FlexibleContexts`. So * Perhaps we should try making `FlexibleContexts` imply `ConstrainedClassMethods`, but ''not'' `MultiParamTypeClasses`, just to see what happens. * If it's painful, then maybe the path of least resistance is to make both imply `ConstrainedClassMethods`. Any views from others? Would someone like to try the experiment? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 10 Mar '15

10 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by ekmett): That was me speaking as me, not in any official capacity. =) I had honestly thought FlexibleContexts _was_ the extension for this sort of thing until now. Putting on my CLC hat for a bit, the main reason I can see why it'd be nice to have FlexibleContexts "just work" is it means we don't have to make the hackage trustees go back and retrofit all sorts of old versions of packages with base upper bounds wherever they find themselves encountering this issue. But mostly that rises to the left of "nice to have" not really "have to have". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide
by GHC 10 Mar '15

10 Mar '15

#10140: Suggestions for improvement of the Safe Haskell chapter in the user's guide -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.4 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've been reading the [http://haskell.inf.elte.hu/docs/7.11.20150306.noWin32/html/users_guide /safe-haskell.html documentation] on Safe Haskell. Cool stuff. Here are some suggestions for improvement, I hope some are useful: * 7.29.1.2 This comment is the first introduction to the pragmas `TrustWorthy` and `Safe`: {{{ -- Either of the following Safe Haskell pragmas would do {-# LANGUAGE Trustworthy #-} {-# LANGUAGE Safe #-} module RIO ... }}} Why is either allowed? I suspect because of the details of this module, but this is not explicitly stated. Furthermore, later it is said that `-XTrustworthy` should be used, not `-XSafe`: "This is done by compiling the RIO module with the -XTrustworthy flag and compiling the Danger module with the -XSafe flag." * 7.29.2 "TemplateHaskell — Is particularly dangerous, as it can cause side effects even at compilation time" One could now think that `Safe Haskell` does guarantee compilation safety. Since that is not the case, I would remove that sentence (things are explained properly in the Safe Compilation section). * 7.29.2 "Hand crafted instances of the Typeable type class are not allowed in Safe Haskell". Make a mention of the [https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/deriving.html following]: "... since GHC 7.8.1, handwritten (ie. not derived) instances of Typeable are forbidden, and will result in an error." * 7.29.4 After listing `-XSafe`, `-XTrustWorthy`, `-XUnsafe`: "The procedure to check if a module is trusted or not depends on if the -fpackage-trust flag is present. The check is very similar in both cases" There are three cases. * 7.29.4.1. Trust check (-fpackage-trust disabled) "A module M in a package P is trusted by a client C if and only if: Both of these hold: 1. The module was compiled with -XSafe 2. All of M's direct imports are trusted by C" But isn't the latter implied by the former, or the module wouldn't compile? If that is correct, please mention it. Same in the next section (7.29.4.2). * 7.29.4.2 "Having the -fpackage-trust flag also nicely unifies the semantics of how Safe Haskell works when used explicitly and how modules are inferred as safe." Should explicitly be implicitly? I don't understand this sentence regardless. What does nicely unifies mean? * 7.29.4.1 and 7.29.4.2 There is no mention of Safe Haskell Inference in these rules, only "The module was compiled with -XSafe" and "The module was compiled with -XTrustWorthy". I think the following statement should be true, but I'm not sure: "If a module M in a package P is inferred to be Safe by GHC, then it is trusted by client C". Actually, there is only a short mention of safe inference in the introduction, whereas I suspect it should be mentioned everywhere where `-XSafe` is. * 7.29.5 "That is, the use cases outlined and the purpose for which Safe Haskell is intended: compiling untrusted code." Before, "compiling and executing untrusted code" was listed as one of two cases. Now it's mentioned as the single purpose. Minor issue. * 7.29.5 "Say you are writing a Haskell library. Then you probably just want to use Safe inference." I have more of a general question about this: if this is true, then why are there over 200 mentions of `{-# Language Safe #-}` in a checkout of ghc? Is it because 'Safe Haskell Inference' was not added to GHC until version 7.4 (is that true? I inferred it from the difference between the 7.2 and 7.4 user's guides). So maybe modules that need to be compileable with earlier versions of GHC have to specify -XSafe explicitly? Some guidance on this would be helpful. * There are 2 `ulink`s that don't work. Should be `xref`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10140> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #2991: .tix file generation broken with -fhpc and --make flags with lhs modules
by GHC 10 Mar '15

10 Mar '15

#2991: .tix file generation broken with -fhpc and --make flags with lhs modules -------------------------------------+------------------------------------- Reporter: ppavel | Owner: andy@… Type: bug | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.10.1 Resolution: fixed | Keywords: hpc make Operating System: Unknown/Multiple | lhs Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: hpc/T2991 | Blocking: | Differential Revisions: Phab:D701 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2991#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2991: .tix file generation broken with -fhpc and --make flags with lhs modules
by GHC 10 Mar '15

10 Mar '15

#2991: .tix file generation broken with -fhpc and --make flags with lhs modules -------------------------------------+------------------------------------- Reporter: ppavel | Owner: andy@… Type: bug | Status: patch Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.10.1 Resolution: | Keywords: hpc make Operating System: Unknown/Multiple | lhs Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: hpc/T2991 | Blocking: | Differential Revisions: Phab:D701 -------------------------------------+------------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"f9344f3646156a9efff2dcfb90e1d5d67fd4f5a1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f9344f3646156a9efff2dcfb90e1d5d67fd4f5a1" Fix `ghc --make -fhpc` with imported lhs modules See Note [Don't normalise input filenames] in `compiler/main/DriverPipeline.hs`. Fixes #2991. Reviewers: austin Differential Revision: https://phabricator.haskell.org/D701 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2991#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations
by GHC 10 Mar '15

10 Mar '15

#7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9722 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9722 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7325#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0