<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 31, 2014 at 6:33 PM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="">On Sunday 31 August 2014 03:51:02 Aleix Pol wrote:<br>
> Hi,<br>
> I've just realized that there's some kind of omnipresent concept in the<br>
> DUChain called "ParseSession".<br>
<br>
</div>Yes, and there was at one point even a ParseSession implementation in<br>
KDevplatform but it doesn't make any sense. The ParseSession is extremely<br>
language dependent. Think of it as a concept, vs. an interface with virtual<br>
functions.<br>
<div class=""><br>
> All language implementations I've looked at implement it but then it's not<br>
> documented anywhere (AFAIK). I've been looking through the code further,<br>
> then I realized there's the AbstractUseBuilder header file. This one<br>
> instantiates some ParseSession as a template argument and does weird things<br>
> with it [1]. And by weird things, I mean Adding an attribute called<br>
> m_mapAst and then expecting the availability of an API such as:<br>
> LanguageSpecificUseBuilderBase::editor()->parseSession()->mapAstUse.<br>
<br>
</div>Yes, it's a concept there is also afaik some more API like finding ranges<br>
which is essential.<br>
<div class=""><br>
> I don't really think this is acceptable API. Or maybe it's just that I<br>
> don't feel like implementing a ParseSession concept in my plugin only<br>
> because of that, so I would like to have your feedback.<br>
><br>
> As a naïve suggestion, alternatively this API should be added to the<br>
> UseBuilder, both the mapAst attribute and the mapAstUse could be specified<br>
> within the AbstractUseBuilder. If the implementation decides to call a<br>
> ParseSession indoors, then it stays as an implementation detail.<br>
<br>
</div>Yes, that could work. But actually, from our (Olivier JG and my) POV, we<br>
should get rid of most of the Abstract*Builder and instead get a list of<br>
helper functions. Take a look at kdev-clang which already builds the whole<br>
cache without using the Abstract*Builder stuff _at all_. These builders are<br>
deceptively easy to use and you think "oh so much code that can be shared,<br>
cool". While actually, most of the code there is crap.<br>
<br>
You are working on the CMake language stuff, right? If possible, don't use the<br>
Abstract*Builders. Just iterate over your AST and create contexts,<br>
declarations and uses as you go, manually. It's not too hard actually.<br>
<div class=""><br>
> Good night and happy hacking!<br>
> Aleix<br>
<br>
</div>You too.<br>
<br>
> [1]<br>
> <a href="https://www.nerdist.com/wp-content/uploads/2014/05/shia-labeouf-magic-gif.gi" target="_blank">https://www.nerdist.com/wp-content/uploads/2014/05/shia-labeouf-magic-gif.gi</a><br>
> f<br>
<br>
Magic :)<br></blockquote><div><br></div><div>Fair enough, it's what cmake used to do anyway. Will try to make a custom UseBuilder directly.</div><div><br></div><div>Thanks!</div><div>Aleix</div><div><br></div><div>PS: What about deprecating the builders API then? :D</div>

<div><a href="http://i0.kym-cdn.com/photos/images/original/000/165/945/444.gif">http://i0.kym-cdn.com/photos/images/original/000/165/945/444.gif</a> </div><div><br></div></div></div></div>