-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
[Bug][move-compiler-v2] visible function names shadow local variables with same name in function calls #15360
Labels
bug
Something isn't working
compiler-v2
stale-exempt
Prevents issues from being automatically marked and closed as stale
Comments
22 tasks
brmataptos
changed the title
[Bug][move-compiler-v2] function declarations shadow override local variables with same name in function calls
[Bug][move-compiler-v2] visible function names shadow local variables with same name in function calls
Nov 26, 2024
brmataptos
added
the
stale-exempt
Prevents issues from being automatically marked and closed as stale
label
Nov 26, 2024
brmataptos
added a commit
that referenced
this issue
Dec 4, 2024
…ront-end code (#15365) - Distinguish between "not supported" and "not implemented" for lambda features. - Add a test case to illustrate the function name aliasing issue ([Bug][move-compiler-v2] visible function names shadow local variables with same name in function calls #15360), but changed other tests here to avoid it. - Remove Constraint::NoFunction as it's too broad. - Make sure there are still errors for all planned unsupported cases - Fix LambdaLifter case for bound free variable without copy. - Refine lambda test cases to make _ok versions that compile up to "not implemented" errors.
danielxiangzl
pushed a commit
that referenced
this issue
Dec 12, 2024
…ront-end code (#15365) - Distinguish between "not supported" and "not implemented" for lambda features. - Add a test case to illustrate the function name aliasing issue ([Bug][move-compiler-v2] visible function names shadow local variables with same name in function calls #15360), but changed other tests here to avoid it. - Remove Constraint::NoFunction as it's too broad. - Make sure there are still errors for all planned unsupported cases - Fix LambdaLifter case for bound free variable without copy. - Refine lambda test cases to make _ok versions that compile up to "not implemented" errors.
danielxiangzl
pushed a commit
that referenced
this issue
Dec 12, 2024
…ront-end code (#15365) - Distinguish between "not supported" and "not implemented" for lambda features. - Add a test case to illustrate the function name aliasing issue ([Bug][move-compiler-v2] visible function names shadow local variables with same name in function calls #15360), but changed other tests here to avoid it. - Remove Constraint::NoFunction as it's too broad. - Make sure there are still errors for all planned unsupported cases - Fix LambdaLifter case for bound free variable without copy. - Refine lambda test cases to make _ok versions that compile up to "not implemented" errors.
georgemitenkov
pushed a commit
that referenced
this issue
Jan 6, 2025
…ront-end code (#15365) - Distinguish between "not supported" and "not implemented" for lambda features. - Add a test case to illustrate the function name aliasing issue ([Bug][move-compiler-v2] visible function names shadow local variables with same name in function calls #15360), but changed other tests here to avoid it. - Remove Constraint::NoFunction as it's too broad. - Make sure there are still errors for all planned unsupported cases - Fix LambdaLifter case for bound free variable without copy. - Refine lambda test cases to make _ok versions that compile up to "not implemented" errors.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
bug
Something isn't working
compiler-v2
stale-exempt
Prevents issues from being automatically marked and closed as stale
🐛 Bug
With the current handling of function calls in the parser/expander, we resolve the function name
f
in a function call from a defined function in preference to a local parameter. This can be seen today with inline function parameters. For example:will yield a warning that parameter
f
is unused, but the program will call the declared functionf
instead of the parameterf
.When we introduce function-valued local variables this will become more of a problem.
Unfortunately, fixing this may be a bit difficult, as the resolution to a declared function happens in
move-compiler/expansion/translate.rs
, where it is intermixed with checking for use of deprecated functions and local variables are being ignored.The text was updated successfully, but these errors were encountered: