replace-megaparsec
replace-megaparsec copied to clipboard
Prelude.undefined with a build executable.
Hi, I have some bizarre behaviour that I pushed to this repository.
https://github.com/locallycompact/replace-megaparsec-bug
I am on NixOS so my commands are with --nix
If I build with stack --nix build and then run stack --nix exec -- replace-megaparsec-bug-exe I get a callstack with Prelude.undefined.
[I] lc@aiur ~/replace-megaparsec-bug (master)>
stack --nix build && stack --nix exec -- replace-megaparsec-bug-exe
replace-megaparsec-bug-exe: Prelude.undefined
CallStack (from HasCallStack):
error, called at libraries/base/GHC/Err.hs:80:14 in base:GHC.Err
undefined, called at src/Replace/Megaparsec.hs:211:21 in replace-megaparsec-1.4.2.0-8z2kgUAlSuYEyo1NOrKi1C:Replace.Megaparsec
However if I run the executable ./Script.hs as a stack script with the exact same content, it executes and returns.
[I] lc@aiur ~/replace-megaparsec-bug (master)> ./Script.hs
[]
Thank you very much for the bug report @locallycompact , I'll check it out.
Okay, I see exactly the same thing that you're seeing, thanks for this reproduction repo.
Here's a clue; The app/Main.hs works correctly if we wrap bracevar in a try:
bracevar = Text.Megaparsec.try $ between (string "{{") (string "}}") (T.pack <$> many (alphaNumChar <|> spaceChar))
I think what's going on here is that I forgot to wrap the sep parser in a try in the sepCapText function.
That doesn't explain why Script.hs works though?
So, I haven't yet been able to figure out why app/Main.hs fails but Script.hs works. Relatedly, I was unable to write a failing test for this case. Very puzzling.
Even so, your bug report did reveal something which is definitely wrong, and which I've fixed in v1.4.3.0, and I'm pretty sure that if you upgrade to the new version then you won't see this problem again.
If you don't want to wait for the new version to hit Stackage, this stack.yaml entry will give you v1.4.3.0.
extra-deps:
- git: https://github.com/jamesdbrock/replace-megaparsec
commit: 96227f50f0083a2839829921a681334cafd90d8d
I'm going to leave this issue open.
(Note to self: I compared the versions of every library in the package databases of the non-failing test and replace-megaparsec-bug and they were the same)