Accept MOD, AND, OR, and XOR in function form - #1936
Closed
biaobiao2233 wants to merge 3 commits into
Closed
biaobiao2233 wants to merge 3 commits into
biaobiao2233 wants to merge 3 commits into
Conversation
Problem: MOD, AND, OR, and XOR are lexer keywords, so RuSTy rejects the IEC function forms MOD(a, b) and AND(x, y) even though the operator forms work.
Solution: Accept those four keywords only as built-in function names and as calls when the next token is '(', and lower them through the existing arithmetic builtin path. Operator forms stay unchanged.
Co-authored-by: Cursor <cursoragent@cursor.com>
Problem: MOD results can skip the enclosing expression's type conversion, producing incorrect signed values and arithmetic results. The operator builtins also conflict with the updated upstream argument handling. Solution: Apply the contextual conversion after generating a replacement expression and reuse the upstream argument ordering and type hints. Add runtime regressions and document the supported calling forms.
Problem: A parenthesized operator function such as (MOD(17, 5)) skips the ReplacementAst, so codegen never applies the lowered operator. Solution: Generate the replacement expression when the parenthesized inner node has a ReplacementAst. Add runtime regressions for parenthesized ADD, MOD, AND, OR, and XOR. Co-authored-by: Cursor <cursoragent@cursor.com>
Member
|
Superseded by #1949 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem:
MOD,AND,OR, andXORare parsed as keywords, so their function forms are rejected even though the corresponding infix operators work. Parentheses around a lowered call also skipped that lowering.Solution: Accept keyword calls and lower them through the existing builtin operator handling, preserving infix syntax and contextual result conversions. A parenthesized call uses its ReplacementAst instead of the raw inner node.
MODtakes two numeric arguments and returns the first argument's type;AND,OR, andXORtake two or moreANY_BITarguments, includingBOOL. Runtime regressions cover signed and unsigned widening, surrounding expressions, named arguments, mixed-width bit strings, and parenthesized calls, with matching user documentation.Validation at
b6e966d3193on ARM64 Linux (Rust 1.95.0, LLVM 21.1.8):cargo test --workspacepassed with 4,456 passed and 47 ignored;cargo fmt --all --checkandcargo clippy --workspace -- -D warningspassed../scripts/build.sh --litpassed at bothdefaultandnone, each with 542 passed, 4 expected failures, and 2 unsupported tests. All 33 independent operator CLI probes passed.Validation of
1f9c522bd86on WSL (Rust 1.98.1, LLVM 21), against the current integration tree plus this branch:parenthesized4 passed,arithmetic_functions21 passed, andmath_operators98 passed. The full workspace suite, clippy, and lit were not rerun for this commit.Fixes #1934