[cfe-commits] [PATCH] Explicitly Build __builtin_va_list
Douglas Gregor
dgregor at apple.com
Fri Jun 15 11:42:00 PDT 2012
On Jun 14, 2012, at 10:12 AM, Jordan Rose wrote:
> I like it! All I have are some nitpicks:
>
> + /// getBuiltinVaListKind - Returns the kind of __builtin_va_list
> + /// type that should be implemented by this target.
>
> s/implemented by/used with/, perhaps? The target isn't doing the implementing.
>
>
> + switch (Kind) {
> + default: llvm_unreachable("Unhandled builtin type kind");
>
> Please put the llvm_unreachable outside the switch so that -Wswitch can give us warnings but GCC still won't whine at us.
>
>
> + if (!BuiltinVaListDecl) {
> + BuiltinVaListDecl = CreateVaListDecl(this, Target->getBuiltinVaListKind());
> + }
>
> Spurious {}, according to the LLVM coding style.
>
>
> + if (Context.getBuiltinVaListDecl())
> + DeclIDs[Context.getBuiltinVaListDecl()] = PREDEF_DECL_BUILTIN_VA_LIST_ID;
> +
>
> Because you're using the accessor, you're forcing construction of the type. Either add a ShouldCreate flag (that can default to true) or access the instance variable directly like the other decls.
Right; just poke at the instance variable directly, because that's what we're doing for the others.
> Again, I'm not an expert on this part of the code, so at least Doug should get a chance to review it before it goes in.
>
> There's a bunch of other code that works around the existing __builtin_va_list hack besides r158085, but some of that may still need to exist since it can still show up in the TU. (But hopefully only when requested now.) Both the __int128 decls and the __builtin_va_list decls should probably be marked Implicit, as tested for in DeclPrinter.cpp.
Yes, they should be marked implicit. That'll keep a number of other places in the code from treating them as user-written code.
Patch looks great. Please feel free to commit once you've addressed Jordan's comments, thanks!
- Doug
More information about the cfe-commits
mailing list