Maxime Arthaud

This commit **fixes a regression** in the **`pyrefly` binding layer** by addressing missing arguments in calls to `synthesize_collections_named_tuple_def` and `synthesize_typing_named_tuple_def`. Specifically, it updates the two call sites within **`expr.rs`** that handle **functional-form `namedtuple` definitions**. The `adjacent_defaults` parameter, which was previously omitted, is now correctly passed as `None` since these functional calls do not have adjacent class-body defaults. This **bug fix** ensures the proper synthesis of `namedtuple` types, resolving an oversight from a prior change that introduced the parameter.

This commit introduces **support for Python properties defined via direct assignment** (e.g., `foo = property(get_foo)`) within the **Pysa call graph generation**. Previously, the call graph only recognized properties defined using the `@property` decorator, leading to incomplete analysis. The **call graph visitor** in `pyrefly/lib/report/pysa/call_graph.rs` is now enhanced to **resolve the underlying getter function** for these assigned properties. This is achieved by updating the **module index** (`pyrefly/lib/report/pysa/module_index.rs`) to store getter references and modifying `ClassField` to identify properties, thereby improving the accuracy of **Pysa's data flow analysis** for a broader range of Python code patterns. This **feature enhancement** ensures more comprehensive security and correctness checks by correctly modeling these property accesses.

This commit introduces a **new capability** to the **`ModuleIds` system** within `pyrefly/lib/report/pysa/module.rs` by **pre-assigning deterministic module IDs** for all bundled **typeshed modules**. It ensures these modules are sorted and assigned IDs starting from 1 *before* project handles are processed, which then continue the ID counter from a rounded boundary. This **feature enhancement** guarantees **stable and predictable identification** for typeshed modules, improving the consistency of static analysis results within tools like Pysa. Dependency modules discovered later will still receive lazy IDs, maintaining flexibility for dynamic dependencies.

This commit **enhances Pysa's static analysis capabilities** by introducing **support for projects with multiple Python versions and/or platforms**. It achieves this by replacing `ModuleKey` with `Handle` in Pysa's module ID assignment, ensuring that modules with different `SysInfo` (Python version or platform) receive distinct `ModuleId`s. This **feature enhancement** involves **refactoring** the **Pysa module identification system** to attach `SysInfo` to each module and updating the `pyrefly.pysa.json` project file structure to support multiple builtin and typing variants. The change allows Pysa to accurately analyze complex codebases that mix environments, significantly improving its applicability.

This commit performs **refactoring** within the **`pyrefly` library** to address lint warnings. It adjusts the visibility of internal components, making the `with_solver` function in `pysa`'s context module crate-private while exposing the `GraphQLDecoratorRef` struct and its fields in `pysa`'s module index as public. Additionally, the argument passing style for the `get_module` function call in the state management module is modified. These changes improve internal code consistency and encapsulation within `pyrefly`'s **`pysa` reporting, module indexing, and state management subsystems**.

This commit **refactors the Pysa reporting mechanism** within `pyrefly` to significantly **reduce memory consumption** and prevent Out-Of-Memory errors during analysis. Instead of a separate post-processing step, Pysa reporting is now **inlined during type checking** for each module, allowing for early eviction of module-specific data from memory. This is achieved by introducing `PysaSolutions` to store per-module Pysa data and a `PysaReporter` that leverages a new `PysaResolver` for efficient cross-module lookups, thereby eliminating the need for large `WholeProgramXXX` data structures. The change primarily impacts the **`pyrefly` type checking pipeline** and **Pysa analysis subsystem**, leading to a more scalable and memory-efficient analysis process.

This commit introduces `ModuleAnswersContext` as a **refactoring** within the **`pyrefly` Pysa reporting subsystem** to separate module-specific data from cross-module dependencies. This change is a **preparatory step** for integrating Pysa reporting directly into the type-checking process, aiming to **reduce memory usage** by avoiding the preservation of full module states. By encapsulating data like AST, bindings, and answers in `ModuleAnswersContext`, it prevents accidental cross-module queries during Pysa information building, thereby avoiding resolution cycles. This architectural adjustment impacts numerous Pysa-related files, including `call_graph.rs` and `class.rs`, by narrowing their context dependencies and inlining `get_class_field_from_current_class_only` to use the new, more restricted context.

This commit **refactors** the **PySA extraction logic** by moving the `overridden_base_method` field from `FunctionBaseDefinition` to `FunctionDefinition` within the `pyrefly` module. This change shifts the override graph lookup from `export_all_functions` to `export_function_definitions`, which is a crucial prerequisite for **inlining PySA extraction** before eviction. As part of this **maintenance** and **code cleanup**, the unused `WholeProgramReversedOverrideGraph` struct and `build_reversed_override_graph` function are removed, simplifying the **override graph handling**. The **PySA analysis pipeline** benefits from a more streamlined architecture, with updated tests reflecting these changes.

This commit **refactors** the **Pysa static analysis module** by making the `global_variables` and `captured_variables` fields of the `CallGraphVisitor` struct **optional**. This change allows for more flexible instantiation of the visitor, particularly in contexts like `resolve_decorator_callees` or during future inline Pysa extraction where these variables might not yet be available. Additionally, the `export_call_graphs` function was updated to accept module-specific captured variables (`&ModuleCapturedVariables<FunctionRef>`) instead of whole-program variables, pushing the per-module extraction logic to its callers. This **refactoring** enhances the modularity and adaptability of the **call graph generation** process within Pysa.

This commit **refactors** the **`pyrefly/lib/report/pysa`** module by modifying the `ModuleContext::create()` function. Instead of returning an `Option<ModuleContext>`, the function now directly returns a `ModuleContext`, incorporating `.expect()` calls internally to provide more descriptive panic messages if essential components are missing during creation. This change **improves error diagnostics** for the `ModuleContext` creation process and simplifies caller code by eliminating redundant `.unwrap()` calls. The update affects all internal callers of `ModuleContext::create()` within the Pysa reporting subsystem and its associated test suite, ensuring consistent and clearer failure modes.

This commit introduces the **`PysaModuleIndex`** and **`WholeProgramPysaModuleIndex`** to fundamentally **refactor** how cross-module data is accessed within the **`pyrefly` Pysa reporting subsystem**. This **new capability** provides a compact, persistent index for Pysa-relevant data like function references and class fields, built during type checking to replace memory-intensive direct `ModuleContext::create` calls. The change significantly impacts **call graph resolution**, **class and function definition handling**, and **override graph construction**, enabling more efficient lookups. This **performance optimization** is a foundational step towards integrating Pysa reporting directly into the type-checking process, aiming for **reduced memory usage** by persisting Pysa-relevant data after module eviction.

This commit **refactors** the **call graph building logic** within **`pyrefly`'s Pysa reporting** to eliminate its direct dependency on the override graph. Previously, call graph generation required a global override graph, which is incompatible with the planned integration of Pysa reporting into the type-checking phase. Now, virtual method calls directly emit a `Target::Override` with a `receiver_class`, deferring the expansion and filtering of overrides to the Pysa analysis itself, where the override graph is available. This **preparatory change** enables a future re-design aimed at **reducing memory usage** during Pysa reporting by avoiding the preservation of internal states across all modules. The changes are primarily in `pyrefly/lib/report/pysa/call_graph.rs`, with corresponding test updates.

This commit **fixes a crash** in the **`answers_solver`** within `pyrefly/lib/alt/answers_solver.rs` that occurred during cross-module SCC cold iteration. The issue stemmed from solver-local `Vars` incorrectly leaking into an outer module's trace sink when `record_type_trace` was called, leading to a panic upon trace finalization. The **bug fix** ensures a dedicated trace sink is always installed when tracing is enabled, regardless of cold iteration status, preventing foreign `Vars` from contaminating outer contexts. Traces collected during cold iteration are now properly discarded, enhancing the **stability** and **correctness** of the solver's tracing mechanism.

This commit **adds a new test case** to `pyrefly/lib/test/pysa/call_graph.rs` to document a **bug** in **Pyrefly's call graph generation** logic. It specifically highlights an issue where calling a class method on a **union type within `Type`** (e.g., `Type[A | B]`) causes Pyrefly to incorrectly lose the `receiver_class`, resulting in a `Function` dispatch instead of the expected `AllOverrides`. This incorrect dispatch prevents **Pysa** from considering subclass overrides, leading to potential **false negatives** in its analysis. The test serves as a **maintenance** item, capturing the current buggy behavior and indicating the need for a future **bug fix** to ensure accurate dispatch and improve Pysa's security analysis.

This commit **adds new call graph tests** within `pyrefly/lib/test/pysa/call_graph.rs` to document the current behavior of constructor call graphs for **dataclass and NamedTuple types**. The tests illustrate that `dataclass` `__init__` resolves to the class and `__new__` to `builtins.object.__new__`, while `NamedTuple` `__new__` resolves to the user's class with `implicit_receiver: TrueWithObjectReceiver`. Furthermore, it demonstrates that `__init__` and `__new__` are attributed to `NamedTuple` subclasses even without explicit definitions. This **maintenance** work improves the accuracy and validation of **Pysa's call graph analysis** for these common Python constructs.

This commit **fixes a bug** in **Pysa's call graph analysis** within `pyrefly` that previously led to **false negatives**. Specifically, the system failed to consider all potential overrides when analyzing calls to expressions inferred as a type variable with a bound. The `receiver_class_from_type` function in `pyrefly/lib/report/pysa/call_graph.rs` is updated to correctly use the bound of a quantified type variable for receiver resolution. This ensures more accurate call graph generation, improving the reliability of `pysa-pyrefly`'s analysis, especially for generic classes and method overrides, and is validated by a new test case.

This commit **adds new tests** to `pyrefly/lib/test/pysa/call_graph.rs` to verify the **call graph resolution** for properties and classproperties that return a `Type[X]`. Specifically, it checks if calling the result correctly resolves to the constructor (`__init__`) in the **Pysa call graph**. The tests confirm that `property` works as expected, but reveal a **bug** where `classproperty` fails to resolve the call to the constructor, treating it as a regular function call instead. This **test addition** helps identify a discrepancy in how **Pysa's call graph analysis** handles these specific scenarios, highlighting an area for improvement in the static analysis.

This commit introduces a **performance optimization** within the **Pysa type export mechanism** by **refactoring** the `pyrefly/lib/report/pysa/type_of_expression.rs` module. Specifically, the `maybe_export_type` and `visit_expression` functions are updated to **selectively export expression types**. Instead of exporting all types, the system now only includes types for Name nodes, Attribute access bases, and Call arguments, which are the only categories required by **Pysa** for features like type breadcrumbs, call graph construction, and method checks. This targeted approach significantly **reduces the volume of data written to JSON and parsed by the OCaml consumer**, thereby improving the overall efficiency of the **Pysa static analysis tool**.

This commit introduces a **new capability** by implementing a `FuncDefIndex` to uniquely identify function definitions within the **PyreFly** system, particularly for **Pysa's taint analysis**. This index is assigned during the binding phase and stored in `UndecoratedFunction` metadata, addressing a critical limitation where functions could not be uniquely identified by name and module alone, leading to unresolved calls. The primary impact is on **Pysa's call graph generation**, enabling more accurate resolution of function calls and significantly improving the precision of taint analysis by reducing false positives and negatives. This change involves **refactoring** across `pyrefly_types`, `pyrefly/lib/binding`, and `pyrefly/lib/alt` to integrate the new indexing mechanism and update existing function metadata structures.

This commit **improves the inference of `is_attribute=True`** within the **Pysa call graph generation** in `pyrefly`. It **refactors** the attribute resolution logic in `pyrefly/lib/report/pysa/call_graph.rs` by removing the dedicated `resolve_magic_dunder_attr` function and integrating its functionality into `resolve_attribute_access`. This **enhancement** ensures that `is_attribute` is correctly inferred when "go to definition" returns the location of an attribute. The change leads to more accurate **Pysa analysis results** and a better understanding of code structure by precisely identifying attributes.