Filter dependent type annotations referencing out-of-scope local vari…

[shubhamk0205]

solves #4105

this pr makes dependent type annotations aware of the scope . after the annotations are applied , any annotation that refers to a local variable that is now not present in the scope is getting removed automatically .

i have also added a test case file in the pr

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a public test class ScopeCleanup with two methods testing dependent-annotation scope cleanup and parameter scoping. Exposes tracked local variables via CFAbstractStore.getLocalVariables(). GenericAnnotatedTypeFactory now filters inferred dependent annotations that reference out-of-scope locals by consulting the store before the current tree. Adds DependentTypesHelper.filterAnnotationsForOutOfScopeVars(...) to remove dependent annotations whose expressions reference locals not in a provided in-scope set. Appends "Shubham Kapoor" to docs/manual/contributors.tex.

Suggested reviewers

• smillst

🚥 Pre-merge checks | ✅ 1

✅ Passed checks (1 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 87.50% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@checker/tests/index/ScopeCleanup.java`:
- Around line 46-58: The test method testParametersRemainInScope lacks any
assertion that uses the parameter after the inner block; add an assignment or
assertion that uses the dependent annotation `@LessThan`("param") (for example
assign a variable annotated `@LessThan`("param") to x or similar) after the inner
block so the checker actually validates that the method parameter param remains
in scope; target the testParametersRemainInScope method and add the annotated
assignment/verification immediately after the closing brace of the inner block
to exercise scope retention.

In
`@framework/src/main/java/org/checkerframework/framework/util/dependenttypes/DependentTypesHelper.java`:
- Around line 781-812: The code in DependentTypesHelper currently calls
StringToJavaExpression.atPath(...) without handling
JavaExpressionParseException; wrap the call to StringToJavaExpression.atPath in
a try/catch that catches JavaExpressionParseException and returns null (dropping
the expression) so parse failures don't produce error annotations; keep the
existing JavaExpressionConverter logic and only catch
JavaExpressionParseException from the atPath invocation (rethrow or preserve
other exceptions).

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In
`@framework/src/main/java/org/checkerframework/framework/type/GenericAnnotatedTypeFactory.java`:
- Around line 1993-2001: The current logic uses Store store =
getStoreBefore(tree); Set<LocalVariable> inScopeVars =
store.getLocalVariables(); which omits syntactically in-scope locals that are
unassigned (TOP), causing valid dependent annotations to be filtered; replace
this by deriving the set of in-scope locals from a scope/syntactic source (e.g.,
the scope for the tree or a helper that returns all local variable symbols for
the current path) or merge store.getLocalVariables() with the syntactic scope's
locals so unassigned locals are included, then pass that complete set into
dependentTypesHelper.filterAnnotationsForOutOfScopeVars(type, inScopeVars,
getPath(tree)); ensure parameters keep their existing special-case handling
analogously.

[mernst]

@shubhamk0205 Please let us know when you have resolved the CI test failures (or if you need help with them).

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In
`@framework/src/main/java/org/checkerframework/framework/util/dependenttypes/DependentTypesHelper.java`:
- Around line 781-786: The lambda assigned to StringToJavaExpression
(stringToJavaExpr) contains a redundant shouldPassThroughExpression check and
creation of PassThroughExpression because convertAnnotationMirror already skips
invoking stringToJavaExpr for pass-through cases; remove that conditional branch
from the lambda so stringToJavaExpr only handles non-pass-through conversion
paths (leave references to objectTM and any remaining expression handling
intact) and ensure all pass-through behavior remains centralized in
convertAnnotationMirror rather than inside stringToJavaExpr.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In
`@framework/src/main/java/org/checkerframework/framework/util/dependenttypes/DependentTypesHelper.java`:
- Around line 771-772: The method filterAnnotationsForOutOfScopeVars declares a
null guard and Javadoc implying that the TreePath parameter may be null but the
signature lacks a nullability annotation; update the method signature to mark
the path parameter as `@Nullable` (e.g., change TreePath path to `@Nullable`
TreePath path), add or update the Javadoc to state that path may be null, and
import the project's nullability annotation (use the project's standard
annotation, e.g., org.checkerframework.checker.nullness.qual.Nullable) so
nullness analysis is consistent with the implementation in
DependentTypesHelper.filterAnnotationsForOutOfScopeVars.

[shubhamk0205]

@mernst can u guide me a little i am a bit stuck here ,

i have tried to make the current filtering approach work , for example - @keyFor on variable declaration , the main problem seems to be that the dependent annotations only store strings, so when they’re checked later those strings get re resolved to whatever variable with the same name is currently in scope . because of this we can not tell that the annotation refers to a variable that went out of the scope or a new one with the same name

now one option to be somehow fix this and the other one would be to follow the second approach that u mentioned
that is A simpler approach would be to re-standardize (or re-parse all dependent type Java expressions), and drop any such that yields an error

what would you prefer ?