You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Clang ICE: unexpected rewritten operator form #64162
Hm, yeah, we're not prepared for operator<=> to return a comparison category by reference. (I think we'd get the same failure if operator<=> returned some other class type that implicitly converts to a comparison category. That'd be worth testing too.)
It's a bit ironic to call IgnoreUnlessSpelledInSource to find an implicitly generated use of the <=> operator that was not spelled in the source, but I think that it would do the right thing in this case.
I think we'd get the same failure if operator<=> returned some other class type that implicitly converts to a comparison category. That'd be worth testing too.)
Do you have an example of this? I was trying to put one together but could not get one that was valid with any implementation.
I think we'd get the same failure if operator<=> returned some other class type that implicitly converts to a comparison category. That'd be worth testing too.)
Do you have an example of this? I was trying to put one together but could not get one that was valid with any implementation.
Sure, here: https://godbolt.org/z/xjK4b8Gve -- though it doesn't crash, unlike the seemingly similar case where we require a constructor call rather than a conversion function call, and I'm not sure why.
Sure, here: https://godbolt.org/z/xjK4b8Gve -- though it doesn't crash, unlike the seemingly similar case where we require a constructor call rather than a conversion function call, and I'm not sure why.
I think b/c it has a MaterializeTemporaryExpr which IgnoreImplicitAsWritten() will skip through.
Activity
llvmbot commentedon Jul 27, 2023
@llvm/issue-subscribers-clang-frontend
shafik commentedon Jul 27, 2023
Confirmed
Backtrace:
shafik commentedon Jul 27, 2023
It looks like the result of
E = Result.LHS->IgnoreImplicitAsWritten();from:
llvm-project/clang/lib/AST/ExprCXX.cpp
Line 114 in f86c81b
is
perhaps we actually need to do
Result.LHS->IgnoreUnlessSpelledInSource()instead?shafik commentedon Jul 27, 2023
CC @zygoloid @royjacobson @AaronBallman
shafik commentedon Jul 27, 2023
I just verified that making that change does not break any test when running
check-clangzygoloid commentedon Jul 28, 2023
Hm, yeah, we're not prepared for
operator<=>to return a comparison category by reference. (I think we'd get the same failure ifoperator<=>returned some other class type that implicitly converts to a comparison category. That'd be worth testing too.)It's a bit ironic to call
IgnoreUnlessSpelledInSourceto find an implicitly generated use of the<=>operator that was not spelled in the source, but I think that it would do the right thing in this case.shafik commentedon Jul 28, 2023
Do you have an example of this? I was trying to put one together but could not get one that was valid with any implementation.
zygoloid commentedon Jul 28, 2023
Sure, here: https://godbolt.org/z/xjK4b8Gve -- though it doesn't crash, unlike the seemingly similar case where we require a constructor call rather than a conversion function call, and I'm not sure why.
shafik commentedon Jul 28, 2023
I think b/c it has a
MaterializeTemporaryExprwhichIgnoreImplicitAsWritten()will skip through.shafik commentedon Sep 14, 2023
PR: #66270
[Clang] Fix CXXRewrittenBinaryOperator::getDecomposedForm to handle c…
[Clang] Fix CXXRewrittenBinaryOperator::getDecomposedForm to handle c…
[Clang] Fix CXXRewrittenBinaryOperator::getDecomposedForm to handle c…
[Clang] Fix CXXRewrittenBinaryOperator::getDecomposedForm to handle c…