Skip to content

Fix the Ord instance for Ident + some other small fixes #42

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

Open
wants to merge 19 commits into
base: master
Choose a base branch
from

Conversation

yav
Copy link

@yav yav commented May 9, 2023

Previously the instance was incorrect because it'd cause an infinite loop.

This version rearranges the fields of the records to ensure that the
hash field is first, which makes it possible to derive Eq and Ord.

We also do a bunch of refactoring to use record notation instead of
constructor pattern matching, to make it easier to do similar refactoring
in the future.

Other fixes: updates to make tests work, updates to make things work with more recent Aeson and Prettyprinter

yav and others added 19 commits May 8, 2023 16:54
Previously the instance was incorrect because it'd cause an infinite loop.

This version rearranges the fields of the records to ensure that the
hash field is first, which makes it possible to derive Eq and Ord.

We also do a bunch of refactoring to use record notation instead of
constructor pattern matching, to make it easier to do similar refactoring
in the future.
This reverts commit 9ff9176.

Per the discussion in #6, having the `Eq` and `Ord` instances ignore the `raw`
field of `Ident` causes more trouble than it's worth, as it causes the parser
to incorrectly deem raw identifiers like `r#return` to be keywords. While we
could fix this issue by changing the parser, this would take quite a bit of
code changes to accomplish. As such, we revert the change here, and we make a
note in the Haddocks for the `Eq` and `Ord` instances to beware of the fact
that `raw` is taken into account.

After this change, the `rustc-tests` test suite passes once more. As such, this
change fixes #6.
Make tests pass, migrate to GitHub Actions
The previous lexer implementation in `Language.Rust.Parser.Lexer` was broken
for Unicode characters with sufficiently large codepoints, as the previous
implementation incorrectly attempted to port UTF-16–encoded codepoints over to
`alex`, which is UTF-8–encoded. Rather than try to fix the previous
implementation (which was based on old `rustc` code that is no longer used),
this ports the lexer to a new implementation that is based on the Rust
`unicode-xid` crate (which is how modern versions of `rustc` lex Unicode
characters). Specifically:

* This adapts `unicode-xid`'s lexer generation script to generate an
  `alex`-based lexer instead of a Rust-based one.

* The new lexer is generated to support codepoints from Unicode 15.1.0.
  (It is unclear which exact Unicode version the previous lexer targeted, but
  given that it was last updated in 2016, it was likely quite an old version.)

* I have verified that the new lexer can lex exotic Unicode characters such as
  `𝑂` and `𐌝` by adding them as regression tests.

Fixes #3.
Lexer: Properly support Unicode 15.1.0
…-2.1

Restrict `happy` version to less then 2.1
`happy-2.1.1` includes a fix for haskell/happy#320,
which was preventing `language-rust` from building. Now that this version of
`happy` is on Hackage, we no longer need to include such a restrictive upper
version bound on `happy`.
Allow building with `happy-2.1.1` or later
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants