GeezerVison

Hi @rcosta358 ,
Thank you for the clarification - that makes sense. You’re right, my initial approach was too naive and incorrectly replaced return and _ directly with $result, which explains the failing tests.

Based on your feedback, I understand the correct direction is to:

1. Extend the grammar to allow identifiers starting with $.
2. Treat $result as a syntactic alias and internally substitute it with _ (similarly to how return is handled today).
3. Add proper tests to validate that $result, _, and return behave consistently.

I’ll update the implementation accordingly and push a revised PR.
Also, I agree that $result may not be the most idiomatic Java-style identifier — I’ll think about alternative suggestions and share them if I find a better fit.

Thanks again for the guidance, this was very helpful.

Fixed the handling of method return values in refinements:
Updated the grammar and AST visitor to allow $result to represent method return values, while still keeping _ as a valid alias.

Added a regression test ResultRefinementRegression.java to verify $result works correctly in refinements.
Ensured existing tests in TestMultiple.java pass with the new $result handling.

Hope This change resolves the issue where return was incorrectly treated as a variable and ensures $result can be safely used in refinement expressions.

Hi @rcosta358 ,

Thanks for the clarification! Got it — I’ll revert the changes in CreateASTVisitor and TestMultiple, and instead implement $result handling in MethodsFunctionsChecker.handleFunctionRefinements as suggested. I’ll also move the regression tests to testSuite with the proper naming convention.

Hi @rajshivu, just out of curiosity, how would you pass a Turing test?

Hello @alcides , you caught me, I used a bit of AI to help polish my explanation and easy for understand, but I promise there's a real person behind the keyboard.

Hi @rcosta358 , I’ve pushed a fix for this issue in last commits,
Could you please pull the latest changes and verify if the solution works on your side?

Hi @CatarinaGamboa , thanks for the clarification
I will work on it.

Hi @rcosta358 @CatarinaGamboa , I’ve pushed an updated fix.
$result is now handled as a dedicated literal in the grammar and mapped to a variable expression only in refinements, without changing global ID handling.
All tests are passing, could you please pull the latest changes and verify on your side?

The branch is already up to date with main and commented code has been removed.
Requesting a new review.

I added the null check after hitting a NullPointerException with fi (fixed in #150), and mirrored the same guard here for safety. Since fi.getRefReturn() is guaranteed to be not-null, I agree the checks are unnecessary. I removed both null checks and comment.

LGTM. However, do you mind changing it from $result to #result? I really don't like the dollar sign. 😅

Sure, no problem. I’ll update it to #result