[aurelien-coet-sonarsource]

---

Summary by Gitar

• PSI frontend integration:
  • Added JavaPsiEnvironment to open a standalone PSI project from explicit source snapshots, classpath, and JDK image
  • Added JavaPsiApplication, JrtVirtualFileSystem, and ExplicitJavaFileManager to load JDK modules and resolve sources
• Language validation:
  • Added PsiLanguageValidator and PsiLanguageFeatures to report source-level and fatal syntax errors
• Diagnostics:
  • Added PsiDiagnosticProvider with unused import, redundant cast, assignment, and masked catch checks
• Token mapping:
  • Added PsiTokenIndex to map PSI tokens to original UTF-16 source positions

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

SONARJAVA-7287

[datadog-sonarsource]

❌ Errors

Your PR has failed checks. Please review the issues below and take necessary action before merging.

🚦 3 Pipeline jobs failed

Build | Build and Unit Test on Windows — 🔧 Needs a code fix, caused by this PR

View more details · View in GitHub Actions

Build | Test Analyze — 🔄 Retry may pass, looks flaky

View more details · View in GitHub Actions

Build | Custom Rules and License Check

View more details · View in GitHub Actions

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: b3bebe7 | Docs | View more details | Give us feedback!}

[gitar-bot]

⚠️ Bug: Java 10 for (var x : xs) is wrongly rejected as fatal 'var' misuse

PsiLanguageFeatures.visitVariable tags every var-typed PsiParameter as Feature.LAMBDA_VAR (PsiLanguageFeatures.java:82). In IntelliJ PSI, the iteration variable of an enhanced for (PsiForeachStatement.getIterationParameter()) is also a PsiParameter, not a PsiLocalVariable, so it gets the same tag.

At source level 10, PsiLanguageValidator turns every LAMBDA_VAR into a Kind.FATAL "'var' is not allowed here" (PsiLanguageValidator.java:91-92). PsiDiagnosticProvider.language then throws a RecognitionException for the first FATAL diagnostic. JLS 10 (JEP 286) allows var in enhanced-for loops, so a valid Java 10 file such as for (var s : list) {} fails to parse. Only Java 11 added var for lambda parameters, which is the case this branch is meant to reject. The tests only cover the lambda case (PsiLanguageValidatorTest.java:72-73).

Fix: give LAMBDA_VAR only to parameters whose declaration scope is a PsiLambdaExpression, and treat foreach iteration parameters (and other non-lambda parameters) as LOCAL_VAR.

Only classify parameters declared by a lambda as LAMBDA_VAR.:

var type = variable.getTypeElement();
if (type != null && type.getText().equals("var")) {
  boolean lambdaParameter = variable instanceof PsiParameter parameter
    && parameter.getDeclarationScope() instanceof com.intellij.psi.PsiLambdaExpression;
  add(lambdaParameter ? Feature.LAMBDA_VAR : Feature.LOCAL_VAR, type);
}

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

CI failed: Two of the three CI jobs fail for reasons unclear to this PR: the license-maven-plugin flags PSI/JetBrains dependencies as forbidden, and java-frontend has three PSI classpath/runtime resolution test failures. The third template is not analyzed in the supplied findings.

Overview

Three unique error templates were analyzed from 5 logs for commit b3bebe7. Two distinct failure patterns are identified: a license policy failure and PSI classpath test failures. Both are marked related_to_pr: unclear, so neither is confirmed as caused by this change.

Failures

License check fails on forbidden licenses in PSI/JetBrains dependencies (confidence: high)

• Type: dependency
• Affected jobs: 125307302535
• Related to change: unclear
• Root cause: license-maven-plugin:aggregate-add-third-party reports 19 dependencies with no license, including Unknown license for com.jetbrains.intellij.java:java-frontback-psi, java-frontback-psi-impl, java-psi, java-psi-impl, java-syntax, and com.jetbrains.intellij.platform:core and util-rt. It also reports 2 forbidden license categories and exits with There are some forbidden licenses used. The supplied diff does not show a dependency or license-policy change in this PR, so the link to the PSI code is not established.
• Suggested fix: Verify the actual license of each flagged JetBrains/PSI artifact, then add accurate mappings to missing-dep-licenses.properties or update the approved license configuration. Do not whitelist unknown licenses without legal verification. The JaCoCo 0.8.13 'unsupported class file major version 70' messages are non-fatal here (tests pass), but upgrading JaCoCo for Java 26 would remove them.

PSI classpath and Android runtime resolution tests fail (confidence: medium)

• Type: test
• Affected jobs: 125307302587
• Related to change: unclear
• Root cause: Three assertions in java-frontend fail with expected: <true> but was: <false>: JavaPsiClasspathTest.resolves_a_generic_method_from_a_dependency_jar_or_directory (lines 55 and 65, two parameterized cases) and JavaPsiQualificationTest.supplied_android_runtime_resolves_only_its_own_classes (lines 116 and 121). The logs do not show the underlying resolution state, and no supplied diff explains the failing classpath or runtime change.
• Suggested fix: Inspect the PSI environment's classpath setup for dependency JARs and directories, and the Android runtime registration in JavaPsiEnvironment. Then rerun the java-frontend tests, including JavaPsiClasspathTest and JavaPsiQualificationTest.

Summary

• Change-related failures: None confirmed. Both failures are marked related_to_pr: unclear.
• Infrastructure/flaky failures: None identified. The cache-miss and StepSecurity log lines are routine and not failure causes.
• Recommended action: Resolve the license classification for the PSI/JetBrains artifacts, and investigate the PSI classpath and Android runtime test failures in java-frontend. Confirm whether either failure reproduces on the base branch to establish whether this PR caused it.

Code Review ⚠️ Changes requested 0 closed / 1 findings

🟡 Medium risk · Adding a standalone PSI environment, language validation, and diagnostics is substantial frontend infrastructure that could alter Java parsing and issue reporting.

Adds the PSI frontend validation and diagnostics layer for Java, but the var handling incorrectly rejects valid Java 10 enhanced-for loops. PsiLanguageFeatures tags every var parameter as LAMBDA_VAR, so for (var s : list) {} fails to parse at source level 10. The tag should be restricted to lambda parameters, with foreach iteration variables treated as local var usage.

⚠️ Bug: Java 10 for (var x : xs) is wrongly rejected as fatal 'var' misuse

📄 java-frontend/src/main/java/org/sonar/java/psi/PsiLanguageFeatures.java:80-83 📄 java-frontend/src/main/java/org/sonar/java/psi/PsiLanguageValidator.java:85-93

PsiLanguageFeatures.visitVariable tags every var-typed PsiParameter as Feature.LAMBDA_VAR (PsiLanguageFeatures.java:82). In IntelliJ PSI, the iteration variable of an enhanced for (PsiForeachStatement.getIterationParameter()) is also a PsiParameter, not a PsiLocalVariable, so it gets the same tag.

At source level 10, PsiLanguageValidator turns every LAMBDA_VAR into a Kind.FATAL "'var' is not allowed here" (PsiLanguageValidator.java:91-92). PsiDiagnosticProvider.language then throws a RecognitionException for the first FATAL diagnostic. JLS 10 (JEP 286) allows var in enhanced-for loops, so a valid Java 10 file such as for (var s : list) {} fails to parse. Only Java 11 added var for lambda parameters, which is the case this branch is meant to reject. The tests only cover the lambda case (PsiLanguageValidatorTest.java:72-73).

Fix: give LAMBDA_VAR only to parameters whose declaration scope is a PsiLambdaExpression, and treat foreach iteration parameters (and other non-lambda parameters) as LOCAL_VAR.

Only classify parameters declared by a lambda as LAMBDA_VAR.

var type = variable.getTypeElement();
if (type != null && type.getText().equals("var")) {
  boolean lambdaParameter = variable instanceof PsiParameter parameter
    && parameter.getDeclarationScope() instanceof com.intellij.psi.PsiLambdaExpression;
  add(lambdaParameter ? Feature.LAMBDA_VAR : Feature.LOCAL_VAR, type);
}

🤖 Prompt for agents

Code Review: Adds the PSI frontend validation and diagnostics layer for Java, but the `var` handling incorrectly rejects valid Java 10 enhanced-for loops. `PsiLanguageFeatures` tags every `var` parameter as `LAMBDA_VAR`, so `for (var s : list) {}` fails to parse at source level 10. The tag should be restricted to lambda parameters, with foreach iteration variables treated as local `var` usage.

1. ⚠️ Bug: Java 10 `for (var x : xs)` is wrongly rejected as fatal 'var' misuse
   Files: java-frontend/src/main/java/org/sonar/java/psi/PsiLanguageFeatures.java:80-83, java-frontend/src/main/java/org/sonar/java/psi/PsiLanguageValidator.java:85-93

   `PsiLanguageFeatures.visitVariable` tags every `var`-typed `PsiParameter` as `Feature.LAMBDA_VAR` (PsiLanguageFeatures.java:82). In IntelliJ PSI, the iteration variable of an enhanced `for` (`PsiForeachStatement.getIterationParameter()`) is also a `PsiParameter`, not a `PsiLocalVariable`, so it gets the same tag.
   
   At source level 10, `PsiLanguageValidator` turns every `LAMBDA_VAR` into a `Kind.FATAL` "'var' is not allowed here" (PsiLanguageValidator.java:91-92). `PsiDiagnosticProvider.language` then throws a `RecognitionException` for the first FATAL diagnostic. JLS 10 (JEP 286) allows `var` in enhanced-for loops, so a valid Java 10 file such as `for (var s : list) {}` fails to parse. Only Java 11 added `var` for lambda parameters, which is the case this branch is meant to reject. The tests only cover the lambda case (PsiLanguageValidatorTest.java:72-73).
   
   Fix: give `LAMBDA_VAR` only to parameters whose declaration scope is a `PsiLambdaExpression`, and treat foreach iteration parameters (and other non-lambda parameters) as `LOCAL_VAR`.

   Fix (Only classify parameters declared by a lambda as LAMBDA_VAR.):
   var type = variable.getTypeElement();
   if (type != null && type.getText().equals("var")) {
     boolean lambdaParameter = variable instanceof PsiParameter parameter
       && parameter.getDeclarationScope() instanceof com.intellij.psi.PsiLambdaExpression;
     add(lambdaParameter ? Feature.LAMBDA_VAR : Feature.LOCAL_VAR, type);
   }

Verification Rules 1/1 met Repos 1 inspected · PRs 1 inspected

Functional validation No results

Rules 1 passed 2 not applicable

✅ Repository license compliance

Broader impact Repos 1 inspected PRs 1 inspected

Cross-repo 1 repository inspected 0 open impacts

SonarSource/sonar-java-symbolic-execution Inspected

Cross-PR 1 PR inspected 0 open impacts

PR 6456: SONARJAVA-7288 Replace Eclipse JDT core with PSI in the Java frontend Inspected

Auto-approval Not enabled

Set up

_{For more verification details, comment gitar display:verbose.}

Tip

Comment Gitar fix CI or enable auto-apply: gitar auto-apply:on

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing compact verification results.
Unblock → Override a blocking verdict and allow merging.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact	Unblock
gitar auto-apply:on	gitar display:verbose	gitar unblock

_{Was this helpful? React with 👍 / 👎 | Gitar}