Page MenuHomePhabricator

[clang] diagnose instead of assert for defaulted comparison return type deduction.
Needs ReviewPublic

Authored by mizvekov on Jun 7 2021, 3:30 PM.



When deducing the return type of defaulted three-way comparison, instead
of asserting in the case of unsupported builtin types, just diagnose it.

For now, we add a test case for function pointers which will produce
slightly incorrect diagnostics. In future work, we will stop adding
function pointers to the candidate set and get the correct diagnostics.

Signed-off-by: Matheus Izvekov <>

Depends on D103760

Diff Detail

Event Timeline

mizvekov requested review of this revision.Jun 7 2021, 3:30 PM
mizvekov created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJun 7 2021, 3:30 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
mizvekov added inline comments.Jun 7 2021, 5:04 PM

I think this should be an error because otherwise we would be accepting and giving this program a different semantic just because of some not-implemented feature.
But I can see the downside that we could potentially reject a program which is not affected by the operator being implicitly deleted.


rsmith added inline comments.Jun 16 2021, 10:39 AM

I think three-way comparison for function pointers is ill-formed, and that the problem in this case is that [over.built] lists candidates for which a three-way comparison is invalid. So our overload resolution succeeds, but results in a meaningless builtin candidate with an undefined return type.

I think the behavior here after this patch is fine -- we should treat the comparison as deleted -- but the diagnostic is wrong. This isn't a "not currently supported" case, this is a "not a valid expression" case, per []/3.2 (except that the wording currently gets this wrong and doesn't actually say what happens here, because we're actually in []/3.1). Though perhaps the better fix would be to not even include a builtin candidate for operator<=>(void (*)(), void (*)())?

mizvekov added inline comments.Jun 16 2021, 10:53 AM

Yeah this was part of my plan to give the correct diagnostic for function pointers in the next patch in the series:

The idea on this one is to produce an error, is the TU will not compile, for built-in types not supported.

After the next one, we just implicitly delete the comparison for function pointers, and leave the error for other unimplemented built-in types.

I think this makes more sense, even if we manage to implement this deduction for all built-in types currently available, it would still be too easy for another patch to introduce a new built-in types and forget to support it here.

And it does make sense to error on these cases than to simply pick an arbitrary answer and churn along, I think