November 2018 - ghc-tickets

[GHC] #15826: Allow using (Source)Plugins through the GHC API
by GHC 11 Dec '18

11 Dec '18

#15826: Allow using (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- One might expect to be able to load plugins through the GHC API by doing something like: {{{ runGHC $ do dflags <- getSessionDynFlags setSessionDynFlags dflags { plugins = [LoadedPlugin some_plugin _conjure_up_modiface []] } }}} but this doesn't actually work because the `plugins` field in `DynFlags` is used as a cache and overwritten by `initializePlugins` whenever plugins loaded through the command-line need reloading. Not to mention that there isn't a meaningful way to fill the `_conjure_up_modiface` hole AFAIK. While in principle it might be possible to use source plugins via the API right now by messing with the exposed cmdline flags the right way it feels much cleaner to just have a new type of plugin that can be added to GHC right through the API. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15826> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #15854: PPC: Panic in native code generator
by GHC 11 Dec '18

11 Dec '18

#15854: PPC: Panic in native code generator ---------------------------------+---------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+---------------------------------------- Head fails on powerpc64le: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181103 for powerpc64le-unknown-linux): PPC.CodeGen.getRegister: no match Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.o' failed }}} I think I know what is going on and will work on a fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15854> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #14225: "No module named ... is imported" message is a bit misleading with qualified imports
by GHC 11 Dec '18

11 Dec '18

#14225: "No module named ... is imported" message is a bit misleading with qualified imports -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that the `No module named ... is imported` message produced in response to out-of-scope identifiers doesn't account for qualified imports. For instance, {{{ $ ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci λ> import qualified Data.Maybe as M λ> M.fromJusr <interactive>:2:1: error: Not in scope: ‘M.fromJusr’ Perhaps you meant ‘M.fromJust’ (imported from Data.Maybe) No module named ‘M’ is imported. λ> }}} I suppose there is the question of whether we consider `M` to be a "module" here; I would argue that I imported it and therefore the message is at very least a bit misleading. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15924: Do not save performance test results if work tree is dirty
by GHC 11 Dec '18

11 Dec '18

#15924: Do not save performance test results if work tree is dirty -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Keywords: performance | Operating System: Unknown/Multiple tests git notes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12758 Differential Rev(s): | Wiki Page: | Performance/Tests -------------------------------------+------------------------------------- The test driver will automatically save performance results to git notes. Notes are attached to commits, but if the working tree is dirty, performance characteristics my be affected and the saved results will not be valid. * Only save performance test results if work tree is dirty. * Bonus: don't save to a git note if we have 0 results. * Update wiki page. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15924> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15949: Hadrian needs more convenient build target names
by GHC 11 Dec '18

11 Dec '18

#15949: Hadrian needs more convenient build target names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- With the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to know the name of the final target which the build will produce which may contain version numbers, platform triples, and all sorts of other ugliness. I suggest we introduce a set of convenience targets to make this easier. For instance one could run: {{{ $ hadrian stage1:lib:ghc }}} to build the stage1 `ghc` library or {{{ $ hadrian stage2:exe:hp2ps }}} to build `hp2ps`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15949> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15946: configure script makes use of argument flag that is not supported in OpenBSD
by GHC 11 Dec '18

11 Dec '18

#15946: configure script makes use of argument flag that is not supported in OpenBSD -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: configure | Operating System: OpenBSD Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After some head-scratching, I found that the configure script makes use of the **-v** verbose flag. This flag does not exist in OpenBSD. It was causing the build process to fail due to some files not existing during the compilation process. I'm getting around this by removing all **-v** occurrences as a pre- compilation step: {{{ find . -type f | xargs sed -i -e 's|^ln -f -v |ln -f |' }}} To make the process a little smoother for other folks, perhaps creating an alias that is conditional based OS type at the header of the script along the lines of would be best: {{{ case "$build_os" in openbsd*) alias mksymlnk="ln -f" ;; *) alias mksymlnk="ln -f -v" ;; esac ... mksymlnk utils/fs/fs.* utils/lndir/ ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15946> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15904: hp2ps fail with parse error when the command args contains double quotes
by GHC 11 Dec '18

11 Dec '18

#15904: hp2ps fail with parse error when the command args contains double quotes -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.7 Keywords: hp2ps | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ watashi % cat test.hs main = pure () watashi % ghc -prof -rtsopts test.hs watashi % ./test '{"e": 2.72, "pi": 3.14}' +RTS -h watashi % hp2ps test.hp hp2ps: test.hp, line 1: integer must follow identifier }}} Manually open `test.hp` and remove the `"`s in `JOB` will mitigate the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15270: TH doesn't verify name types during conversion
by GHC 11 Dec '18

11 Dec '18

#15270: TH doesn't verify name types during conversion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.3 Haskell | 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: -------------------------------------+------------------------------------- Angerman reported that a use of the [[http://hackage.haskell.org/package /deriving-compat-0.4.2/docs/src/Data.Eq.Deriving.Internal.html#deriveEq1 `deriveEq`]] splice is causing GHC to abort with an assertion failure: {{{#!hs zonkExpr env (HsVar x (L l id)) = ASSERT2( isNothing (isDataConId_maybe id), ppr id ) return (HsVar x (L l (zonkIdOcc env id))) }}} I suspect the `deriveEq1` is calling `varE` with a DataCon name. We should catch this case and throw a better error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15847: GHCi cannot load .o built from c with -fPIC on i386 linux
by GHC 11 Dec '18

11 Dec '18

#15847: GHCi cannot load .o built from c with -fPIC on i386 linux -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.7 System (Linker) | Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi cannot load .o built from c with -fPIC on i386 linux. On i386 linux, the PIC object code looks like: {{{ 000001ac <hs_remWord64>: 1ac: 53 push %ebx 1ad: 83 ec 08 sub $0x8,%esp 1b0: e8 fc ff ff ff call 1b1 <hs_remWord64+0x5> 1b1: R_386_PC32 __x86.get_pc_thunk.bx 1b5: 81 c3 02 00 00 00 add $0x2,%ebx 1b7: R_386_GOTPC _GLOBAL_OFFSET_TABLE_ 1bb: ff 74 24 1c pushl 0x1c(%esp) 1bf: ff 74 24 1c pushl 0x1c(%esp) 1c3: ff 74 24 1c pushl 0x1c(%esp) 1c7: ff 74 24 1c pushl 0x1c(%esp) 1cb: e8 fc ff ff ff call 1cc <hs_remWord64+0x20> 1cc: R_386_PLT32 __umoddi3 1d0: 83 c4 18 add $0x18,%esp 1d3: 5b pop %ebx 1d4: c3 ret }}} 1. the GOT symbol `_GLOBAL_OFFSET_TABLE_` may be undefined 2. the runtime linker doesn't support PIC-related i386 relocations like `R_386_GOTPC` or `R_386_PLT32` As a result, we will see errors like `unknown symbol '_GLOBAL_OFFSET_TABLE_'` or `unhandled ELF relocation`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15847> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15920: Implement a flag which disables safe Haskell
by GHC 11 Dec '18

11 Dec '18

#15920: Implement a flag which disables safe Haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 adding a plugin to a module, it marks the module as unsafe. If I automatically run a plugin on every module I build then all the modules are therefore marked unsafe. This means that libraries start failing to compile as the safety properties change. However, I don't care about safe haskell and want to turn off this error but there appears to be no way to do so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6