Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 355523 - Missing ProblemBinding when accessing type members "wrongly"
Summary: Missing ProblemBinding when accessing type members "wrongly"
Status: RESOLVED WONTFIX
Alias: None
Product: CDT
Classification: Tools
Component: cdt-indexer (show other bugs)
Version: 8.0   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Markus Schorn CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-23 11:04 EDT by Lukas Felber CLA
Modified: 2011-08-24 02:33 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Felber CLA 2011-08-23 11:04:53 EDT
Build Identifier: I20110613-1736

In the first following two code examples, the bindings which are returned for name "f" are CPPField bindings (even if the code won't compile). In the third code example the retuned binding is a ProblemBinding.

Would it not be nice to have all the (more or less similar) cases behave in the same way? Actually, I would prefer that for all cases, a ProblemBinding should be retuned. Since ProblemBinding can contain a reason about whats wrong, this would be very helpful. Reasons like "accessing none-static members in static way" or "access not allowed to private member" would be great. What do you think on this issue?

Reproducible: Always

Steps to Reproduce:
Example 1.
struct X {
private:
	static int f;
};
int main() {
	X::f = 5;
}
Example 2.
struct X {
	int f;
};
int main() {
	X::f = 5;
}
Example 3.
struct X {
	void f();
};
int main() {
	X::f();
}
Comment 1 Markus Schorn CLA 2011-08-24 02:33:11 EDT
The parser does not go beyond name-resolution and that makes sense. In the case of function calls the parser needs to perform overload resolution, which does detect the missing implicit object parameter for calling f().