Rebecca Chen (Python)

This commit **reverts a previously introduced, non-spec-compliant rule** within the **overload evaluation logic** of the type checker. It removes an incorrect elimination step for variadic parameters and keyword arguments from the `solve_call` method in `pyrefly/lib/alt/overload.rs`. This **bug fix** ensures that the **overload resolution** process correctly aligns with the behavior of established type checkers, preventing erroneous overload eliminations. Accompanying test cases in `pyrefly/lib/test/overload.rs` are updated and expanded to validate this corrected, spec-compliant behavior.

This commit introduces a **temporary fix** within the **`pyrefly` type solver** to address issue #105, specifically concerning the handling of advanced type constructs. It modifies the `is_subset_eq` function in `pyrefly/lib/solver/solver.rs` to implement **eager pinning** for `ParamSpec` and `TypeVarTuple` when they appear as quantified variables. This **bug fix** ensures these specific type constructs are correctly resolved during subset equality checks, preventing potential type resolution errors or incorrect type inference. The change is a **targeted workaround** to stabilize type checking for these features while a more comprehensive solution is developed.

This commit introduces a **bug fix** to the **type solver logic** within the `pyrefly` library. It **modifies the `solve_variable_with_type` function** in `pyrefly/lib/solver/solver.rs` to prevent the addition of a lower bound if it would violate an existing upper bound for a variable. Instead of allowing an inconsistent state, the solver now assigns an `Any::Error` type to the variable, indicating a type conflict without marking it as unsolved. This change improves the robustness and accuracy of **type inference** by ensuring that contradictory bounds are properly handled, addressing issue #105.

This commit introduces a **refactoring** within the **solver library** by extracting a new private helper function, `add_bound`, from the existing `add_lower_bound` function in `pyrefly/lib/solver/solver.rs`. This new helper encapsulates common logic for adding bounds, making `add_lower_bound` simpler and more readable. The extraction prepares the groundwork for future improvements to `add_upper_bound` by allowing it to also leverage this shared logic. Ultimately, this enhances the maintainability and clarity of the **solver's** bound management by centralizing common operations.

This commit introduces a **new capability** to the **solver library** by adding the `get_current_bound` function in `pyrefly/lib/solver/solver.rs`. This function retrieves the current bound of an unfinished variable, crucially differing from `solve_one_bounds` by *not* filtering out `Any` types. This ensures that the **solver's bound comparison logic** can correctly evaluate new upper or lower bounds against existing ones, even when `Any` types are present, preventing premature errors. The change refines how bounds are accessed for comparison, leading to more robust and accurate type resolution within the **solver subsystem**.

This commit **enhances the `solver` module** in `pyrefly` by improving its bound-solving capabilities. It **fixes a limitation** in the `Solver::solve_bounds` function, allowing it to now consider **upper bounds** when lower bounds are not definitive. Consequently, the `Bounds::is_empty` method has been updated to accurately reflect the presence of either lower or upper bounds. This ensures more robust and complete bound calculations, leading to more precise constraint resolution within the system.

This commit provides a **bug fix** for the **PyreFly type solver**, specifically addressing an issue where promoting implicit literals could inadvertently cause a lower bound to violate an existing upper bound. The `is_subset_eq_quantified` function within `pyrefly/lib/solver/solver.rs` is modified to perform an explicit check against upper bounds *before* promoting literals. This prevents the solver from generating inconsistent or invalid type constraints. The change ensures more robust and accurate type inference by maintaining the integrity of type bounds during literal promotion.

This commit performs a **code simplification** within the **`pyrefly` solver** by **refactoring** the `solver.rs` file. It removes the redundant `is_partial` variable and its associated conditional check, as the condition was always evaluating to true after a previous change. This change streamlines the logic for handling `PartialQuantified` variables, making the code more concise and easier to understand without altering its functional behavior. The primary impact is improved **maintainability** and **readability** of the solver's internal implementation.

This commit **improves the type inference accuracy** within the **`pyrefly` type solver** by implementing the collection of upper bounds for `Quantified` and `Unwrap` type variables. Specifically, the `is_subset_eq` function in `pyrefly/lib/solver/solver.rs` now correctly gathers these bounds during subset equality checks when a variable is compared to a non-variable type. This **bug fix** resolves several long-standing issues related to generic type handling, as evidenced by the removal of `bug` comments and error annotations across various **test cases** in `pyrefly/lib/test/`. The change leads to more precise type checking, reducing false positives in certain scenarios and updating expected conformance test output.

This commit **refactors** the **`pyrefly` solver library** by modifying the `add_upper_bound` function in `solver.rs` to internally utilize the existing `add_bound` function, promoting code reuse and simplifying the logic. This change updates the signature of `add_upper_bound` and its call site within `solve_call`, as well as the call from `is_subset_eq` in `subset.rs` to pass a new `is_subset` closure argument. This **refactoring** acts as a **bug fix**, specifically addressing issue #105 by eliminating false positives encountered in `mypy_primer`, thereby improving the accuracy of the type solver's constraint handling.

This commit **reverts** a recent change that introduced a "function defined here" secondary annotation to **error messages**. The annotation was found to be incorrect, pointing to the wrong location, and a proper fix would require substantial additional plumbing. Consequently, this change **removes** the misleading annotation from the **error reporting system** to prevent user confusion and ensure accuracy. The associated **test files** (`test/errors.md`, `test/snippet.md`, `test/tensor_shapes/negative_tests/test_errors.md`) are updated to reflect the absence of this annotation in expected error outputs.

This commit introduces a **new configuration flag**, `--spec-compliant-overloads`, to the **PyRefly project**, enabling future control over the **overload evaluation algorithm** within the `Solver` module. It establishes the complete **configuration plumbing** across the `pyrefly_config` crate, allowing the flag's value to be passed from command-line arguments and configuration files through the `State` module to the `Solver` and its associated test utilities. While this **feature addition** currently has no functional impact on the solver's behavior, it lays the essential groundwork for future modifications to ensure spec compliance.

This commit **refactors** the **overload evaluation and disambiguation logic** within the **`pyrefly` library's `alt/overload.rs` module**. The existing disambiguation logic, previously part of `solve_overloads`, has been extracted into a new helper function, `disambiguate_overloads_spec_compliant`, within the `AnswersSolver` struct. This is a **non-functional refactoring** effort, explicitly undertaken to **prepare the codebase for future enhancements**, specifically to facilitate the addition of a behavior flag that will control how multiple overload matches are handled. The change improves modularity and maintainability without altering current runtime behavior of the **overload resolution subsystem**.

This commit **enhances the Pyrefly type checker's overload resolution logic** by refining how ambiguous overloaded function calls are handled. Previously, such calls defaulted to a return type of `Any`; now, the system attempts to select the "most general" return type among the matched overloads, if one exists, providing more specific type inference. This **feature improvement** significantly **reduces `assert_type` failures** in complex libraries like NumPy and SciPy by providing more precise return types. While this change leads to **more accurate type checking**, it may also introduce new, technically correct errors in other projects, potentially requiring explicit type annotations in affected codebases like `nanogpt.py`.

This commit **fixes a bug in Pyrefly's overload resolution** by correcting how it determines return types for ambiguous calls. Previously, the system incorrectly used `is_consistent` instead of `is_equivalent` when comparing return types, leading to inaccurate type inference for overloaded functions. The change in `pyrefly/lib/alt/overload.rs` ensures that **overload resolution properly checks for equivalent return types**, improving the accuracy of type checking for ambiguous calls. This **bug fix** addresses a user-reported issue and updates `assert_type` expectations in `pyrefly/lib/test/overload.rs` to reflect the corrected behavior, ensuring more reliable type inference within the **Pyrefly type checker**.

This commit **enhances the `--spec-compliant-overloads` flag** within the **`pyrefly` overload resolution system** to ensure full adherence to the specification. It **modifies the core overload resolution logic** in `pyrefly/lib/alt/overload.rs` to conditionally disable all three known non-spec-compliant behaviors, specifically addressing `varargs`/`kwargs` compatibility and argument materialization. This **compliance improvement** ensures that when the flag is active, the system behaves precisely as defined by the specification, impacting how overloads are matched for variadic parameters and literal arguments. New test cases in `pyrefly/lib/test/overload.rs` validate this corrected behavior.

This commit provides a **bug fix** to resolve a **GitHub build failure** within the `pyrefly` project. It updates the call to `LspInteraction::new_with_args` in the **`pytorch_benchmark.rs`** test file by adding a `None` argument for `thrift_remapper`. This change aligns the function call with an updated signature, which was previously missed because the affected test is exclusively compiled in GitHub/cargo environments, not internal builds. The fix ensures the **`lsp_interaction`** module's `pytorch_benchmark` test compiles correctly, restoring the integrity of external CI builds.

This commit **improves code style and maintainability** within the **LSP server's request handling logic** by refactoring deeply nested `if let` statements. Specifically, it collapses six such blocks in `pyrefly/lib/lsp/non_wasm/server.rs` into more concise chained `&& let` expressions. This **maintenance task** addresses **Clippy warnings** related to `collapsible_if`, making the code easier to read and understand. The change is purely a **code quality improvement** and introduces no functional alterations to the server's behavior.

This commit **refactors** the **solver** module in `pyrefly` to enhance its variable unification capabilities. It modifies the unification logic to now **copy upper bounds** when unifying variables and introduces an `extend` method to the `Bounds` struct. This is a **preparatory enhancement** that, while currently having no immediate functional effect as upper bounds are not yet collected, lays essential groundwork. This change enables future improvements in **type inference** and **constraint solving** by allowing the propagation of upper bound information.

This commit **enhances** the **`pyrefly` solver library** by introducing an `upper` field to the `Bounds` struct within `solver.rs`. Although this new field is currently unused, it is properly initialized in the constructor, laying the groundwork for future **constraint handling** or **solver logic improvements**. This **preparatory change** ensures the `Bounds` data structure is ready for expanded functionality, specifically addressing requirements outlined in issue #105. The modification to `Bounds` is a **refactoring** that anticipates future needs without immediately altering existing solver behavior.