feat: add type size/alignment hover information#3175
feat: add type size/alignment hover information#3175ShadowCurse wants to merge 3 commits intozigtools:masterfrom
Conversation
ShadowCurse
force-pushed
the
add_size_align
branch
2 times, most recently
from
0cdb45e to
5d32009
Compare
Add utility functions for calculation of size and alignment of a given type. These will be used in the following commit to provide additional hover information. Signed-off-by: ShadowCurse <shadowcurse@noreply.codeberg.org>
Add functions for size/alignment retrieval for types. The implementation tries to get size/align info from InternPool if it can, but since not all types exist there (as far as I can see, only primitive types do), there is an alternative calculation path using the AST directly. This seems to work pretty well, but has limitations that for `extern` types it is not possible to correctly calculate the size since the order of fields may be unstable. Additionally, manually `align(..)`ed fields also do not work in this version. Next commit will use these to add size/alignment info to the hover tooltips. Signed-off-by: ShadowCurse <shadowcurse@noreply.codeberg.org>
Wire up functions from previous commits to display basic size/alignment information for types. Current limitations: - types which require comptime evaluation do not show anything - if such type is a field, the parent will not show anything as well - `extern` types do not calculate size correctly due to AST not having stable field ordering Signed-off-by: ShadowCurse <shadowcurse@noreply.codeberg.org>
ShadowCurse
force-pushed
the
add_size_align
branch
from
5d32009 to
53f2c05
Compare
|
I appreciate your work on this issue, however I do not believe that a good solution to #1677 is reimplement the size calculation logic of the Zig compiler in ZLS at this time. Especially when dealing with properties like size and alignment, you would like to put your trust into tools to always tell you the correct answer. But this implementation is too buggy and maintenance heavy that I'd rather wait until we can query the compiler to get reliable results from the source of truth. There is no way around this anyway since some types like auto structs have implementation defined size. The compiler is free to reorder fields, add padding or insert "invisible" fields however it may wish. Any standalone implementation of this in ZLS would be an approximation at best. |
|
I see your points and do agree with them. This compiler query feature you mentioned seems like the exact solution we need here indeed. |
2 participants
Add a basic version of size/alignment calculations for types and print these values as a part of the hover tool tip.
There are 2 main paths to get this info:
InternPoolcan calculate size/alignment for types it contain, but it does not contain many thingsIn general, this machinery seems to function pretty well from my testing. There are some limitations though:
comptimedoes not show any info. It also recursively prevents parent types from showing any info as wellexternstructs cannot have proper size calculations since AST can mess up the field orderingMaybe
externcan be solved if someone more knowledgeable about internals can take a look at the problem.Fixes: #1677