diff options
author | Douglas Gregor <dgregor@apple.com> | 2009-09-30 21:46:01 +0000 |
---|---|---|
committer | Douglas Gregor <dgregor@apple.com> | 2009-09-30 21:46:01 +0000 |
commit | 66950a32d9083727a89ea489b07b90d29f6c9b87 (patch) | |
tree | 8509c4754ddee1c92ce98002c177695f464d8312 /clang/lib/CodeGen/CodeGenModule.cpp | |
parent | 64c8d5a004cc2f746ed50d0de1401c99b271b054 (diff) | |
download | bcm5719-llvm-66950a32d9083727a89ea489b07b90d29f6c9b87.tar.gz bcm5719-llvm-66950a32d9083727a89ea489b07b90d29f6c9b87.zip |
When overload resolution fails for an overloaded operator, show the
overload candidates (but not the built-in ones). We still rely on the
underlying built-in semantic analysis to produce the initial
diagnostic, then print the candidates following that diagnostic.
One side advantage of this approach is that we can perform more validation
of C++'s operator overloading with built-in candidates vs. the
semantic analysis for those built-in operators: when there are no
viable candidates, we know to expect an error from the built-in
operator handling code. Otherwise, we are not modeling the built-in
semantics properly within operator overloading. This is checked as:
assert(Result.isInvalid() &&
"C++ binary operator overloading is missing
candidates!");
if (Result.isInvalid())
PrintOverloadCandidates(CandidateSet, /*OnlyViable=*/false);
The assert() catches cases where we're wrong in a +Asserts build. The
"if" makes sure that, if this happens in a production clang
(-Asserts), we still build the proper built-in operator and continue
on our merry way. This is effectively what happened before this
change, but we've added the assert() to catch more flies.
llvm-svn: 83175
Diffstat (limited to 'clang/lib/CodeGen/CodeGenModule.cpp')
0 files changed, 0 insertions, 0 deletions