python_param_annotations Namespace Reference

Classes
struct	module_ast
	One module's AST. More...

Functions
void	propagate_tuple_list_params (const std::vector< module_ast > &modules)
	Retype list[...] parameters from the tuples their callers pass.
void	propagate_scalar_params (const std::vector< module_ast > &modules)
	Annotate the unannotated parameters of imported modules' top-level functions with the scalar type every call site passes (GitHub #8501).

Function Documentation

propagate_scalar_params()

void python_param_annotations::propagate_scalar_params

(

const std::vector< module_ast > &

modules

)

Annotate the unannotated parameters of imported modules' top-level functions with the scalar type every call site passes (GitHub #8501).

Only modules with a non-null write are rewritten, and only parameters reached by at least one call from another module.

propagate_tuple_list_params()

void python_param_annotations::propagate_tuple_list_params

(

const std::vector< module_ast > &

modules

)

Retype list[...] parameters from the tuples their callers pass.

Python does not enforce annotations, so def f(a: list[int]) fed [(1, 5), (1, 2)] would have each tuple's payload reinterpreted as an int and report VERIFICATION SUCCESSFUL for a program CPython rejects (GitHub #5936). Rewriting the parameter's annotation to the element type its callers actually pass corrects every consumer at once, and must therefore run before the AST is type-annotated.

A parameter fed different element types by different call sites, or one whose argument this pass cannot type, is left alone: the frontend emits one GOTO function per Python function, so no single annotation could be correct. Only tuple element types are inferred; a mis-annotated scalar is already corrected at read time by the stored-type_id dispatch in the list model.

Parameters

modules

Every module in the import graph. Call sites are searched in all of them; only those with a non-null write are rewritten.