September 2018 - ghc-tickets

[GHC] #15616: Bug when using TimerManager/GHC.Event ?
by GHC 08 Sep '18

08 Sep '18

#15616: Bug when using TimerManager/GHC.Event ? -------------------------------------+------------------------------------- Reporter: ddellacosta | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- It was suggested on #haskell that this is a bug and that I should report it here. Hopefully this is the simplest possible example that shows the issue. The code sample I got from a StackOverflow answer (https://stackoverflow.com/a/25488677) which I found just trying to learn how to use GHC.Event properly so presumably, and it seemed to work there, so I assume it is still valid code (but let me know if not!). Minimal example repo is here: https://github.com/ddellacosta/timermanager- bug, please see Main.hs I'm on on OS X 10.13.6, and hopefully the shell dump below combined with the repo above gives you everything else you need: {{{#!bash $ cabal new-configure Resolving dependencies... Build profile: -w ghc-8.4.3 -O1 In order, the following would be built (use -v for more details): - timermanager-bug-0.1.0.0 (exe:timermanager-bug) (first run) $ cabal new-build Build profile: -w ghc-8.4.3 -O1 In order, the following will be built (use -v for more details): - timermanager-bug-0.1.0.0 (exe:timermanager-bug) (first run) Configuring executable 'timermanager-bug' for timermanager-bug-0.1.0.0.. clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] Preprocessing executable 'timermanager-bug' for timermanager-bug-0.1.0.0.. Building executable 'timermanager-bug' for timermanager-bug-0.1.0.0.. [1 of 1] Compiling Main ( Main.hs, /Users/ddellacosta/code /timermanager-bug/dist-newstyle/build/x86_64-osx/ghc-8.4.3/timermanager- bug-0.1.0.0/x/timermanager-bug/build/timermanager-bug/timermanager-bug- tmp/Main.o ) Linking /Users/ddellacosta/code/timermanager-bug/dist- newstyle/build/x86_64-osx/ghc-8.4.3/timermanager-bug-0.1.0.0/x /timermanager-bug/build/timermanager-bug/timermanager-bug ... clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] clang: warning: argument unused during compilation: '-nopie' [-Wunused- command-line-argument] $ cabal new-exec timermanager-bug timermanager-bug: user error (Pattern match failure in do expression at libraries/base/GHC/Event/Thread.hs:216:3-10) $ }}} Let me know if there's any more information I can supply! Apologies if this is not actually a bug but something I'm doing wrong! Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15599: typeclass inference depends on whether a module is exposed.
by GHC 07 Sep '18

07 Sep '18

#15599: typeclass inference depends on whether a module is exposed. -------------------------------------+------------------------------------- Reporter: gleachkr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- My first bug report for GHC: I've found some strange behavior in GHC 8.2.2 relating to typeclass inference. Essentially, for two identical modules, GHC infers for one of them that one typeclass instance applies, and for another that a different instance applies. The only language extensions involved are FlexibleInstances, MultiParamTypeClasses, GADTs, and ScopedTypeVariables. There are no INCOHERENT pragmas involved. The only difference between the two modules is that one of them (the one displaying correct typeclass inference) is an exposed module, while the other is not mentioned in the cabal file. The phenomenon affects other packages that import the original package---they display the incorrect behavior, rather than the correct behavior that the exposed module displays. The original discussion is here: [https://github.com/gleachkr/Carnap/issues/4] My best attempt at a minimal example can be found at [https://github.com/gleachkr/GHC-Repro] You can run the "test.sh" script included there to see the phenomenon in action. I don't see this behavior in other GHC versions, but I'm told that bug reports for older GHC versions are welcome, so here I am. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15599> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12356: StaticPointers support in GHCi
by GHC 07 Sep '18

07 Sep '18

#12356: StaticPointers support in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | 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: #12000 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently GHCi does not support `-XStaticPointers`, which is quite annoying for those of us who actually use `-XStaticPointers` in day-to-day development. It would be great if GHCi could grow support for this extension. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

Re: [GHC] #3372: Allow for multiple linker instances
by GHC 07 Sep '18

07 Sep '18

#3372: Allow for multiple linker instances -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): This is not fixed. The C API for the linker in the runtime was made thread-safe, so that multiple C clients could call it simultaneously, but GHC still has a single global instance of its own linker state. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3372#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15615: Rename some mutable closure types for consistency
by GHC 07 Sep '18

07 Sep '18

#15615: Rename some mutable closure types for consistency -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4784 | Wiki Page: -------------------------------------+------------------------------------- Description taken from the diff: {{{ SMALL_MUT_ARR_PTRS_FROZEN0 -> SMALL_MUT_ARR_PTRS_FROZEN_DIRTY SMALL_MUT_ARR_PTRS_FROZEN -> SMALL_MUT_ARR_PTRS_FROZEN_CLEAN MUT_ARR_PTRS_FROZEN0 -> MUT_ARR_PTRS_FROZEN_DIRTY MUT_ARR_PTRS_FROZEN -> MUT_ARR_PTRS_FROZEN_CLEAN }}} Naming is now consistent with other CLEAR/DIRTY objects (MVAR, MUT_VAR, MUT_ARR_PTRS). (alternatively we could rename MVAR_DIRTY/MVAR_CLEAN etc. to MVAR0/MVAR) Removed a few comments in Scav.c about FROZEN0 being on the mut_list because it's now clear from the closure type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15615> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15614: Test suite should show reason for skipping a test
by GHC 07 Sep '18

07 Sep '18

#15614: Test suite should show reason for skipping a test -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.5 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 want to add a GHCi test, but it's a bit tricky to run the test so I use a make rule and use `run_command`, like this: {{{ test('UnsafeReenterGhci', [only_ways(['ghci']), exit_code(1), extra_files(['UnsafeReenter.hs', 'UnsafeReenterC.c'])], run_command, ['$MAKE -s --no-print-directory UnsafeReenterGhci']) }}} The important part is `run_command` and `only_ways(['ghci'])`. The problem is that it's impossible to run this test, because by default a `run_command` test can only be run in normal way (see test_common_work() in testlib.py), but there's no way to know this without reading the source code. Having better documentation might help, but I think the test driver should print why a test is skipped (maybe only in verbose mode -- if such a mode exists). In our case it should print something like "Test is only run in 'normal' way" (because `run_command` tests only run in 'normal' way). Correct version of this test is: {{{ test('UnsafeReenterGhci', [extra_ways(['ghci']), only_ways(['ghci']), exit_code(1), extra_files(['UnsafeReenter.hs', 'UnsafeReenterC.c'])], run_command, ['$MAKE -s --no-print-directory UnsafeReenterGhci']) }}} The `extra_ways` makes the test driver consider running the test in `ghci` way, `only_ways` is to avoid running it in `normal` way (the default and only way for `run_command`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15614> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14743: `UnsafeReenter` test hangs
by GHC 07 Sep '18

07 Sep '18

#14743: `UnsafeReenter` test hangs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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 a `./validate --slow` run `UnsafeReenter` process hangs forever, using CPU as well. Not sure if this happens in fast or normal validate yet, or which way do I need to reproduce. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #3427: control what sort of entity a deprecated pragma applies to
by GHC 07 Sep '18

07 Sep '18

#3427: control what sort of entity a deprecated pragma applies to -------------------------------------+------------------------------------- Reporter: igloo | Owner: nineonine Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: deprecate | warning, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5126 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for doing this! But before I can review this I need a specification of what the change is, exactly. It's hard to review code without knowing exactly what it is trying to achieve. In fact, it should really be a GHC proposal -- it's clearly a user-facing change. It'd be an easy proposal to write, and could be reviewed quickly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3427#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3427: control what sort of entity a deprecated pragma applies to
by GHC 07 Sep '18

07 Sep '18

#3427: control what sort of entity a deprecated pragma applies to -------------------------------------+------------------------------------- Reporter: igloo | Owner: nineonine Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: deprecate | warning, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5126 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: => Phab:D5126 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3427#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9622: GHCi command to solve a constraint
by GHC 07 Sep '18

07 Sep '18

#9622: GHCi command to solve a constraint -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It would be nice to have a `:solve` command for ghci that took a class constraint and returned either its derivation or an error message. A possible interface could look like so: {{{ ghci> :solve Eq (Maybe Type1, Bool) 1) instance Eq Type1 -- Defined in ‘MyModule’ 2) instance Eq a => Eq (Maybe a) -- Defined in ‘GHC.Classes’ 3) instance Eq (Maybe Type1) -- Put a ~ Int in 2) and use 1) 4) instance Eq Bool -- Defined in ‘GHC.Classes’ 5) instance (Eq a, Eq b) => Eq (a,b) -- Defined in ‘GHC.Classes’ 6) instance Eq (Maybe Type1, Bool) -- Put a ~ Maybe Type1, b ~ Bool in 5) and use 3), 4) ghci> :solve Eq (Int -> Int) No instance for Eq (Int -> Int) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2