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
so it seems like the llvm::SourceMgr isn't completely necessary for
building a frontend?
~Craig
On Tue, Sep 7, 2021 at 1:06 AM lxsameer via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>>>
>>> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210907/c9e00f6c/attachment.html>