E530 Fix range for cast expression with lambda child by johannescoetzee · Pull Request #4721 · javaparser/javaparser · GitHub
[go: up one dir, main page]

Skip to content

Conversation

johannescoetzee
Copy link
Contributor

Fixes #4488.

The cause of the issue is that lambda expressions are created in 2 steps (seemingly to avoid ambiguity issues). First, only a node for the lambda parameters is created (which could be a NameExpr or a LambdaExpr with only the params set) and then later in parsing the full LambdaExpr is created or the body is added to the LambdaExpr, depending on the context. The problem is that, for cast expressions, the range of the cast expression wasn't correctly adjusted.

In the recursive generateLambda calls, propagateRangeGrowthOnRight is called to update the range of the lambda expression and all ancestor nodes, but this is called before the lambda expression inner is added as a child to the CastExpr node, so the range of the cast was never updated. This PR fixes that by explicitly calling propagateRangeGrowthOnRight after the lambda is added to the cast.

Copy link
codecov bot commented Apr 10, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 58.287%. Comparing base (c40cd37) to head (f6f62aa).
Report is 4 commits behind head on master.

Additional details and impacted files

Impacted file tree graph

@@               Coverage Diff               @@
##              master     #4721       +/-   ##
===============================================
+ Coverage     58.235%   58.287%   +0.052%     
  Complexity      2511      2511               
===============================================
  Files            671       671               
  Lines          38767     38768        +1     
  Branches        7034      7034               
===============================================
+ Hits           22576     22597       +21     
+ Misses         13295     13278       -17     
+ Partials        2896      2893        -3     
Flag Coverage Δ
AlsoSlowTests 58.287% <100.000%> (+0.052%) ⬆️
javaparser-core 58.287% <100.000%> (+0.052%) ⬆️
javaparser-symbol-solver 58.287% <100.000%> (+0.052%) ⬆️
jdk-10 57.838% <100.000%> (+0.052%) ⬆️
jdk-11 57.837% <100.000%> (+0.052%) ⬆️
jdk-12 57.837% <100.000%> (+0.052%) ⬆️
jdk-13 57.837% <100.000%> (+0.052%) ⬆️
jdk-14 58.085% <100.000%> (+0.052%) ⬆️
jdk-15 58.085% <100.000%> (+0.052%) ⬆️
jdk-16 58.059% <100.000%> (+0.052%) ⬆️
jdk-17 58.214% <100.000%> (+0.052%) ⬆️
jdk-18 58.214% <100.000%> (+0.052%) ⬆️
jdk-8 57.840% <100.000%> (+0.052%) ⬆️
jdk-9 57.836% <100.000%> (+0.052%) ⬆️
macos-latest 58.280% <100.000%> (+0.052%) ⬆️
ubuntu-latest 58.274% <100.000%> (+0.052%) ⬆️
windows-latest 58.269% <100.000%> (+0.052%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
...com/github/javaparser/GeneratedJavaParserBase.java 82.681% <100.000%> (+0.097%) ⬆️

... and 4 files with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6ef01d8...f6f62aa. Read the comment docs.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@jlerbsc
Copy link
Collaborator
jlerbsc commented Apr 10, 2025

Perfect.

@jlerbsc jlerbsc merged commit bd84967 into javaparser:master Apr 10, 2025
35 checks passed
@jlerbsc jlerbsc added this to the next release milestone Apr 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Lexical parsing on a lambda with type fails to replace
2 participants
0