Fixes PR46484: Clang crash in clang/lib/Sema/SemaChecking.cpp:10028
Details
Diff Detail
Event Timeline
Did this only crash during error recovery before, or also for your void g() example? If we were only crashing in error recovery, that would suggest that error recovery was producing a bad AST, and perhaps we should be fixing this elsewhere.
clang/lib/Sema/SemaChecking.cpp | ||
---|---|---|
10164 | Can we handle this in code that's specific to conditional expressions instead? Presumably somewhere higher up in the call graph, some code is assuming that it can recurse from a conditional expression to its subexpressions, and that assumption is wrong. |
I added void g() since that's valid code which also caused an assertion failure. So the issue isn't in the error recovery but in determining the required IntRange. It seems the code doesn't take http://eel.is/c++draft/expr.cond#2.1 into account.
clang/lib/Sema/SemaChecking.cpp | ||
---|---|---|
10164 | I can take a look at it if you want. However I feel this fix is better. If the conditional doesn't throw it can properly evaluate the required IntRange. If it throws the range doesn't matter, therefore I didn't want to increment the required range. |
clang/lib/Sema/SemaChecking.cpp | ||
---|---|---|
10164 | In order to get here, we need to have called functions that are documented as taking only integer types but passing them a void type. So the bug has already occurred before we got here. | |
10317–10320 | It seems to me that the bug is here. GetExprRange is documented as "Pseudo-evaluate the given integer expression", but the true and false expressions here might not be integer expressions -- specifically, one of them could be of type void if it's a throw-expression. In that case, we should only call GetExprRange on the other expression. The expression range of the void-typed expression is irrelevant in this case, because that expression never returns. |
clang/lib/Sema/SemaChecking.cpp | ||
---|---|---|
10317–10320 | Thanks for the hint I'll look into this solution. |
Can we handle this in code that's specific to conditional expressions instead? Presumably somewhere higher up in the call graph, some code is assuming that it can recurse from a conditional expression to its subexpressions, and that assumption is wrong.