Skip to content
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

Fix type_is_recursive and really_recursive #299

Merged
merged 2 commits into from
Nov 15, 2021

Conversation

NathanReb
Copy link
Collaborator

These functions used to return Recursive if the types appeared inside attributes within the type declarations.

The bug and the fix were discovered by @ceastlund while trying out #297 on Jane Street's code base.

I split this in two parts: first one adds tests, second one fixes the bug and updates the tests accordingly.

Let me know what you think!

@NathanReb NathanReb requested a review from ceastlund as a code owner November 4, 2021 15:30
@NathanReb NathanReb requested a review from a user November 4, 2021 15:30
@NathanReb NathanReb requested a review from pitag-ha as a code owner November 4, 2021 15:30
@NathanReb NathanReb force-pushed the fix-type-is-rec branch 2 times, most recently from 41e3cb1 to b335ff2 Compare November 4, 2021 15:58
Signed-off-by: Nathan Rebours <nathan.p.rebours@gmail.com>
Those used to recurse into attributes, sometimes falsly returning
`Recursive`.

Signed-off-by: Nathan Rebours <nathan.p.rebours@gmail.com>
Copy link
Member

@pitag-ha pitag-ha left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! LGTM.

I'm curious: how did #295 / #297 make you find out about the bug? Since attributes are kept in the AST even after being applied, I wouldn't have expected that #295 / #297 make a difference with regard to this bug.

@NathanReb
Copy link
Collaborator Author

It is indeed a broader bug.

@ceastlund will confirm but I think it's discovery is related to the change in application order, i.e. the fact that deriver now receive the expanded node. It seems some ppx used at Janestreet will add attributes that weren't visible by the derivers before. Since those derivers use really_recursive (for obvious reasons), they were wrongly assuming the type were recursive because of those generated attributes.

#297 made discovering this possible because before it, the builds would fail at earlier stages, before the ppx-es were all applied.

@NathanReb NathanReb merged commit 24b3e1b into ocaml-ppx:main Nov 15, 2021
pitag-ha added a commit to pitag-ha/opam-repository that referenced this pull request Dec 8, 2021
CHANGES:

- Add support for OCaml 4.14 (ocaml-ppx/ppxlib#304, @kit-ty-kate)

- Expand nodes before applying derivers or other inline attributes based
  transformation, allowing better interactions between extensions and
  derivers (ocaml-ppx/ppxlib#279, ocaml-ppx/ppxlib#297, @NathanReb)

- Add support for registering ppx_import as a pseudo context-free rule (ocaml-ppx/ppxlib#271, @NathanReb)

- Add `input_name` to the `Expansion_context.Extension` and `Expansion_context.Deriver` modules (ocaml-ppx/ppxlib#284, @tatchi)

- Improve `gen_symbol` to strip previous unique suffix before adding a new one (ocaml-ppx/ppxlib#285, @ceastlund)

- Improve `name_type_params_in_td` to use prefixes `a`, `b`, ... instead of `v_x`. (ocaml-ppx/ppxlib#285, @ceastlund)

- Fix a bug in `type_is_recursive` and `really_recursive` where they would
  consider a type declaration recursive if the type appeared inside an attribute
  payload (ocaml-ppx/ppxlib#299, @NathanReb)
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