[cfe-commits] r83650 - in /cfe/trunk: include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/SemaOverload.cpp test/SemaCXX/builtin-ptrtomember-ambig.cpp

[Douglas Gregor]

On Oct 9, 2009, at 10:09 AM, Fariborz Jahanian wrote:

> Author: fjahanian
> Date: Fri Oct  9 12:09:58 2009
> New Revision: 83650
>
> URL: http://llvm.org/viewvc/llvm-project?rev=83650&view=rev
> Log:
> Produce good looking diagnostics on ambiguous built-in operators.
> Now we produce things like:
> bug1.cpp:21:11: error: use of overloaded operator '->*' is ambiguous
>        int i = c->*pmf;        // expected-error {{use of overloaded  
> operator '->*' is ambiguous}} \
>                ~^  ~~~
> bug1.cpp:21:11: note: built-in candidate operator ->* ('struct A  
> volatile *', 'int const struct A::*')
> bug1.cpp:21:11: note: built-in candidate operator ->* ('struct A  
> volatile *', 'int restrict struct A::*')

Much improved, thanks!

> = 
> = 
> = 
> = 
> = 
> = 
> = 
> = 
> ======================================================================
> --- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaOverload.cpp Fri Oct  9 12:09:58 2009
> @@ -4045,14 +4045,12 @@
>         Diag(Cand->Surrogate->getLocation(),  
> diag::err_ovl_surrogate_cand)
>           << FnType;
>       } else if (OnlyViable) {
> -        QualType FnType
> -          = Context.getFunctionType(Cand->BuiltinTypes.ResultTy,
> -                                    Cand->BuiltinTypes.ParamTypes,
> -                                    Cand->Conversions.size(),
> -                                    false, 0);
> -
> -        Diag(OpLoc, diag::err_ovl_builtin_candidate) << FnType <<
> -	  BinaryOperator::getOpcodeStr(Opc);
> +        assert(Cand->Conversions.size() == 2 &&
> +               "builtin-binary-operator-not-binary");
> +        Diag(OpLoc, diag::err_ovl_builtin_candidate)
> +          << Cand->BuiltinTypes.ParamTypes[0]
> +          << Cand->BuiltinTypes.ParamTypes[1]
> +          << BinaryOperator::getOpcodeStr(Opc);

There are unary built-in operator candidates (such as operator++,  
operator--) and, although it isn't implemented yet, there are ternary  
candidates for ?:, so we'll need to deal with those. I've attached a  
test case that triggers this assert with a builtin operator++ candidate.

>
> +       				// FIXME. Why so many built-in candidates?
> +	int i = c->*pmf; 	// expected-error {{use of overloaded operator '- 
> >*' is ambiguous}} \
> +				// expected-note 40 {{built-in candidate operator ->* ('struct  
> A}}

Pruning the candidate set can be tricky; if we're too aggressive in  
our pruning, we'll start seeing ambiguities that should not be there.  
Two heuristics come to mind:

   - if a the volatile or restrict qualifier is not mentioned in any  
of the types in the set, we don't need to produce candidates that add  
that qualifier.

   - when printing candidates after an ambiguity, we can suppress any  
candidate for which there is any other candidate that is better.

The ideas get crazier after that.

	- Doug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: unary_cand.cpp
Type: application/octet-stream
Size: 117 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20091012/be928f31/attachment.obj>