Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 317883 - improve range of syntax error for function declaration with bogus specifiers
Summary: improve range of syntax error for function declaration with bogus specifiers
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-parser (show other bugs)
Version: 7.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-24 17:28 EDT by Mike Kucera CLA
Modified: 2020-09-04 15:17 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kucera CLA 2010-06-24 17:28:44 EDT
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.
Comment 1 Jan Klass CLA 2015-04-14 12:26:30 EDT
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?
Comment 2 Nathan Ridge CLA 2015-04-14 14:00:11 EDT
(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.