-
Notifications
You must be signed in to change notification settings - Fork 476
Fix let? unwrap early return for option types #8091
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
base: master
Are you sure you want to change the base?
Fix let? unwrap early return for option types #8091
Conversation
|
@HuijungYoon could you please run |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @HuijungYoon , thank you for taking this on!
Returning a variable is intentional (it means we don't need to recreate the value at runtime). So that should not be changed. The problem to fix is what this variable is called.
So, the fix here should most likely be to propagate the name of the variable used in the let binding:
let? Some(myVar) = someOptFn()
// We need to propagate the `myVar` name to where `x` is now used hard coded
23985b2 to
7e70c3a
Compare
|
Thank you. Now you need to do these things:
|
7e70c3a to
bfe8279
Compare
When using `let? Some(myVar) = ...`, the variable name was hardcoded as "x" instead of using the actual pattern variable name "myVar". This fix extracts the variable name from the pattern and uses it in the early return cases, ensuring proper variable propagation and avoiding unnecessary runtime allocations. Fixes rescript-lang#8085 Signed-Off-By: [Huijung Yoon] <[markup3604@gmail.com]>
bfe8279 to
cafc70b
Compare
|
@HuijungYoon Thank you! |
rescript
@rescript/darwin-arm64
@rescript/darwin-x64
@rescript/linux-arm64
@rescript/linux-x64
@rescript/runtime
@rescript/win32-x64
commit: |
When using
let? Some(x) = Nonein a function returningoption<T>, the early return was incorrectly returning a variable instead of None.This fixes the issue by explicitly returning None/Some values instead of using pattern-matched variables, ensuring correct type propagation and JS interop compatibility.
Fixes #8085