Very strange, I was referring to: git show 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27 commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27 Author: Simon Peyton Jones 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 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" mailto:roma@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 mailto:simonpj@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 mailto:roma@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