A source location identification regression in GHC triggered by seven bytes

2021-03-22, post № 242

haskell, compiler-bug, #ghc, #parsing

Working on a minimal XML parser which does both build a data structure and remember its nodes’ source origin, I discarded the second part of a two-tuple by not requiring anything to be present. Yet instead of informing me that a mapping cannot be deconstructed, GHC 8.10.4 gave me an obscure error message:

% runhaskell Xml.hs

<no location info>: error: Tuple section in pattern context

Thankfully I sometimes adhere to a mindfully incremental approach and was not as bewilderingly disoriented as I could have been — after all, a there is an error message possesses little more value than solely stating an executable cannot be built.

Inspecting the probable location I had intelligence on, I managed to extract a seven long byte sequence which triggers a <no location info> compilation error:

j(0,)=0

Yet compilers are squeamish and shapeshifting entities — especially with regards to diagnostic capabilities. Whilst j(0,)=0 cannot be traced, j(,0)=0 induces the expected and appropriate error. As such, I tested the phenomenon using varying GHC versions:

% ghc --version && printf '%s' 'j(0,)=0' > /tmp/nli.hs && ghc /tmp/nli.hs 2>&1 \
cmdand cmdand>     | grep -q '<no location info>' ; echo $?
The Glorious Glasgow Haskell Compilation System, version 8.10.4
0

% ghc --version && printf '%s' 'j(0,)=0' > /tmp/nli.hs && ghc /tmp/nli.hs 2>&1 \
cmdand cmdand>     | grep -q '<no location info>' ; echo $?
The Glorious Glasgow Haskell Compilation System, version 8.8.4
1

To my surprise, I seemed to have found a GHC regression — triggered by only seven bytes.

Alas, this regression is a known one: Another <no location info> error (Tuple section in pattern context) has been opened on the 8th of March 2021, with its comments identifying it as a regression. Yet the fix outlined and performed is as much resolving an aspect of the issue as is it making a stylistic decision — myself facing the same problem of source location corseness, I am leaning further and further towards the approach of less pedantically accurate reporting allowing for a more minimal implementation.