<div>AFAIK the clang implementation is older and the aim is to use the llvm one instead (based on a similar discussion on IRC). But I think if it is internal to the llvm it's better to mention that explicitly in the docs and maybe even remove it from code examples and tutorials. wdyt?<br></div><div class="protonmail_signature_block protonmail_signature_block-empty"><div class="protonmail_signature_block-user protonmail_signature_block-empty"></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"></div></div><div><br></div><div class="protonmail_quote"><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Tuesday, September 7th, 2021 at 7:44 PM, David Blaikie <dblaikie@gmail.com> wrote:<br></div></div><div><br></div><blockquote class="protonmail_quote" type="cite">
<div dir="ltr">I think llvm's SourceMgr is mostly implemented for LLVM's own internal needs (TableGen and the integrated assembler - maybe some others?) & /probably/ isn't the right foundation for more high level language frontends (as seen by Clang having it's own SourceManager, not trying to use llvm's SourceMgr).</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 7, 2021 at 11:29 AM lxsameer <<a href="mailto:lxsameer@lxsameer.com" rel="noreferrer nofollow noopener">lxsameer@lxsameer.com</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>I can see that it used in many places through out the source code. <br></div><div><br></div><div>IMHO the concept of source manager is necessary but since the `llvm::sourcemgr` is made in a certain way and at the same time it's not possible to extend the `llvm::SourceMgr`, frontends will try to make their own. So if the `llvm::SourceMgr` at the current state can't deliver enough that frontends can take benefit from and they have to write their own any way, then that raises the question of what is the purpose of `llvm::SourceMgr` ? Logically speaking, I think the source manager need to have a generic api with a mechanism to let the frontend tweak its behavior based on their set of requirement. <br></div><div><br></div><div>The source manager concept seems to be quite common among frondends and I think everyone can benefit from a better implementation,<br></div><div><div></div><div></div></div><div><br></div><div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Tuesday, September 7th, 2021 at 4:55 PM, Craig Topper <<a target="_blank" href="mailto:craig.topper@gmail.com" rel="noreferrer nofollow noopener">craig.topper@gmail.com</a>> wrote:<br></div></div><div><br></div><blockquote type="cite">
<div dir="ltr">Are there many llvm APIs that take a SourceMgr? The main ones I see are YAML parsing and some backend diagnostic stuff, but I admit I didn't look very hard. Clang has its own SourceManager class that is independent of llvm's <div>so it seems like the llvm::SourceMgr isn't completely necessary for building a frontend?</div><div><br clear="all"><div><div dir="ltr">~Craig</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 7, 2021 at 1:06 AM lxsameer via llvm-dev <<a target="_blank" rel="noreferrer nofollow noopener" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>What about adding some customizable hooks to the source manager to let users tweak different aspect of it?<br></div><div><div></div><div></div></div><div><br></div><div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Tuesday, September 7th, 2021 at 2:23 AM, David Blaikie <<a target="_blank" rel="noreferrer nofollow noopener" href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div></div><div><br></div><blockquote type="cite">
<div dir="ltr"><div dir="ltr">On Mon, Sep 6, 2021 at 5:21 PM lxsameer <<a target="_blank" href="mailto:lxsameer@lxsameer.com" rel="noreferrer nofollow noopener">lxsameer@lxsameer.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>I think a bit of pseudo code might be good to demonstrate roughly what I had in mind:<br></div><div>```<br></div><div>template <typename ConcreteType, template <typename T> class... Traits><br></div><div>class WithTrait : public Traits<ConcreteType>... {<br></div><div>protected:<br></div><div> WithTrait(){};<br></div><div> friend ConcreteType;<br></div><div>};<br></div><div><br></div><div>template <typename ConcreteType, template <typename> class TraitType><br></div><div>class TraitBase {<br></div><div>protected:<br></div><div> ConcreteType &Object() { return static_cast<ConcreteType &>(*this); };<br></div><div>};<br></div><div><br></div><div>template <typename ConcreteType><br></div><div>class SourceMgr : public TraitBase<ConcreteType, SourceMgr> {<br></div><div>public:<br></div><div> .... source mgr interface functions ....<br></div><div>};<br></div><div><br></div><div>class DefaultSourceMgr : public WithTrait<DefaultSourceMgr, SourceMgr> {<br></div><div>..... implementation ....<br></div><div><div></div><div></div></div><div>}<br></div><div>```<br></div><div>This way function that want to use SourceMgr would need a template but that template can be defaulted to `DefaultSourceMgr`. I hope I could demonstrate my thoughts clear enough.<br></div></blockquote><div><br>Yep yep. Not sure what the specific purpose of all the various abstractions there would be, but get the gist of the architecture.<br> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>As for the functionality I need in the sourcemgr, my compiler uses namespaces as the center piece and the unit of compilation, i want my source manager to accept a namespace name and load the source code of that namespace. At the moment I had to copy paste the llvm::SourceMgr and manually tweak it.</div></blockquote><div><br>Perhaps there's something narrower that could be added directly to the existing SourceMgr (perhaps something fairly general/not specific to the particular features you're designing for, but addressing whatever in SourceMgr doesn't make it suitable for that direction/gets in the way)? I suspect if the extension is too invasive that way, or such that it would require the kind of abstraction/templates suggested above - it might be that SourceMgr isn't a great foundation for the functionality you're building.<br> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div> <br></div><div><br></div><div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Tuesday, September 7th, 2021 at 1:03 AM, David Blaikie <<a target="_blank" href="mailto:dblaikie@gmail.com" rel="noreferrer nofollow noopener">dblaikie@gmail.com</a>> wrote:<br></div></div><div><br></div><blockquote type="cite">
<div dir="ltr"><div dir="ltr">On Mon, Sep 6, 2021 at 4:58 PM lxsameer <<a target="_blank" rel="noreferrer nofollow noopener" href="mailto:lxsameer@lxsameer.com">lxsameer@lxsameer.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Sorry about the terminology, I was thinking about CRTP style traits. I see CRTP based classes and templates quite often it the LLVM source code.</div></blockquote><div><br>Yeah, there's a fair bit of CRTP, and traits, but they are different things - <a target="_blank" rel="noreferrer nofollow noopener" href="https://www.internalpointers.com/post/quick-primer-type-traits-modern-cpp">https://www.internalpointers.com/post/quick-primer-type-traits-modern-cpp</a> discusses traits, for some details.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>So I think the current SourceMgr can be renamed to something like `DefaultSourceManager` that implement the `SourceMgr` CRTP trait ( sorry I don't know the exact term here).</div></blockquote><div><br>I'm still a bit unclear on how the existing SourceMgr-using code would work - it'd have to be updated to be templated on the specific SourceMgr implementation in use, would it? Some other ideas?<br><br>Might be worth a more narrowly defined discussion about what extensibility/features you're looking for in SourceMgr, without the need to create a whole new hierarchy.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> <br></div><div><div></div><div></div></div><div><br></div><div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Tuesday, September 7th, 2021 at 12:50 AM, David Blaikie <<a target="_blank" rel="noreferrer nofollow noopener" href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div></div><div><br></div><blockquote type="cite">
<div dir="ltr"><div dir="ltr">On Mon, Sep 6, 2021 at 3:59 PM lxsameer via llvm-dev <<a target="_blank" href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer nofollow noopener">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Hey folks,<br>
Hope you're doing well. <br>
<br>
<br>
It seems to me that it is not possible to extend the current behavior of `llvm::SourceMgr` (at least I couldn't think of any solution) and it is quite C/C++ish ( for lack of a better word).<br>
<br>
For my use case, I need to tweak it a little bit and since there is now way to do that, I have to write my own which means I'm going to lose the ability to use any llvm api that expect a source manager and that's a big price to pay.<br>
<br>
It seems that the source manger will benefits from a trait like design. This way, any front end that need a customized source manager can easily do that and the current source manager would be an implementation of that trait.<br></blockquote><div><br>I /think/ the C++ terminology that's a closer match for what you're describing might be a "concept" rather than a "trait"?<br><br>But then, if I'm understanding correctly, all the code that currently is written in terms of the SourceMgr would have to become a template so it can be used by different implementations of the SourceMgr concept? That, at first guess, seems unlikely/infeasible?<br><br></div><div> - Dave</div></div></div>
</blockquote></blockquote></div></div>
</blockquote></blockquote></div></div>
</blockquote>_______________________________________________<br>
LLVM Developers mailing list<br>
<a target="_blank" rel="noreferrer nofollow noopener" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a target="_blank" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer nofollow noopener">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></blockquote></div>
</blockquote>