feat: support type inference for @field and @type function declarations in method overrides#3368
feat: support type inference for @field and @type function declarations in method overrides#3368ChouUn wants to merge 3 commits intoLuaLS:masterfrom
Conversation
…ns in method overrides When a child class overrides a parent class method that was declared using @field or @type annotations (instead of function declarations), the parameter types are now correctly inferred from the parent class. This extends the existing method override type inference (PR LuaLS#2859) to support field-style function declarations. Example: ```lua ---@Class Buff local mt = {} ---@type (fun(self: Buff, target: Buff): boolean)? mt.on_cover = nil ---@Class Buff.CommandAura : Buff local tpl = {} function tpl:on_cover(target) -- target type is now correctly inferred as Buff (was any before) return self.level > target.level end ``` Changes: - Modified compileFunctionParam in script/vm/compiler.lua to extract function type from doc.field nodes by accessing their extends property - Added support for doc.type.function in parent class field lookup - Added comprehensive test cases for @field and @type method overrides Fixes LuaLS#3367 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary of ChangesHello, I'm Gemini Code Assist1! 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 addresses a type inference bug where method overrides in child classes failed to correctly infer parameter types when the parent method was declared using Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Activity
Using Gemini Code AssistThe 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
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 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
|
There was a problem hiding this comment.
Code Review
This pull request extends method override type inference to support function declarations using @field and @type annotations. The changes in script/vm/compiler.lua correctly implement this by looking into doc.field nodes for the function type. The addition of new tests in test/type_inference/field_override.lua is great and covers various scenarios. Overall, this is a good improvement. I have one suggestion regarding code duplication to improve maintainability.
There was a problem hiding this comment.
Pull request overview
Extends the existing method-override parameter type inference to also pick up function types declared via field-style annotations (@field / @type) on parent classes, and adds regression tests for these override scenarios.
Changes:
- Update
compileFunctionParamto recognize parent field function types coming fromdoc.type.functionin addition to concretefunctionnodes. - Add a new
field_overridetest suite and include it in the type inference test runner.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
script/vm/compiler.lua |
Expands override lookup to consider doc-annotated function types when inferring overridden method parameter types. |
test/type_inference/init.lua |
Registers the new field_override test module. |
test/type_inference/field_override.lua |
Adds test coverage for overrides where the parent method is declared via @type / @field function types (including optional + multi-param cases). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Remove unnecessary doc.field handling (vm.compileNode already handles it) - Keep doc.type.function support in parent class field lookup - Add changelog entry for the new feature
n.args is guaranteed to exist for function/doc.type.function nodes, only n.args[aindex] needs to be checked.
358ad45 to
91e41aa
Compare
Summary
This PR extends the existing method override type inference (PR #2859) to support field-style function declarations using
@fieldand@typeannotations.Problem
When a child class overrides a parent class method that was declared using
@fieldor@typeannotations, the parameter types were incorrectly inferred asanyinstead of the types defined in the parent class.Before this PR:
After this PR:
Root Cause
In
script/vm/compiler.lua, when searching parent class fields for method overrides (line 1463), the code only checked for'function'node types. However, whenvm.compileNode(field)processes@fieldor@typedeclarations, it returns'doc.type.function'nodes, which were not being recognized.Changes
Modified parent class field lookup (line 1463): Added support for
'doc.type.function'node type in addition to'function'when searching parent class fields for overridden methods.Added comprehensive test cases: Created
test/type_inference/field_override.luawith 5 test cases covering:@typefunction declarations@fieldfunction declarationsAdded changelog entry: Documented the new feature in
changelog.mdTesting
All tests pass successfully:
@fieldand@typeoverridesRelated Issues
Fixes #3367
Note
This PR contains multiple small commits. I recommend using "Squash and merge" when merging to keep the main branch history clean.