RDP record updates are converted to regular record updates

[davidmrt98]

Bug description

When the RecordDotPreprecessor plugin is enabled, record updates which conform to the RDP syntax (no space before the opening brace), but have one or many spaces after the opening brace, are converted to regular record updates when invoking Ormolu.

I consider this bug the "first half" of the idempotency bug presented in #701, since it can be observed in the first described invocation of Ormolu, whereas the second invocation uncovers another (somewhat unrelated) problem, which can be dealt with separately.

Steps To Reproduce

• create a file with the following RDP style record update:

{-# OPTIONS_GHC -fplugin=RecordDotPreprocessor #-}

def{ g = 1}

• invoke Ormolu on this file
• the result looks like this (note the inserted space before the opening brace):

{-# OPTIONS_GHC -fplugin=RecordDotPreprocessor #-}

def {g = 1}

According to the last test case in data/examples/declaration/value/function/record/dot-singleline.hs and its -out.hs counterpart, this is intended behaviour, but I guess that is just an oversight.

Expected behavior

As RDP record updates are semantically different from regular ones, Ormolu should always preserve the absence of spaces before the opening brace (when RDP is enabled). Thus, the formatting result should look like this:

{-# OPTIONS_GHC -fplugin=RecordDotPreprocessor #-}

def{g = 1}

Environment

• Ubuntu 18.0.4
• ormolu-0.1.4.1

The cause of the bug

Ormolu determines if a record update conforms to RDP syntax by comparing the source span of the expression (def) and the source span of the first updated field (g). Unfortunately, the position of the opening brace is independent of these source spans, so the current method for differentiating between regular and RDP record updates does not work correctly in the general case.

One possible way of fixing this is storing the location information of all the AnnKeywordIds in the Ormolu-specific Anns type so that the the exact location of the opening brace can be looked up, when needed. But considering that the actual RecordDotSyntax extension is around the corner, the added complexity of such a big change might not be worth it.