August 2018 - ghc-tickets

[GHC] #15209: ~# is always in scope with TypeOperators
by GHC 15 Sep '18

15 Sep '18

#15209: ~# is always in scope with TypeOperators -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- When `TypeOperators` is turned on, `~#` comes into scope automatically. As far as I know, this extremely magical operator really isn't supposed to be in Haskell at all, but if it is, it should surely be hidden in `GHC.Magic` or `GHC.Prim` or some such. {{{#!hs {-# LANGUAGE GADTs, TypeOperators #-} foo :: a ~# Int -> () foo = () -- No arguments, because of a magical `Type`/`Constraint` swap or something. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #12565: unhelpful error message about enabling TypeApplications
by GHC 14 Sep '18

14 Sep '18

#12565: unhelpful error message about enabling TypeApplications -------------------------------------+------------------------------------- Reporter: mauke | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- {{{ % cat bug.hs }}} {{{#!hs {-# LANGUAGE TypeApplications #-} main = return (id@() ()) }}} {{{ % ghc bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) bug.hs:2:16: error: Pattern syntax in expression context: id@() Did you mean to enable TypeApplications? }}} This error message makes no sense because `TypeApplications` is already enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12565> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14770: Allow static pointer expressions to have static pointer free variables
by GHC 14 Sep '18

14 Sep '18

#14770: Allow static pointer expressions to have static pointer free variables -------------------------------------+------------------------------------- Reporter: TheKing01 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple StaticPointers | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Static pointer expressions can not have free variables. For example: {{{#!hs addPointers :: StaticPtr Int -> StaticPtr Int -> StaticPtr Int addPointers x y = static (deRefStaticPtr x + deRefStaticPtr y) }}} would be invalid, since `x` and `y` are free variables. My proposal would be to make this code sample valid. In particular, my proposal is to allow free variables in `static` expressions if the free variables of the type `StaticPtr a` for some type `a`. Let's say that `m` `n` are Static pointers to integers. The serialized form would of `addPointers m n` would be: A pointer to the code `deRefStaticPtr x + deRefStaticPtr y` The serialized form of `m`, associated with `x`. The serialized form of `n`, associated with `y`. When this is sent over the wire and dereferenced, the other machine would Find `m` and `n`'s pointers Find the code `deRefStaticPtr x + deRefStaticPtr y` Evaluate `deRefStaticPtr x + deRefStaticPtr y`, substituting `m`'s value for `x`, and `n`'s value for y. The reason this feature would be useful is would let the user modify and combine static pointers. You might ask "why not let the user create a GADT to do that (like in https://hackage.haskell.org/package/distributed-static-0.3.8/docs/Control- Distributed-Static.html#t:Static)?" The reason is that then it won't fuse (with recreating every fusion rule for that GADT). For example, if `m` is `static 7` and `n` is `static 3`, then `addPointers m n` can fuse to `static 11`. This is more important then it seems. For example, say you have `composePointers :: StaticPtr (a -> b) -> StaticPtr (b -> c) -> StaticPtr (a -> c)`, and you compose a bunch of pointers. With the GADTS, every `composePointers` would be its own node, but with GHC support, it would probably fuse. In general, dealing with a GADT requires a lot of "glue code" that can be eliminated with GHC support. I'm not sure if this proposal makes a performance difference (it probably makes it more efficient), but it would make code more elegant, cutting out all the glue code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15501: Fix unknown symbols/addresses in perf output
by GHC 14 Sep '18

14 Sep '18

#15501: Fix unknown symbols/addresses in perf output -------------------------------------+------------------------------------- Reporter: last_g | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Compiler | Version: 8.5 (CodeGen) | Keywords: perf, | Operating System: Linux symbols, elf, linux | Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D4713 | Wiki Page: -------------------------------------+------------------------------------- After https://phabricator.haskell.org/D4713 will be merged some addresses in perf output won't be mapped to the symbols. This needs investigation and fix. A draft idea about the root cause: The issue comes from the current perf symbolization algorithm. The basic logic is (kind of) simple: # Take all the @function symbols and put into a sorted list; # the next steps are a hack to support handwritten assembly # Take all the NOTYPE symbols with the size equals to 0 and put into the same ordered list; # Run the symbols__fixup_end procedure which sets a symbol end address to be the beginning of the next symbol for every 0 sized symbol; # If the last symbol is zero sized: set its size to be ~4k. (The actual logic is more complicated because it also involves sections&map groups) In GHC compiled binaries there are no @function symbols and most internal symbols are NOTYPE and 0 sized so we are ending up in the hack's code. This logic effectively means that every address in our code space is attributed to some internal symbol (correct or not). Adding @function symbols with size directive stops this from happening. As the first guess, those addresses can come from _con_info entries which we don't mark as @function but in that case, there should be no unknown addresses in D4730 but we have some there too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14313: “Result signatures are no longer supported in pattern matches” lost
by GHC 14 Sep '18

14 Sep '18

#14313: “Result signatures are no longer supported in pattern matches” lost -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #2310 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This commit (b98ff25f4c8cb4bf18b784c848fabaaa6e4b11b8) from two years ago broke the error message (at least according to when `T2310.stderr` was modified): {{{ T2310.hs:5:22: Illegal result type signature ‘a’ Result signatures are no longer supported in pattern matches In a lambda abstraction: \ x :: a -> (x :: a) }}} that was displayed previously. Either we do want that error message (then this is a bug) or we don’t care about this error message any more, then probably we can remove the `m_type` field of `Match` in `HsExpr`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14313> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14229: Contraditions in users_guide/using-warnings.html
by GHC 14 Sep '18

14 Sep '18

#14229: Contraditions in users_guide/using-warnings.html -------------------------------------+------------------------------------- Reporter: | Owner: (none) MikolajKonarski | Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Lists are not updated in https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html E.g., it says "The warnings that are not enabled by -Wall are ...-Wredundant-constraints", but then it says "This option is on by default". Also "-Worphans" is on none of the list of enabled or not enabled flags and also there is no mention in its description if its enabled by default or not. I guess there may be more. Also, it may be worth mentioning that obsolete warnings or warnings subsumed by others are not on any of the list, or whatever the actual rule is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14229> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14711: Machine readable output of coverage
by GHC 14 Sep '18

14 Sep '18

#14711: Machine readable output of coverage -------------------------------------+------------------------------------- Reporter: Koterpillar | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Code Coverage | Version: 8.2.2 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 integrating with a CI system, it might be useful to fail the build, alert or take other actions based on coverage percentage. To do that, hpc needs to output a summary coverage report in a machine readable format. For example, the current output: {{{ 38% expressions used (1779/4624) 57% boolean coverage (16/28) 56% guards (9/16), 6 always True, 1 always False 58% 'if' conditions (7/12), 2 always False, 3 unevaluated 100% qualifiers (0/0) 7% alternatives used (103/1410) 75% local declarations used (102/136) 40% top-level declarations used (185/457) }}} can be represented as: {{{ { expressions: { total: 4624, used: 1779, percentage: 0.38 }, boolean: { total: 28, used: 16, percentage: 0.57 }, <...> } }}} This output can be then parsed to decide whether to fail the build, produce a coverage graph over time, etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14711> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14099: Document fundeps
by GHC 14 Sep '18

14 Sep '18

#14099: Document fundeps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: newcomers | 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 the documentation for functional dependencies in the GHC user's guide is quite poor. Fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14099> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray#
by GHC 14 Sep '18

14 Sep '18

#11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 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): | Wiki Page: -------------------------------------+------------------------------------- Currently, primops for indexing `ByteArray#` and reading/writing `MutableByteArray#` have the following form: {{{#!hs indexTYPEArray# :: ByteArray# -> Int# -> TYPE# readTYPEArray# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, TYPE##) writeTYPEArray# :: MutableByteArray# s -> Int# -> TYPE# -> State# s -> State# s }}} where second argument of type `Int#` is an offset measured in terms of the size of `TYPE#`. This is inconvinient if I want to store values of different types inside `ByteArray#`: I have to read values of type `Int8` and then glue them together with some bitwise operations. I suggest adding number of primops, similar to existing ones, which would accept offset in bytes from the start of the `ByteArray#`: {{{#!hs -- | Read 8-bit integer; offset in bytes. indexByteInt8Array# :: ByteArray# -> Int# -> Int# -- | Read 16-bit integer; offset in bytes. indexByteInt16Array# :: ByteArray# -> Int# -> Int# -- | Read 32-bit integer; offset in bytes. indexByteInt32Array# :: ByteArray# -> Int# -> Int# -- | Read 8-bit integer; offset in bytes. readInt8Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) -- | Read 16-bit integer; offset in bytes. readInt16Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) -- | Read 32-bit integer; offset in bytes. readInt32Array# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, Int##) }}} and so on... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10700: include/stg/Prim.h isn't C++ compatible
by GHC 14 Sep '18

14 Sep '18

#10700: include/stg/Prim.h isn't C++ compatible -------------------------------------+------------------------------------- Reporter: Fabian | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Keywords: FFI | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- StgWord hs_cmpxchg8(volatile StgWord8 *x, StgWord old, StgWord new); and a few other declarations in Prim.h causes problems as they use ''new'' as a variable name. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8