On 10/26/2011 03:38 PM, Jason Merrill wrote:
On 10/26/2011 02:00 AM, Ed Smith-Rowland wrote:
The patch was bootstrapped and regtested on x86_64-linux-gnu.
Really? I ran into a warning about the unused "suffix" parameter to
interpret_integer. So I've fixed that error. I also added a couple
of comments, and implemented the change to check_literal_operator_args
that I wondered about a while back. And checked it all in.
But we aren't quite done, I think: I notice that the lookup of
operators doesn't match what's in 2.14.8. For instance, I don't think
this should be accepted:
double operator"" _foo (long long unsigned);
double d = 1.2_foo;
I'm on it.
It looks like these incorrectly pass too:
int operator"" _char(char);
int operator"" _wchar_t(wchar_t);
int operator"" _char16_t(char16_t);
int operator"" _char32_t(char32_t);
int cwc = 'c'_wchar_t;
int cc16 = 'c'_char16_t;
int cc32 = 'c'_char32_t;
int wcc = L'c'_char;
int wcc16 = L'c'_char16_t;
int wcc31 = L'c'_char32_t;
etc.
I'm guessing pointer conversion errors would prevent something similar
happening to raw and string operators but I'll check and repair.
The lookup described in 2.14.8 involves looking through the overload
set for a particular signature before doing normal overload resolution.
Also, we don't need to worry about argument-dependent lookup for these
operators, since none of the arguments can have associated namespaces.
So I think we can use lookup_name rather than
lookup_function_nonclass, only look it up once in
cp_userdef_numeric_literal, and then only build one call depending on
the contents of the overload set.
Jason
