This is an archive of the discontinued LLVM Phabricator instance.

[clang] Improve diagnostic note for implicit conversion sequences that would work if more than one implicit user-defined conversion were allowed.
AbandonedPublic

Authored by logan-5 on Feb 7 2020, 10:14 AM.

Details

Reviewers
rsmith
Summary

The current text of the 'note' diagnostic for bad conversions is confusing in the presence of user-defined conversion operations: https://godbolt.org/z/zrgeHH
For the first error, the conversion function is simply pointed at in a note without any further explanation. For the second error, the final note claims there is no conversion from X2 to Y2, even though it is plainly visible in the source code. The reason for the error is that only one implicit user-defined conversion may be applied in these circumstances, but the error message is misleading to those who may not know this rule.

This is determined by searching for these illegal conversions in CompleteNonViableCandidate after overload resolution fails.

Depends on D74234. Also depends on D74235.

Diff Detail

Event Timeline

logan-5 created this revision.Feb 7 2020, 10:14 AM
Eugene.Zelenko retitled this revision from [clang] [clang] Improve diagnostic note for implicit conversion sequences that would work if more than one implicit user-defined conversion were allowed. to [clang] Improve diagnostic note for implicit conversion sequences that would work if more than one implicit user-defined conversion were allowed..Feb 7 2020, 10:20 AM

Pinging this and the patches it depends on. I figured it would need a rebase by now, but it still applies cleanly to trunk.

How do you defend against attempting an infinite sequence of user-defined conversion? For example:

template<int N> struct X {
    operator X<N + 1>();
};
X<0> x0 = X<1>();
clang/lib/Sema/SemaOverload.cpp
7333

Conversions[0] is for the conversion of the object argument to the implicit object parameter. This should be stored in Candidate.FinalConversion instead.

11349

&& goes on the previous line (here and below).

logan-5 abandoned this revision.May 5 2020, 4:24 PM

@rsmith the intention is to only speculatively search one level deep (e.g. search for chains like A->B, B->C, but no deeper), which should cover most of the cases that are surprising to users.

However, the implementation of this patch has some issues, and it doesn't work quite how I intended. I still like the idea and I'd like to revisit it, but pondering how to get it to work properly is more than I have time for at the moment, with all the craziness in the world. So in the meantime, I'd like to withdraw it--I'll mark it and its related patches as 'abandoned'. Thanks very much for your time considering it.