[cfe-dev] Finding function declaration?

[Ben Laurie]

On 16 May 2015 at 16:15, Manuel Klimek <klimek at google.com> wrote:

> On Thu, May 14, 2015 at 3:46 PM Ben Laurie <benl at google.com> wrote:
>
>> On 14 May 2015 at 14:43, Manuel Klimek <klimek at google.com> wrote:
>>
>>> Ah, wrong parent map :) the ast context has a function to retrieve
>>> parents that supports crossing into decls. I can look up the details when
>>> I'm back at a real computer ...
>>>
>>
>> Ah! Thanks.
>>
>
> You can get the ASTContext from the CheckerContext, and then call
> getParents() on it.
>

Mildly puzzled why there might be multiple parents, but in any case, it
works, thanks.


>
> Also cc'ing Anna and Jordan, who might have better ideas how to capture
> context info from a static analyzer check.
>
>
>>
>>
>>> BTW do you need the symbolic execution engine for what you want to
>>> check? If the ast is enough consider using a clang-tidy check, those are a
>>> bit simpler to write with the ast matchers.
>>>
>>
>> I do need symbolic execution.
>>
>>
>>>
>>> On Thu, May 14, 2015, 1:20 PM Ben Laurie <benl at google.com> wrote:
>>>
>>>> Manuel asked me for more info.
>>>>
>>>> Given a checker like this:
>>>>
>>>> class MyChecker :
>>>>     public Checker< check::PreStmt<ReturnStmt> > {
>>>> public:
>>>>   void checkPreStmt(const ReturnStmt *RS, CheckerContext &C) const;
>>>> };
>>>>
>>>> void MyChecker::checkPreStmt(const ReturnStmt *RS,
>>>>      CheckerContext &C) const {
>>>>   RS->dump();
>>>>
>>>>   const Stmt *s = RS;
>>>>
>>>>   ParentMap &PM = C.getLocationContext()->getParentMap();
>>>>
>>>>   while ((s = PM.getParent(s)) != NULL) {
>>>>     std::cerr << "------\n";
>>>>     s->dump();
>>>>   }
>>>> }
>>>>
>>>> And this as input:
>>>>
>>>> int f(void)
>>>>     {
>>>>     return 1;
>>>>     }
>>>>
>>>>
>>>> This is the output:
>>>>
>>>> ReturnStmt 0x807cbdda8
>>>> `-IntegerLiteral 0x807cbdd88 'int' 1
>>>> ------
>>>> CompoundStmt 0x807cbddc0
>>>> `-ReturnStmt 0x807cbdda8
>>>>   `-IntegerLiteral 0x807cbdd88 'int' 1
>>>>
>>>> As you can see, it terminates at the function body, not the declaration.
>>>>
>>>>
>>>> On 14 May 2015 at 07:03, Ben Laurie <benl at google.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 11 May 2015 at 11:20, Manuel Klimek <klimek at google.com> wrote:
>>>>>
>>>>>> On Sun, May 10, 2015 at 11:54 PM Nikola Smiljanic <popizdeh at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I think you'll need to use ParentMap from ASTContext.
>>>>>>>
>>>>>>
>>>>>> Note that the parent-map is lazy-built (that is, the first time you
>>>>>> get a parent, you build the parent-map for the whole TU), and thus has a
>>>>>> pretty high cost. Usually we first try to get away with not using it.
>>>>>>
>>>>>> Can you give a bit more context on what you're trying to do?
>>>>>>
>>>>>
>>>>> Sorry for delay ... I am trying to label functions to have certain
>>>>> checks done on their return values if an attribute is set on the function.
>>>>>
>>>>> ParentMap appears not to work for this case (it stops finding parents
>>>>> once you have the function body).
>>>>>
>>>>> Currently, the only way I could make this work was to construct a map
>>>>> of function bodies that have the attribute set in an AST observer, and then
>>>>> using ParentMap to get back to the body, which is looked up in the map.
>>>>>
>>>>> Doesn't seem optimal!
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> On Mon, May 11, 2015 at 4:18 AM, Ben Laurie <benl at google.com> wrote:
>>>>>>>
>>>>>>>> If I have a checker for check::PreStmt<ReturnStmt>, how do I get
>>>>>>>> from
>>>>>>>> the ReturnStmt to the function it is part of (I want to check
>>>>>>>> attributes on that function)?
>>>>>>>> _______________________________________________
>>>>>>>> cfe-dev mailing list
>>>>>>>> cfe-dev at cs.uiuc.edu
>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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/20150517/9e6435af/attachment.html>