From 6b429409c53b0a675d2430bffea7209b9e07825e Mon Sep 17 00:00:00 2001 From: Douglas Creager Date: Wed, 10 Dec 2025 16:47:52 -0500 Subject: [PATCH] fix docs --- crates/ty_python_semantic/src/types/signatures.rs | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/crates/ty_python_semantic/src/types/signatures.rs b/crates/ty_python_semantic/src/types/signatures.rs index 0a9dd56268..b91c8d626c 100644 --- a/crates/ty_python_semantic/src/types/signatures.rs +++ b/crates/ty_python_semantic/src/types/signatures.rs @@ -32,13 +32,12 @@ use ruff_python_ast::{self as ast, name::Name}; /// Infer the type of a parameter or return annotation in a function signature. /// -/// This is very similar to -/// [`definition_expression_type`][crate::types::definition_expression_type], but knows that -/// `TypeInferenceBuilder` will always infer the parameters and return of a function in its PEP-695 -/// typevar scope, if there is one; otherwise they will be inferred in the function definition -/// scope, but will always be deferred. (This prevents spurious salsa cycles when we need the -/// signature of the function while in the middle of inferring its definition scope — for instance, -/// when applying decorators.) +/// This is very similar to [`definition_expression_type`], but knows that `TypeInferenceBuilder` +/// will always infer the parameters and return of a function in its PEP-695 typevar scope, if +/// there is one; otherwise they will be inferred in the function definition scope, but will always +/// be deferred. (This prevents spurious salsa cycles when we need the signature of the function +/// while in the middle of inferring its definition scope — for instance, when applying +/// decorators.) fn function_signature_expression_type<'db>( db: &'db dyn Db, definition: Definition<'db>,