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?