[llvm-testresults] buildbot failure in llvm on clang-x86_64-linux-selfhost-rel

[John McCall]

On Aug 27, 2011, at 8:53 AM, Douglas Gregor wrote:

> 
> On Aug 27, 2011, at 8:46 AM, Andrew Trick wrote:
> 
>> My revert doesn't help. I'm suspecting this is John's change?
>> 
>> llvm[3]: Compiling APIntTest.cpp for Release+Asserts build
>> /build/buildbot-llvm/clang-x86_64-linux-selfhost-rel/llvm.src/unittests/VMCore/InstructionsTest.cpp:35:13: error: calling a private constructor of class 'llvm::Use'
>>   EXPECT_EQ(*b, One);
> Yeah, it's probably John's r138691.

Interesting.  gtest has a metaprogramming hack:
  char IsNullLiteralHelper(Secret* p);
  char (&IsNullLiteralHelper(...))[2];  // NOLINT
to which we are passing a llvm::Use l-value:
  #define EXPECT_EQ(expected, actual) \
    EXPECT_PRED_FORMAT2(::testing::internal:: \
                        EqHelper<GTEST_IS_NULL_LITERAL_(expected)>::Compare, \
                        expected, actual)
...
  Constant* One = ConstantInt::get(Int1, 1, true);
  const ReturnInst* r1 = ReturnInst::Create(C, One);
  EXPECT_EQ(r1->getNumOperands(), 1U);
  User::const_op_iterator b(r1->op_begin());
  EXPECT_NE(b, r1->op_end());
  EXPECT_EQ(*b, One);

We're expecting an implicit conversion from llvm::Use& to llvm::User*, and that does happen for the actual equality test, but not in this metaprogramming code.

On the one hand, this is actually a source bug on a couple levels:  first, passing something through varargs does generally require copying it, and second, we're passing reversed arguments to EXPECT_EQ.  On the other hand, I'm creeped out by the fact that nobody else seems to diagnose this.  Maybe because it's in an unevaluated context?

I'll fix the test and we can separately decide on a policy for when to diagnose this.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-testresults/attachments/20110827/d25c2137/attachment.html>