[MannXo]

Summary

Fixes #5478

Typing a. on a TypedDict instance now also offers the TypedDict's keys. Accepting one rewrites the access into a subscript, so a. followed by f1 becomes a["f1"].

Each key item has a text edit that replaces everything from the end of the base expression through the attribute name (the dot and any typed prefix) with ["key"]. Its filterText starts with that same text (.f1), because clients match the filter text against what was typed from the start of the edit, and that includes the dot. fastapi_endpoint_support.rs uses the same pattern.

The keys come from collect_typed_dict_keys, which subscript key completion already uses, so inherited, NotRequired and ReadOnly keys are all included. The regular attribute completions (get, keys, ...) are still offered next to them. Keys are quoted with serde_json::to_string, which always gives a valid Python string literal, so functional-syntax keys like "two words" work too. The items are skipped when the base and the attribute are on different lines, since a completion text edit has to stay on one line.

Two behaviours you may want changed:

1. Keys are offered whenever any member of the base type is a TypedDict, so A | None gets them too. This matches what a[ already does.
2. Key items use CompletionItemKind::Field with the value type as detail, the same as subscript key completion. They sort alongside the attributes by name.

• I am a human, and I fully understand the code I am submitting.

Test Plan

Added five tests in pyrefly/lib/test/lsp/completion.rs. They cover the issue example (exact range, newText and filterText, with dict methods still present), a typed prefix (a.fi), inherited/NotRequired/ReadOnly keys, quoting of non-identifier keys, and no rewrite items for a plain class instance or the TypedDict class object. The first commit adds only the tests. Four of them fail on it, and the fifth is a negative check that passes either way.

cargo test -p pyrefly --lib typed_dict_attribute_completion
test result: ok. 5 passed; 0 failed

cargo fmt -- --check                  # clean
cargo clippy --release                # 0 warnings
cargo test --profile bench            # pyrefly lib: 9896 passed, 0 failed, 3 ignored; all other crates pass
cargo check -p pyrefly_wasm --target wasm32-unknown-unknown   # builds
python3 conformance/conformance_output.py conformance/third_party --mode check --executable target/release/pyrefly   # clean
python3 test.py --no-test --no-tensor-shapes --no-conformance --no-jsonschema --no-extension   # clean

I also ran target/release/pyrefly lsp (from the bench-profile build above) over stdio with the issue's example and requested completion right after a.:

{"detail": "int", "filterText": ".f1", "kind": 5, "label": "f1", "sortText": "0.9999.f1", "textEdit": {"newText": "[\"f1\"]", "range": {"end": {"character": 2, "line": 7}, "start": {"character": 1, "line": 7}}}}
{"detail": "int", "filterText": ".f2", "kind": 5, "label": "f2", "sortText": "0.9999.f2", "textEdit": {"newText": "[\"f2\"]", "range": {"end": {"character": 2, "line": 7}, "start": {"character": 1, "line": 7}}}}

copy, get, items, keys, pop, setdefault, update and values came back in the same response. I did not run the Scrut or tensor-shape suites, and I only tested on macOS.

[meta-codesync]

This pull request has been imported. If you are a Meta employee, you can view this in D128918542. (Because this pull request was imported automatically, there will not be any future comments.)

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[stroxler]

Thanks!

Overall this looks pretty good to me. AI code review caught a few edge cases we should clean up before merging though:

1. Parenthesized receivers produce broken syntax — [dict_completions.rs:1112–1113](

   pyrefly/pyrefly/lib/state/lsp/dict_completions.rs

   Lines 1112 to 1113 in f23386e

   	let edit_range =
   	module_info.to_lsp_range(TextRange::new(base_range.end(), attribute.range().end()));

   )
   Accepting field after (a).fi produces (a["field"], deleting the closing parenthesis. base_range excludes grouping parentheses, so its end is not necessarily immediately before the dot. Start the edit at the actual attribute dot, preserving parentheses.

2. Rewriting inside f-strings breaks Python <3.12 — [dict_completions.rs:1124–1132](

   pyrefly/pyrefly/lib/state/lsp/dict_completions.rs

   Lines 1124 to 1132 in f23386e

   	let quoted_key = to_string(&key).expect("Serializing a string cannot fail");
   	completions.push(RankedCompletion::new(CompletionItem {
   	filter_text: Some(format!("{accessor}{key}")),
   	label: key,
   	detail: Some(ty.to_string()),
   	kind: Some(CompletionItemKind::Field),
   	text_edit: Some(CompletionItemTextEdit::TextEdit(TextEdit {
   	range: edit_range,
   	new_text: format!("[{quoted_key}]"),

   )
   Completing inside f"{a.fi}" produces f"{a["field"]}". JSON quoting is valid for a standalone Python string, but this is invalid before PEP 701. Choose quoting compatible with the enclosing f-string, or suppress unsafe rewrites on older Python versions.

3. Value patterns receive invalid subscript rewrites — [completion.rs:1227–1233](

   pyrefly/pyrefly/lib/lsp/wasm/completion.rs

   Lines 1227 to 1233 in f23386e

   	self.add_typed_dict_attribute_key_completions(
   	handle,
   	&base_type,
   	base_range,
   	&identifier,
   	&mut result,
   	);

   )
   Completing case a.fi: produces case a["field"]:, but subscripts are not allowed in patterns. Skip these items in PatternMatchValue contexts.

Otherwise, the feature placement is sensible and the non-TypedDict fast path stays cheap.

Verification: Codex and Claude independently reviewed the change. Existing tests passed; additional applied-edit probes reproduced all three issues. Rust check, build, and lint passed. Validation was Linux-only; no review was posted and no source changes were retained.