Skip to content

feat: support type inference for @field and @type function declarations in method overrides#3368

Open
ChouUn wants to merge 3 commits intoLuaLS:masterfrom
ChouUn:fix/field-override-type-inference
Open

feat: support type inference for @field and @type function declarations in method overrides#3368
ChouUn wants to merge 3 commits intoLuaLS:masterfrom
ChouUn:fix/field-override-type-inference

Conversation

@ChouUn
Copy link

@ChouUn ChouUn commented Mar 5, 2026

Summary

This PR extends the existing method override type inference (PR #2859) to support field-style function declarations using @field and @type annotations.

Problem

When a child class overrides a parent class method that was declared using @field or @type annotations, the parameter types were incorrectly inferred as any instead of the types defined in the parent class.

Before this PR:

---@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: any ❌
    return self.level > target.level
end

After this PR:

---@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: Buff ✅
    return self.level > target.level
end

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, when vm.compileNode(field) processes @field or @type declarations, 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.

// Before
if n.type == 'function' and n.args[aindex] then

// After  
if (n.type == 'function' or n.type == 'doc.type.function')
and n.args[aindex]
then

Added comprehensive test cases: Created test/type_inference/field_override.lua with 5 test cases covering:

  • @type function declarations
  • @field function declarations
  • Optional methods
  • Multiple parameters

Added changelog entry: Documented the new feature in changelog.md

Testing

All tests pass successfully:

  • ✅ New test cases for @field and @type overrides
  • ✅ Existing test suite (no regressions)
  • ✅ All diagnostic tasks complete without errors

Related 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.

…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>
Copilot AI review requested due to automatic review settings March 5, 2026 16:21
@gemini-code-assist
Copy link

Summary of Changes

Hello, 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 @field or @type annotations. The changes ensure that the compiler accurately recognizes and applies the specified function types, leading to more robust and predictable type checking in such scenarios.

Highlights

  • Enhanced Type Inference: Extended method override type inference to correctly handle @field and @type function declarations in parent classes, resolving issues where parameter types were incorrectly inferred as any.
  • Compiler Logic Update: Modified the compileFunctionParam function in script/vm/compiler.lua to properly extract function types from doc.field nodes by accessing their extends property.
  • Improved Parent Class Field Lookup: Updated the parent class field lookup mechanism to support both doc.field and doc.type.function types when searching for overridden methods.
  • Comprehensive Test Coverage: Added a new test file, test/type_inference/field_override.lua, with five specific test cases covering various scenarios including @type and @field declarations, optional methods, and multiple parameters.

🧠 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
  • script/vm/compiler.lua
    • Modified compileFunctionParam to extract function types from doc.field nodes by checking their extends property.
    • Enhanced parent class field lookup to correctly identify function types from both doc.field and doc.type.function nodes.
  • test/type_inference/field_override.lua
    • Added tests for @type function declarations with method overrides.
    • Added tests for @field function declarations with method overrides.
    • Included tests for optional methods.
    • Included tests for multiple parameters.
  • test/type_inference/init.lua
    • Required the new field_override test file to integrate it into the test suite.
Activity
  • All new test cases for @field and @type overrides passed successfully.
  • The existing test suite passed without any regressions.
  • All diagnostic tasks completed without errors.
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.

Copy link

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 compileFunctionParam to recognize parent field function types coming from doc.type.function in addition to concrete function nodes.
  • Add a new field_override test 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.

ChouUn added 2 commits March 6, 2026 00:30
- 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.
@ChouUn ChouUn force-pushed the fix/field-override-type-inference branch from 358ad45 to 91e41aa Compare March 5, 2026 17:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Type inference not working for @field and @type function declarations in method overrides

2 participants