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:
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.