Stream: t-compiler/rust-analyzer

Topic: IntellijRules in completions


Kirill Bulatov (Mar 11 2021 at 22:30, on Zulip):

I'm checking the way we complete the modules in mod_.rs and for test like

#[test]
    fn module_partially_named() {
        check(
            r#"
            //- /lib.rs
            mod a$0
            //- /foo.rs
            fn foo() {}
            //- /bar/mod.rs
            fn bar() {}
            //- /bar/ignored_bar.rs
            fn ignored_bar() {}
        "#,
            expect![[r#"
                md bar;
            "#]],
        );
    }

we actually have no completions.

The completion considers a to be the current module (returning it in the let current_module = ctx.scope.module()?;) and I want to determine this fact to throw this incomplete module away from the path lookups.

Besides the current module, I have the mod_under_caret: ast::Module so checking that their names match sounds reasonable, but the name of that ast module is actually aintellijRulezz.
What's even more odd, when I call ctx.scope.module()?.definition_source(ctx.db).value and extract the module ast to print, it's different to the one that the ast the completion gets.

What would be a good way to understand that I'm on some odd unfinished module-like thing in this test?

Laurențiu (Mar 12 2021 at 08:33, on Zulip):

IIRC intelliJRulezz is an identifier we insert at the completion point (after .) to make things parse correctly

Lukas Wirth (Mar 12 2021 at 09:51, on Zulip):

^

Lukas Wirth (Mar 12 2021 at 09:53, on Zulip):

What's even more odd, when I call ctx.scope.module()?.definition_source(ctx.db).value and extract the module ast to print, it's different to the one that the ast the completion gets.

The completion context actually has two trees, one with the synthetic inserted Identifier and one without

Lukas Wirth (Mar 12 2021 at 09:54, on Zulip):

from what I remember

Florian Diebold (Mar 12 2021 at 10:06, on Zulip):

yeah, that's because we can parse the code with the insert identifier, but we can't really analyze it any further, so we have to use the original trees for that

Florian Diebold (Mar 12 2021 at 10:07, on Zulip):

I think the inserted identifier is a red herring here though, the problem is that mod a<|> gets parsed as mod a {<|>} I guess

Florian Diebold (Mar 12 2021 at 10:10, on Zulip):

I mean, the problem is that we consider a the current module in this situation

Kirill Bulatov (Mar 12 2021 at 10:58, on Zulip):

Yes, all that's very fishy indeed.

I have no idea where to adjust the code related to the module resolution, but feels like manually cutting out that synthetic marker is the worst, so I'm a bit clueless right now, asking for code pointers and/or the path to tackle that.

As usual, a small anticipated fix turned into a long expedition :smiley:

Florian Diebold (Mar 12 2021 at 11:10, on Zulip):

I would hope that if we have mod a<|> {}, we don't consider it as being inside the module (otherwise that's a straight-up bug). If not, maybe we need some special tweaking for the mod a<|> case. I think the relevant code is analyze_impl / find_container in semantics.rs

Last update: Jul 29 2021 at 22:15UTC