[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


            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


template<typename T>
class foo {

void func(foo<std::string>);

int main() {
  foo<const std::string> 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

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