馃悰 Set imported binding as an alias of target symbol #1193
Conversation
The file-level binding is now treated as an alias of the global symbol.
There was a problem hiding this comment.
This does not fully fix #1154.
The symbol deployed to mcdoc still contains the non-aliased reference.
If I delete the visibility: SymbolVisibility.File, in line 271, and edit my code to also do symbol.resolveAlias() when performing the lookup, I do get the correct node with the correct typedef.
I am not sure it is desirable to declare a public alias here though, I think I would prefer it if the reference type used the resolved path, and the alias wasn't public.
I think that's solved now. I also added a test that shows the global symbol instead of the file-level alias symbol is stored in the symbol table. |
|
Btw, you can use my NeunEinser:neun branch which is a combination of SPG's branch and my mcdoc branch for testing and compare errors with just the NeunEinser:mcdoc-validator branch on its own to see it working. |
Alias requires the target symbol to exist and can dereference multi-layer aliasing. We simply do not need the first requirement as the target file may not have been loaded yet by the time the local binding is referenced, and we do not need the second feature since use statement bindings are local and cannot be used for imports across files.
There was a problem hiding this comment.
I don't think I quite understand why alias didn't work. Is this a bug in how aliases are implemented or expected behavior when trying to declare an alias of sth not loaded yet?
If it is expected behavior, how would you use aliases in a way that avoids this problem?
All known edge cases are solved, NeunEinser:neun is updated.
it's mostly this. i could still use an alias but don't actually check the existence of the target when resolving it, in which case using a custom data is just simpler than using an alias. |
Fixes #1154.
mcdoc-binding.mp4
The file-level binding introduced by
useis now treated as an alias of the global symbol.