pyrefly — Engineering Performance

Port 9 TorchBench models with tensor shape annotations Summary: 9 new model ports with full shape tracking: tacotron2, llama, stargan, sam, tts_angular, drq, dlrm, deeprecommender, background_matting. Key improvements over initial ports: - sam: PromptEncoder[D, ES, MIC] fully typed, window partition/unpartition typed, ImageAttention generic over H/W, unified D across components - llama: RoPE chain typed (arange/outer DSL), KV cache typed with Optional start_pos, build_causal_mask typed - tacotron2: variadic Prenet[*Bs], full decoder forward with autoregressive loop - stargan: Generator and Discriminator generic over spatial dim S - drq: SquashedNormal[*EventShape] with typed distributions - dlrm: tensor fancy indexing verified with assert_type 11 type: ignore remaining (5× A1 algebraic, rest genuine limitations). Stub additions: torch.quantization, optim updates, F.interpolate symint. Reviewed By: stroxler Differential Revision: D97893786 fbshipit-source-id: 863984bee7092fdff92b5df46de35cb771c6ac9e

Add Tensor type and subtyping rules Summary: [4/N] of a stack implementing tensor shapes in Pyrefly. Adds foundational tensor shape type system support for torch.Tensor: Type System: - Type::Tensor(Box<TensorType>) for representing shaped tensors - TensorType, TensorShape for shape representation with literal and symbolic dimensions - tensor.rs with broadcast_shapes, parsing, and canonicalization Subtyping Rules: - Tensor rank and dimension matching in subset.rs - Shape compatibility with symbolic arithmetic expressions (N + M, N * 2, etc.) - Shapeless Tensor compatible with any shaped Tensor - TypeVarTuple support for variadic shapes (with arbitrary prefix and suffix) Core Features: - .shape property returns tuple of Literal[n] or Dim[N] types - Integer indexing, slice indexing being shape-aware - Arithmetic operations preserve shape via Self return type (TensorInstance) Minimal torch fixture with Tensor class, arithmetic, comparison, and unary operators. No constructors (torch.randn, etc.) or meta_shape inference - those come in subsequent commits. Reviewed By: samwgoldman Differential Revision: D92527702 fbshipit-source-id: c8716058d88513424678a885657e59c139f65550

Add github workflow for v1 issue ranking Summary: The full issue_ranker package, which is a 5-pass LLM pipeline for ranking pyrefly GitHub issues by priority: 1. GitHub Actions workflow (manual dispatch for now) 2. Issue collection which consists of: - code extraction from issue bodies - snippet repair via LLM - type checker execution (pyrefly/pyright/mypy) - status classification - relationship resolution, - dependency resolution 3. 5-pass LLM ranking pipeline: categorize (Haiku) → primer impact (deterministic error matching then LLM matching if that fails) → dependencies (Opus) → scoring (Sonnet) → final ranking (Opus, batched with retry) 4. Report generation: markdown + JSON output with V1 gap analysis 5. compare_typecheckers.py fixes — 10-min timeouts, pyrefly config cleanup, pyright path overrides (scipy takes too long because it has no config, so we override it) The ranking pipeline uses 8 weighted signals: false positive impact (x3), performance (x3), team priority labels (x2), false negatives/spec compliance (x2), actionability (x2), IDE/usability (x1.5), primer breadth (x1.5), and adoption ecosystem labels (x1.5). Team priority labels (P0/P1/P2) contribute ~20% of the weighting. On the full 391-issue run, the top 20 (critical tier) are dominated by type inference bugs and false positives that affect many primer projects — these would rank highly regardless of labels. Local Results: - Top 10 is 70% the same with or without labels - Labels boost V1 overlap from 29% → 38% (19 → 25 out of 65) with labels P2230410941 without P2230411326 The V1 overlap data from the comparison: WITH labels: 25/65 V1 issues in top 65 (38%) WITHOUT labels: 19/65 V1 issues in top 65 (29%) The 25 V1 issues captured (with labels): #105, #630, #1252, #1286, #1321, #1486, #1518, #1763, #1982, #2043, #2105, #2309, #2370, #2382, #2419, #2445, #2452, #2515, #2517, #2519, #2520, #2522, #2610, #2611, #2616 The 40 V1 issues missed (not in top 65): #43, #219, #317, #383, #385, #397, #793, #795, #881, #908, #920, #1078, #1089, #1159, #1336, #1340, #1422, #1440, #1474, #1728, #1956, #2039, #2064, #2065, #2132, #2139, #2184, #2199, #2207, #2219, #2227, #2303, #2304, #2319, #2386, #2454, #2508, #2535, #2558, #2621 So the ranker agrees with about 38% of the team's V1 picks. NOTE: I need to test this as an actual github workflow. I cannot be 100% certain that the workflow works end to end without kicking off a manual run there. Reviewed By: yangdanny97 Differential Revision: D95686786 fbshipit-source-id: 8de3332306be7d69875a4dfca9f8979e7d19c846

Add plumbing for literal-capturing Flag-bound type vars Summary: Pyrefly needs literal-preserving `Flag` type parameters, but adding a new restriction kind creates broad exhaustive-match fanout before source syntax should construct it. Model `Flag` as a passive `Restriction` with its small builtin domain beside `Restriction`, and mechanically teach display, simplification, solving, queries, and reporting to preserve or project that restriction. The end goal here is to allow us to pass flags to the type-level shape DSL with code that looks like this: ``` def f[B: Flag[bool]](b: B) -> Tensor[takes_a_bool(B)] ``` The stubs use this pattern extensively to avoid the need for a combinatorial number of overloads for all kinds of transforms that take flag values. This commit intentionally does not recognize `Flag` annotations or change inference; the following activation commit provides the single source construction point. Splitting passive representation from activation keeps the mechanical type-system fanout reviewable and behavior-neutral. Reviewed By: rchen152 Differential Revision: D114061238 fbshipit-source-id: c9a3acbff0ef9083a75bcadeb57fcaac1c8c1955

Port 7 TorchBenchmark models with tensor shape annotations Summary: Ports Demucs, DenseNet, LearningToPaint, SoftActorCritic, SpeechTransformer, Super-SloMo, and U-Net from TorchBenchmark with full tensor shape annotations. Each model demonstrates end-to-end shape inference through complex architectures including pooling, upsampling, LSTM, GLU, PixelShuffle, and None indexing. Also adds fixture stubs for torch.distributions (used by SoftActorCritic) and additional torch/__init__.pyi and nn/functional.pyi function stubs needed by the ported models. Reviewed By: yangdanny97 Differential Revision: D97134636 fbshipit-source-id: 672256498c414706845c51ab5c500d519a2b7328

Add attr and attrs stubs to test directory Summary: As discussed in D90205508, we will first add the stubs (attr and attrs) and then followup with testcases. Before adding the unittests, we will setup the plumbing so that the unittest site package path can access the stubs. We will also add a macro like the one for pydantic and django. Reviewed By: yangdanny97 Differential Revision: D90268993 fbshipit-source-id: 01a04045147a89d2ec285dc9e42c12f60bbb9ecd

TypeVar variant for arithmetic Summary: Add torch_shapes.TypeVar and TypeVarTuple classes that support arithmetic operators (N + 1, N * 2, etc.) at Python runtime, unlike typing.TypeVar which raises TypeError. These use __class__ = typing.TypeVar so that isinstance checks pass and Generic[N] works correctly. On the pyrefly side, extend the TypeVar/TypeVarTuple special export recognition to accept torch_shapes as a valid defining module, so torch_shapes.TypeVar is treated identically to typing.TypeVar by the type checker. Also add int_type_var model variants (nanogpt, gptfast) that use torch_shapes.TypeVar instead of PEP 695 syntax, with both type-checked and runnable versions, plus comprehensive runtime and type-checking tests. Reviewed By: stroxler Differential Revision: D95282862 fbshipit-source-id: ec07dbb9efc94b653d6afc4ec9bf6b3d821580f0

Move tests to end of solver.rs Summary: Moves a `mod test {...}` that was sandwiched in the middle of a file. No other changes. Reviewed By: grievejia Differential Revision: D115827083 fbshipit-source-id: e1307a251debc80a27043ba6cbc7523d4faf6645

Add Size and Dim types for dimension tracking Summary: [3/N] of a stack implementing tensor shapes in Pyrefly. Introduce type system support for concrete and symbolic integers appearing in type positions. We will use these eventually to model dimensions in tensor shapes, but they also form a standalone feature. - Type::Size for dimension values (SizeExpr expressions). This is internal, and corresponds to int literals like 1, int symbols like N, and arithmetic expressions on ints like N + 1. - Type::Dim for symbolic integer annotations (Dim[N], Dim[N+1]). This is user-facing, and generalizes Literal[1]. - Arithmetic operations on Dim types (+, -, *, //). If n: Dim[N] then n + 1: Dim[N+1]. - Subtyping rules for Size and Dim types. Here we have a (semi-)decision procedure for equality of arithmetic expressions, which amounts to canonicalization via a set of arithmetic identities, followed by structural equality. Importantly, we never ask for satisfiability (i.e., does there exist a substitution that makes two expressions equal); rather, two expressions are equal only when they are universally equal (for all substitutions). - torch_shapes fixture with Dim class. Reviewed By: samwgoldman Differential Revision: D92527699 fbshipit-source-id: 4d593e1d9e6b9f1a4193d24f5dd464670f3740d2

Update TSP to version 0.2.0 (#1010) Summary: This PR updates TSP to match the newest internal version that Pylance is using. It eliminates the following requests: - `SearchForTypeAttributes` - `GetTypeAttributes` - `GetSymbolsForFile` - `GetSymbol` - `GetFunctionParts` It eliminates the `Attribute` class and replaces it with the already existing `Symbol` idea. It adds two new requests - `GetSymbolsForType` that can find the symbols for a type. - `GetSymbolsForNode` that can find the symbols scoped by a node. These two new requests handle the situations required by the 4 of the original functions. `GetFunctionParts` was eliminated entirely as it was printing out parameters and such and could be reimplemented with just the `GetRepr` request. This PR is a prerequisite for adding the handlers for these requests. Pull Request resolved: https://github.com/facebook/pyrefly/pull/1010 Reviewed By: stroxler Differential Revision: D81353800 Pulled By: kinto0 fbshipit-source-id: 656fab5331dba768ede9cf830e3787bd300f9ef6