Bug 409041 - KDevelop shows wrong data type in tooltip
Summary: KDevelop shows wrong data type in tooltip
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: Language Support: CPP (Clang-based) (show other bugs)
Version: 5.3.2
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-22 15:41 UTC by Bernd Buschinski
Modified: 2019-09-28 10:36 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
kdevelop-unittest-type.patch (2.70 KB, patch)
2019-06-22 15:43 UTC, Bernd Buschinski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bernd Buschinski 2019-06-22 15:41:28 UTC
SUMMARY

For the following code:
```
typedef struct {
    int bitmask[1];
} bitmask_a;

typedef struct {
    int bitmask[6];
} bitmask_c;

typedef union {
    bitmask_c bitmask;
} bitmask_union;

void foo()
{
    bitmask_union u;
    (void)u.bitmask;
}
```
When I hover my mouse over last "(void)u.bitmask;", the bitmask part.
It shows "int[1] bitmask", which is wrong it should be "bitmask_c bitmask".

SOFTWARE/OS VERSIONS
Linux: 5.1.11
KDE Plasma Version: 5.16.1
KDE Frameworks Version: 5.59.0
Qt Version: 5.12.3
Comment 1 Bernd Buschinski 2019-06-22 15:43:19 UTC
Created attachment 121079 [details]
kdevelop-unittest-type.patch

I tried adding a unit test. It shows the error but I am pretty sure I did it wrong.

For now I am kinda lost, but with a little help, maybe we can fix it together quickly? Just need a hint into which direction to go :)
Comment 2 Aaron Puchert 2019-07-06 22:41:45 UTC
I can reproduce this. When I hover over either of the bitmask members, it also highlights the bitmask in u.bitmask. The tool tips show no "Container:", probably because these are unnamed structs/unions. When I give them names, everything is fine. So I assume something is wrong with our handling of unnamed structs, probably because they seem to be represented by empty strings.

For example, `typedef struct {} tp;` is

|-RecordDecl 0x101d5e8 <<stdin>:1:9, col:17> col:9 struct definition
`-TypedefDecl 0x107a5f8 <col:1, col:19> col:19 tp 'struct tp':'tp'
  `-ElaboratedType 0x107a5a0 'struct tp' sugar
    `-RecordType 0x101d660 'tp'
      `-Record 0x101d5e8 ''

while `typedef struct X {} tp;` is

|-RecordDecl 0x109b5e8 <<stdin>:1:9, col:19> col:16 struct X definition
`-TypedefDecl 0x10f85b8 <col:1, col:21> col:21 tp 'struct X':'struct X'
  `-ElaboratedType 0x10f8560 'struct X' sugar
    `-RecordType 0x109b660 'struct X'
      `-Record 0x109b5e8 'X'
Comment 3 Bernd Buschinski 2019-07-14 14:46:16 UTC
Posted https://phabricator.kde.org/D22455 as a workaround.
I am not very confident about this workaround and would really appreciate your feedback :)
Comment 4 Bernd Buschinski 2019-07-19 17:21:45 UTC
Git commit d1f58562046494b78e17c50c2fdab5c2800d9aaf by Bernd Buschinski.
Committed on 19/07/2019 at 17:21.
Pushed by buschinski into branch 'master'.

Fix code completion for nameless structs/unions with the same member

Summary:
The code completion always shows the first declaration it finds for a matching name.
This works fine as long as the parent has a name, for nameless structs/unions it just returns the first declaration it finds.
Fix this by checking that the found declaration has the expected type.

Test Plan:
See https://bugs.kde.org/show_bug.cgi?id=409041 for example code
or see the unit test in this patch.

Reviewers: #kdevelop, apol

Reviewed By: #kdevelop, apol

Subscribers: kdevelop-devel

Tags: #kdevelop

Differential Revision: https://phabricator.kde.org/D22455

M  +13   -0    plugins/clang/codecompletion/context.cpp
M  +43   -2    plugins/clang/tests/test_codecompletion.cpp
M  +2    -0    plugins/clang/tests/test_codecompletion.h

https://invent.kde.org/kde/kdevelop/commit/d1f58562046494b78e17c50c2fdab5c2800d9aaf
Comment 5 Milian Wolff 2019-09-21 12:30:07 UTC
Git commit a6df33cf7cd7463f146b724606bf4add169badb8 by Milian Wolff.
Committed on 21/09/2019 at 12:27.
Pushed by mwolff into branch '5.4'.

Use type name as fallback ID for anon typedef'ed structs/unions etc.

The cursor pointing to the struct within `typedef struct {...} foo;`
has an empty cursor spelling, but its type spelling is set to `foo`.
This is ideal to disambiguate between different structs. Without that,
we would end up associating uses of different cursors to the first
declaration with an empty name. Now that we set a proper non-empty
name, we can correctly disambiguate and associate the uses correctly.

M  +8    -1    plugins/clang/duchain/builder.cpp
A  +42   -0    plugins/clang/tests/files/uses.c     [License: UNKNOWN]  *

The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page.


https://invent.kde.org/kde/kdevelop/commit/a6df33cf7cd7463f146b724606bf4add169badb8
Comment 6 Milian Wolff 2019-09-21 12:46:10 UTC
aaaand I broke code completion with this :D
Comment 7 Milian Wolff 2019-09-21 14:00:01 UTC
Git commit 26ee0da99a0cb9497fdebc0121576b34508e5d9d by Milian Wolff.
Committed on 21/09/2019 at 13:59.
Pushed by mwolff into branch '5.4'.

Use type name as fallback ID for anon typedef'ed structs/unions etc.

The cursor pointing to the struct within `typedef struct {...} foo;`
has an empty cursor spelling, but its type spelling is set to `foo`.
This is ideal to disambiguate between different structs. Without that,
we would end up associating uses of different cursors to the first
declaration with an empty name. Now that we set a proper non-empty
name, we can correctly disambiguate and associate the uses correctly.

Sadly, clang_getCompletionParent is broken too for this case - it
doesn't return the typedef name :( We now work-around this limitation
by parsing the USR of the container which _does_ contain that info.
Very hacky but at least this makes it work for both, uses and code
completion! Also, we can get rid of the previous hack which tried to
match the type too, which is probably way more costly than this.

M  +18   -16   plugins/clang/codecompletion/context.cpp
M  +8    -1    plugins/clang/duchain/builder.cpp
A  +42   -0    plugins/clang/tests/files/uses.c     [License: UNKNOWN]  *

The files marked with a * at the end have a non valid license. Please read: https://community.kde.org/Policies/Licensing_Policy and use the headers which are listed at that page.


https://invent.kde.org/kde/kdevelop/commit/26ee0da99a0cb9497fdebc0121576b34508e5d9d
Comment 8 Milian Wolff 2019-09-21 14:01:23 UTC
Hey Bernd, I hope to have finally fixed it. Can you please try it out and see how it goes?

thanks
Comment 9 Bernd Buschinski 2019-09-28 10:36:33 UTC
Works perfectly. Thanks! :D