Every non haddock comments before OPTIONS_GHC pragma get pushed to the top

[SeungheonOh]

Describe the bug
Every non haddock comments that appears before a OPTIONS_GHC pragma get pushed to the very top.

To Reproduce

module Plugin.Data.Spec where

{-
foo bar boz
-}
monoConstructor :: CompiledCode (Integer -> Integer -> MyMonoData)
monoConstructor = plc (Proxy @"monoConstructor") Mono1

-- hello world
-- | A type of rose trees with empty leaves.
data EmptyRose = EmptyRose [EmptyRose]

-- This seems to cause issue
{-# OPTIONS_GHC -Wno-incomplete-patterns #-}

-- bob alice eve
f :: ()
f = ()

formats to

{-
foo bar boz
-}
-- hello world
-- This seems to cause issue
{-# OPTIONS_GHC -Wno-incomplete-patterns #-}

module Plugin.Data.Spec where

monoConstructor :: CompiledCode (Integer -> Integer -> MyMonoData)
monoConstructor = plc (Proxy @"monoConstructor") Mono1

-- | A type of rose trees with empty leaves.
data EmptyRose = EmptyRose [EmptyRose]

-- bob alice eve
f :: ()
f = ()

Expected behavior
Location of the comments should be respected regardless of the presence of OPTIONS_GHC pragma

Environment
Used web application at https://ormolu-live.tweag.io/

[SeungheonOh]

Also reported to fourmolu: fourmolu/fourmolu#475

[amesgen]

Thanks for the report, this is a consequence of the fact that our placement logic for non-Haddock comments doesn't work well when formatting AST elements in a different order than how they occur in the input source (combined with the choice to render pragmas like OPTIONS_GHC at the top).

Similar things happen due to import sorting, cf. #469.

At least, one can work around this by manually moving the OPTIONS_GHC pragma to the top before formatting, but it would of course be better if this were not necessary.

[SeungheonOh]

For fourmolu, I was able to work around this by wrapping OPTIONS_GHC with FOURMOLU_DISABLE and FOURMOLU_ENABLE pragmas.

[amesgen]

Right, that approach should also work in Ormolu 👍