November 2013 - ghc-tickets

[GHC] #8517: Add library function retrieve label set by GHC.Conc.Sync.labelThread
by GHC 18 Nov '14

18 Nov '14

#8517: Add library function retrieve label set by GHC.Conc.Sync.labelThread ------------------------------------+------------------------------------- Reporter: blitzcode | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It would be useful to be able to retrieve the label set by the labelThread function. For instance, a logging / tracing system could output a human readable string for the thread the trace originated from instead of just the thread ID. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES`
by GHC 18 Nov '14

18 Nov '14

#8558: Build xhtml and haddock only when `HADDOCK_DOCS=YES` ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- In order to save contributor’s time, and in order to run the test suite faster, I suggest to not builds haddock and its dependencies (xhtml, anything else?) if `HADDOCK_DOCS=YES` is specified. The change is rather simple: {{{ diff --git a/ghc.mk b/ghc.mk index dd91a82..b0f93a0 100644 --- a/ghc.mk +++ b/ghc.mk @@ -437,7 +437,9 @@ REGULAR_INSTALL_PACKAGES += compiler endif REGULAR_INSTALL_PACKAGES += $(addprefix libraries/,$(PACKAGES_STAGE2)) +ifeq "$(HADDOCK_DOCS)" "YES" PACKAGES_STAGE1 += xhtml +endif ifeq "$(Windows_Target)" "NO" ifneq "$(TargetOS_CPP)" "ios" PACKAGES_STAGE1 += terminfo @@ -652,8 +654,10 @@ BUILD_DIRS += libraries/integer-gmp/gmp BUILD_DIRS += libraries/integer-gmp/mkGmpDerivedConstants endif +ifeq "$(HADDOCK_DOCS)" "YES" BUILD_DIRS += utils/haddock BUILD_DIRS += utils/haddock/doc +endif BUILD_DIRS += compiler BUILD_DIRS += utils/hsc2hs BUILD_DIRS += utils/ghc-pkg }}} and it does not affect validate runs, as validate has `HADDOCK_DOCS` set to `YES`. If this is introduced, I suggest to annotate these two with a tag in packages, so that one can run `./sync-all get --no-haddock`, similar to `--no-dph`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8558> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8544: Auto-Reference ticket-related branches in tickets
by GHC 18 Nov '14

18 Nov '14

#8544: Auto-Reference ticket-related branches in tickets ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This has two possible implementations (and both are useful and can complement each other): * Add a new field to the description „Related branch“. If for ticket #1234 there is a branch matching `T1234` (usually something like `wip/T1234`), link it from there. * When such a branch is created or deleted, post a message to the ticket. This way subscribers know about a possible ongoing implementation, and can review it. These should link somewhere I believe `https://ghc.haskell.org/trac/ghc/log/ghc?rev=<branchname>` is the most useful link. If the link is part of the „branch created“ message, it will become dangling after the branch is closed (presumably because the feature was merged; then the actually commits, if they reference the bug, will be auto-linked). I don’t think this is a problem. But if that is a problem, only put the link in the “Related branches” field, and clear it when the branch is deleted. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8544> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8527: container's Typeable.h is being shadowed by base's Typeable.h during preprocessing
by GHC 17 Nov '14

17 Nov '14

#8527: container's Typeable.h is being shadowed by base's Typeable.h during preprocessing ------------------------------------+------------------------------------- Reporter: parcs | Owner: parcs Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Here's a reduced test case: == cpp.hs == {{{ #!haskell {-# LANGUAGE CPP #-} #include "Typeable.h" main = return () }}} == command line == {{{ $ ghc-stage2 -c -package base cpp.hs In file included from cpp.hs:4:0: /home/patrick/code/ghc/libraries/base/include/Typeable.h:17:2: warning: #warning <Typeable.h> is obsolete and will be removed in GHC 7.10 [-Wcpp] #warning <Typeable.h> is obsolete and will be removed in GHC 7.10 ^ compilation IS NOT required $ ghc-stage2 -c -package base -package containers cpp.hs compilation IS NOT required $ ghc-stage2 -c -package containers -package base cpp.hs }}} Notice that if I pass `-package containers` to ghc, the cpp warning from Typeable.h (from the base library) doesn't appear. This is because containers also has a Typeable.h in its include path, and in the invocation of the preprocessor, containers' include path precedes base's no matter how I order the `-package` directives. This behavior is intuitive and limiting. To fix this, I think that the ordering of -I directives passed to the preprocessor should be consistent with the ordering of -package directives passed to ghc. For example, in the above test case, a warning should be shown in the 1st and 2nd invocations of ghc but not the 3rd, because in the 3rd invocation containers precedes base. Does this sound okay? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8527> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8528: Preprocessor issues building GHC HEAD on Mavericks
by GHC 17 Nov '14

17 Nov '14

#8528: Preprocessor issues building GHC HEAD on Mavericks ----------------------------------+---------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Building GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------------- I can't build GHC HEAD on Mavericks with Xcode 5 and GCC 4.2. My system: * Mavericks, Xcode 5. * Building with GHC 7.6.3 x64 installed from . * Apple GCC 4.2 installed via homebrew. In /Library/Frameworks/GHC.framework/Versions/7.6.3-x86_64/usr/lib/ghc-7.6.3/settings, I've changed the compiled to this: ("C compiler command", "/Users/nkpart/bin/gcc"), ~/bin/gcc is #!/bin/sh echo $* >> ~/bin/gcc_log gcc-4.2 $@ I have run: $ git clone .. $ perl boot $ ./configure $ make The error I get is: "/usr/bin/ghc" -M -static -H64m -O0 -fasm -package-db libraries/bootstrapping.conf -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -package array -no-user-package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build -dep-makefile utils/genprimopcode/dist/build/.depend.haskell.tmp -dep-suffix "" -include-pkg-deps utils/genprimopcode/dist/build/Lexer.hs utils/genprimopcode/./Main.hs utils/genprimopcode/./ParserM.hs utils/genprimopcode/dist/build/Parser.hs utils/genprimopcode/./Syntax.hs line-map.c: file "templates/GenericTemplate.hs" left but not entered utils/genprimopcode/dist/build/Lexer.hs:143:0: error: #else without #if utils/genprimopcode/dist/build/Lexer.hs:144:0: warning: "GTE" redefined utils/genprimopcode/dist/build/Lexer.hs:141:0: warning: this is the location of the previous definition utils/genprimopcode/dist/build/Lexer.hs:145:0: warning: "EQ" redefined utils/genprimopcode/dist/build/Lexer.hs:142:0: warning: this is the location of the previous definition utils/genprimopcode/dist/build/Lexer.hs:146:0: error: #endif without #if utils/genprimopcode/dist/build/Lexer.hs:197:0: error: #else without #if utils/genprimopcode/dist/build/Lexer.hs:200:0: error: #endif without #if make[1]: *** [utils/genprimopcode/dist/build/.depend.haskell] Error 1 make: *** [all] Error 2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8528> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8545: Reorganize Git repositories
by GHC 17 Nov '14

17 Nov '14

#8545: Reorganize Git repositories ------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Trac & Git | Version: Keywords: git | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8251 | ------------------------------------+------------------------------------- This is to track the progress for the GitRepoReorganization which is to be tackled post-7.8 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8545> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8559: Compiling dph-lifted fails with "NoSpecConstr" not in scope
by GHC 17 Nov '14

17 Nov '14

#8559: Compiling dph-lifted fails with "NoSpecConstr" not in scope -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Data Parallel | Version: 7.7 Haskell | Operating System: Linux Keywords: | Type of failure: Building GHC Architecture: powerpc64 | failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Building ghc-7.7.20131120 fails with this on powerpc64 Linux: {{{ "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -package-name dph-lifted-copy-0.8.0.1 -hide-all-packages -i -ilibraries/dph/dph-lifted-copy/. -ilibraries/dph/dph-lifted-copy/dist- install/build -ilibraries/dph/dph-lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/dist-install/build -Ilibraries/dph/dph- lifted-copy/dist-install/build/autogen -Ilibraries/dph/dph-lifted-copy/. -optP-include -optPlibraries/dph/dph-lifted-copy/dist- install/build/autogen/cabal_macros.h -package array-0.5.0.0 -package base-4.7.0.0 -package dph-base-0.8.0.1 -package dph-prim-par-0.8.0.1 -package ghc-7.7.20131115 -package random-1.0.1.1 -package template- haskell-2.9.0.0 -package vector-0.10.9.1 -Odph -funbox-strict-fields -fcpr-off -fno-warn-orphans -fno-warn-missing-signatures -XHaskell98 -XTypeFamilies -XGADTs -XRankNTypes -XBangPatterns -XMagicHash -XUnboxedTuples -XTypeOperators -O2 -no-user-package-db -rtsopts -odir libraries/dph/dph-lifted-copy/dist-install/build -hidir libraries/dph/dph-lifted-copy/dist-install/build -stubdir libraries/dph /dph-lifted-copy/dist-install/build -c libraries/dph/dph-lifted- copy/./Data/Array/Parallel/PArray/PData.hs -o libraries/dph/dph-lifted- copy/dist-install/build/Data/Array/Parallel/PArray/PData.o [23775s] [23775s] libraries/dph/dph-lifted- copy/Data/Array/Parallel/PArray/PData.hs:49:20: [23775s] Not in scope: data constructor `NoSpecConstr' [23775s] make[1]: *** [libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/PData.o] Error 1 [23775s] make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8559> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8427: GHC accepts invalid program because of EPS poisoning
by GHC 10 Nov '14

10 Nov '14

#8427: GHC accepts invalid program because of EPS poisoning -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC accepts Difficulty: Moderate (less | invalid program than a day) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Assume the following setup: - compiling in batch mode (`--make`), - package klassz, module Class contains the class "Class a" and the data "Data", - package klassz, module A contains an (orphan) instance "Class Data", - package main, module AImporter just imports A, - package main, module B imports only Class, but uses the instance (invalidly); then - if package main, module Main imports B, later imports AImporter; then it compiles; - if package main, module Main imports AImporter, later imports B, then it doesn't compile. The attached tgz contains this setup. `diff -u main-docompile main- nocompile` shows that the only difference between the two main directories is the order of import statements. The language definitely doesn't accept compilation success to depend on import ordering, therefore this is a bug. My current understanding is that the issue is that this code should never compile, both mains should be rejected, since module B imports only the class, but not the instance. The issue is that the EPS is only ever increased, never decreased between compilation of different modules in a single batch compilation. This naïve approach causes the instances to be loaded and then never unloaded, so it can be magically found when compiling the invalid B module. The current code can be found in [[GhcFile(compiler/iface/LoadIface.hs)]] line 280. I propose to instead of always loading ifaces into the EPS directly, introduce a proper cache for interfaces, that contains parsed up interface data in a `ModuleEnv`. Then we can start up with an empty EPS at the beginning of the compilation of every unit and quickly merge info from this cache. I guess the majority of time is the file reading IO and the parsing, not the merging of multiple interface files together. I also think that these kind of issues will get more and more prominent as people start to use parallel cabal and ghc, because if compilation of the attached example program is randomly parallelized, then in some cases it will build, some cases it won't. Any opinions, alternative fix ideas? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8427> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8482: Permission denied when copying file to current directory with copyFile
by GHC 03 Nov '14

03 Nov '14

#8482: Permission denied when copying file to current directory with copyFile -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.6.3 libraries/directory | Operating System: Windows Keywords: copyFile | Type of failure: Incorrect result permission denied | at runtime Architecture: x86 | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- While the MS-DOS command {{{ C:\tmp\b>copy c:\tmp\a\x }}} runs successfully, the Haskell equivalent {{{ copyFile "c:\\tmp\\a\\x" "" }}} results in {{{ copyFile.hs: .\.copyFile584.tmp: copyFile: does not exist (Het systeem kan het opgegeven pad niet vinden.) }}} The Dutch explanation says: "The system can not find the specified path" {{{ copyFile "c:\\tmp\\a\\x" "." }}} results in {{{ copyFile.hs: .\.copyFile3960.tmp: copyFile: permission denied (Toegang geweigerd.) }}} The Dutch explanation says: "Access denied" -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8482> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8261: Windows Testsuite stuck at configuring timeout
by GHC 02 Nov '14

02 Nov '14

#8261: Windows Testsuite stuck at configuring timeout ------------------------------+--------------------------------- Reporter: leroux | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------+--------------------------------- When running the testsuite, it gets stuck at {{{Configuring timeout-1...}}}. I tried adding a verbosity flag to the ENV vars, but they didn't make any affect on the {{{./Setup}}} args. Relating to my development setup...I've followed the instructions from http://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows (using MinGW). I was rather surprised when I was building GHC, it threw an error saying that "libmpfr-3.dll" was missing, so I fetched that from a cygwin mirror and threw it in {{{msys/bin}}}, but even after doing that, I got errors saying that it could find certain cygwin libraries ({{{cyg*.dll}}}). So I just installed the entirety of cygwin and it started working fine. The only ticket I found that is related to this is #1599, but I'm not sure. ---- System details: {{{ # Windows 7 x86 (32-bit) $ uname -a MINGW32_NT-6.1 LEROUX-WINBUILD 1.0.18(0.48/3/2) 2012-11-21 22:34 i686 Msys $ echo $PATH /c/MinGW/bin:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files/Haskell/bin:/c/Program Files/Haskell Platform/2013.2.0.0/lib/extralibs/bin:/c/ Program Files/Haskell Platform/2013.2.0.0/bin:/c/Windows/system32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v 1.0/:/c/Program Files/Haskell Platform/2013.2.0.0/mingw/bin:/c/Program Files/Git/cmd:/c/Users/leroux/AppData/Roaming/cabal/bin:/mingw/bin:/us r/bin:/c/cygwin/bin }}} ---- Here's the testsuite run: {{{ $ make test WAY=normal make -C testsuite/tests CLEANUP=1 OUTPUT_SUMMARY=../../testsuite_summary.txt fast make[1]: Entering directory `/home/leroux/devel/ghc- validate/testsuite/tests' make fast=YES make[2]: Entering directory `/home/leroux/devel/ghc- validate/testsuite/tests' Looks like you don't have timeout, building it first... make -C ../timeout all make[3]: Entering directory `/home/leroux/devel/ghc- validate/testsuite/timeout' rm -rf install-inplace 'C:/MinGW/msys/1.0/home/leroux/devel/ghc-validate/inplace/bin/ghc- stage2.exe' --make Setup ./Setup configure --with-compiler='C:/MinGW/msys/1.0/home/leroux/devel /ghc-validate/inplace/bin/ghc-stage2.exe' \ --with-hc- pkg='C:/MinGW/msys/1.0/home/leroux/devel/ghc-validate/inplace/bin/ghc- pkg.exe' \ --with- hsc2hs='C:/MinGW/msys/1.0/home/leroux/devel/ghc- validate/inplace/bin/hsc2hs.exe' \ \ --ghc-option=-threaded --prefix='C:/MinGW/msys/1.0/home/leroux/devel/ghc- validate/testsuite/timeout/install-inplace ' Configuring timeout-1... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11