VM.OnCompileFunctionParam does not work at all

Commencez par reproduire le plugin dans plugin.lua et par examiner le chemin de chargement référencé par script\plugin.lua:157, puis comparez le point d’entrée documenté VM.OnCompileFunctionParam avec le hook OnSetText fonctionnel. Reproduisez l’erreur VM nil avec la configuration .vscode/settings.json indiquée. Le travail est terminé lorsque le callback peut être défini et invoqué sans l’erreur VM globale.

How are you using the lua-language-server?

Visual Studio Code Extension (sumneko.lua)

Which OS are you using?

Windows

What is the issue affecting?

Plugins

Expected Behaviour

According to https://luals.github.io/wiki/plugins/#vmoncompilefunctionparam, VM.OnCompileFunctionParam() is supposed to work.

Actual Behaviour

It simply does not work, and throws this error instead:

2026-01-28 20:58:08.342 [info] C:\Path\plugin.lua:4: attempt to index a nil value (global 'VM')
stack traceback:
	C:\Path\plugin.lua:4: in main chunk
	[C]: in global 'xpcall'
	script\plugin.lua:157: in function <script\plugin.lua:95>

2026-01-28 20:58:08.348 [info] [Error - 8:58:08 PM] An error occurred in the plugin, please report it to the plugin author.
Please check the details in the output or log.
Plugin path: C:\Path\plugin.lua

Reproduction steps

1. Write function VM.OnCompileFunctionParam(next, func, param) end in plugin.lua
2. Add "Lua.runtime.plugin": "C:/Path/plugin.lua" to .vscode/settings.json or similar
3. The error happens

Additional Notes

Please note that OnSetText() works as advertised, so the plugin system works; it is only this specific feature that does not seem to be working correctly.

For context, my library has JS-style event callbacks that work roughly like this:

addHook("PlayerUpdate", function(player)
end)

As you probably guessed already, I was hoping to use VM.OnCompileFunctionParam() to make it detect the parameter's type without requiring explicitly annotations, since generics do not seem to support this pattern at the moment?
I could also use OnSetText() instead, but it sounds like a less reliable method as it depends on the formatting, and it would also cause a warning about duplicate annotations if the user typed the ---@param explicitly.

Log File

No response