- ghc-tickets - Haskell.org

Re: [GHC] #4385: Type-level natural numbers
by GHC 20 Feb '15

20 Feb '15

#4385: Type-level natural numbers -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dmcclean): Could anyone provide an update on the current state of efforts to improve the constraint solver? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4385#comment:71> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax
by GHC 19 Feb '15

19 Feb '15

#2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: bug | Status: patch Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D669 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D669 Comment: The 2010 report, section 11.4, mentions: "The result of `show` is a syntactically correct Haskell expression ... Parenthesis are only added where needed ..." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2530#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9054: runghc-<version> does not call ghc of the same version
by GHC 19 Feb '15

19 Feb '15

#9054: runghc-<version> does not call ghc of the same version ------------------------------------+------------------------------------- Reporter: EyalLotem | 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: | ------------------------------------+------------------------------------- When I ran runghc-7.6.3, it actually executed "/usr/local/bin/ghc" which points to ghc-7.8.2. The offending line is inside the runghc-<version> script: {{{ exec "$executablename" -f "$bindir/ghc" ${1+"$@"} }}} Which should be: {{{ exec "$executablename" -f "$bindir/ghc-<version>" ${1+"$@"} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9054> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS
by GHC 19 Feb '15

19 Feb '15

#10093: Library configure scripts should not clobber CPPFLAGS nor LDFLAGS -------------------------------------+------------------------------------- Reporter: PHO | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime crash Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `libraries/base/configure` currently clobbers `CPPFLAGS` and `LDFLAGS` when `--with-iconv-includes` and `--with-iconv-libraries` are given, but really it shouldn't. I will soon submit a patch for this. Here's what I stumbled upon (TL;DR): This is somewhat related to #2933. I have libiconv installed in `/usr/pkg`, which is a non-standard path that `ld.so` normally doesn't search libraries for. So I built GHC with `CONF_GCC_LINKER_OPTS_STAGE{0,1,2}` set to `-Wl,-rpath,/usr/pkg/lib` so that GHC links executables with `RPATH` pointing to `/usr/pkg/lib`. The build went fine until it started using `ghc-stage2` and `haddock`: they were causing segfaults in `evacuate()` with a probability of about 70%, which suggested a heap corruption occuring somewhere. I tried rebuilding RTS with `-O0 -g`, changed various parameters for GC, etc. Nothing changed. Then I suddenly realized that `libraries/base/configure` was the root cause of the problem. Those `configure` scripts are executed with `LDFLAGS` being set to the value of `CONF_GCC_LINKER_OPTS_STAGE2`, which is `-Wl,-rpath,/usr/pkg/lib` in my case, but `libraries/base/configure` overwrites it to `-L/usr/pkg/lib` when `--with-iconv- libraries=/usr/pkg/lib` is given. On the other hand, `FP_SEARCH_LIBS_PROTO(iconv)` appends `-liconv` to `$LIBS` so it will be linked to any conftest executables that follow, including one which will be generated by `AC_CHECK_SIZEOF()`. The problem is that if libraries listed in `$LIBS` are in a non-standard path while rpath flags are missing (due to `LDFLAGS` being clobbered in this case), conftest executables cannot run even if they can be linked. And if anything goes wrong during `AC_CHECK_SIZEOF(T)`, it considers `sizeof(T)` as 0 unless `T` is known to be an existing type: {{{ ... checking for library containing iconv... -liconv checking for library containing locale_charset... none required checking size of struct MD5Context... 0 ... }}} This means `SIZEOF_STRUCT_MD5CONTEXT` gets defined to 0, `GHC.Fingerprint.fingerprintData` allocates 0 bytes on the heap, `MD5Init`/`Update`/`Final` corrupts the heap and then Bad Things will happen. I have found the problem on NetBSD/amd64 but I'm sure the same thing happens on every ELF platform. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10093> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9402: Vestigial external core code in genprimops
by GHC 19 Feb '15

19 Feb '15

#9402: Vestigial external core code in genprimops -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- It looks like `gen_ext_core_source` in `utils/genprimopcode/Main.hs` is no longer needed. I'm not quite confident enough here to make the change myself, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9402> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9606: Improve outdated ghc-pkg cache warning
by GHC 19 Feb '15

19 Feb '15

#9606: Improve outdated ghc-pkg cache warning -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: ghc-pkg | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Sometimes you get this: {{{ WARNING: cache is out of date: /home/user/.ghc/x86_64-linux-7.8.3/package.conf.d/package.cache. Use 'ghc-pkg recache' to fix }}} The warning is correct but a bit confusing, because running `ghc-pkg recache` does nothing here: It will by default update your global package DB, and the DB the warning is about will still be out of date. This seems to have frustrated others as well: https://gist.github.com/mcandre/5789498 I suggest we make the message more clear: `You might have to pass --user to update this cache file`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9094: remove RAW_CPP
by GHC 19 Feb '15

19 Feb '15

#9094: remove RAW_CPP ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 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: 8683 | Blocking: Related Tickets: #8683 | ------------------------------------+------------------------------------- once the CPP settings ticket is merged #8683 one cleanup task is to remove the RAW_CPP bits from the ghc build system because they're not longer needed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9094> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #3874: GHC.Exts.traceEvent segfaults
by GHC 18 Feb '15

18 Feb '15

#3874: GHC.Exts.traceEvent segfaults -----------------------------------+-------------------------------- Reporter: cjs | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.12.2 Component: Runtime System | Version: 6.12.1 Resolution: fixed | Keywords: event, eventlog Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: -----------------------------------+-------------------------------- Comment (by Austin Seipp <austin@…>): In [changeset:"a82364c9410d35fa9cb5031d553212267c3628c5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a82364c9410d35fa9cb5031d553212267c3628c5" Don't truncate traceEvents to 512 bytes (#8309) Summary: Don't call postLogMsg to post a user msg, because it truncates messages to 512 bytes. Rename traceCap_stderr and trace_stderr to vtraceCap_stderr and trace_stderr, to signal that they take a va_list (similar to vdebugBelch vs debugBelch). See #3874 for the original reason behind traceFormatUserMsg. See the commit msg in #9395 (d360d440) for a discussion about using null-terminated strings vs strings with an explicit length. Test Plan: Run `cabal install ghc-events` and inspect the result of `ghc-events show` on an eventlog file created with `ghc -eventlog Test.hs` and `./Test +RTS -l`, where Test.hs contains: ``` import Debug.Trace main = traceEvent (replicate 510 'a' ++ "bcd") $ return () ``` Depends on D655. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D656 GHC Trac Issues: #8309 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3874#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9395: Debug.Trace should not use %s for format string
by GHC 18 Feb '15

18 Feb '15

#9395: Debug.Trace should not use %s for format string -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Incorrect Blocked By: | result at runtime Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The current implementation of traceIO in Debug.Trace is as follows: {{{ traceIO :: String -> IO () traceIO msg = do withCString "%s\n" $ \cfmt -> withCString msg $ \cmsg -> debugBelch cfmt cmsg }}} This is bad news: it means if the String has a null in it, the string will be silently truncated. For example, in GHC, this means that you cannot pretty-print FastString uniques, since the default printing algorithm often results in a null. Probably the proper thing to do here is to also pass a length indicator for the CString. We should also fix unique pretty-printing to never generate nulls. A good test case would be: {{{ main = trace "\0foo" (return ()) }}} which should have non-empty output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10086: Disambiguate type variables using dictionaries
by GHC 18 Feb '15

18 Feb '15

#10086: Disambiguate type variables using dictionaries -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: Other Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this code: {{{#!hs type family TF t type instance TF (Maybe a) = Maybe a class Id f where idTF :: TF f -> TF f instance Id (Maybe a) where idTF x = x g = idTF (Just 'c') }}} Definition of `g` is rejected due to ambiguity: {{{ Couldn't match expected type ‘TF f0’ with actual type ‘Maybe Char’ The type variable ‘f0’ is ambiguous Relevant bindings include g :: TF f0 (bound at T6018.hs:18:1) In the first argument of ‘idTF’, namely ‘(Just 'c')’ In the expression: idTF (Just 'c') }}} There are two ways to proceed: 1. Introduce `Proxy` argument and disambiguate `f` with explicit type annotation. 2. With injective type families (coming Real Soon Now) we can declare `TF` as injective and this code will compile. That obviously won't work if `TF` is not injective. I think we could do better here. `idTF` is a type class function and when it is called GHC uses a concrete implementation from a dictionary. But notice that if we have the dictionary we could equally well use it to disambiguate `f`. In this example we call `idTF` with a `Maybe Char` argument, which means we are using `Id (Maybe a)` instance. Knowing this we could infer that `f` is `Maybe a`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10086> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2