[LLVMbugs] [Bug 16613] New: Type diffing should not expand (& should maybe even contract) types to canonical form where possible
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Fri Jul 12 14:10:42 PDT 2013
http://llvm.org/bugs/show_bug.cgi?id=16613
Bug ID: 16613
Summary: Type diffing should not expand (& should maybe even
contract) types to canonical form where possible
Product: clang
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: C++
Assignee: unassignedclangbugs at nondot.org
Reporter: dblaikie at gmail.com
CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu,
rtrieu at google.com
Classification: Unclassified
Given:
template<typename T>
class foo {
};
void func(foo<std::string>);
int main() {
foo<const std::string> f;
func(f);
}
Clang prints the expanded (& then abbreviated with [...]) form of the type in
the type diff'd diagnostic:
"candidate function not viable: no known conversion from 'foo<const
basic_string<[...]>>' to 'foo<basic_string<[...]>>' for 1st argument"
It would be nice if we could print "foo<std::string>" here.
I'm not sure if it's the right thing to do, but even better would be if one of
the types was canonical & the other wasn't, but they were the same actual type,
we could still print the shorter, non-canonical type out.
(this comes from some callback-like code with type deduction:
void func(std::string);
callback<const std::string&> c = MakeCallback(func); // MakeCallback's type
uses type deduction & presumably ends up with the raw canonical type, not
std::string so even without template type diffing we print out the expanded
type rather than the std::string typedef
)
The "aka" (provided in cases where template type diffing doesn't trigger) is
useful but I fear it's noisier than necessary in many cases - especially when
the same sugared type is used on both sides of a type diff (in which case we
could at least provide a single aka, rather than redundantly print it on both
sides)
--
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/20130712/5f5d27df/attachment.html>
More information about the llvm-bugs
mailing list