- ghc-devs - Haskell.org

RE: Windows build broken
by David Feuer 01 Mar '17

01 Mar '17

I can't fix that (no windows) but I just broke all the builds with a -Werror mistake and I can fix that one... David FeuerWell-Typed, LLP -------- Original message --------From: Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> Date: 2/28/17 7:07 PM (GMT-05:00) To: ghc-devs(a)haskell.org Subject: Windows build broken Windows build is broken again. Might someone fix? Simon "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_p\" -optc-DWINVER=0x06000100 -static -prof -eventlog -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wnoncanonical-monad-instances -c rts/Sparks.c -o rts/dist/build/Sparks.p_o rts\Profiling.c: In function 'reportCCSProfiling': rts\Profiling.c:704:9: error: error: implicit declaration of function 'writeCCSReportJson' [-Werror=implicit-function-declaration] writeCCSReportJson(prof_file, stack, totals); ^~~~~~~~~~~~~~~~~~ | 704 | writeCCSReportJson(prof_file, stack, totals); | ^ rts\Profiling.c:704:9: error: error: nested extern declaration of 'writeCCSReportJson' [-Werror=nested-externs] | 704 | writeCCSReportJson(prof_file, stack, totals); | ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) make[1]: *** [rts/ghc.mk:255: rts/dist/build/Profiling.p_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:127: all] Error 2 /c/code/HEAD$

1 0

Windows build broken
by Simon Peyton Jones 01 Mar '17

01 Mar '17

Windows build is broken again. Might someone fix? Simon "inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_p\" -optc-DWINVER=0x06000100 -static -prof -eventlog -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wnoncanonical-monad-instances -c rts/Sparks.c -o rts/dist/build/Sparks.p_o rts\Profiling.c: In function 'reportCCSProfiling': rts\Profiling.c:704:9: error: error: implicit declaration of function 'writeCCSReportJson' [-Werror=implicit-function-declaration] writeCCSReportJson(prof_file, stack, totals); ^~~~~~~~~~~~~~~~~~ | 704 | writeCCSReportJson(prof_file, stack, totals); | ^ rts\Profiling.c:704:9: error: error: nested extern declaration of 'writeCCSReportJson' [-Werror=nested-externs] | 704 | writeCCSReportJson(prof_file, stack, totals); | ^ cc1.exe: all warnings being treated as errors `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) make[1]: *** [rts/ghc.mk:255: rts/dist/build/Profiling.p_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:127: all] Error 2 /c/code/HEAD$

1 0

Proposal: make throwIO and throw strict
by David Feuer 27 Feb '17

27 Feb '17

It's possible for code to throw an exception that itself throws an imprecise exception. Such an exception is a bit tricky to catch. For example: import Control.Exception strange = throwIO (undefined :: SomeException) `catch` \ex -> case () of _ | Just _ <- (fromException ex :: Maybe IOError) -> print "IOError" | otherwise -> print "Something else" You might think that this would catch the exception and print "Something else", but in fact it does not. If others think this is as surprising as I do, then I think we should make throwIO and throw strict, so an exception will never itself be bottom. Using throwIO' !e = throwIO e in the code above instead of throwIO allows the exception to be caught. A more conservative approach might be to just force result of toException before calling raise#, but this only works when users use an explicit type signature to fix the expression type, rather than an exception constructor. David

1 0

Deriving Data for poly-kinded datatypes
by Ryan Scott 24 Feb '17

24 Feb '17

Hi Pedro, I'm quite confused by a peculiarity of deriving Data (more info in Trac #13327 [1]). In particular, if you write this: data T phantom = T deriving Data Then the derived Data instance is NOT this: instance Typeable phantom => Data (T phantom) where ... But instead, it's this: instance Data phantom => Data (T phantom) where ... dataCast1 f = gcast1 f The gcast1 part is why it requires the stronger (Data phantom) context, as you noted in Trac #4028 [2]. What confuses me, however, is that is apparently does not carry over to poly-kinded datatypes. For instance, if you write this: data T (phantom :: k) = T deriving Data Then you do NOT get this instance: instance Data (phantom :: *) => Data (T phantom) where ... dataCast1 f = gcast1 f But instead, you get this instance! instance (Typeable k, Typeable (phantom :: k)) => Data (T phantom) where ... -- No implementation for dataCast1 This is quite surprising to me. I'm not knowledgeable enough about Data to know for sure if this is an oversight, expected behavior, or something else, so I was hoping you (or someone else highly knowledgeable about SYB-style generic programming) could help me out here. In particular: 1. Does emitting "dataCast1 f = gcast1 f" for datatypes of kind (k -> *) make sense? Or does it only make sense for types of kind (* -> *)? 2. Is there an alternate way to define dataCast1 that doesn't require the stronger Data context, but instead only requires the more general Typeable context? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/13327 [2] https://ghc.haskell.org/trac/ghc/ticket/4028#comment:5

3 6

MSYS2 update (those who build on Windows please read)
by Phyx 24 Feb '17

24 Feb '17

Hi Windows devs, February comes with a major change in behavior for MSYS2/Cygwin. Tools such as awk/sed etc now use binary mode unless on a text mount: https://cygwin.com/ml/cygwin-announce/2017-02/msg00036.html This is problematic because GHC etc only use the underlying OS to determine how to output line endings. As such we output \r\n but in sed et al $ will no longer match line endings. Which means out scripts are currently broken. Do not upgrade your MSYS2 install until a workaround for this is in place or you will be unable to compile GHC. If you have updated your MSYS2 then using a text mount may be the easiest option to get a working build again. As it seems just downgrading the tools alone is not enough. Thanks, Tamar

1 1

Datacon RULES test
by David Feuer 24 Feb '17

24 Feb '17

For good or ill, Simon doesn't want RULES for datacons. T12689 has to be removed (leaving T12689a, which is still fine). But I don't know enough about what you're doing with T12689broken to know how to make it express the right idea after this change. Can you please advise? Thanks, David Feuer Well-Typed LLP

2 1

Windows build broken
by Simon Peyton Jones 22 Feb '17

22 Feb '17

Please please please could some one fix this? On windows. It's frustrating being unable to build. Please please Simon libraries\time\lib\Data\Time\Clock\Internal\SystemTime.hs:57:5: error: Not in scope: data constructor FILETIME Perhaps you meant Win32.FILETIME (imported from System.Win32.Time) | 57 | FILETIME ft <- Win32.getSystemTimeAsFileTime | ^^^^^^^^

3 5

RE: Windows build broken
by Simon Peyton Jones 22 Feb '17

22 Feb '17

Re-adding ghc-devs. | Settup up things so that all master pushes go through a build&smoke-test-on- | all-relevant-platforms purgatory shouldn't be that problematic.. I know. We discuss it periodically The trouble is that it takes work to do these things (reliably, solidly) and everyone is busy. If someone felt able to step up to doing it, it'd be great. Simon | -----Original Message----- | From: Kosyrev Serge [mailto:skosyrev@ptsecurity.com] | Sent: 22 February 2017 14:18 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Windows build broken | | Simon, | | It pains me to see how something trivially preventable by a functioning | "continuous integration" setup keeps causing you trouble so regularly. | | Settup up things so that all master pushes go through a build&smoke-test-on- | all-relevant-platforms purgatory shouldn't be that problematic.. | | I know, it's not my ground to meddle in, but I just can't be calmly watching | this entirely preventable suffering.. | | Simon Peyton Jones via ghc-devs writes: | > Please please please could some one fix this? On windows. | > | > It’s frustrating being unable to build. | > | > Please | > | > please | > | > Simon | > | > libraries\time\lib\Data\Time\Clock\Internal\SystemTime.hs:57:5: error: | > | > Not in scope: data constructor FILETIME | > | > Perhaps you meant Win32.FILETIME (imported from System.Win32.Time) | > | > | | > | > 57 | FILETIME ft <- Win32.getSystemTimeAsFileTime | > | > | ^^^^^^^^ | | -- | с уважениeм / respectfully, not a GHC developer at all, Косырев Сергей | -- | “Most deadly errors arise from obsolete assumptions.” | -- Frank Herbert, Children of Dune

1 0

Status of early-inline branch
by David Feuer 21 Feb '17

21 Feb '17

I've been working on trying to get the branch in shape for review and such, but I see that you're also still working on it. So we don't tread on each other's toes too much, I'm wondering if you could give me a sense of what the status is, which commits are firm and which you might change, etc. Thanks, David Feuer

2 2

XTypeApplication and @spaces
by Gracjan Polak 21 Feb '17

21 Feb '17

Hi all, I was thinking about implementing @Type syntax <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext…> highlight for haskell-mode <https://github.com/haskell/haskell-mode> and noticed a rule about spacing required before @-sign. I do not understand where does this rule come from and what does it buy us. Experimentation shows that @-patterns do not care about spaces at all: Prelude> let f a @ Nothing = print a in f Nothing Nothing Comment next to implementation says: "This, of course, conflicts with as-patterns. The conflict arises because expressions and patterns use the same parser, and also because we want to allow type patterns within expression patterns." As I understand pattern and expression contexts are always separate in Haskell so the part just after 'of course' is not clear to me. Can I get an example for "we want to allow type patterns within expression patterns"? I understand the part "expressions and patterns use the same parser" but then I'd rather file a bug report about this one. Rationale: I'd rather limit usage for horizontal space to separate tokens on the lexer level. This looks like it tries to promote space to separate things on parser level, which is rather hard to get right in crude parsers that we have for syntax highligh, indentation, completion and the like. -- Gracjan

2 2