Bugzilla – Full Text Bug Listing
| Summary: | Index cannot maintain different typedefs with the same name | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Andrew Gvozdev <angvoz.dev> | ||||
| Component: | cdt-indexer | Assignee: | Project Inbox <cdt-indexer-inbox> | ||||
| Status: | NEW --- | QA Contact: | Jonah Graham <jonah> | ||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | aegges, alvaro.sanchez-leon, callahdev, cdtdoug, elliott.partridge, gonwan, kis36205, malaperle, martin.gerhardy, Oliver_Loidl, simon.marchi, veit.scharf, yevshif, y_anitha | ||||
| Version: | 8.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 421014, 439553, 490778, 497867, 533259, 520322 | ||||||
| Attachments: |
|
||||||
Created attachment 189293 [details]
sample project
Actually the index just maintains a single version for each typedef name. In your example it happens to point to the anonymous struct in file 'other.h', because this file was indexed at a later point. Because classes, structs and unions can be fwd-declared, we cannot determine whether the same name is meant to name the same type or not. Therefore, there is only one definition for a type-name in the index. However, there are no fwd-declarations for typedefs and therefore it should be possible to track different version for typedefs with the same name. *** Bug 350479 has been marked as a duplicate of this bug. *** *** Bug 438305 has been marked as a duplicate of this bug. *** *** Bug 481283 has been marked as a duplicate of this bug. *** *** Bug 530348 has been marked as a duplicate of this bug. *** *** Bug 520322 has been marked as a duplicate of this bug. *** |
When typedefs with the same name are defined in different files parser fails to follow #include strictly and matches wrong typedef (or thinks its ambiguous). include/file.h: typedef struct { int x; } SS; file.c: #include "include/file.h" void fun() { SS var; var.x; } Import the attached sample project, reindex and open file.c: - "var.x" triggers an error "x cannot be resolved" - content assist on "var." adds "y" instead - F3 on "SS" gives a popup with 2 choices. That should not be happening as there is explicit #include "include/file.h" pointing to the proper header. This problem is pretty severe for big projects and given a chance Codan with the default settings generates tens of thousands of errors for the kinds of projects we are using.