Skip to content

Workaround for @asin labels in uncurried externals. #6527

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

Merged
merged 5 commits into from
Dec 14, 2023

Conversation

cristianoc
Copy link
Collaborator

@cristianoc cristianoc commented Dec 13, 2023

Examples like this:

@obj
external makeOptions: (
  ~objectMode: @as(json`false`) _,
  ~name: string,
  unit,
) => int = ""

change the arity of the function.
The arity of uncurried functions is determined at parsing type. This means that this peculiarity of externals affects parsing. This PR gives an approximate workaround based on the labelled arg having @as, and the type being _ (the any type).

Fixes #6517

Examples like this:
```
@obj
external makeOptions: (
  ~objectMode: @as(json`false`) _,
  ~name: string,
  unit,
) => int = ""
```

change the arity of the function.
The arity of uncurried functions is determined at parsing type.
This means that this peculiarity of externals affects parsing.
This PR gives an approximate workaround based on the labelled arg having `@as`, and the type being `_` (the any type).

Fixes #6517
Comment on lines 4288 to 4291
let has_as =
Ext_list.exists typ.ptyp_attributes (fun (x, _) -> x.txt = "as")
in
if typ_is_any && has_as then arity - 1 else arity
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think there can be multiple @as() _, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is inside a fold for each argument.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This check is approximate: does not check that we're inside an external.
The same construction inside a normal type annotation which is not an external should have no effect (in that the rest of the compiler ignores it).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It would be good to deprecate this whole construction in future.
Kind of hesitant to go for this workaround, unless it's really needed to unbreak something.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Good stuff!

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah we should get rid of this eventually. But for v11 we should have it imo.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

OK I've guarded it to only apply inside externals, so it won't accidentally break in the corner case where the annotations are used outside externals by mistake.

@cristianoc
Copy link
Collaborator Author

This is safe enough to merge now.

@cristianoc cristianoc merged commit fe60fcb into master Dec 14, 2023
@cristianoc cristianoc deleted the as_uncurried_externals branch December 14, 2023 12:42
@TheSpyder
Copy link
Contributor

I'm not very familiar with building the compiler from source, so I'm not sure whether this works on rescript-nodejs (after changing uncurried to true in bsconfig.json) 🤔

It failed, then I tried removing the external check and it worked, then I put it back and it still worked 🙃

(also there is a second uncurried error I didn't notice earlier, I might need to log another bug for that)

@TheSpyder
Copy link
Contributor

I've gone back and forth a few times and I can only assume something was out of date when it seemed to not work. It's working great, thank you.

I logged a new ticket for the other error (completely unrelated to this issue, I just hadn't noticed it because I was focused on this one).

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.

Uncurried breaks @obj when used with @as
3 participants