Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'm not sure that changing isPotentiallyEvaluated() is the right thing to do. The meaning of that corresponds to text in the standard: https://eel.is/c++draft/expr.typeid#3 so changing it to something that doesn't match the standard exactly seems wrong.
I think it would be safer to do the change purely as an optimization in codegen (maybe we could add a new helper method that could also be used by the warning).
Also, I found another interesting test case: https://godbolt.org/z/aW4ojr
#include <typeinfo> class B { public: virtual void f(); }; B f(); const std::type_info& g() { return typeid(f()); }
Here MSVC warns about /GR- and emits the call to __RTtypeid even though I think it's not necessary since the type is statically known. Actually, if I understand things correctly, f() shouldn't even be evaluated here since the expression is not a glvalue, and Clang gets that right. So that's a case where our codegen is better than MSVC :-)
If the operand of CXXTypeidExpr is already most derived object, no need to look up vtable.
If the type of the operand is already most derived, we could just emit the typeinfo of the type. This would match the standard: https://eel.is/c++draft/expr.typeid#2
I think it would be safer to do the change purely as an optimization in codegen (maybe we could add a new helper method that could also be used by the warning).
For "optimization in codegen", do you mean optimization after the IR is generated or like I did in CodeGenFunction::EmitCXXTypeidExpr?
I think it would be safer to do the change purely as an optimization in codegen (maybe we could add a new helper method that could also be used by the warning).
For "optimization in codegen", do you mean optimization after the IR is generated or like I did in CodeGenFunction::EmitCXXTypeidExpr?
I mean like you did in CodeGenFunction::EmitCXXTypeidExpr.
clang/include/clang/AST/ExprCXX.h | ||
---|---|---|
844 | A comment would be good here. | |
clang/lib/AST/ExprCXX.cpp | ||
157 | I suppose it depends on what you want the semantics of this function to be, but returning false here seems odd.. wouldn't true make as much sense? | |
160 | I think checking for DeclRefExpr isn't guaranteed to handle all cases, like typeid(*&obj) for example. That's okay, but it should be clear from the function comment (and maybe the name) that this is a best-effort check, not a strong guarantee about whether the expression refers to a most derived object. | |
clang/test/SemaCXX/constant-expression-cxx2a.cpp | ||
312 | This appears to be changing semantics. It could be that this test is unnecessary strict (that's my understanding), but usually these checks are based on examples in the standard, or the current understanding of the standard. I think it would be best to check with Richard before changing this. Actually, I'm surprised this affected since you're only updating CodeGen, not Sema. Is the static_assert really invoking Codegen? |
clang/test/SemaCXX/constant-expression-cxx2a.cpp | ||
---|---|---|
312 | This was caused by my previous changes on isPotentiallyEvaluated, which is used by Sema. I reverted this. |
lgtm
clang/test/SemaCXX/constant-expression-cxx2a.cpp | ||
---|---|---|
312 | Ah, great. That makes more sense :) |
A comment would be good here.