[LLVMbugs] [Bug 18830] New: Truly atrocious diagnostic for missing typename inside gtest's EXPECT_EQ
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Thu Feb 13 10:55:58 PST 2014
http://llvm.org/bugs/show_bug.cgi?id=18830
Bug ID: 18830
Summary: Truly atrocious diagnostic for missing typename inside
gtest's EXPECT_EQ
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Frontend
Assignee: unassignedclangbugs at nondot.org
Reporter: rnk at google.com
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
Created attachment 12058
--> http://llvm.org/bugs/attachment.cgi?id=12058&action=edit
diagnostic output
A missing typename resulted in a 227 lines of output, 6 errors, and ~10 notes
for each error. Output attached. We have this code in our DenseMap unittest:
TYPED_TEST(DenseMapTest, EmptyIntMapTest) {
// Size tests
EXPECT_EQ(0u, this->Map.size());
EXPECT_TRUE(this->Map.empty());
// Iterator tests
EXPECT_TRUE(this->Map.begin() == this->Map.end());
// Lookup tests
EXPECT_FALSE(this->Map.count(this->getKey()));
EXPECT_TRUE(this->Map.find(this->getKey()) == this->Map.end());
#ifndef _MSC_VER
EXPECT_EQ(typename TypeParam::mapped_type(),
this->Map.lookup(this->getKey()));
#else
// MSVC, at least old versions, cannot parse the typename to disambiguate
// TypeParam::mapped_type as a type. However, because MSVC doesn't implement
// two-phase name lookup, it also doesn't require the typename. Deal with
// this mutual incompatibility through specialized code.
EXPECT_EQ(TypeParam::mapped_type(),
this->Map.lookup(this->getKey()));
#endif
}
When I compiled this with clang-cl, _MSC_VER is defined, so we didn't have the
typename.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140213/f9aebd09/attachment.html>
More information about the llvm-bugs
mailing list