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

Attachment: unary_cand.cpp
Description: Binary data

_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to