[move-ide] Added support for init function auto-completion

[awelc]

Description

This PR adds preliminary support for auto-completing init function definition. It contains the beginning of the proposed fine-grain error recovery in the parser, currently only implemented for function definitions. The gist of the idea is that we parse function definition as much as we can, and regardless of whether the parsing was fully successful or not, we still return a correct function Function AST node if we can (i.e., if we correctly parse attributes, fun keyword, and function name).

In particular, this would generate a correct Function AST node, for function ini even though its definition is incomplete:

module 0x0::some_module {
    fun ini
}

What this allows us to do, is context-sensitive auto-completion for init functions using LSP concept of snippets. In particular, when triggering auto-completion in the code fragment above right after ini, the IDE will recognize that we are trying to auto-complete a function whose name starts with ini and will offer a code snippet expanding this to a full init function definition (we will be able to omit sui::tx_context prefix once auto-imports are in place):

module 0x0::some_module {
    fun init(ctx: &mut sui::tx_context::TxContext) {   
    }
}

Furthermore, if the module contains a struct definition being a one-time-witness candidate, the IDE will be smart enough to recognize this and offer an expanded snippet:

module 0x0::some_module {
    struct SOME_MODULE has drop {}
    fun init(witness: SOME_MODULE, ctx: &mut sui::tx_context::TxContext) {   
    }
}

Finally, this snippet will not be offered for all identifiers with a given prefix, only those that represent function definitions. In particular, it will not do it for local variable declaration in the following code fragment:

module 0x0::some_module {
    fun foo() {
        let ini   
    }
}

The main current limitation is that at this point auto-completion must be preceded by a save (to rebuild symbols information in the LSP server) and manual re-triggering of the auto-completion command. In order to support a smooth user experience, we need to add support for the compiler to use a virtual file system (files stored in memory).

Test Plan

Added a compiler test and a symbolicator test for this feature.

---

If your changes are not user-facing and do not break anything, you can skip the following section. Otherwise, please briefly describe what has changed under the Release Notes section.

Type of Change (Check all that apply)

• protocol change
• user-visible impact
• breaking change for a client SDKs
• breaking change for FNs (FN binary must upgrade)
• breaking change for validators or node operators (must upgrade binaries)
• breaking change for on-chain data layout
• necessitate either a data wipe or data migration

Release notes

Developers might see more compiler diagnostics as selected parsing errors no longer prevent compilation and diagnostics from the compiler reaching later compilation stages where additional diagnostics may be generated.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
explorer	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 14, 2024 10:42pm
multisig-toolkit	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 14, 2024 10:42pm
mysten-ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 14, 2024 10:42pm
sui-core	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 14, 2024 10:42pm
sui-kiosk	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 14, 2024 10:42pm
sui-typescript-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 14, 2024 10:42pm

[cgswords]

I'm dubious about marking this native, as it will likely produce very strange results. Inserting abort 0 or something is safer. We could even consider adding a FunctionBody_::Error form.

[awelc]

This is exactly the kind of feedback I am looking for! I was wondering about it myself (also because we introduce an essentially fake location here), but did not want to go to crazy with the changes without getting feedback first.

In a similar vein (though perhaps more acceptable) is that an incomplete function actually has a Type_::Unit return type (rather then perhaps something like Type_::Error).

[tnowacki]

+1 For something like FunctionBody_::Error
Though you could probably achieve the same thing by doing FunctionBody_::Defined(...UnresolvedError...)

[awelc]

+1 For something like FunctionBody_::Error Though you could probably achieve the same thing by doing FunctionBody_::Defined(...UnresolvedError...)

I went this route (actually just provided empty Sequence as the function body) as this does not require changes to subsequent passes (to handle the new type of UnresolvedError).

[tnowacki]

+1 For something like FunctionBody_::Error
Though you could probably achieve the same thing by doing FunctionBody_::Defined(...UnresolvedError...)

[tnowacki]

This feels strange to me. Can we not just log the diagnostic if we have it? Why bother passing it back instead of just logging it?

[tnowacki]

I guess what I'm suggesting is that the function parsing can locally handle trying to advance the parser to the next valid state, much like we did in the lexer, and hide the error handling complexity from the caller

[awelc]

I was not sure what the best way was to structure this, but you are obviously right - we don't really have to pass the diagnostics on the success case when we can log them on the spot

[tnowacki]

I will take a deeper look tomorrow, but most of these parser errors look really suspicious, like something has gone wrong with the thing that is supposed to consume tokens until the start of the next module member

[tnowacki]

nit, could you add an underscore here

[tnowacki]

How did we end up expecting a module member here?

[tnowacki]

Similar question as above

[tnowacki]

This looks a bit suspicious

[awelc]

This is because the function definition is parsed correctly as having the u64 return type but the body was not parsed correctly and (being treated as empty), typing throws an error on incompatible return type. I adjusted all tests (including this one) to only report parsing errors.

[awelc]

Superseded by #17137 and #16673