Attached is a patch to add support for explicitly referring to member operators in C++, e.g. x.operator++(). It supports both overloaded operators and conversion operators.
The patch also contains a fix in the same area of the code to eliminate a crash when compiling syntactically-incorrect code as part of a member-reference (e.g. x.int). That crash was actually my fault anyway, since it came about from adding support for qualified-ids in class member access. If you think the fix should be a separate patch, let me know and I'll pull them apart.
There are also tests for both parts of the patch.
- Jim
explicit-operators.patch (9.61 KB)
+ // TODO: support conversion operators too
Is that supposed to be there?
+ } else if(TypeTy *ConvType = ParseConversionFunctionId()) {
Space after if.
Otherwise, looks fine to me, but Doug should probably look at it as well.
-Eli
Eli Friedman wrote:
+ // TODO: support conversion operators too
Is that supposed to be there?
Oops! That's not supposed to be there.
+ } else if(TypeTy *ConvType = ParseConversionFunctionId()) {
Space after if.
Fixed.
Thanks,
Jim
explicit-operators.patch (9.55 KB)
Sean Hunt wrote:
James Porter wrote:
+ x.operator; // expected-error{{missing type specifier after 'operator'}}
- Jim
That error message should probably read "missing type specifier or
operator after 'operator' keyword" or something similar.
Hm, probably. However, you get the same error when doing something like the following:
struct foo {
operator typedef();
// or...
int operator typedef();
};
I can't think of any cases off the top of my head where conversion functions are allowed but overloaded operators aren't allowed, so maybe this is just a case where the error message needs changed.
- Jim
Copy-paste error with this comment (I've fixed it).
Patch committed here, thanks!
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20090831/020837.html
- Doug