[fastapi] Fix false positive for pre-assigned Depends variables (FAST003)#26354
[fastapi] Fix false positive for pre-assigned Depends variables (FAST003)#26354kpeis695 wants to merge 1 commit into
Depends variables (FAST003)#26354Conversation
|
Can you rephrase the title please? I'm not sure what's up with installing fastapi |
Depends variables (FAST003)Depends variables (FAST003)
|
Updated the title — sorry about that, the FastAPI CLI in my shell polluted the output when I created the PR. |
| // We can't statically resolve what it wraps, so treat it as unknown to avoid | ||
| // false positives — unless it clearly isn't a dependency (i.e. it resolves to | ||
| // something other than an assignment). | ||
| match semantic.only_binding(name).map(|id| semantic.binding(id)) { |
There was a problem hiding this comment.
If we're going to the trouble of resolving a Name to a binding, I don't think it would take much more to get the value itself and see if it's a Depends. Is that right?
There was a problem hiding this comment.
Good point. If the binding is an Assignment, we could walk the RHS and look for a Depends(...) call. Would you want us to fully resolve what it wraps in that case, or just confirm it's a Depends and suppress if we can't trace it further? Happy to give it a shot either way.
There was a problem hiding this comment.
I think we should treat it the same way as an inline Depends.
There was a problem hiding this comment.
Done. When the binding is an Assignment, we now walk the RHS and call depends_arguments on it. If it's a Depends call we treat it exactly like an inline one. If the RHS isn't a Depends at all we still fall back to Unknown to stay conservative.
When a `Depends(...)` call is stored in a variable and that variable is used as metadata in `Annotated[T, AssignedDepends]`, ruff now resolves the assignment RHS to determine which parameters the dependency covers, treating it the same as an inline `Depends(...)`. Previously the rule suppressed the diagnostic for all bare-name metadata elements that resolved to an assignment, which caused false negatives when the path parameter was genuinely missing. Now only the assignment case where the RHS is not a `Depends` call falls back to `Unknown`. Fixes astral-sh#17226 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
593fb48 to
b0e2b83
Compare
Summary
Fixes #17226.
When a
Depends(...)call is pre-assigned to a variable and that variable is used as metadata in anAnnotatedannotation,FAST003incorrectly fires:The rule scans
Annotatedmetadata elements for literalDepends(...)calls. A pre-assignedDependsvariable is a bare name — not a call expression — sodepends_argumentsreturnsNone, the element is silently skipped by thefilter_map, and the path parameter appears unused.The fix treats a bare-name metadata element as
Dependency::Unknown(unless it clearly resolves to a function, class, or import), which causes the check to abort conservatively rather than emitting a false positive.Test Plan
Snapshot tests (
cargo nextest runandcargo insta test).