[cfe-dev] Lazily parsing additional source files

[Richard Smith]

On Mon, May 26, 2014 at 8:16 AM, Gábor Horváth <xazax.hun at gmail.com> wrote:

> Hi!
>
> Do you know, if the module system is also capable to handle not self
> contained modules? So is it possible to use the type information from the
>  translation unit that is being parsed and compile and load a module that
> contains no type definitions (assuming all the required type information is
> available in the translation unit at the point when the module needs to be
> loaded).
>

It'd theoretically be possible (you could take your existing AST, emit it
as a module, then build another module starting with an import of the first
one), but I'm not really sure what the benefit would be. You wouldn't be
able to reuse the things you parsed, since they depend on the particular
translation unit you're within.

It sounds like all you really want is to parse, then, at the end of the
translation unit, scan the parsed translation unit for declarations that
you'd like to implicitly define, and parse those declarations. Something
similar to injecting a '#pragma clang define_needed_decls' at the end of
the TU and teaching the lexer to translate that pragma into the right set
of #includes would seem reasonable. (You'll need to be a little careful
that lookahead doesn't cause you to pick too few things, but other than
that it should be OK.)


> Thanks,
> Gábor
>
>
> On 23 May 2014 16:50, Manuel Klimek <klimek at google.com> wrote:
>
>> +richardsmith, the C++-modules-man
>>
>> On Fri, May 23, 2014 at 4:45 PM, Gábor Horváth <xazax.hun at gmail.com>wrote:
>>
>>> Thanks, that is a good point. Do yo know what is the current status of
>>> module support for C++? Is it mature enough to be used? If not mature
>>> enough yet is it worth for me to start working on it (so it is less effort
>>> to make them work with regular translation units than creating my own lazy
>>> parsing logic)?
>>>
>>
>> I assume it's stable for C/Obj-C, as that's what Apple uses it for
>> (afaik). Richard is currently making lots of progress on getting it ready
>> for C++.
>>
>> It just seems to me like adding a second way to lazily pull in parts of
>> the AST would be a waste of engineering time (and very hard to do without
>> the change in language restrictions that modules impose).
>>
>> Cheers,
>> /Manuel
>>
>>
>>
>>>
>>> Cheers,
>>> Gábor
>>>
>>>
>>> On 23 May 2014 16:10, Manuel Klimek <klimek at google.com> wrote:
>>>
>>>> On Mon, May 19, 2014 at 8:37 PM, Gábor Horváth <xazax.hun at gmail.com>wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> I am working on a Google Summer of Code project to improve the Clang
>>>>> Static Analyzer. In that project it would be essential to parse external
>>>>> source files and inject AST into the translation unit that is being
>>>>> compiled. The external files would contain definitons that are being looked
>>>>> up. The goal would be to avoid runtime cost if no lookup is required. So
>>>>> basicly I want to add new code lazily to an existing AST after parsing is
>>>>> done by injecting new source code.
>>>>>
>>>>
>>>> Isn't that exactly what modules solve?
>>>>
>>>> Cheers,
>>>> /Manuel
>>>>
>>>>
>>>>>
>>>>> Moreover some type information may not be available in those external
>>>>> source files, so type information in the translation unit that is being
>>>>> analyzed should be utilized.
>>>>>
>>>>> What do you think, what would be the most efficient and elegant way to
>>>>> approach this problem?
>>>>>
>>>>> Thanks in advance,
>>>>> Gábor
>>>>>
>>>>> _______________________________________________
>>>>> 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/20140526/fa383420/attachment.html>