- ghc-devs - Haskell.org

Custom warning suppression
by David Feuer 24 Sep '16

24 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 21 Sep '16

21 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 21 Sep '16

21 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 19 Sep '16

19 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

Re: Add a signaling Nans rts option to ghc?
by Carter Schonwald 16 Sep '16

16 Sep '16

IEEE standard specify infinities as distinguished from NAN. Not that the IEEE standard always makes the best choices (semantics of min and max being the naughtiest ). But to the extent that hardware supoorts toggling what values trigger failure it should be reasonably toggle -able For Intel hardware I'll presume only hardware that has sse2 and newer, and maybe a warm-up or sibling patch would be to excise x87 float support from the code gen in GHC Amusingly one intended use for the large space of nan values was to encode the nature of the computation that created the nan. And this was intended to be used by language implementors. Not sure if that will be useful. Anyways, this and the other positive response is encouraging and I'll see about making the time to dig into this stuff. Merry friday all! -Carter On Sep 16, 2016 11:40 AM, "Ben Gamari" <ben(a)smart-cactus.org> wrote: Carter Schonwald <carter.schonwald(a)gmail.com> writes: > Hello All! > I had some interesting conversations yesterday with a few folks and the > take away was that I might experiment with adding an off by default rts > flag that on applicable architectures that makes all floating point > computations that yield Nans signaling , plus mayve some HS side hooks to > enable or disable that per green thread if it doesn't harm no fib. Kinda > like the way green threads track and save / restore the state of the magic > c error tracking variable > Sounds reasonable to me; debugging floating point issues is certainly a chore and this could only help. Regarding a per-thread handling I think we'd certainly need to benchmark. Note that rts/posix/Signals.c already has some logic to handle SIGFPE, although it has been disabled for over a decade due to an infinite loop where the handler immediately threw another FPE. It would be nice to have a solution to this issue; looping is quite bad. Do you lump infinities into the class of NaN values? I'm not sure how much code would fail due to "legitimate" uses of infinity if so. Cheers, - Ben

1 0