update

[xuhuanzy]

1. refactor(visibility): improve type visibility #1004
2. constructor特性第四个参数从return_self更改为return_mode以支持返回值使用泛型
3. 泛型参数现在支持默认值

---@class A<T = number>
---@class B<T : number = number>
---@class C<T extends number = number> -- `extends` 关键词等效于 `:`, 但更清晰且更容易被大模型识别

4. 条件类型完善, 现在条件类型的行为更接近 TS 了

[gemini-code-assist]

Code Review

This pull request introduces significant changes to the EmmyLua analysis engine, including a new module visibility system, improved workspace path configuration, and a new diagnostic check for inconsistent type access modifiers. The export tag has been removed in favor of a more robust visibility system. I have reviewed the changes and suggest removing the commented-out code block in crates/emmylua_code_analysis/src/compilation/analyzer/doc/property_tags.rs to maintain code cleanliness.

[gemini-code-assist]

This block of code is commented out. If it's no longer needed, it should be removed to improve code clarity.

[clason]

f407e4b introduced a regression that persists on HEAD. The commit message is meaningless to me unfortunately, but I now get a slew of warnings on nvim-treesitter like

-- lua/nvim-treesitter/util.lua [2 warnings]
warning: expected `string? ...` but found `string?`.  [param-type-mismatch]
  -->: lua/nvim-treesitter/util.lua:6:23

  5 │ function M.read_file(filename)
  6 │   local file = assert(io.open(filename, 'r'))
  7 │   local r = file:read('*a')

warning: expected `string? ...` but found `string?`.  [param-type-mismatch]
  -->: lua/nvim-treesitter/util.lua:15:23

  14 │ function M.write_file(filename, content)
  15 │   local file = assert(io.open(filename, 'w'))
  16 │   file:write(content)

@lewis6991

[xuhuanzy]

@clason This is a breaking change. Earlier, I mistakenly treated extends Type as a default value constraint, but now it must be written in a syntax similar to TypeScript's extends Type = Type. I think this might be the issue.
Could you provide some reproduction code?

[clason]

https://github.com/nvim-treesitter/nvim-treesitter

It's enough to clone this repo and run VIMRUNTIME=/usr/local/share/nvim/runtime/ emmylua_check . at the root (assuming you have Neovim installed to /usr/local; adjust to taste, e.g., point the VIMRUNTIME variable to a local clone of https://github.com/neovim/neovim instead of /usr/local/share/nvim).

I am not aware of using type extensions at all.

[xuhuanzy]

f407e4b introduced a regression that persists on HEAD. The commit message is meaningless to me unfortunately, but I now get a slew of warnings on nvim-treesitter like

This issue has nothing to do with generics.

--- @type string?
local message

--- @param ... (string?) ...
function test(...) end

test(message)

[clason]

That may be (and what I assume); nevertheless, I bisected the regression to that commit. Note that the examples I listed deliberately do not involve any user-defined functions; only LuaJIT builtins that emmyluals defines the annotations for.

[CppCXY]

That may be (and what I assume); nevertheless, I bisected the regression to that commit. Note that the examples I listed deliberately do not involve any user-defined functions; only LuaJIT builtins that emmyluals defines the annotations for.

I have time to look into this issue; by the way, why this project was archived?

[clason]

why this project was archived?

Long story I don't want to go much into right now; some people were very vocal in their dislike of the way I handled things, and I didn't want to have to deal with that anymore. The important thing is that it's still available and doing what it was designed to do.

[xuhuanzy]

f407e4b introduced a regression that persists on HEAD. The commit message is meaningless to me unfortunately, but I now get a slew of warnings on nvim-treesitter like

Confirmed it's a generic issue. A long time ago, I used a workaround to treat all such cases as 'any', and this operation has been removed in this commit.

--- @type string?
local message

--- @param ... (string?) ...
function test(...) end

test(message)

This is an incorrect notation; ---@param ... (string?) ... should not appear. ... should only appear after generics. I am considering whether to add a diagnostic or simply remove the ... keyword, as its semantics are highly unintuitive and cause many processing difficulties.

[lewis6991]

... should be a keyword. How else would you type annotate varargs?

[xuhuanzy]

... should be a keyword. How else would you type annotate varargs?

I am referring to T..., and currently, the handling of T... is very confusing. Please refer to fn test_variadic_base().