<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 9, 2014 at 1:25 PM, Peter Stirling <span dir="ltr"><<a href="mailto:peter@pjstirling.plus.com" target="_blank">peter@pjstirling.plus.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
            <div>I think you can compute this more directly with
              inType->isIncompleteType().</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    Thanks for the suggestion, I hadn't seen that either. Unfortunately
    it doesn't work, for the same cases as getDefinition(), these are
    (from my test data):<br>
    <br>
      std::fpos<__mbstate_t > </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"> ... snip ...</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
      std::initializer_list<TagLib::String > </div></blockquote><div><br></div><div>I think these are just uninstantiated templates. We don't instantiate templates when you declare a function that takes a template specialization by value, for example, this code compiles:</div><div><div>template <typename T> struct MyVec;</div><div>void f(MyVec<int> v);</div></div><div><br></div><div>... but if you add a call to f, it will fail because it cannot complete MyVec<int> by instantiation:</div><div><div>void g(MyVec<int> &x) { f(x); }</div></div><div><br></div><div>For your use case, you probably need to call RequireCompleteType at the appropriate point. You may need to wait until the end of the TU if there are some circular dependencies.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I've
              also discovered that parsing code that calls a builtin
              function causes a no-argument, returns-int declaration to
              be inserted. It's been a while, but as I remember, in C
              this kind of declaration actually means that the function
              takes an unspecified number of arguments, but each one
              passed should be promoted to the size of an int (did they
              update this since pointers became much larger than ints?).
              In C++ it means something rather different. It seems a bit
              odd to me that builtin functions don't have the correct
              declaration inserted, since the compiler must have them on
              hand somewhere.<br>
            </blockquote>
            <div><br>
            </div>
            <div>Yes, in C, this is a no-prototype, implicit int return
              function. I'm not sure what kind of builtin function
              you're referring to. If the name starts with __builtin_,
              then the compiler knows the prototype. If it's a libc
              function like "fprintf()", then you will probably get a
              warning and the implicit declaration you describe. In C++,
              you shouldn't get these implicit declarations, it's just
              an error.</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    The functions that I've hit in my test data are:<br>
      __atomic_fetch_add();<br>
      __builtin_isfinite();<br>
      __builtin_isinf();<br>
      __builtin_isnan();<br>
      __builtin_isnormal();<br>
      __builtin_isgreater();<br>
      __builtin_isgreaterequal();<br>
      __builtin_isless();<br>
      __builtin_islessequal();<br>
      __builtin_islessgreater(); <br>
    <br>
    For all of the above FunctionDecl::getBuiltinID() returns non-zero.</div></blockquote><div><br></div><div>These are actually supposed to be variadic, according to the builtins table:</div><div><div>BUILTIN(__builtin_isunordered   , "i.", "nc")</div></div><div><br></div><div>They have custom type checking:</div><div><div>/// SemaBuiltinUnorderedCompare - Handle functions like __builtin_isgreater and</div><div>/// friends.  This is declared to take (...), so we have to check everything.</div><div>bool Sema::SemaBuiltinUnorderedCompare(CallExpr *TheCall) {</div></div></div></div></div>