llvm dev - Sep 2021 - Extending the SouceMgr

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/20210906/56aa4b0f/attachment.html>

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.

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).

‐‐‐‐‐‐‐ 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/20210906/9be4c649/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/20210906/9be4c649/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/20210906/9be4c649/attachment.sig>