[ty] Improve support for `object.<CURSOR>` completions #18629

BurntSushi · 2025-06-11T15:00:07Z

This makes it work for a number of additional cases, like nested
attribute access and things like [].<CURSOR>.

The basic idea is that instead of selecting a covering node closest to a
leaf that contains the cursor, we walk up the tree as much as we can.
This lets us access the correct ExprAttribute node when performing
nested access.

This also adds a number of tests covering some interesting cases.

Ref astral-sh/ty#86

This commit doesn't change any functionality, but instead changes the representation of `CoveringNode` to make the implementation simpler (as well as planned future additions). By putting the found node last in the list of ancestors (now just generically called `nodes`), we reduce the amount of special case handling we need. The downside is that the representation now allows invalid states (a `CoveringNode` with no elements). But I think this is well mitigated by encapsulation.

This routine lets us climb up the AST tree when we find a contiguous sequence of nodes that satisfy our predicate. This will be useful for making things like `a.b.<CURSOR>` work. That is, we don't want the `ExprAttribute` closest to a leaf. We also don't always want the `ExprAttribute` closest to the root. Rather, (I think) we want the `ExprAttribute` closest to the root that has an unbroken chain to the `ExprAttribute` closest to the leaf.

github-actions · 2025-06-11T15:03:32Z

`mypy_primer` results

No ecosystem changes detected ✅

AlexWaygood

Great work!

AlexWaygood · 2025-06-11T16:18:38Z

crates/ty_ide/src/completion.rs

-            };
-            CompletionTargetTokens::Generic { token: last }
-        }
+        Some(


This is probably out of scope for this PR. But for something like import collections.<CURSOR> or from collections.<CURSOR>, do we want to be able to provide autocomplete suggestions for the collections.abc submodule of collections in due course? (That would be cool!)

Definitely. Working on import auto-completions (from module import <CURSOR>) is next on my list. I think it would make sense to put import module.<CURSOR> in that bucket too.

crates/ty_ide/src/completion.rs

crates/ty_ide/src/find_node.rs

AlexWaygood · 2025-06-11T16:36:04Z

crates/ty_ide/src/completion.rs

+            } else if let Some([_]) = token_suffix_by_kinds(before, [TokenKind::Ellipsis]) {
+                // Similarly as above. If we've just typed an ellipsis,
+                // then we shouldn't show completions. Note that
+                // this doesn't prevent `....<CURSOR>` from showing
+                // completions (which would be the attributes available
+                // on an `ellipsis` object).
+                return None;


this appears to work great for class Foo: ... and def bar(): ... at the top level. But in nested contexts, I still seem to be getting "unwelcome" autocompletions after ellipses when I run the playground locally using this branch:

Odd. I can't repro that in neovim. That is, if I have this:

class Foo: def bar(self): ...<CURSOR>

Then I don't get completions, even if I specifically ask for them.

Huh... FWIW, the way I tested this PR locally with the playground was to checkout this branch, navigate to the playground directory, then run npm start --workspace ty-playground

(no idea why the playground might be doing something different to neovim -- @MichaReiser or @dhruvmanila might be able to help there!)

I got this initially when running npm start --workspace ty-playground:

[INFO]: ⬇️ Installing wasm-bindgen... [INFO]: License key is set in Cargo.toml but no LICENSE file(s) were found; Please add the LICENSE file(s) to your project directory [INFO]: ✨ Done in 23.87s [INFO]: 📦 Your wasm pkg is ready to publish at ../../playground/ty/ty_wasm. > ty-playground@0.0.0 start > vite sh: line 1: vite: command not found npm error Lifecycle script `start` failed with error: npm error code 127 npm error path /home/andrew/astral/ruff/pr1/playground/ty npm error workspace ty-playground@0.0.0 npm error location /home/andrew/astral/ruff/pr1/playground/ty npm error command failed npm error command sh -c vite npm notice npm notice New minor version of npm available! 11.3.0 -> 11.4.1 npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.4.1 npm notice To update run: npm install -g npm@11.4.1 npm notice

I then went to install vite via the AUR and got this build error:

CMake Error at CMakeLists.txt:237 (message): libglm-dev package is required, you might specify the include directory where to find glm/glm.hpp through -DGLM_INC=/path/to/glm

I then installed glm and tried again and got more build errors:

CMake Error in src/CMakeLists.txt: Found relative path while evaluating include directories of "vite": "GLEW_INCLUDE_PATH-NOTFOUND" CMake Error in src/CMakeLists.txt: Found relative path while evaluating include directories of "vite": "GLEW_INCLUDE_PATH-NOTFOUND" CMake Error in src/CMakeLists.txt: Found relative path while evaluating include directories of "vite": "GLEW_INCLUDE_PATH-NOTFOUND"

I'll try futzing with this later.

Okay I got it running... Does it serve it as a web site somewhere? How do I get to it?

Should be serving at localhost:5173 -- it should also say this on its terminal output, if it's working correctly?

Yeah I usually get to this state after running the command above:

And then I can just navigate to localhost:5173 in a browser to use my local playground deploy. Which I can usually get to immediately by holding down command and then double-clicking on the http://localhost:5173/ line in my terminal

This is what I see:

[andrew@duff playground]$ npm start --workspace ty-playground > ty-playground@0.0.0 prestart > npm run dev:wasm > ty-playground@0.0.0 dev:wasm > wasm-pack build ../../crates/ty_wasm --dev --target web --out-dir ../../playground/ty/ty_wasm [INFO]: 🎯 Checking for the Wasm target... [INFO]: 🌀 Compiling to Wasm... Compiling ruff_python_ast v0.0.0 (/home/andrew/astral/ruff/pr1/crates/ruff_python_ast) Compiling ty_wasm v0.0.0 (/home/andrew/astral/ruff/pr1/crates/ty_wasm) Compiling ruff_python_parser v0.0.0 (/home/andrew/astral/ruff/pr1/crates/ruff_python_parser) Compiling ruff_python_literal v0.0.0 (/home/andrew/astral/ruff/pr1/crates/ruff_python_literal) Compiling ruff_db v0.0.0 (/home/andrew/astral/ruff/pr1/crates/ruff_db) Compiling ty_python_semantic v0.0.0 (/home/andrew/astral/ruff/pr1/crates/ty_python_semantic) Compiling ty_vendored v0.0.0 (/home/andrew/astral/ruff/pr1/crates/ty_vendored) Compiling ruff_python_formatter v0.0.0 (/home/andrew/astral/ruff/pr1/crates/ruff_python_formatter) Compiling ty_ide v0.0.0 (/home/andrew/astral/ruff/pr1/crates/ty_ide) Compiling ty_project v0.0.0 (/home/andrew/astral/ruff/pr1/crates/ty_project) Finished `dev` profile [unoptimized + debuginfo] target(s) in 10.36s [INFO]: ⬇️ Installing wasm-bindgen... [INFO]: License key is set in Cargo.toml but no LICENSE file(s) were found; Please add the LICENSE file(s) to your project directory [INFO]: ✨ Done in 13.45s [INFO]: 📦 Your wasm pkg is ready to publish at ../../playground/ty/ty_wasm. > ty-playground@0.0.0 start > vite

A "vite" window opens, but it's blank. And:

[andrew@duff playground]$ curl localhost:5173 curl: (7) Failed to connect to localhost port 5173 after 0 ms: Could not connect to server

I am doing this on a remote box... And I'm guessing the vite window is opening via X11 forwarding. So I wonder if that's messing with things.

Yeah it looks like things are hanging right after running vite. So this is probably an X11 forwarding issue. Boooooo.

I'll try this directly on my laptop tomorrow.

AlexWaygood · 2025-06-11T16:40:03Z

crates/ty_ide/src/completion.rs

+    #[test]
+    fn betwixt_attribute_access1() {
+        let test = cursor_test(
+            "\
+class Foo:
+    xyz: str
+
+class Bar:
+    foo: Foo
+
+class Quux:
+    bar: Bar
+
+quux = Quux()
+quux.<CURSOR>.foo.xyz
+",
+        );
+
+        test.assert_completions_include("bar");
+        test.assert_completions_do_not_include("xyz");
+        test.assert_completions_do_not_include("foo");
+    }


Also probably not something for this PR, but consider something like this:

Playground screenshot

Eventually, it would be great if bar and mro were positioned above a in the completion suggestions in this screenshot. Foo.bar and Foo.mro both have a __defaults__ attribute (they're both FunctionType instances), but Foo.a does not (it's an int)!

Yeah that's a tricky one. Not just taking the prefix context into account, but the suffix context as well. I added that to the completion notes.

BurntSushi · 2025-06-11T18:16:56Z

Demo:

object-attr-improved.mp4

(I still haven't setup VS Code.)

This makes it work for a number of additional cases, like nested attribute access and things like `[].<CURSOR>`. The basic idea is that instead of selecting a covering node closest to a leaf that contains the cursor, we walk up the tree as much as we can. This lets us access the correct `ExprAttribute` node when performing nested access.

BurntSushi · 2025-06-11T18:31:04Z

Going to bring this in even with the unknown playground issue (which isn't a regression) since it improves a lot of other cases. I'm happy to do follow-ups if folks have them.

dhruvmanila

This looks good!

I haven't been able to reproduce the nested context issue that Alex pointed out, I've asked him to see if it's reproducible now otherwise we can ignore that for now.

I think it might be useful to add couple of tests when the dot (.) character is inside a string and f-string. Following are couple of examples that already work correctly:

foo = 1
bar = 2

class Foo:
    def method(self): ...

f = Foo()

# String, this is not an attribute access
"f.<CURSOR>
# F-string, this is an attribute access
f"{f.<CURSOR>

AlexWaygood · 2025-06-12T11:01:58Z

I haven't been able to reproduce the nested context issue that Alex pointed out, I've asked him to see if it's reproducible now otherwise we can ignore that for now.

This still reproduces for me on https://play.ty.dev/:

Screen.Recording.2025-06-12.at.11.59.49.mov

dhruvmanila · 2025-06-12T11:37:54Z

This still reproduces for me on play.ty.dev:

Interesting! Thanks, I'm able to reproduce it on the playground and in VS Code but not in Neovim!

And, the trace logs:

[Trace - 5:06:24 PM] Sending request 'textDocument/completion - (146)'.
Params: {
    "textDocument": {
        "uri": "file:///Users/dhruv/playground/ty_server/completions.py"
    },
    "position": {
        "line": 1,
        "character": 16
    },
    "context": {
        "triggerKind": 2,
        "triggerCharacter": "."
    }
}


[Trace - 5:06:24 PM] Received response 'textDocument/completion - (146)' in 1ms.
Result: [
    {
        "label": "Foo"
    }
]

The above trace logs is for the following snippet along with the cursor position:

class Foo:
    class Bar: .<CURSOR>

BurntSushi · 2025-06-12T11:43:10Z

Interesting. I've recorded that in my notes to try and address later. Once I get around to setting up VS Code.

Ref #18629 (review)

BurntSushi added 2 commits June 11, 2025 10:56

BurntSushi requested review from AlexWaygood, MichaReiser, carljm, dcreager and sharkdp as code owners June 11, 2025 15:00

BurntSushi requested review from dhruvmanila and removed request for carljm, dcreager and sharkdp June 11, 2025 15:00

MichaReiser added server Related to the LSP server ty Multi-file analysis & type inference labels Jun 11, 2025

AlexWaygood approved these changes Jun 11, 2025

View reviewed changes

BurntSushi force-pushed the ag/completion-object-v2 branch from 7b4fb09 to 7da22fc Compare June 11, 2025 18:17

BurntSushi merged commit 7893cf9 into main Jun 11, 2025
35 checks passed

BurntSushi deleted the ag/completion-object-v2 branch June 11, 2025 18:31

dhruvmanila reviewed Jun 12, 2025

View reviewed changes

BurntSushi added a commit that referenced this pull request Jun 12, 2025

[ty] Add some "inside string" tests for object.<CURSOR> completions

f28360f

Ref #18629 (review)

BurntSushi mentioned this pull request Jun 12, 2025

[ty] Add some "inside string" tests for object.<CURSOR> completions #18644

Merged

BurntSushi added a commit that referenced this pull request Jun 12, 2025

[ty] Add some "inside string" tests for object.<CURSOR> completions

8123dab

Ref #18629 (review)

[ty] Improve support for object.<CURSOR> completions #18629

[ty] Improve support for object.<CURSOR> completions #18629

Uh oh!

Conversation

BurntSushi commented Jun 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jun 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

mypy_primer results

Uh oh!

AlexWaygood left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BurntSushi commented Jun 11, 2025

Uh oh!

BurntSushi commented Jun 11, 2025

Uh oh!

Uh oh!

dhruvmanila left a comment

Choose a reason for hiding this comment

Uh oh!

AlexWaygood commented Jun 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dhruvmanila commented Jun 12, 2025

Uh oh!

BurntSushi commented Jun 12, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

[ty] Improve support for `object.<CURSOR>` completions #18629

[ty] Improve support for `object.<CURSOR>` completions #18629

BurntSushi commented Jun 11, 2025 •

edited

Loading

github-actions bot commented Jun 11, 2025 •

edited

Loading

`mypy_primer` results

AlexWaygood commented Jun 12, 2025 •

edited

Loading