[fastapi] Avoid false positive for class dependencies (FAST003)

[twentyone212121]

Summary

Closes #17226.

This PR updates the FAST003 rule to correctly handle FastAPI class dependencies. Specifically, if a path parameter is declared in either:

• a pydantic.BaseModel used as a dependency, or
• the __init__ method of a class used as a dependency,

then FAST003 will no longer incorrectly report it as unused.

FastAPI allows a shortcut when using annotated class dependencies - Depends can be called without arguments, e.g.:

class MyParams(BaseModel):
    my_id: int

@router.get("/{my_id}")
def get_id(params: Annotated[MyParams, Depends()]): ...

This PR ensures that such usage is properly supported by the linter.

Note: Support for dataclasses is not included in this PR. Let me know if you’d like it to be added.

Test Plan

Added relevant test cases to the FAST003.py fixture.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[ntBre]

Thanks! I had a couple of very minor suggestions, but this looks good to me.

How much work do you think it would be to add support for dataclasses? I don't feel too strongly either way. I think we could handle typing.NamedTuples with just a | ["typing", "NamedTuple"] in the is_pydantic_base_model match, but that's probably even less common.

The issue was about BaseModel anyway, so I think it's totally fine to leave it here.

[ntBre]

I'm pretty sure it's impossible to get here if tuple.elts is empty, but we could use tuple.elts.first()? just in case.

[ntBre]

Suggested change

	let Some(qualified_name) = semantic.resolve_qualified_name(expr) else {
	return false;
	};
	matches!(qualified_name.segments(), ["pydantic", "BaseModel"])
	semantic.resolve_qualified_name(expr)
	.is_some_and(|qualified_name| matches!(qualified_name.segments(), ["pydantic", "BaseModel"]))

[ntBre]

Can we use non_posonly_non_variadic_parameters like in the function branch and just tack skip(1) on the end? I think that would be the same as this, just with the chain and skip calls swapped, which seems like it should be okay.

[twentyone212121]

Thanks for the review! I’ve made the changes you suggested in the latest commit.

Regarding dataclasses, the simple option would be to check if "dataclass" is in class_def.decorator_list. But since pydantic has its own version (pydantic.dataclasses.dataclass) and there’s also support from the attrs library, it gets a bit trickier.

I saw that Ruff already has some logic for handling this in ruff/rules/helpers.rs, which seems pretty thorough. But it seems like I can't access it from fastapi module.

ruff/crates/ruff_linter/src/rules/ruff/rules/helpers.rs

Lines 95 to 109 in 04dc48e

	/// Enumeration of various kinds of dataclasses recognised by Ruff
	#[derive(Debug, Copy, Clone, PartialEq, Eq)]
	pub(super) enum DataclassKind {
	/// dataclasses created by the stdlib `dataclasses` module
	Stdlib,
	/// dataclasses created by the third-party `attrs` library
	Attrs(AttrsAutoAttribs),
	}
	/// Return the kind of dataclass this class definition is (stdlib or `attrs`),
	/// or `None` if the class is not a dataclass.
	pub(super) fn dataclass_kind<'a>(
	class_def: &'a ast::StmtClassDef,
	semantic: &SemanticModel,
	) -> Option<(DataclassKind, &'a ast::Decorator)> {

That said, I’m not sure we need that level of complexity for this rule. Open to your thoughts if you think it’s worth adding support for them here.

[twentyone212121]

CI / ecosystem check is failing due to a Connect Timeout Error. Not sure what to do about this

[ntBre]

Ah okay, I didn't really consider the full variety of "dataclasses." I think it's fine to leave the PR as is! Nice find on the helpers, though, that will come in handy if we update this later. I think we'd just need to change pub(super) to pub(crate) to access them here, but it's possible that we'd have to change some module visibilities or even move the code too.

CI / ecosystem check is failing due to a Connect Timeout Error. Not sure what to do about this

Looks like this resolved eventually, probably just a temporary network issue.

I'll give this another quick review soon, hopefully today!

[ntBre]

Looks great, thanks again!