[clang][NFC] Remove dead code

[wingo]

Summary

Remove code that has no effect in SemaType.cpp:processTypeAttrs.

[wingo]

Hi John, I am new to clang, having mostly worked on the WebAssembly target in llvm proper. I have a stack of patches related to address space treatment in codegen -- most of them NFC refactors to later allow the WebAssembly target to alloca in different address spaces. See https://lists.llvm.org/pipermail/cfe-dev/2021-July/068559.html for broader context. Would it be OK if I sent them your way? Cheers, Andy.

[rjmccall]

Hi, Andy. This patch is obviously okay, although it makes me wonder if it was introduced by a patch collision or something similar that needs closer attention. CC'ing Anastasia.

I'm not sure that I agree with your overall plan, though:

• The WebAssembly operand stack is not a good match for an address space at the language level because it's not addressable at all. If you can't meaningfully have a pointer into the address space, then you don't really need this in the type system; it's more like a declaration modifier at best.
• Allocating local variables on the operand stack ought to be a very straightforward analysis in the backend. There's not much optimization value in trying to do it in the frontend, and it's going to be problematic for things like coroutine lowering.
• The security argument seems pretty weak, not because security isn't important but because this is not really an adequate basis for getting the tamper-proof guarantee you want. For example, LLVM passes can and do introduce its own allocas and store scalars into them sometimes. Really you need some sort of "tamper-proof" *type* which the compiler can make an end-to-end guarantee of non-tamper-ability for the values of, and while optimally this would be implemented by just keeping values on the operand stack, in the general case you will need to have some sort of strategy for keeping things in memory.

[wingo]

Thanks for feedback! Following up on general question in D108464.

[wingo]

@Anastasia is this good to go for you or does this need closer attention?

[Anastasia]

In D108360#2962010, @wingo wrote:

@Anastasia is this good to go for you or does this need closer attention?

Yeah I agree that this code seems like a left-over from some refactoring as it seems to have no effect.

[Anastasia]

LGTM! Thanks!

clang/lib/Sema/SemaType.cpp

if (isa<AttributedType>(type) && attr.hasMacroIdentifier() &&
         attr.getKind() != ParsedAttr::AT_ObjCOwnership) {
       const IdentifierInfo *MacroII = attr.getMacroIdentifier();
       type = state.getSema().Context.getMacroQualifiedType(type, MacroII);
       state.setExpansionLocForMacroQualifiedType(
           cast<MacroQualifiedType>(type.getTypePtr()),
           attr.getMacroExpansionLoc());
     }
   }
-
-  if (!state.getSema().getLangOpts().OpenCL ||
-      type.getAddressSpace() != LangAS::Default)
-    return;
 }
 
 void Sema::completeExprArrayBound(Expr *E) {
   if (DeclRefExpr *DRE = dyn_cast<DeclRefExpr>(E->IgnoreParens())) {
     if (VarDecl *Var = dyn_cast<VarDecl>(DRE->getDecl())) {
       if (isTemplateInstantiation(Var->getTemplateSpecializationKind())) {
         auto *Def = Var->getDefinition();
         if (!Def) {