January 2016 - ghc-tickets

Re: [GHC] #7277: Recompilation check fails for TH unless functions are inlined
by GHC 08 Jan '16

08 Jan '16

#7277: Recompilation check fails for TH unless functions are inlined -------------------------------------+------------------------------------- Reporter: orenbenkiki | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: 481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): Related #7414, which is the opposite problem but for plugins: we ALWAYS recompile, even when the implementation is the same. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7277#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9009: Confusing error message when loading package with TH
by GHC 08 Jan '16

08 Jan '16

#9009: Confusing error message when loading package with TH ------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I got this error message when compiling a file that calls Template Haskell function from `singletons` package: {{{ [1 of 1] Compiling Splices ( Splices.hs, Splices.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package syb-0.4.1 ... linking ... done. Loading package th-desugar-1.4.0 ... linking ... done. Loading package singletons-1.0 ... <command line>: can't load .so/.DLL for: /home/killy/.cabal/lib/x86_64-linux- ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so (/home/killy/.cabal/lib/x86_64-linux- ghc-7.8.2/singletons-1.0/libHSsingletons-1.0-ghc7.8.2.so: undefined symbol: singletonszm1zi0_DataziSingletonsziSingleziMonad_lookupProxy1_info) }}} After some investigation it turned out that the module Data.Singletons.Single.Monad was not listed in singletons.cabal file - neither under exported-modules nor other-modules - when the package was installed. The error message is mostly confusing. It would be good to at least get a hint on the possible cause. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9009> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules
by GHC 08 Jan '16

08 Jan '16

#8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules -----------------------------------+--------------------------------------- Reporter: tvynr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- I have constructed two Cabal projects named "first" and "second". The "first" project defines three files: Logging.hs (which provides some basic logging functionality) and FirstExample.hs and FirstDependent.hs (the latter of which imports the former). In the cabal file, only Logging and FirstDependent are exposed modules. FirstDependent uses a Template Haskell function "loggingFunctions" which defines logging functions for that module. Using cabal or cabal-dev to build this package works quite nicely. The second project depends on the first project and contains a single file, Second.hs. This file imports Logging but neither of the other two files. It also uses the loggingFunctions routine to generate local logging functions. The presence of the "$(loggingFunctions)" splice in Second.hs makes the problem visible, but the real problem is in the first project. Upon compilation of the "second" project with cabal or cabal- dev, the following error is generated: {{{ cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal configure Resolving dependencies... Configuring second-0.1... cabal-dev -s ../cabal-dev-sandbox --with-cabal-install=cabal build Building second-0.1... Preprocessing library second-0.1... [1 of 1] Compiling Second ( lib-src/Second.hs, dist/build/Second.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package filepath-1.3.0.1 ... linking ... done. Loading package old-locale-1.0.0.5 ... linking ... done. Loading package time-1.4.0.1 ... linking ... done. Loading package bytestring-0.10.0.2 ... linking ... done. Loading package unix-2.6.0.1 ... linking ... done. Loading package directory-1.2.0.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package text-0.11.3.1 ... linking ... done. Loading package parsec-3.1.3 ... linking ... done. Loading package network-2.4.1.2 ... linking ... done. Loading package process-1.1.0.2 ... linking ... done. Loading package hslogger-1.2.1 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package first-0.2 ... linking ... ghc: /home/some- directories/example/first/../cabal-dev- sandbox//lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o: unknown symbol `firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure' ghc: unable to load package `first-0.2' make[1]: *** [build] Error 1 }}} Upon further investigation, it would seem that the .o file constructed to represent the "first" project has not been completely constructed: {{{ $ objdump -t cabal-dev- sandbox/lib/first-0.2/ghc-7.6.1.20121207/HSfirst-0.2.o | grep '\*UND\*' | grep first 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczg_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfShowErrorSpec3_closure 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczl_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfEqErrorSpeczuzdczeze_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczlze_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdccompare_info 00000000 *UND* 00000000 firstzm0zi2_FirstExample_zdfOrdErrorSpeczuzdczgze_info }}} (While the above dump is for ghc 7.6.1, this has also been tested on ghc 7.6.3 as well as on both i386- and amd64-based OS installs.) If the "$(loggingFunctions)" splice is removed from Second.hs, then the project builds (presumably because the logic used by non-Template Haskell projects for linking differs from that of Template Haskell projects). Fortunately, it seems that exposing every module of the "first" project resolves this issue. But please note that the FirstExample.hs and FirstDependent.hs files are completely unrelated to the Second.hs file; the latter does not depend on the former in any way. It seems strange that I can't use Template Haskell across projects without exposing all of my project modules. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8060> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11373: GHC should support static archive creation on all systems
by GHC 07 Jan '16

07 Jan '16

#11373: GHC should support static archive creation on all systems -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 7.11 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, we have in `DriverPipeline.hs`: {{{ linkStaticLibCheck :: DynFlags -> [String] -> [UnitId] -> IO () linkStaticLibCheck dflags o_files dep_packages = do when (platformOS (targetPlatform dflags) `notElem` [OSiOS, OSDarwin]) $ throwGhcExceptionIO (ProgramError "Static archive creation only supported on Darwin/OS X/iOS") linkBinary' True dflags o_files dep_packages }}} Seems a bit odd/awful for this to only work on OS X. Either we should support none of it (not GHC's job) or all of it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11373> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1853: hpc mix files for Main modules overwrite each other
by GHC 07 Jan '16

07 Jan '16

#1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by ezyang): So, in some sense, you are actually completely screwed, because at runtime the executable producing Tix files has no idea if it was compiled from `Main1.hs` or `Main2.hs`: the symbol names for the two executables live in the same namespace, etc. There is actually a very cunning way this problem could be fixed: 1. `-main-is` could be extended to work with modules which are not in the `main` package. 2. Executables could then be compiled while setting `-package-name` to something that is not `main`. Then the symbol names would be different and you could merge them reliably. The alternative is that HPC can be told explicitly that a mix file is for a specific file name (extending it's model to not be profiling a pile of `Module`s, but a pile of `Module`s or files). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1853#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #10186, #10139, #9554, #10140, #10132, #10112, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10186, #10139, #9554, #10140, #10132, #10112, #10026, #10040, #9973, #9972, #9939 by thomie: milestone to 8.0.1 Action: leave -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10186%2C10139%2C9554%2C10140%2C101…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9969: panic in T7562
by GHC 07 Jan '16

07 Jan '16

#9969: panic in T7562 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: T7562 | Blocked By: Blocking: | Related Tickets: #7562 Differential Revisions: | -------------------------------------+------------------------------------- Various people observe this test failure: {{{ =====> T7562(normal) 869 of 4389 [0, 0, 0] cd ./typecheck/should_compile && '/home/jojo/build/haskell/ghc- validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci- history -c T7562.hs -fno-warn-incomplete-patterns >T7562.comp.stderr 2>&1 Compile failed (status 256) errors were: T7562.hs:3:14: Warning: UNPACK pragma lacks '!' on the first argument of ‘Pair2’ In the definition of data constructor ‘Pair2’ In the data declaration for ‘Pair2’ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150108 for x86_64-unknown-linux): toIfaceBang Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} According to my logs, this was caused by changeset:9564bb8c84cbc0397a414e946cc8c28801f0fbe7/ghc -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9969> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] Batch modify: #10407, #10384, #9851, #10306, #10121, #10325, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10407, #10384, #9851, #10306, #10121, #10325, #10281, #10180, #10265, #9958, #10191 by thomie: milestone to 8.0.1 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10407%2C10384%2C9851%2C10306%2C101…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #8555, #8799, #9131
by GHC 07 Jan '16

07 Jan '16

Batch modification to #8555, #8799, #9131 by thomie: Action: leave Comment: For future reference: commit 0cc47eb90805f3e166ac4d3991e66d3346ca05e7 {{{ Author: Richard Eisenberg <eir(a)cis.upenn.edu> Date: Fri Dec 12 17:19:21 2014 -0500 Rewrite `Coercible` solver Summary: This is a rewrite of the algorithm to solve for Coercible "instances". A preliminary form of these ideas is at https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver The basic idea here is that the `EqPred` constructor of `PredTree` now is parameterised by a new type `EqRel` (where `data EqRel = NomEq | ReprEq`). Thus, every equality constraint can now talk about nominal equality (the usual case) or representational equality (the `Coercible` case). This is a change from the previous behavior where `Coercible` was just considered a regular class with a special case in `matchClassInst`. Because of this change, representational equalities are now canonicalized just like nominal ones, allowing more equalities to be solved -- in particular, the case at the top of #9117. A knock-on effect is that the flattener must be aware of the choice of equality relation, because the inert set now stores both representational inert equalities alongside the nominal inert equalities. Of course, we can use representational equalities to rewrite only within another representational equality -- thus the parameterization of the flattener. A nice side effect of this change is that I've introduced a new type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness in the flattener. This commit includes some refactoring as discussed on D546. It also removes the ability of Deriveds to rewrite Deriveds. This fixes bugs #9117 and #8984. Reviewers: simonpj, austin, nomeata Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D546 GHC Trac Issues: #9117, #8984 }}} -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=8555%2C8799%2C9131> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] Batch modify: #10670, #10632, #10463, #10570, #10561, #10351, ...
by GHC 07 Jan '16

07 Jan '16

Batch modification to #10670, #10632, #10463, #10570, #10561, #10351, #9665, #10573, #10414, #10519, #10569, #10420, #10503, #10533, #10211, #10485, #10474, #10461, #10466, #10423, #8292 by thomie: milestone to 8.0.1 -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=10670%2C10632%2C10463%2C10570%2C10…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0