- ghc-devs - Haskell.org

CircleCI currently failing - possibly due to lack of disk space?
by Matthew Pickering 31 Oct '18

31 Oct '18

The bridge which sends diffs to circleci is currently failing with the following error: {"args":["clone","ssh://git@phabricator-origin.haskell.org:2222/diffusion/GHCDIFF/GHC-Differentials.git","/tmp/ghc-diffs-1008dbb33e68821b"],"prog":"git","code":128,"err":"Clonage dans '/tmp/ghc-diffs-1008dbb33e68821b'...\nfatal: Impossible d'accéder au répertoire de travail courant: No such file or directory\nfatal: échec de index-pack\n","type":"Non-zero exit code","out":""} https://phabricator.haskell.org/harbormaster/build/62371/2/ https://github.com/alpmestan/phab-circleci-bridge/blob/master/src/Main.hs#L… The repo is 150mb big so it is possible that the machine running the bridge has run out of disk space as it clones this repo repeatedly. Could someone look into this? Cheers, Matt

2 1

ghc-prim package-data.mk failed
by Simon Peyton Jones 30 Oct '18

30 Oct '18

This has started happening when I do 'sh validate -no-clean' "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install --with-ghc="/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --enable-shared --with-hscolour="/home/simonpj/.cabal/bin/HsColour" --configure-option=CFLAGS="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold" --with-ar="ar" --with-alex="/home/simonpj/.cabal/bin/alex" --with-happy="/home/simonpj/.cabal/bin/happy" Configuring ghc-prim-0.5.3... configure: WARNING: unrecognized options: --with-compiler checking for gcc... /usr/bin/gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking whether GCC supports __atomic_ builtins... no configure: creating ./config.status config.status: error: cannot find input file: `ghc-prim.buildinfo.in' libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/package-data.mk' failed make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 I think it is fixed by saying 'sh validate' (i.e. start from scratch). But that is slow. I'm not 100% certain about the circumstances under which it happens, but can anyone help me diagnose what is going on when it does? Thanks SImon

3 3

Hitting RTS bug on GHC 8.0.2
by Harendra Kumar 30 Oct '18

30 Oct '18

Hi, I got the following crash in one of my CI tests ( https://travis-ci.org/composewell/streamly/jobs/448112763) test: internal error: RELEASE_LOCK: I do not own this lock: rts/Messages.c 54 (GHC version 8.0.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I have hit this just once yet. Is this worth opening a ticket, given that this is an older version of the compiler? Has something like been fixed since then or might this be present in newer versions as well? -harendra

2 2

Re: [GHC DevOps Group] The future of Phabricator
by Ben Gamari 30 Oct '18

30 Oct '18

Andres Löh <andres(a)well-typed.com> writes: > Hi. > >> Unfortunately, if I am not mistaken, GitLab also has a big problem. It requires the use of GitLab CI — i.e., we cannot use CircleCI and Appveyor with it. (At least, that is my current understanding. Please correct me if I am wrong.) > > Just a clarification on this issue. > > I might be wrong, but my understanding is that: > > - Gitlab offers its own Gitlab CI, but it doesn't force you to use it, > and doesn't prevent you from using other CI solutions. > > - Web-based CI solutions have to specifically support Gitlab for you to > be able to use them with Gitlab. > > - To my knowledge, Appveyor supports Gitlab, but Circle and Travis > currently do not. I know that there are issues open for these systems > to support Gitlab, but I have no idea whether this is likely to happen > anytime soon. For example, for Circle, the discussion seems to be > here: https://circleci.com/ideas/?idea=CCI-I-248 > That is entirely correct; however, we have already invested the effort to build a bridge between Phabricator and CircleCI (only to have deployment complicated by an apparent Phabricator bug). The implementation of this didn't take particularly long and I expect migrating this work to GitLab would be if anything easier (since GitLab has a more-standard REST interface than Phabricator's Conduit). Cheers, - ben

1 0

Using GHC Core as a Language Target
by Ara Adkins 29 Oct '18

29 Oct '18

Hey All, I was chatting to SPJ about the possibility of using GHC Core + the rest of the GHC compilation pipeline as a target for a functional language, and he mentioned that asking here would likely be more productive when it comes to the GHC API. I'm wondering where the best place would be for me to look in the API for building core expressions, and also whether it is possible to trigger the GHC code-generation pipeline from the core stage onwards. Best, Ara

3 4

CI status
by Ben Gamari 29 Oct '18

29 Oct '18

Hi everyone, As you likely have noticed, GHC's CI is a bit of a mess since the Hadrian merge, especially for differentials based on commits prior to the merge. The problem is a tiresome limitation of Harbormaster's CI strategy [1]. I have taken this opportunity to finally move testing of Differentials to CircleCI. Unfortunately this has taken longer than anticipated due to more tiresome Phabricator issues. At the moment the only guidance I can offer for those in need of CI is to sit tight; the problem is being worked on. Cheers, - Ben [1] Namely, Harbormaster attempts to reuse working trees to perform builds. However, it fails to remove stale submodules, meaning any attempt to checkout a post-Hadrian-merge commit fails.

1 0

Treatment of unknown pragmas
by Ben Gamari 28 Oct '18

28 Oct '18

Hi everyone, Recently Neil Mitchell opened a pull request [1] proposing a single-line change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the lexer for every tool that wants a pragma seems quite unsustainable. On the other hand, a reasonable counter-argument could be made on the basis of the Haskell Report, which specifically says that implementations should ignore unrecognized pragmas. If GHC did this (instead of warning, as it now does) then this wouldn't be a problem. Of course, silently ignoring mis-typed pragmas sounds terrible from a usability perspective. For this reason I proposed that the following happen: * The `{-# ... #-}` syntax be reserved in particular for compilers (it largely already is; the Report defines it as "compiler pragma" syntax). The next Report should also allow implementations to warn in the case of unrecognized pragmas. * We introduce a "tool pragma" convention (perhaps even standardized in the next Report). For this we can follow the model of Liquid Haskell: `{-@ $TOOL_NAME ... @-}`. Does this sound sensible? Cheers, - Ben [1] https://github.com/ghc/ghc/pull/204

14 36

[ANNOUNCE] GHC 8.4.4 released
by Ben Gamari 27 Oct '18

27 Oct '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.4, a patch-level release in the 8.4 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.4 This release fixes several bugs present in 8.4.3 These include, - A bug which could result in memory unsafety with certain uses of `touch#` has been resolved. (#14346) - A compiler panic triggered by some GADT record updates has been fixed (#15499) - The `text` library has been updated, fixing several serious bugs in the version shipped with GHC 8.4.3 (see `text` issues #227, #221, and #197. - A serious code generation bug in the LLVM code generation, potentially resulting in incorrect evaluation of floating point expressions, has been fixed (#14251) As always, the full release notes can be found in the users guide, https://downloads.haskell.org/~ghc/8.4.4/docs/html/users_guide/8.4.4-notes.… Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here:

7 9

can't get docs / sphinx building for ghc 8.4.4
by Carter Schonwald 26 Oct '18

26 Oct '18

hello all, i'm getting the following error quite consistently on OSX, for getting the docs working / built and its quite impossible to install if the docs aren't fully built i've bolded below an except how do i fix thisssss please help meeeee :) many thanks. *Extension error:* *The 'ghc-flag' directive is already registered to domain std* *docs/users_guide/ghc.mk:16 <http://ghc.mk:16>: recipe for target 'docs/users_guide/users_guide.pdf' failed* *make[1]: *** [docs/users_guide/users_guide.pdf] Error 2* *make[1]: *** Waiting for unfinished jobs....* *Extension error:* *The 'ghc-flag' directive is already registered to domain std* *Extension error:* *The 'ghc-flag' directive is already registered to domain std* *docs/users_guide/ghc.mk:28 <http://ghc.mk:28>: recipe for target 'docs/users_guide/build-man/ghc.1' failed* the full end of the build is as follows any /usr/local/bin/ginstall -c -m 755 utils/genapply/dist/build/tmp/genapply inplace/lib/bin/genapply cp libffi/build/inst/lib/libffi.a rts/dist/build/libCffi.a "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries/ghc-prim/dist-install/build -ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist-install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc-prim -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist-install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc-prim/./GHC/Tuple.hs -o libraries/ghc-prim/dist-install/build/GHC/Tuple.o -dyno libraries/ghc-prim/dist-install/build/GHC/Tuple.dyn_o Running Sphinx v1.8.1 Running Sphinx v1.8.1 Running Sphinx v1.8.1 loading pickled environment... done building [mo]: targets for 0 po files that are out of date building [html]: targets for 4 source files that are out of date updating environment: 0 added, 0 changed, 0 removed looking for now-outdated files... none found pickling environment... done preparing documents... done writing output... [ 25%] index Extension error: The 'ghc-flag' directive is already registered to domain std docs/users_guide/ghc.mk:16: recipe for target 'docs/users_guide/users_guide.pdf' failed make[1]: *** [docs/users_guide/users_guide.pdf] Error 2 make[1]: *** Waiting for unfinished jobs.... Extension error: The 'ghc-flag' directive is already registered to domain std Extension error: The 'ghc-flag' directive is already registered to domain std docs/users_guide/ghc.mk:28: recipe for target 'docs/users_guide/build-man/ghc.1' failed make[1]: *** [docs/users_guide/build-man/ghc.1] Error 2 docs/users_guide/ghc.mk:16: recipe for target 'docs/users_guide/build-html/users_guide/index.html' failed make[1]: *** [docs/users_guide/build-html/users_guide/index.html] Error 2 writing output... [100%] markup /Users/carter/dev-checkouts/ghc-tree/ghc-8.4.4-checkout-clang-build/utils/haddock/doc/invoking.rst:457: WARNING: unknown option: -cpp generating indices... genindex writing additional pages... search copying static files... done copying extra files... done dumping search index in English (code: en) ... done dumping object inventory... done build succeeded, 1 warning. The HTML pages are in .build-html. cp -R utils/haddock/doc/.build-html utils/haddock/doc/haddock Makefile:122: recipe for target 'all' failed make: *** [all] Error 2

1 0

Re: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms
by Ryan Scott 25 Oct '18

25 Oct '18

The fact that `LL` can't be used in a COMPLETE pragma is a consequence of its current design. Per the users' guide [1]: To make things more formal, when the pattern-match checker requests a set of constructors for some data type constructor T, the checker returns: * The original set of data constructors for T * Any COMPLETE sets of type T Note the use of the phrase *type constructor*. The return type of all constructor-like things in a COMPLETE set must all be headed by the same type constructor T. Since `LL`'s return type is simply a type variable `a`, this simply doesn't work with the design of COMPLETE sets. But to be perfectly honest, I feel that trying to put `LL` into a COMPLETE set is like putting a square peg into a round hole. The original motivation for COMPLETE sets, as given in this wiki page [2], is to support using pattern synonyms in an abstract matter—that is, to ensure that users who match on pattern synonyms don't have any internal implementation details of those pattern synonyms leak into error messages. This is well and good for many use cases, but there are also many use cases where we don't *care* about abstraction. Sometimes, we simply define a pattern synonym to be a convenient shorthand for a complicated pattern to facilitate code reuse, and nothing more. `LL` is a perfect example of this, in my opinion. `LL` is simply a thin wrapper around the use of `decomposeSrcSpan` as a view pattern. Trying to put `LL` into a COMPLETE set is silly since our intention isn't to hide the implementation details of decomposing a `SrcSpan`, but rather to avoid the need to copy-paste `(decomposeSrcSpan -> (m , s))` in a bazillion patterns. Correspondingly, any use of `LL` ought to be treated as if the `(decomposeSrcSpan -> (m , s))` pattern were inlined—and from the pattern-match coverage checker's point of view, that *is* exhaustive! What's the moral of the story here? To me, this is a sign that the design space of pattern synonym coverage checking isn't rich enough. In addition to the existing {-# COMPLETE #-} machinery that we have today, I think we need to have a separate pragma for pattern synonyms that are intended to be transparent, non-abstract wrappers around patterns ({-# TRANSPARENT #-}, perhaps). Ryan S. ----- [1] https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/glasgow_exts… [2] https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs

3 2