fix(parser): Support cond generic literals true, false, and nil.

[xuhuanzy]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello, 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 enhances the EmmyLua parser to support true, false, and nil as literal values in generic type constraints within LuaDoc. This improvement ensures that conditional generic type aliases using these boolean and null literals are correctly parsed and analyzed, leading to more accurate type inference and error detection.

Highlights

• Parser Enhancement: The parser now correctly recognizes true, false, and nil as valid generic literals within LuaDoc type definitions.
• Lexer Update: The LuaDoc lexer has been updated to tokenize true, false, and nil as distinct LuaTokenKind values.
• Test Coverage: A new test case was added to generic_test.rs to verify the proper handling of extends true in generic type aliases.

🧠 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

• crates/emmylua_code_analysis/src/compilation/test/generic_test.rs
  • Added test_extends_true to validate generic type aliases using true in extends clauses.
• crates/emmylua_parser/src/lexer/lua_doc_lexer.rs
  • Modified the LuaDocLexer to map the string literals "true", "false", and "nil" to their respective LuaTokenKind variants.

Activity

• No specific activity has been recorded for this pull request yet.

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 aims to add parser support for true, false, and nil as literals in conditional generics. The changes are a good step in the right direction. I've left a couple of specific comments on the code.

Most importantly, the implementation appears to be incomplete. While the lexer is updated to produce a TkNil token, the parser in crates/emmylua_parser/src/grammar/doc/types.rs (specifically parse_primary_type) does not seem to be updated to handle this token as a literal type. This will likely cause parsing to fail when nil is used.

Additionally, the new test case only covers true, and it would be beneficial to expand it to cover false and nil to fully validate the feature. There's also an opportunity to reduce some code duplication in the lexer. Please see my detailed comments.

[gemini-code-assist]

The test name test_extends_true is a bit specific given it also tests string and number literals. To fully validate the changes in this PR, which aims to support true, false, and nil, it would be beneficial to expand this test to include cases for false and nil as well. Also, consider renaming the test to something more general like test_extends_literal.

Here's a suggested update:

#[test]
fn test_extends_literal() {
    let mut ws = VirtualWorkspace::new();
    assert!(ws.check_code_for(
        DiagnosticCode::TypeNotFound,
        r#"
        ---@alias TestA<T> T extends "test" and number or string
        ---@alias TestB<T> T extends true and number or string
        ---@alias TestC<T> T extends 111 and number or string
        ---@alias TestD<T> T extends false and number or string
        ---@alias TestE<T> T extends nil and number or string
        "#,
    ));
}

Note that for the nil case to pass, the parser will also need to be updated to recognize TkNil as a literal type, which seems to be missing from this PR.

    #[test]
    fn test_extends_literal() {
        let mut ws = VirtualWorkspace::new();
        assert!(ws.check_code_for(
            DiagnosticCode::TypeNotFound,
            r#"
            ---@alias TestA<T> T extends "test" and number or string
            ---@alias TestB<T> T extends true and number or string
            ---@alias TestC<T> T extends 111 and number or string
            ---@alias TestD<T> T extends false and number or string
            ---@alias TestE<T> T extends nil and number or string
            "#,
        ));
    }