Very strange, I was referring to: git show 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27 Author: Simon Peyton Jones <simo...@microsoft.com> Date: Mon Dec 1 17:07:48 2014 +0000 Fix parser for UNPACK pragmas {-# NOUNPACK #-} {-# NOUNPACK #-} ! were being parsed the same way. The former was wrong. Thanks to Alan Zimmerman for pointing this out diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y index e3f82ce..c7143ae 100644 --- a/compiler/parser/Parser.y +++ b/compiler/parser/Parser.y @@ -1350,11 +1350,11 @@ sigtypes1 :: { (OrdList (LHsType RdrName)) } -- Always HsForAllTys -- Types strict_mark :: { Located ([AddAnn],HsBang) } - : '!' { sL1 $1 ([],HsUserBang Nothing True) } - | '{-# UNPACK' '#-}' { sLL $1 $> ([mo $1,mc $2],HsUserBang (Just True) False) } - | '{-# NOUNPACK' '#-}' { sLL $1 $> ([mo $1,mc $2],HsUserBang (Just False) True) } - | '{-# UNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc $2],HsUserBang (Just True) True) } - | '{-# NOUNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc $2],HsUserBang (Just False) True) } + : '!' { sL1 $1 ([], HsUserBang Nothing True) } + | '{-# UNPACK' '#-}' { sLL $1 $> ([mo $1,mc $2], HsUserBang (Just True) False) } + | '{-# NOUNPACK' '#-}' { sLL $1 $> ([mo $1,mc $2], HsUserBang (Just False) False) } + | '{-# UNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc $2], HsUserBang (Just True) True) } + | '{-# NOUNPACK' '#-}' '!' { sLL $1 $> ([mo $1,mc $2], HsUserBang (Just False) True) } -- Although UNPACK with no '!' is illegal, we get a -- better error message if we parse it here I'm not sure that is there were no other commits that that are related to the issue. TBH, I can't see warnings for this example program that was mentioned in this thread using GHC-HEAD, but having either `{-# UNPACK #-} !` or `!` or `{-# UNPACK #-}` do not change core output, regardless whether -fno-unbox-small-strict-fields or -fno-unbox-strict-fields provided or not. On 23 January 2015 at 11:59, Roman Cheplyaka <r...@ro-che.info> wrote: > I did. The rest is whitespace; @git show -w 1d32a85@ shows only one > changed line (NOUNPACK). > > On 23/01/15 10:53, Alexander V Vershilov wrote: >> Please take a took at that commit, UNPACK was also handled there, >> despite commit message do not explicitly state this. >> >> On Jan 23, 2015 11:49 AM, "Roman Cheplyaka" <r...@ro-che.info >> <mailto:r...@ro-che.info>> wrote: >> >> How is parsing of the *NOUNPACK* pragma relevant here? >> >> On 23/01/15 10:45, Alexander V Vershilov wrote: >> > Hi. >> > >> > As far as I understand it was fixed as: >> > >> > commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27 >> > Author: Simon Peyton Jones <simo...@microsoft.com >> <mailto:simo...@microsoft.com>> >> > Date: Mon Dec 1 17:07:48 2014 +0000 >> > >> > Fix parser for UNPACK pragmas >> > >> > {-# NOUNPACK #-} >> > {-# NOUNPACK #-} ! >> > were being parsed the same way. The former was wrong. >> > >> > Thanks to Alan Zimmerman for pointing this out >> > >> > >> > So it will fix is in 7.10. And I can't reproduce this anymore on >> > ghc-HEAD. >> > >> > >> > On 20 January 2015 at 17:35, Roman Cheplyaka <r...@ro-che.info >> <mailto:r...@ro-che.info>> wrote: >> >> Interesting question. I managed to trace this to: >> >> >> >> compiler/basicTypes/MkId.hs:699 >> >> >> >> isUnpackableType fam_envs ty >> >> | Just (tc, _) <- splitTyConApp_maybe ty >> >> , Just con <- tyConSingleAlgDataCon_maybe tc >> >> , isVanillaDataCon con >> >> = ok_con_args (unitNameSet (getName tc)) con >> >> | otherwise >> >> = False >> >> >> >> where isVanillaDataCon is defined as: >> >> >> >> dcVanilla :: Bool, >> >> -- True <=> This is a vanilla Haskell 98 data constructor >> >> -- Its type is of form >> >> -- forall a1..an . t1 -> ... tm -> T a1..an >> >> -- No existentials, no coercions, nothing. >> >> >> >> There's no explanation why this limitation is introduced; it might be >> >> just a conservative one. >> >> >> >> On 20/01/15 15:08, Nicholas Clarke wrote: >> >>> I'd like to be able to use the UNPACK pragma on an existentially >> >>> quantified datatype. So as in the below example: >> >>> >> >>> {-# LANGUAGE ExistentialQuantification #-} >> >>> >> >>> data Foo = forall a. Show a => Foo !a >> >>> instance Show Foo where >> >>> show (Foo a) = "Foo! " ++ show a >> >>> >> >>> data Bar = >> >>> Bar {-# UNPACK #-} !Foo >> >>> deriving (Show) >> >>> >> >>> main :: IO () >> >>> main = do >> >>> let foo = Foo "Hello" >> >>> bar = Bar foo >> >>> print bar >> >>> >> >>> I would expect the `Foo` constructor to be unpacked into Bar, as >> if I >> >>> had written: >> >>> >> >>> data Bar = forall a. Show a => Bar !a >> >>> >> >>> However, instead I get the 'Ignoring unusable UNPACK pragma on >> the first >> >>> argument of ‘Bar’' warning. Is there a reason this shouldn't >> work, or a >> >>> workaround to get it to do so? >> >> >> >> _______________________________________________ >> >> Glasgow-haskell-users mailing list >> >> Glasgow-haskell-users@haskell.org >> <mailto:Glasgow-haskell-users@haskell.org> >> >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> > >> > >> > >> > -- Alexander _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users