Bugzilla – Full Text Bug Listing
| Summary: | improve range of syntax error for function declaration with bogus specifiers | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Mike Kucera <mikekucera> |
| Component: | cdt-parser | Assignee: | Project Inbox <cdt-parser-inbox> |
| Status: | NEW --- | QA Contact: | Jonah Graham <jonah> |
| Severity: | normal | ||
| Priority: | P3 | CC: | klass, yevshif, zeratul976 |
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
How would it know it supposedly is a macro if it does not know it? C++ standard-wise is this even valid? Does that even compile without the define? (In reply to Jan Klass from comment #1) > How would it know it supposedly is a macro if it does not know it? It wouldn't. My understanding of what's being asked for is to heuristically recognize that this is supposed to be a function declaration, and restrict the syntax error to the extra identifier rather than the whole declaration. > C++ standard-wise is this even valid? > Does that even compile without the define? No and no. But the IDE still needs to have *some* behaviour when dealing with invalid code, and some behaviours are better than others. |
Example: #define XCALL void XCALL foo() { printf(); printf(); } Comment out the #define and the entire function gets marked as a syntax error. I see this quite often with the codebase I'm using now. I guess people like to add empty macros to the function declaration as a kind of documentation. When the header that contains the #define is unresolved the entire function is reported as an error, and these functions can be large.