Enforce function arity in type inclusion and coercion - #8559
Conversation
88d1209 to
1e014c4
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #8559 +/- ##
=======================================
Coverage 75.79% 75.79%
=======================================
Files 476 476
Lines 62680 62702 +22
=======================================
+ Hits 47506 47525 +19
- Misses 15174 15177 +3
🚀 New features to boost your workflow:
|
rescript
@rescript/belt
@rescript/darwin-arm64
@rescript/darwin-x64
@rescript/linux-arm64
@rescript/linux-x64
@rescript/runtime
@rescript/win32-x64
commit: |
|
Developer playground preview: https://rescript-lang.github.io/rescript/dev-playground/?version=pr-8559 |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1e014c4432
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Add the arity guard (already present in unify) to the Tarrow cases of moregen, eqtype, and subtype_rec. Previously a curried implementation (int => int => int) could satisfy an uncurried interface ((int, int) => int) through signature inclusion or :> coercion; calls made through the interface type compile to direct JavaScript calls with the declared arity, so a first-class use of such a value miscompiled (e.g. returning a closure where an int was expected). The value-mismatch report in includemod now prints a dedicated hint when the two sides are functions of different arities, replacing the vestigial empty curry_kind slot. mcomp is deliberately left arity-lenient: it is an incompatibility oracle for pattern and GADT reasoning, where leniency errs toward "possibly compatible". Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Cristiano Calcagno <cristianoc@users.noreply.github.com>
Drop the explanatory second sentence from the signature arity mismatch error; the first sentence already states the problem. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Cristiano Calcagno <cristianoc@users.noreply.github.com>
a2267c0 to
4dd2af4
Compare
|
@cknitt addressed your comments and evaluated what codex comments have merit. I think this stack of 3 PRs is ready to go. |
Summary
Why
A curried implementation such as
int => int => intcould previously satisfy an uncurried interface such as(int, int) => int, or be coerced to that type. Calls through the declared interface are emitted as plain JavaScript calls with the declared arity, so first-class uses could return a closure where a value was expected.The root cause was that unification checked arrow arity, while the parallel
moregen,eqtype, andsubtype_recpaths did not.Validation
make testnode tests/build_tests/super_errors/input.jsnode tests/build_tests/super_errors_multi/input.jsmake checkformat