Determine better policy for handling ahead-of-time struct definitions
Open, NormalPublic

Description

If a struct is defined prior to a corresponding typedef, future uses of this typedef link to the underlying struct instead of just the relatively uninteresting typedef line.

The opposite is true for structs defined after their referencing typedef.

This is very annoying for reading through C source which follows this C idiom for concealing implementation details of module data structures. In fact, KDevelop seems entirely ignorant of the link between this struct Example definition and its typedef. While this is understandably somewhat ambiguous when it comes to references outside of the containing module, the Example in our Example abc declaration is entirely unambiguous in this context.

EDIT: This doesn't seem to be so much an issue of KDevelop not being able to support this idiom and resolving forward-declarations, but more a problem with the overlapping of struct and typedef namespaces.

mswan created this task.Jul 11 2019, 7:30 AM
mswan triaged this task as Normal priority.
mswan added a comment.EditedJul 11 2019, 9:32 PM

Even in contexts where you are specifying the struct itself, it is still matching against the typedef.

The problem here is that the struct and typedef namespaces aren't realized as separate, so the typedef itself is considered the resolution to this forward declaration. In cases where it could be ambiguous, e.g. there are multiple 'struct <name>' definitions somewhere in the known universe, ideally we could allow users a quick choice between them instead of opening the full list of uses or picking one of them arbitrarily, but in either case, this typedef should recognize the distinction between 'struct Example' being in the namespace of structs and 'Example' being in the namespace of typedefs.

Since this is a matter of namespace collision, renaming the typedef solves one issue, but for some reason our first struct Example mention doesn't ever get resolved.

If we add a struct Example declaration prior to our typedef, suddenly it is properly resolved. This almost looks to be a kind of off-by-one error, but I will need to look further.

mswan updated the task description. (Show Details)Jul 11 2019, 10:25 PM