Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alias table does not recognise another alias as key #67

Closed
pouwelsjochem opened this issue Mar 23, 2021 · 1 comment
Closed

Alias table does not recognise another alias as key #67

pouwelsjochem opened this issue Mar 23, 2021 · 1 comment

Comments

@pouwelsjochem
Copy link
Contributor

Environment

name version
IDEA version IC2020.3
Luanalysis version 1.2.2
OS MacOS Big Sur

What are the steps to reproduce this issue?

---@alias aOrB "a"|"b"
---@alias aAndBPropertyAlias {a:true, b:true}
---@alias aAndBStringAlias {["a"]:true, ["b"]:true}
---@shape aAndBShape
---@field a true
---@field b true

local b = "b" ---@type aOrB

local abPropertyAlias = --[[---@type aAndBPropertyAlias]] {}
abPropertyAlias["a"] = true
abPropertyAlias.b = true
abPropertyAlias[b] = true -- No such indexer '["a"]' found on type '{ a: true, b: true } || No such indexer '["b"]' found on type '{ a: true, b: true }'

local abStringAlias = --[[---@type aAndBStringAlias]] {}
abStringAlias["a"] = true -- No such member 'a' found on type '{ ["a"]: true, ["b"]: true }' 
abStringAlias.b = true -- No such member 'b' found on type '{ ["a"]: true, ["b"]: true }' 
abStringAlias[b] = true

local abShape = --[[---@type aAndBShape]] {}
abShape["a"] = true
abShape.b = true
abShape[b] = true

What happens?

When using the '{}' format with either the @param or @alias annotation it doesn't recognise the keys correctly.
Using {a:true, b:true} breaks when using another alias as key.
Using {["a"]:true, ["b"]:true} does the opposite, it breaks when not using an alias

What were you expecting to happen?

The '{}' format to work the same as a @shape does. As far as I can tell these effectively define the same type of table structure.

@Benjamin-Dobell
Copy link
Owner

The issue wasn't really related to aliases, but rather that "doc tables" were initially much more limited than shapes. The main issue was no generics, but I later added generic aliases so you can emulate generic doc tables.

I've now gone back and made doc tables behave more like @shape. The main difference is doc tables cannot inherit from other doc tables. They also can't represent a callable type. Aside from that, they should now be pretty comparable.

In a follow-up commit to the one referenced above, I added support for inheriting from doc table aliases, or any @alias that references a legal type.

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

No branches or pull requests

2 participants