No unknown operations diagnostic

[NathanSnail]

Adds diagnostic to prevent operations which result in an unknown value. Differences with no-unknown diagnostic is that no-unknown is when the type of a binding cannot be inferred whereas this is for the types of expressions who's values are inferred resulting in a value who's type can't be inferred (including values which are never used in a binding). Catches common typo mistakes like

---@param name string
---@return string
local function greet(name)
    return "Hello " .. name "!" -- <-- Note the missing ..
end

Needs ./tools/build-doc.lua and ./tools/locale.lua run.

I'm not sure if this diagnostic should be enabled by default, it's kind of similar to need-check-nil and if it does trigger it's almost certainly a bug which is unlike the other disabled by default diagnostics which are more code quality focused.

[gemini-code-assist]

Summary of Changes

Hello @NathanSnail, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new diagnostic, no-unknown-operations, designed to identify and flag expressions where the outcome of an operation, such as a function call or a binary operation, results in an unknown type. This diagnostic is crucial for catching subtle programming errors and typos that might otherwise lead to unexpected type inference issues, thereby improving code reliability and type safety. It complements existing diagnostics by focusing specifically on the inferability of operation results.

Highlights

• New Diagnostic no-unknown-operations: Introduces a new diagnostic to detect operations (calls, binary operations) that result in an unknown type, even when input types are known.
• Distinction from no-unknown: Clarifies that this diagnostic targets unknown expression results rather than unknown binding types, helping to catch common typos like missing concatenation operators.
• Enhanced Operator Handling: Refactors script/vm/operator.lua by introducing vm.getOperators to improve how operators are retrieved and processed, and adds an isCallable method to vm.Infer in script/vm/infer.lua.
• Localization and Configuration: Adds new diagnostic messages in locale/en-us/script.lua and registers the diagnostic in locale/en-us/setting.lua and script/proto/diagnostic.lua as a 'strong' warning.
• Comprehensive Test Cases: Includes a new test file test/diagnostics/no-unknown-operations.lua with various scenarios to validate the diagnostic's effectiveness.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a valuable new diagnostic, no-unknown-operations, to detect operations that result in an unknown type, which often indicates a typo or a bug. The implementation is solid, adding a new isCallable helper and refactoring operator handling for better clarity and reuse. The changes are well-supported by a comprehensive set of tests. I've added a couple of suggestions to remove TODO comments where the existing code is already robust or the behavior is correct, which will improve code clarity.

[gemini-code-assist]

The TODO here questions the necessity of the if not state.ast then return end check. It's a good practice to keep this check for robustness. It acts as a safeguard against potential crashes if files.getState(uri) returns a state object that, for some reason (like a severe parsing error), lacks an AST. Keeping this check makes the diagnostic more resilient. I'd recommend removing the TODO comment.

[gemini-code-assist]

The TODO comment discusses a scenario where an operation with a known type and an unknown type results in unknown. The current implementation correctly chooses not to report a diagnostic in this case. This diagnostic should focus on operations that are inherently invalid for the given known types, rather than issues stemming from a variable that is already unknown. The no-unknown diagnostic is better suited for flagging the unknown variable itself. Since the current behavior is correct, this TODO can be removed to avoid confusion.