[cfe-dev] Semantic Analysis in Clang

[Mohammad Adil]

Let us say that I write some code which has some errors. Now I am reparsing
it. Can I halt the parsing when I encounter an error so that I can remedy
it? If so, what happens to the AST? I mean, does it break at that point or
does it contain the rest of the code too with some kind of substitution for
the error part?



On Fri, Jan 25, 2013 at 7:31 PM, Manuel Klimek <klimek at google.com> wrote:

> On Fri, Jan 25, 2013 at 2:57 PM, Mohammad Adil <madil90 at gmail.com> wrote:
>
>> I need to insert some code in the file being parser. I need to make sure
>> that the resulting file compiles fine. The code that I am inserting will
>> mostly be " ostream << type_x ;". Now before I do that, I need to ensure
>> that "type_x" has a stream operator defined. Is that possible any other
>> way? I am very grateful for your help.
>>
>
> What we do in the c++11 transition tools in clang-extra is:
> - parse
> - detect place to insert
> - insert
> - reparse, look for errors
>
> Whether that's viable depends on how big the chance is that you're making
> an error, and what fallbacks you have.
>
> Cheers,
> /Manuel
>
>
>
>>
>> Regards,
>> Adil
>>
>>
>> On Fri, Jan 25, 2013 at 6:34 PM, Manuel Klimek <klimek at google.com> wrote:
>>
>>> On Fri, Jan 25, 2013 at 1:13 PM, Mohammad Adil <madil90 at gmail.com>wrote:
>>>
>>>> Thanks for the reply. Well, here's the detailed problem. Once all the
>>>> syntax checking has been done, the next step before generating IR is to do
>>>> semantic analysis and type checking. Let us say that I encounter a code
>>>> like this:
>>>>
>>>> string b;
>>>> vector<T> a;
>>>> cout<<b;
>>>> cout<<a;
>>>>
>>>>       How does clang figure out that the 3rd statement is valid because
>>>> an operator for string exists, while the 4rth statement is not valid. More
>>>> specifically, I want to know how clang searches through all the operators
>>>> (or functions). I have to use this functionality. Does the clang api allow
>>>> me to do this easily or will I have to replicate this functionality?
>>>>
>>>
>>> As far as I know the clang API does not allow you to do that easily -
>>> you need the full semantic analysis state at that point during parsing, and
>>> as far as I'm aware this only exists implicitly in the Sema* classes.
>>> Overload resolution is one of those really complex and messy parts of C++ :)
>>>
>>> If you let us know what actual problem you're trying to solve, there
>>> might be solutions to that which are simpler than using overload resolution
>>> :)
>>>
>>> Cheers,
>>> /Manuel
>>>
>>>
>>>> Regards,
>>>> Adil
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jan 25, 2013 at 4:35 PM, Manuel Klimek <klimek at google.com>wrote:
>>>>
>>>>> On Thu, Jan 24, 2013 at 12:49 PM, madil90 <madil90 at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>    I am looking to perform some semantic analysis in clang. More
>>>>>> specifically, I want to know whether a function exists for a certain
>>>>>> type.
>>>>>> The function is global. e.g.
>>>>>>
>>>>>> String toString(A a);
>>>>>>
>>>>>>     I want to differentiate that this function exists for type A and
>>>>>> not for
>>>>>> type B. I have built an AST and am parsing it. How can I achieve this?
>>>>>> (Whenever I encounter a type)
>>>>>>
>>>>>
>>>>> I'd loop over all declarations of toString and see which type they
>>>>> take... Perhaps I'm misunderstanding your problem though :)
>>>>>
>>>>> Cheers,
>>>>> /Manuel
>>>>>
>>>>>
>>>>>> Regards,
>>>>>> Adil
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://clang-developers.42468.n3.nabble.com/Semantic-Analysis-in-Clang-tp4030012.html
>>>>>> Sent from the Clang Developers mailing list archive at Nabble.com.
>>>>>> _______________________________________________
>>>>>> cfe-dev mailing list
>>>>>> cfe-dev at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Mohammad Adil
>>>> LUMS SSE
>>>>
>>>
>>>
>>
>>
>> --
>> Mohammad Adil
>> LUMS SSE
>>
>
>


-- 
Mohammad Adil
LUMS SSE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130125/f3c8dd00/attachment.html>