October 2015 - ghc-tickets

Re: [GHC] #7988: Big integers crashing integer-simple on qnxnto-arm
by GHC 20 Oct '15

20 Oct '15

#7988: Big integers crashing integer-simple on qnxnto-arm ----------------------------------+--------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: QNX | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+--------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7988#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10981: Not detecting clang correctly
by GHC 20 Oct '15

20 Oct '15

#10981: Not detecting clang correctly -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have Jenkins build job that builds GHC from Git using Clang as the C compiler. Recently a Debian update changed clang's `-v1 output to: {{{ Debian clang version 3.5.2-2 (tags/RELEASE_352/final) (based on LLVM 3.5.2) Target: x86_64-pc-linux-gnu Thread model: posix }}} which is no longer being detected by `compiler/main/SysTools.hs` as `Clang`. Working around this is trivially easy. Patch in progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10981> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #602: Warning Suppression
by GHC 20 Oct '15

20 Oct '15

#602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edgar.zhavoronkov): Hi everyone! Do someone know, if there is such pragma or i need to implement it myself? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/602#comment:22> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10985: When a "non-exhaustive pattern"-error occurs, output the arguments (if possible)
by GHC 20 Oct '15

20 Oct '15

#10985: When a "non-exhaustive pattern"-error occurs, output the arguments (if possible) -------------------------------------+------------------------------------- Reporter: Watercrystal | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Debugging) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10972 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For Haskell-beginners like me, "non-exhaustive pattern"-errors occur rather often and they can take some time to fix. While it is obvious that one has made a critical mistake when writing a function, I don't think adding some debugging help would certainly not be bad. I know that this feature only really makes sense when working with types that are instances of `Show`, but then again beginners find themselves working with these types. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10985> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs
by GHC 19 Oct '15

19 Oct '15

#9360: GHCi: Behave nicely on `-e`, like `ghc` and other programs -------------------------------------+------------------------------------- Reporter: mcandre | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Like many programming language environments, GHC offers a handy `-e` option for evaluating an expression, then returning to the shell. {{{ $ ghc -e '2 + 2' 4 }}} One would expect the interpreter, GHCi, to offer a similar flag, but it surprisingly rejects it. {{{ ghci -e '2 + 2' ghc: on the commandline: cannot use `--interactive' with `-e' Usage: For basic information, try the `--help' option. }}} I think this behavior is quite unintuitive--when I pass `-e <exp>` to ghci, or pass `--interactive -e <exp>` to ghc, I expect the expression to be evaluated as the leading expression in an interactive interpreter session. Could we please tweak ghc like this to make it slightly more intuitive when these flags are used together? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9360> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10983: Installing GHC with Centos 7
by GHC 19 Oct '15

19 Oct '15

#10983: Installing GHC with Centos 7 -------------------------------------+------------------------------------- Reporter: | Owner: scott_wilson46 | Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Hi, I've spent about half an hour of fruitless searching to try and get round this issue. It seems that there is no libgmp.so.3 on Centos 7 so I can't get GHC installed via any of the methods suggested. I even tried building gmp from source but this only gave me a static library for libgmp (libgmp.la), so am pretty frustrated really. Any ideas on how to get past this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10983> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10951: HPC program has poor error reporting / strange CLI in general
by GHC 19 Oct '15

19 Oct '15

#10951: HPC program has poor error reporting / strange CLI in general -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Code Coverage | 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): | -------------------------------------+------------------------------------- 1. Many erroneous usages of the hpc program result in reporting 100% (0/0) coverage. Proposed resolution: * Report an error and exit with failure. I can't think of a legitimate case where you would want a report that doesn't consider any expressions / declarations. * If a --include flag is specified, I think it would be valuable to output all the module names, so that it's clearer why the --include flag didn't work. * At the very least, (0/0) coverage shouldn't be reported as "100%". 2. Positional arguments after the initial tix file get interpreted as --include filters, filtering which modules / packages are considered. By default, HPC includes all modules in the report, unless include filters are supplied. If you accidentally provide a positional argument which isn't a valid thing for "--include", then your reports will always be (0/0) coverage. Proposed resolution: * Deprecate using positional arguments for include filters. This way it will complain about this instead of yielding trivial (0/0) coverage reports 3. Ideally, you'd be able to pass in multiple tix files and combine them in memory instead of using "hpc combine" and generating intermediate tix files. This would be a better usage of positional arguments than include filters. For now, the additional tix files would need to be flag arguments. This also isn't all that useful until https://ghc.haskell.org/trac/ghc/ticket/1853 is fixed. 4. `--srcdir`, `--hpcdir`, and `--reset-hpcdirs` interface has strange semantics for searching for mix files. It literally does something roughly like `[sd </> hd | sd <- srcDirs, hd <- hpcDirs]`, and uses this when looking for mix files. This would be OK, except that the `srcdir` must be the work dir used for compilation, in order for source markup to be generated. This means that you are tied to having your hpcdir be a sub-directory of the compilation work dir. Proposed resolution: * Add `--mixdir`, specifying a path to a mix file directory. Can be supplied multiple times. If `--mixdir` is provided, then it's an error to also use `--hpcdir` / `--reset-hpcdirs`. Instead of fixing the hpc program, I have considered forking it and giving it a new executable name, so that the CLI and behavior can be entirely changed. Thoughts on this alternative? It is appealing because it seems tricky to fix the hpc program's CLI while ensuring that backwards compatibility is maintained. I am keen on working on fixing this situation, but I want consensus from y'all about the approach that should be taken. Maybe it makes sense for this hpc-ng program to be developed outside of the GHC repo? This way it can use more recent libraries for generating HTML and parsing command line arguments. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10951> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #1853: hpc mix files for Main modules overwrite each other
by GHC 19 Oct '15

19 Oct '15

#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 mgsloan): Hi, thanks for the response Andy! Handily, I already had a minimal repro for this from back when I initially started working on coverage support in stack: https://github.com/mgsloan /multi-test-suite In particular: {{{ mgsloan@computer:~/fpco/multi-test-suite$ cabal test --ghc-options -fhpc # ...mgsloan@computer:~/fpco/multi-test-suite$ hpc report multi-test- suite-test.tix hpc: can not find Main in ["./.hpc"] mgsloan@computer:~/fpco/multi-test-suite$ hpc report multi-test-suite- test-2.tix 50% expressions used (1/2) 100% boolean coverage (0/0) 100% guards (0/0) 100% 'if' conditions (0/0) 100% qualifiers (0/0) 100% alternatives used (0/0) 100% local declarations used (0/0) 100% top-level declarations used (1/1) }}} This issue will also affect cabal files that have other stanzas like executables and benchmarks. I added a folder called sub-package to multi- test-repo, actually debug / test out a different stack coverage related issue. The only reasonable way I can think of to fix this is to add a flag to GHC, which takes the name to use for the mix file folder. This won't directly fix the problem with current Cabal, but it would allow future version of Cabal to pass the info so that this issue is resolved. I'm not sure what to call the flag - it doesn't necessarily need to be specific to HPC - since there might be other places in GHC that benefit from knowing the cabal component. So, I'm thinking either `-component- name`, or `-hpc-component-name`. I took a look at Cabal's current invocations of GHC to see if there is any way for GHC to know that it's building a particular executable component. Unfortunately, I don't see any arguments that would make a good source for this info: {{{ /usr/local/bin/ghc --make -no-link -fbuilding-cabal-package -O -j8 -static -outputdir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -odir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -hidir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -stubdir dist/build/multi-test-suite-test/multi-test-suite-test-tmp -i -idist/build /multi-test-suite-test/multi-test-suite-test-tmp -itest -idist/build/autogen -Idist/build/autogen -Idist/build/multi-test-suite- test/multi-test-suite-test-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages -package-db dist/package.conf.inplace -package-id base-4.8.1.0-4f7206fd964c629946bb89db72c80011 -package-id multi-test- suite-0.1.0.0-inplace -XHaskell2010 test/Spec.hs -threaded -rtsopts '-with-rtsopts=-N' -fhpc }}} (Sorry, the naming isn't all that clear, `multi-test-suite-test` is the name of the component) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1853#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 19 Oct '15

19 Oct '15

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, Wiki Page: | Phab:D1268 -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:123> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
by GHC 18 Oct '15

18 Oct '15

#3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) ---------------------------------+----------------------------- Reporter: jeffz1 | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #7097 | Differential Rev(s): Wiki Page: | ---------------------------------+----------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0