Skip to content

refactor generic#1081

Open
xuhuanzy wants to merge 9 commits into
EmmyLuaLs:mainfrom
xuhuanzy:refactor-generic
Open

refactor generic#1081
xuhuanzy wants to merge 9 commits into
EmmyLuaLs:mainfrom
xuhuanzy:refactor-generic

Conversation

@xuhuanzy
Copy link
Copy Markdown
Member

No description provided.

@xuhuanzy xuhuanzy changed the title refactor(generic): Add more precise type widening refactor generic May 14, 2026
@github-actions

This comment was marked as resolved.

gemini-code-assist[bot]

This comment was marked as resolved.

@xuhuanzy
Copy link
Copy Markdown
Member Author

/gemini review

gemini-code-assist[bot]

This comment was marked as resolved.

@xuhuanzy
Copy link
Copy Markdown
Member Author

/gemini review

gemini-code-assist[bot]

This comment was marked as resolved.

@xuhuanzy
Copy link
Copy Markdown
Member Author

/gemini review

gemini-code-assist[bot]

This comment was marked as resolved.

@xuhuanzy xuhuanzy force-pushed the refactor-generic branch from 9ddc9a4 to 9a4ec66 Compare May 22, 2026 17:13
@xuhuanzy xuhuanzy marked this pull request as ready for review May 22, 2026 17:14
@xuhuanzy
Copy link
Copy Markdown
Member Author

/gemini review

Copy link
Copy Markdown
Contributor

@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 significantly refactors the generic type system, replacing the TypeSubstitutor with a more flexible TypeMapper and introducing a dedicated inference module to handle complex generic scenarios. It adds support for built-in utility types like Pick and Omit, implements mapped types, and improves the inference of nested table literals in function calls. Reviewers identified opportunities to improve string template matching by including documentation-defined constants, suggested a more robust approach for handling iterator return types in __pairs metamethods, and provided a correction to ensure consistent literal preservation logic during type resolution.

}
}
LuaType::StrTplRef(str_tpl) => {
if let LuaType::StringConst(s) = target {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

medium

The pattern matching for StrTplRef only handles LuaType::StringConst, but it should also handle LuaType::DocStringConst to support string literals defined in documentation annotations. This ensures consistent behavior between source-code literals and annotation-defined literals.

            if let LuaType::StringConst(s) | LuaType::DocStringConst(s) = target {

Comment on lines +1557 to +1559
if let Some(LuaType::Variadic(variadic)) = &final_return_type {
let key_type = variadic.get_type(0).ok_or(InferFailReason::None)?;
let value_type = variadic.get_type(1).ok_or(InferFailReason::None)?;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

medium

The check for LuaType::Variadic might be too restrictive. If the iterator function returns only a single value (the key), final_return_type will be a simple type rather than a Variadic multi-return. Using get_result_slot_type would handle both single and multiple return values more robustly.

    if let Some(key_type) = final_return_type.as_ref().and_then(|t| t.get_result_slot_type(0)) {
        let value_type = final_return_type.as_ref().and_then(|t| t.get_result_slot_type(1)).unwrap_or(LuaType::Nil);
        let (key_type, value_type) = (&key_type, &value_type);

Comment on lines +31 to +32
let preserve_root_literal_form =
primitive_constraint || const_preserving || return_top_level;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

medium

For consistency with the resolution of covariant candidates (see line 84), the preserve_root_literal_form logic for multi-type candidates should also include the !info.top_level check. This ensures that literals are regularized correctly when matched against nested structures, preventing premature widening.

Suggested change
let preserve_root_literal_form =
primitive_constraint || const_preserving || return_top_level;
let preserve_root_literal_form =
primitive_constraint || const_preserving || !info.top_level || return_top_level;

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.

1 participant