Clarifying target-version in flake8-future-annotations docs (#6520)

crates/ruff/src/rules/flake8_future_annotations/rules/future_required_type_annotation.rs

@@ -20,6 +20,12 @@ use crate::checkers::ast::Checker;
 /// annotations at evaluation time, making the code compatible with both past
 /// and future Python versions.
 ///
+/// This rule respects the [`target-version`] setting. For example, if your
+/// project targets Python 3.10 and above, adding `from __future__ import annotations`
+/// does not impact your ability to leverage PEP 604-style unions (e.g., to
+/// convert `Optional[str]` to `str | None`). As such, this rule will only
+/// flag such usages if your project targets Python 3.9 or below.
+///
 /// ## Example
 /// ```python
 /// def func(obj: dict[str, int | None]) -> None:
@@ -34,6 +40,9 @@ use crate::checkers::ast::Checker;
 /// def func(obj: dict[str, int | None]) -> None:
 ///     ...
 /// ```
+///
+/// ## Options
+/// - `target-version`
 #[violation]
 pub struct FutureRequiredTypeAnnotation {
     reason: Reason,

crates/ruff/src/rules/flake8_future_annotations/rules/future_rewritable_type_annotation.rs

@@ -13,14 +13,25 @@ use crate::checkers::ast::Checker;
 ///
 /// ## Why is this bad?
 /// PEP 563 enabled the use of a number of convenient type annotations, such as
-/// `list[str]` instead of `List[str]`, or `str | None` instead of
-/// `Optional[str]`. However, these annotations are only available on Python
-/// 3.9 and higher, _unless_ the `from __future__ import annotations` import is present.
+/// `list[str]` instead of `List[str]`. However, these annotations are only
+/// available on Python 3.9 and higher, _unless_ the `from __future__ import annotations`
+/// import is present.
+///
+/// Similarly, PEP 604 enabled the use of the `|` operator for unions, such as
+/// `str | None` instead of `Optional[str]`. However, these annotations are only
+/// available on Python 3.10 and higher, _unless_ the `from __future__ import annotations`
+/// import is present.
 ///
 /// By adding the `__future__` import, the pyupgrade rules can automatically
 /// migrate existing code to use the new syntax, even for older Python versions.
 /// This rule thus pairs well with pyupgrade and with Ruff's pyupgrade rules.
 ///
+/// This rule respects the [`target-version`] setting. For example, if your
+/// project targets Python 3.10 and above, adding `from __future__ import annotations`
+/// does not impact your ability to leverage PEP 604-style unions (e.g., to
+/// convert `Optional[str]` to `str | None`). As such, this rule will only
+/// flag such usages if your project targets Python 3.9 or below.
+///
 /// ## Example
 /// ```python
 /// from typing import List, Dict, Optional

crates/ruff/src/rules/pylint/rules/too_many_arguments.rs

@@ -10,7 +10,7 @@ use crate::checkers::ast::Checker;
 /// Checks for function definitions that include too many arguments.
 ///
 /// By default, this rule allows up to five arguments, as configured by the
-/// `pylint.max-args` option.
+/// [`pylint.max-args`] option.
 ///
 /// ## Why is this bad?
 /// Functions with many arguments are harder to understand, maintain, and call.

crates/ruff/src/rules/pylint/rules/too_many_branches.rs

@@ -8,7 +8,7 @@ use ruff_python_ast::identifier::Identifier;
 /// Checks for functions or methods with too many branches.
 ///
 /// By default, this rule allows up to 12 branches. This can be configured
-/// using the `max-branches` option.
+/// using the [`pylint.max-branches`] option.
 ///
 /// ## Why is this bad?
 /// Functions or methods with many branches are harder to understand
@@ -66,8 +66,8 @@ use ruff_python_ast::identifier::Identifier;
 ///     return city
 /// ```
 ///
-/// ## References
-/// - [Ruff configuration documentation](https://beta.ruff.rs/docs/settings/#max-branches)
+/// ## Options
+/// - `pylint.max-branches`
 #[violation]
 pub struct TooManyBranches {
     branches: usize,

crates/ruff/src/rules/pylint/rules/too_many_return_statements.rs

@@ -10,7 +10,7 @@ use ruff_python_ast::statement_visitor::StatementVisitor;
 /// Checks for functions or methods with too many return statements.
 ///
 /// By default, this rule allows up to six return statements, as configured by
-/// the `pylint.max-returns` option.
+/// the [`pylint.max-returns`] option.
 ///
 /// ## Why is this bad?
 /// Functions or methods with many return statements are harder to understand

crates/ruff/src/rules/pylint/rules/too_many_statements.rs

@@ -8,7 +8,7 @@ use ruff_python_ast::identifier::Identifier;
 /// Checks for functions or methods with too many statements.
 ///
 /// By default, this rule allows up to 50 statements, as configured by the
-/// `pylint.max-statements` option.
+/// [`pylint.max-statements`] option.
 ///
 /// ## Why is this bad?
 /// Functions or methods with many statements are harder to understand