-
Notifications
You must be signed in to change notification settings - Fork 3
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
Falsified "CI Text" test #7
Comments
Which GHC this is (the |
Ok, I see: -- on GHC-8.6
Prelude Data.Char> generalCategory '\43929'
NotAssigned
-- on GHC-8.8
Prelude Data.Char> generalCategory '\43929'
LowercaseLetter This will be fixed when https://github.com/nick8325/quickcheck/pull/274/files change makes it to Hackage. |
It's GHC 8.8.2 in case it still matters :P |
And it seems that behavior is "wrong" in Data.Text.Lazy> toCaseFold "\43929" :: Text
"\5065" I guess what happens for unassigned characters is undefined, so I don't know what should/shouldn't happen (one could agree that doing nothing is what should happen) |
Hmm,
CHEROKEE LETTER QUO and CHEROKEE SMALL LETTER QUO |
Ok, found an issue: Cherokee letters should fold to upper case, but now the don't converge:
The docs say: toCaseFold :: Text -> Text O(n) Convert a string to folded case. Subject to fusion. This function is mainly useful for performing caseless (also known as case insensitive) string comparisons. A string x is a caseless match for a string y if and only if: toCaseFold x == toCaseFold y https://unicode.org/faq/casemap_charprop.html Says
Could you report this to |
@phadej Sure. Thanks for investigating! |
There is yet another CI Text failure with tasty-golden 2.3.3.2, should be a different thing though. |
It is the same issue:
|
Hrm, weird that it's only triggered after a tasty-golden update though. Sorry for the noise. |
The foldedCase is derivative of the original string, while the latter is unique. So, putting foldedCase instead of original string leads to loss of data, while getting from the original string must always restore CI object correctly as it has been built from the original string. Probably it should also fix weird cases like in issue haskellari#7. My own case was restoring serialized ResponseHeaders from Network.HTTP.Types. Say, putting Custom-Header and restoring it later makes it custom-header (when I take it with original), while when putting original string it restores correctly as Custom-Header (when I take it with original).
This I suggest making tests always fail by adding counterexample explicitly. Or always pass by filtering out known problematic cases. |
The text was updated successfully, but these errors were encountered: