What about adding some customizable hooks to the source manager to let users
tweak different aspect of it?
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, September 7th, 2021 at 2:23 AM, David Blaikie <dblaikie at
gmail.com> wrote:
> On Mon, Sep 6, 2021 at 5:21 PM lxsameer <lxsameer at lxsameer.com>
wrote:
>
> > I think a bit of pseudo code might be good to demonstrate roughly what
I had in mind:
> > ```
> > template <typename ConcreteType, template <typename T>
class... Traits>
> > class WithTrait : public Traits<ConcreteType>... {
> > protected:
> > WithTrait(){};
> > friend ConcreteType;
> > };
> >
> > template <typename ConcreteType, template <typename> class
TraitType>
> > class TraitBase {
> > protected:
> > ConcreteType &Object() { return static_cast<ConcreteType
&>(*this); };
> > };
> >
> > template <typename ConcreteType>
> > class SourceMgr : public TraitBase<ConcreteType, SourceMgr> {
> > public:
> > .... source mgr interface functions ....
> > };
> >
> > class DefaultSourceMgr : public WithTrait<DefaultSourceMgr,
SourceMgr> {
> > ..... implementation ....
> >
> > }
> > ```
> > 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.
>
> Yep yep. Not sure what the specific purpose of all the various abstractions
there would be, but get the gist of the architecture.
>
>
>
> > 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.
>
> 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.
>
>
>
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Tuesday, September 7th, 2021 at 1:03 AM, David Blaikie <dblaikie
at gmail.com> wrote:
> >
> > > On Mon, Sep 6, 2021 at 4:58 PM lxsameer <lxsameer at
lxsameer.com> wrote:
> > >
> > > > 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.
> > >
> > > Yeah, there's a fair bit of CRTP, and traits, but they are
different things
- https://www.internalpointers.com/post/quick-primer-type-traits-modern-cpp
discusses traits, for some details.
> > >
> > >
> > >
> > > > 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).
> > >
> > > 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?
> > >
> > > 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.
> > >
> > >
> > >
> > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > > On Tuesday, September 7th, 2021 at 12:50 AM, David Blaikie
<dblaikie at gmail.com> wrote:
> > > >
> > > > > On Mon, Sep 6, 2021 at 3:59 PM lxsameer via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> > > > >
> > > > > > Hey folks,
> > > > > >
> > > > > > Hope you're doing well.
> > > > > >
> > > > > > 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).
> > > > > >
> > > > > > 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.
> > > > > >
> > > > > > 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.
> > > > >
> > > > > I /think/ the C++ terminology that's a closer match
for what you're describing might be a "concept" rather than a
"trait"?
> > > > >
> > > > > 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?
> > > > >
> > > > > - Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210907/a807f858/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - lxsameer at lxsameer.com - 0x037C595D.asc
Type: application/pgp-keys
Size: 671 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210907/a807f858/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210907/a807f858/attachment.sig>