[Attr] Fix pointer_with_type_tag assert fail for variadic

[aaron.ballman]

LGTM, thank you for the fix!

[jdenny]

Hi Aaron. Thanks for accepting. I do not have commit privileges. Would
you please commit this (and any other patches you accept) for me?

[aaron.ballman]

Why is this dependent on D43248?

[aaron.ballman]

In D43747#1018814, @jdenny wrote:

Hi Aaron. Thanks for accepting. I do not have commit privileges. Would
you please commit this (and any other patches you accept) for me?

I'm happy to do so. Just to double-check though, there's nothing about this patch that actually relies on functionality in D43248, correct?

[jdenny]

In D43747#1018824, @aaron.ballman wrote:

In D43747#1018814, @jdenny wrote:

Hi Aaron. Thanks for accepting. I do not have commit privileges. Would
you please commit this (and any other patches you accept) for me?

I'm happy to do so. Just to double-check though, there's nothing about this patch that actually relies on functionality in D43248, correct?

Right. The dependency is in the other direction.

[aaron.ballman]

Committed in r326057.

If you're not already on IRC, I would recommend joining the #llvm channel on OFTC so that you can watch for build break notifications from the build bots.

[jdenny]

In D43747#1018844, @aaron.ballman wrote:

Committed in r326057.

If you're not already on IRC, I would recommend joining the #llvm channel on OFTC so that you can watch for build break notifications from the build bots.

Thanks. Can your recommend effective ways to make use of this? Do developers just stay logged in all day to catch failures relevant to their work?

[aaron.ballman]

In D43747#1021209, @jdenny wrote:

In D43747#1018844, @aaron.ballman wrote:

Committed in r326057.

If you're not already on IRC, I would recommend joining the #llvm channel on OFTC so that you can watch for build break notifications from the build bots.

Thanks. Can your recommend effective ways to make use of this? Do developers just stay logged in all day to catch failures relevant to their work?

Generally, yes. Some folks will even go so far as to set up IRC bouncers to capture messages while their host machine is asleep and no longer connected (but this is by no means required). The key thing is: most build bots send out an email if a commit breaks the build, but not all bots do (some only send to IRC) and that email goes to whoever is on the commit list. So if you make commits or have someone commit something on your behalf, being in the IRC channel can help you quickly fix issues. However, if you're not on the IRC channel, someone else will help make sure you get notified if something goes wrong, so being in IRC isn't required.

[jdenny]

In D43747#1021234, @aaron.ballman wrote:

In D43747#1021209, @jdenny wrote:

In D43747#1018844, @aaron.ballman wrote:

Committed in r326057.

If you're not already on IRC, I would recommend joining the #llvm channel on OFTC so that you can watch for build break notifications from the build bots.

Thanks. Can your recommend effective ways to make use of this? Do developers just stay logged in all day to catch failures relevant to their work?

Generally, yes. Some folks will even go so far as to set up IRC bouncers to capture messages while their host machine is asleep and no longer connected (but this is by no means required). The key thing is: most build bots send out an email if a commit breaks the build, but not all bots do (some only send to IRC) and that email goes to whoever is on the commit list. So if you make commits or have someone commit something on your behalf, being in the IRC channel can help you quickly fix issues. However, if you're not on the IRC channel, someone else will help make sure you get notified if something goes wrong, so being in IRC isn't required.

Makes sense. Thanks for the tips.

lib/Sema/SemaDeclAttr.cpp

static void handleArgumentWithTypeTagAttr(Sema &S, Decl *D,
   uint64_t TypeTagIdx;
   if (!checkFunctionOrMethodParameterIndex(S, D, AL, 3, AL.getArgAsExpr(2),
                                            TypeTagIdx))
     return;
 
   bool IsPointer = AL.getName()->getName() == "pointer_with_type_tag";
   if (IsPointer) {
     // Ensure that buffer has a pointer type.
-    QualType BufferTy = getFunctionOrMethodParamType(D, ArgumentIdx);
-    if (!BufferTy->isPointerType()) {
+    if (ArgumentIdx >= getFunctionOrMethodNumParams(D) ||
+        !getFunctionOrMethodParamType(D, ArgumentIdx)->isPointerType())
       S.Diag(AL.getLoc(), diag::err_attribute_pointers_only)
           << AL.getName() << 0;
-    }
-  }
 
   D->addAttr(::new (S.Context) ArgumentWithTypeTagAttr(
       AL.getRange(), S.Context, AL.getArgAsIdent(0)->Ident, ArgumentIdx,
       TypeTagIdx, IsPointer, AL.getAttributeSpellingListIndex()));
 }
 
 static void handleTypeTagForDatatypeAttr(Sema &S, Decl *D,
                                          const AttributeList &AL) {

test/Sema/warn-type-safety.c

 int wrong8(void *buf, MPI_Datatype datatype)
     __attribute__(( pointer_with_type_tag(mpi,1,x) )); // expected-error {{attribute requires parameter 3 to be an integer constant}}
 
 int wrong9 __attribute__(( pointer_with_type_tag(mpi,1,2) )); // expected-error {{'pointer_with_type_tag' attribute only applies to non-K&R-style functions}}
 
 int wrong10(double buf, MPI_Datatype type)
     __attribute__(( pointer_with_type_tag(mpi,1,2) )); // expected-error {{'pointer_with_type_tag' attribute only applies to pointer arguments}}
 
+int ok11(void *, ...)
+    __attribute__(( pointer_with_type_tag(mpi,1,2) ));
+int wrong11(void *, ...)
+    __attribute__(( pointer_with_type_tag(mpi,2,3) )); // expected-error {{'pointer_with_type_tag' attribute only applies to pointer arguments}}
 
 extern struct A datatype_wrong1
     __attribute__(( type_tag_for_datatype )); // expected-error {{'type_tag_for_datatype' attribute requires parameter 1 to be an identifier}}
 
 extern struct A datatype_wrong2
     __attribute__(( type_tag_for_datatype(mpi,1,2) )); // expected-error {{expected a type}}
 
 extern struct A datatype_wrong3