Details
- Reviewers
aaron.ballman jwakely
Diff Detail
Unit Tests
| Time | Test | |
|---|---|---|
| 100 ms | x64 debian > Clang.AST/Interp::cxx20.cpp |
Event Timeline
| clang/lib/AST/ExprConstant.cpp | ||
|---|---|---|
| 12951–12954 | A comment to explain this change would be helpful. It isn't intuitive (for me anyway) why Objective-C's @encode would require special handling here. Was this needed to avoid a test failure? | |
| clang/lib/AST/ExprConstant.cpp | ||
|---|---|---|
| 12951–12954 | In ../clang/test/CodeGenObjC/encode-test-4.m: int a(void) {
return @encode(int) == @encode(int) &&
@encode(Color) == @encode(long) &&
@encode(PrintColor) == @encode(int);
}The comparisons need to be rejected here and are folded to a 1 later on, it seems. Letting the comparison happen will lead to a 0. | |
| clang/lib/AST/ExprConstant.cpp | ||
|---|---|---|
| 12951–12954 | Apologies, I meant it would be helpful to add a comment to the code :) I think @encode(...) expressions should be treated the same as string literals; the former is lowered to the latter; both contribute to the string table. | |
| clang/lib/AST/ExprConstant.cpp | ||
|---|---|---|
| 12951–12954 | You mean the special case for them here should go away? I've tracked this down to CodeGenFunction::ConstantFoldsToSimpleInteger(). Without this special case for endcode expressions, we will return true here and fold the comparison to false, so we will just emit that. This is a funny case though, which also exists in C++. With this patch, "a" == "a" evaluates to true, as one would expect. That's pretty wrong so I think the patch needs more work. | |
| clang/lib/AST/ExprConstant.cpp | ||
|---|---|---|
| 12951–12954 | Should "a" == "a" evaluate to true? The standard seems clear that the behavior is unspecified ((lex.string)p9). Is there a special case for constexpr context somewhere? I see that gcc, icc, and MSVC all compare them equally in constexpr context, but that doesn't mean that Clang needs to. Gcc appears to treat Objective-C @encode() expressions equivalently to string literals in constexpr context. https://godbolt.org/z/Kxz3E8xKa | |
A comment to explain this change would be helpful. It isn't intuitive (for me anyway) why Objective-C's @encode would require special handling here. Was this needed to avoid a test failure?