September 2016 - ghc-devs

Solaris feature_tests.h
by Ben Gamari 26 Sep '16

26 Sep '16

Hi Karel, A few months ago we reverted a cleanup [1] to PosixSource.h due to breakage on Solaris. I believe I have found [2] a build log from a failing build, but sadly it's far from clear what is going on. Do you suppose you could send us your /usr/include/sys/feature_tests.h? I suspect this will shed some light on what has gone wrong. For the record, I've opened #12624 to track this issue. Cheers, - Ben [1] https://git.haskell.org/ghc.git/commitdiff/cac3fb06f4b282eee21159c364c4d08e… [2] http://haskell.inf.elte.hu/builders/solaris-amd64-head/573/10.html

2 1

Custom warning suppression
by David Feuer 23 Sep '16

23 Sep '16

Currently, the only way to suppress custom warnings and deprecations is with -fno-warn-warnings-deprecations, which is a rather large hammer. I see two ways we can improve this, and I propose that we should do both. 1. Per-binding suppression Add -fno-warn-binding, -fno-deprecate-binding, -fwarn-binding options, and -fdeprecate-binding options. These would take the (optionally qualified) name of a binding and control warnings tied to it. So if you invoked -fno-warn-binding "sillyFunction", then GHC would not warn you about the silliness of anything named sillyFunction. -fno-warn-binding "Data.Silly.sillyFunction" would limit the suppression to the silly function in Data.Silly. -fno-deprecate-binding would refrain from emitting deprecation warnings for the binding in question. -fno-deprecate-binding would presumably imply no-warn-binding, since someone who doesn't care that a function is going to be removed probably also doesn't care what else is wrong with it. 2. Named warning classes I'd like to add an optional "warning class" to the WARNING pragma, preceding the warning description. This would be a short string indicating what sort of warning is involved. This would be totally free-form, but the documentation would suggest a few conventional options such as "partial" and "slow". Then whole warning classes could be controlled with -fno-warn-class and -first-class.

4 3

RE: Test T12504 on Windows
by Richard Cook 20 Sep '16

20 Sep '16

Thanks! Yes, I did mean to reply all. -Richard Sent via the Samsung Galaxy S7 edge, an AT&T 4G LTE smartphone -------- Original message --------From: lonetiger(a)gmail.com Date: 9/20/16 6:03 PM (GMT-08:00) To: Richard Cook <rcook(a)rcook.org>, Simon Peyton Jones <simonpj(a)microsoft.com>, ghc-devs(a)haskell.org Subject: RE: Test T12504 on Windows I believe you forgot to press Reply-All Richard. In any case a fix is up at https://phabricator.haskell.org/D2537 Sorry, should have caught this during review. Tamar From: Richard Cook Sent: Tuesday, September 20, 2016 23:35 To: Phyx Subject: Re: Test T12504 on Windows Dear All, This is the test case that was added to validate the fix to hsc2hs. Here's the commit that added the test case: https://git.haskell.org/ghc.git/commitdiff/76286af5c621f032c4afab1f26b992e8… Output on Windows should include backslashes, other platforms should use forward slashes. This is keyed off the WINDOWS Makefile variable. -Richard On Tue, Sep 20, 2016 at 3:10 PM, Phyx <lonetiger(a)gmail.com> wrote:The new output is correct. hsc2hs was patched to fix the error messages it gives. We missed a test it seems. I'll update the test output when I get home. Thanks Simon, Tamar On Tue, Sep 20, 2016, 23:06 Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> wrote:Test hsc2hs/T12504 is failing thus on Windows. Something path-y.Simon -{-# LINE 1 "T12504/path/to/T12504.hsc" #-}-{-# LINE 2 "T12504/path/to/T12504.hsc" #-}+{-# LINE 1 "T12504\\path\\to\\T12504.hsc" #-}+{-# LINE 2 "T12504\\path\\to\\T12504.hsc" #-}*** unexpected failure for T12504(normal)_______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

RE: Test T12504 on Windows
by lonetiger＠gmail.com 20 Sep '16

20 Sep '16

I believe you forgot to press Reply-All Richard. In any case a fix is up at https://phabricator.haskell.org/D2537 Sorry, should have caught this during review. Tamar From: Richard Cook

1 0

Test T12504 on Windows
by Simon Peyton Jones 20 Sep '16

20 Sep '16

Test hsc2hs/T12504 is failing thus on Windows. Something path-y. Simon -{-# LINE 1 "T12504/path/to/T12504.hsc" #-} -{-# LINE 2 "T12504/path/to/T12504.hsc" #-} +{-# LINE 1 "T12504\\path\\to\\T12504.hsc" #-} +{-# LINE 2 "T12504\\path\\to\\T12504.hsc" #-} *** unexpected failure for T12504(normal)

2 1

building ghc-8.0 branch on Win10
by Josh Berman 19 Sep '16

19 Sep '16

Hi, I was able to build the "master" branch of ghc 8.0.1 using the instructions found here: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows When I switched to the "ghc-8.0" branch, though, I get the following error: configure: error: > You've selected: > BUILD: x86_64-w64-mingw32 (the architecture we're building on) > HOST: x86_64-unknown-mingw32 (the architecture the compiler we're > building will execute on) > TARGET: x86_64-unknown-mingw32 (the architecture the compiler we're > building will produce code for) > BUILD must equal HOST; that is, we do not support building GHC itself > with a cross-compiler. To cross-compile GHC itself, set TARGET: stage > 1 will be a cross-compiler, and stage 2 will be the cross-compiled > GHC. Anyone know off the top of their heads what the issue is? Thanks, - Josh Berman

5 7

Grand Plan for 8.0.2
by Ben Gamari 18 Sep '16

18 Sep '16

tl;dr: GHC 8.0.2 is coming, however there are a number of issues we would like to see resolved. Consequently it's not entirely clear when it will arrive, but if things go well it may be as early as this Friday. Hello everyone, Over the past few weeks I've been making preparations for the coming 8.0.2 release. I've merged a few more patches to the stable branch in response to last week's call for merge requests, bringing the total up to 180 commits since 8.0.1. At this point there are only a couple things that remain to be cleared up, * #12220, #12533: These are unfortunate behaviors of default signatures, #12220 being an interaction with type applications and #12533 being an obscure corner case. While we have a fix for these (d2958bd0), the fix changes the behavior of the typechecker's inaccessible code check, breaking some code on Hackage; this is documented as #12466. There are some tricky unresolved questions here regarding how we want the inaccessible code here to behave. At the moment I am leaning towards simply punting these off to 8.2.1. If you would like to see them fixed in 8.0.2, please say so. Moreover, please contribute your thoughts on #12466 as resolving the remaining questions on that ticket is a prerequisite for merging the fix for #12220. * #12954: Currently Haddock does not produce documentation for bundled pattern synonyms. There is a pull request [1] that may fix this but it is currently needing reviewers. It would be great to fix this for 8.0.2, but ultimately someone is going to need to finish this up. * #10986: This is a rather unfortunate leak of temporary files which we would ideally fix since it can produce rather large temporary directories on the user's system. * #12519: Haddock inexplicably forgets to render the class members of Eq and Ord. It would be great if someone could get to the bottom of this. * #12433 is a rather nasty correctness bug which currently has no resolution. * #11819: There are still a number of full validation issues which would be nice to sort out. I would like to be able to say that we have a concrete timeline for a 8.0.2 release and I was originally planning to propose a candidate source release for late this week, however in light of the the large number of unresolved issues, I think it would be unwise to commit to this timeframe. I'll say that the candidate source tarball could come as early as Friday, although sometime next week is far more likely. As always, any help that you could offer on any of the above issues would be greatly appreciated. Cheers, - Ben [1] https://github.com/haskell/haddock/pull/494/commits/7984c8fb8f238793641a419…

4 7

8.0 tip doesn't build sans reverting c51caafae7669d
by Carter Schonwald 18 Sep '16

18 Sep '16

I had to revert c51caafae7669d4246f4efd3d1a6858020780e02 to get the tip of 8.0 to work current tip for me as of this checkout d3ac6ce08f282060ca6dc61de527b5b77885ab88

1 0

Do we have free bits in the info pointer itself?
by Ryan Newton 16 Sep '16

16 Sep '16

Our heap object header is one word -- an info table pointer <https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects>. Well, a 64 bit info table pointer leaves *at least* 16 high bits inside the object header for other purposes, right? Is there any problem with using these other than having to mask the info table pointer each time it is dereferenced? Thanks, -Ryan

4 4

Is Safe Haskell intended to allow segfaults?
by Ryan Newton 16 Sep '16

16 Sep '16

We're trying to spend some cycles pushing on Safe Haskell within the stackage packages. (It's looking like a slog.) But we're running up against some basic questions regarding the core packages and Safe Haskell guarantees. The manual currently says: <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/safe_haskel…> *Functions in the IO monad are still allowed and behave as usual. * As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe language you can trust the types", and I'd always assumed that meant Safe Haskell is a type safe language, even in the IO fragment. Was there an explicit decision to allow segfaults and memory corruption? This can happen not just with FFI calls but with uses of Ptrs within Haskell, for example the following: ``` {-# LANGUAGE Safe #-} module Main where import Foreign.Marshal.Alloc import Foreign.Storable import Foreign.Ptr import System.Random fn :: Ptr Int -> IO () fn p = do -- This is kosher: poke p 3 print =<< peek p -- This should crash the system: ix <- randomIO pokeElemOff p ix 0xcc main = alloca fn ``` -Ryan

10 23