[cfe-dev] Further AST spelunking

[Peter Stirling]

Never-mind, CompilerInstance::getSema()

On 11/10/14 20:17, Peter Stirling wrote:
> How do I get access to Sema, from a FrontendAction/ASTConsumer?
>
> On 09/10/14 21:40, Reid Kleckner wrote:
>> On Thu, Oct 9, 2014 at 1:25 PM, Peter Stirling 
>> <peter at pjstirling.plus.com <mailto: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) {
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141011/1ee44364/attachment.html>