[cfe-dev] Further AST spelunking

[Reid Kleckner]

On Thu, Oct 9, 2014 at 1:25 PM, Peter Stirling <peter at pjstirling.plus.com>
wrote:
>
> I think you can compute this more directly with inType->isIncompleteType().
>
>
> 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):
>
>   std::fpos<__mbstate_t >
>
 ... snip ...
>
  std::initializer_list<TagLib::String >
>

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:
template <typename T> struct MyVec;
void f(MyVec<int> v);

... but if you add a call to f, it will fail because it cannot complete
MyVec<int> by instantiation:
void g(MyVec<int> &x) { f(x); }

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.

> 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.
>>
>
>  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.
>
>
> The functions that I've hit in my test data are:
>   __atomic_fetch_add();
>   __builtin_isfinite();
>   __builtin_isinf();
>   __builtin_isnan();
>   __builtin_isnormal();
>   __builtin_isgreater();
>   __builtin_isgreaterequal();
>   __builtin_isless();
>   __builtin_islessequal();
>   __builtin_islessgreater();
>
> For all of the above FunctionDecl::getBuiltinID() returns non-zero.
>

These are actually supposed to be variadic, according to the builtins table:
BUILTIN(__builtin_isunordered   , "i.", "nc")

They have custom type checking:
/// SemaBuiltinUnorderedCompare - Handle functions like __builtin_isgreater
and
/// friends.  This is declared to take (...), so we have to check
everything.
bool Sema::SemaBuiltinUnorderedCompare(CallExpr *TheCall) {
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141009/df768377/attachment.html>