[PATCH] D156185: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of StringLiterals

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGd1199808afa5: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of… (authored by nickdesaulniers). Changed prior to commit:

[PATCH] D156185: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of StringLiterals

efriedma accepted this revision. efriedma added a comment. This revision is now accepted and ready to land. I don't have any concern with this specific patch; LGTM Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156185/new/

[PATCH] D156185: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of StringLiterals

nickdesaulniers added a comment. In D156185#4533083 , @efriedma wrote: > No, that's taking the address of a string literal lvalue. ah! sorry, yeah `const char* foo = "foo";` vs `char foo[10] = "x";` That AST looks like: `-VarDecl 0x55eaf6075ba8

[PATCH] D156185: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of StringLiterals

efriedma added a comment. No, that's taking the address of a string literal lvalue. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156185/new/ https://reviews.llvm.org/D156185 ___ cfe-commits mailing

[PATCH] D156185: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of StringLiterals

nickdesaulniers added a comment. In D156185#4530163 , @efriedma wrote: >> so if you were concerned with arrays of string literals, we need this patch. > > Ohhh that's not what I meant by StringLiterals. I meant cases where the > string literal is

[PATCH] D156185: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of StringLiterals

efriedma added a comment. > so if you were concerned with arrays of string literals, we need this patch. Ohhh that's not what I meant by StringLiterals. I meant cases where the string literal is an rvalue, like `char foo[10] = "x";`. If it's an lvalue, we go through

[PATCH] D156185: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of StringLiterals

efriedma added a comment. > I guess I lost focus on the "struct or array part." Right... scalars weren't the concern for D76096 . They have much less overhead going through ExprConstant, and any evaluation of scalars isn't a regression because we currently

[PATCH] D156185: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of StringLiterals

nickdesaulniers added a comment. For this case in this patch in particular: extern const char* bar; const char* foo [] = { "hello", "goodbye", bar }; TranslationUnitDecl |-VarDecl col:20 used bar 'const char *' extern `-VarDecl line:2:13 foo 'const char *[3]'

[PATCH] D156185: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of StringLiterals

nickdesaulniers added a comment. In D156185#4530117 , @efriedma wrote: > We can do a whole bunch of these, but at some point we hit diminishing > returns... bailing out here isn't *that* expensive. Do you have some idea > how far you want to go with

[PATCH] D156185: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of StringLiterals

efriedma added a comment. We can do a whole bunch of these, but at some point we hit diminishing returns... bailing out here isn't *that* expensive. Do you have some idea how far you want to go with this? Adding a couple obvious checks like this isn't a big deal, but I don't want to build up

[PATCH] D156185: [clang][ConstExprEmitter] handle ArrayToPointerDecay ImplicitCastExpr of StringLiterals

nickdesaulniers created this revision. Herald added a project: All. nickdesaulniers requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Consider the following statement: const char* foo = "foo"; For the sub-AST: `-ImplicitCastExpr