[Enhancement] Error suppression support.

[well-in-that-case]

A project of mine named Pluto adds some new syntax into Lua. It's largely compatible, but symbols such as compound operators, new keywords, and expression syntaxes throw insuppressible errors that make the extension incompatible with any mild fork of Lua.

It's evident this excellent extension involves some interest in foreign Lua syntax, see non-standard symbol support. As such, I feel it'd be beneficial if this extension received error suppression equitable to diagnostic warning suppression.

--- @diagnostic disable: unknown-symbol
--- @diagnostic disable: exp-in-action

This syntax would greatly enhance the extension's compatibility with syntactic expansions and increase the coverage of this extension.

[sumneko]

It does not make much sense to suppress syntax errors, because most of the time this will cause other syntax to produce other errors.

The best way is to use plugin

[well-in-that-case]

It does not make much sense to suppress syntax errors, because most of the time this will cause other syntax to produce other errors.

I don't understand the sentiment. In the case of compound operators, the two aforementioned errors could be specifically disabled and the extension would be 100% compatible with the rest of the file, especially regarding Intellisense. With non-standard operator support, you already implement this half-way. However, it's hard-coded and supports a limited set of non-standard operators. Plugins support custom doc syntax, but they don't appear to support actual new syntax in the Lua language, like new operators or keywords.

In particular, each syntax error doesn't need to be the duty of the extension to manage. Lua can report these fine, but you can implement best of both worlds by allowing a toggle.

[sumneko]

As you see, even if I suppress syntax errors, but the semantic of x is wrong.

[well-in-that-case]

I am not sure what you mean precisely with semantic, but the largest Intellisense error is missing end, because it perceives the if ternary as a control flow statement. This is what causes the error to cascade into other sections of the program.

--- @diagnostic disable: keyword
--- @diagnostic disable: exp-in-action
--- @diagnostic disable: miss-symbol
--- @diagnostic disable: undefined-global

This would silence all of the errors associated with the expression. The addition of one more diagnostic:

--- @diagnostic disable: unknown-symbol

Would silence issues with new keyword expressions too. Alternatively, a powerful toggle to completely disable syntax checking for the current file or workspace would allow any sort of foreign Lua syntax, but still provide Intellisense where possible. This may likely be optimal, since some crazy forks exist and will require tedious tweaking that can otherwise be avoided. To a lesser extent, this may provide some more performance to much larger codebases that simply don't need syntax checking.

[sumneko]

Let's divide the discussion into two questions

Q: Why not provide the feature of suppressing syntax errors?
A: In the example above, the user expects the 'x' in line 8 to point to line 1, but in fact it will point to line 3. Incorrect syntax leads to errors in subsequent semantic analysis such as variable scope. These semantic errors cannot be corrected by suppressing warnings.

Q: Can add core support for this dialect?
A: No, unless this dialect is very popular. Lua has many dialects, so I don't have the energy to be compatible with them one by one.

[well-in-that-case]

In the example above, the user expects the 'x' in line 8 to point to line 1, but in fact it will point to line 3. Incorrect syntax leads to errors in subsequent semantic analysis such as variable scope. These semantic errors cannot be corrected by suppressing warnings.

Is this not just the cascading issue mentioned above? Sorry if I'm misunderstanding, but there could even be a full denial of analysis (or in this case, semantic analysis?) when necessary, so any syntax highlighting or standard library Intellisense can be applied. No need to specialize core support for dialect by dialect. This extension also makes third-party Intellisense fairly easy to type, which is another loss.

If, in theory of course, something like this were to be introduced as a strong suppression for errors and warnings resulting from errors, then any user confusion is the fault of the user. "Don't disable diagnostic if you want warnings" type thing, because it can be applied in appropriate scenarios. If we can already fully disable warnings, why shouldn't we be able to fully disable static syntax checks? These are not things the extension must handle, they can be configurable.

That is, unless I've missed something critical? Is Lua-Check tied to all the other features of this extension? If so, I can see why it cannot be disabled. However, if it's not, then this seems as trivial as disabling warnings was.