-
Notifications
You must be signed in to change notification settings - Fork 483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add encodeUtf8/decodeUtf8 for bytestrings and strings. #3288
Conversation
, test_applyBuiltinFunction EncodeUtf8 | ||
, test_applyBuiltinFunction DecodeUtf8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please drop these changes, that module is going to be gone once #3208 is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done 👌
, test_applyBuiltinFunction EncodeUtf8 | ||
, test_applyBuiltinFunction DecodeUtf8 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done 👌
pretty EncodeUtf8 = "encodeUtf8" | ||
pretty DecodeUtf8 = "decodeUtf8" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tangential: @michaelpj I'm so annoyed that we don't derive Pretty
in terms of Show
for DefaultFun
, because of stuff like
pretty GreaterThanEqInteger = "greaterThanEqualsInteger"
Adding that pretty EncodeUtf8 = "encodeUtf8"
line (and the other one) manually is stupid redundant work. Should we rename the constructors of DefaultFun
to match with the Pretty
instance or should we change the Pretty
instance to be derived in terms of Show
(with the first letter lowered) even if that breaks backwards compatibility?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Backwards compatibility for whom? Nobody uses the parser. I say change it. Not in this PR, though.
CI fails with
🤔 |
Looking at |
@effectfully yeah, right, thanks! Missed the warnings from the compiler somehow. Is there a reason why |
I think there were no warnings? It's decoding that is problematic and it has a bunch of clauses for particular integers and a final catch-all clause, hence we don't get any warnings when we forget to update the decoding function. We need a cocoverage checker! Or do the two "co"s cancel each other and it's verage checker in fact? Anyway, as long as tests catch such errors, we're fine. |
It is enabled in CI form what I know (@michaelpj, right?). We used to have it enabled for development as well, but people were annoyed and so we switched (I personally don't care either way). |
Oh, right, my bad, should not write things in the late evening. |
@@ -112,6 +114,10 @@ lessThanByteString = (<) | |||
greaterThanByteString :: ByteString -> ByteString -> Bool | |||
greaterThanByteString = (>) | |||
|
|||
{-# NOINLINE decodeUtf8 #-} | |||
decodeUtf8 :: ByteString -> String |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
haddock for these. Yes, it's somewhat obvious, but it never hurts.
And yes, we run with -Werror in CI. Has conflicts now. |
Rebase went wrong, it seems? |
b484433
to
f88a107
Compare
I think it was the consequence of yesterday's GitHub issues. Updated. |
This PR fills the gap in strings/bytestrings functionality and will help for further literal bytestrings support.
Pre-submit checklist:
Pre-merge checklist: