first wave of fixes for @encode sema support. This is part of PR3648.

The big difference here is that (like string literal) @encode has 
array type, not pointer type.

llvm-svn: 65391

1 files changed, 3 insertions, 1 deletions

diff --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index 3aea3e324ba..d551eac3006 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -478,7 +478,8 @@ Expr::isLvalueResult Expr::isLvalue(ASTContext &Ctx) const {
 
   // the type looks fine, now check the expression
   switch (getStmtClass()) {
-  case StringLiteralClass: // C99 6.5.1p4
+  case StringLiteralClass:  // C99 6.5.1p4
+  case ObjCEncodeExprClass: // @encode behaves like its string in every way.
     return LV_Valid;
   case ArraySubscriptExprClass: // C99 6.5.3p4 (e1[e2] == (*((e1)+(e2))))
     // For vectors, make sure base is an lvalue (i.e. not a function call).
@@ -829,6 +830,7 @@ bool Expr::isConstantInitializer(ASTContext &Ctx) const {
   switch (getStmtClass()) {
   default: break;
   case StringLiteralClass:
+  case ObjCEncodeExprClass:
     return true;
   case CompoundLiteralExprClass: {
     // This handles gcc's extension that allows global initializers like