[cfe-dev] Custom C++ extension

[mats petersson]

I have my own Pascal compiler frontend. So I need to keep up with API
changes in the LLVM API, but not the Clang changes. I don't do what
Marcello suggests - not because I think it's a bad idea, just because I
haven't made the effort to set it up.

I find that the API breaks once in a while - the other day, when I moved to
latest version, I found that the IRBuilder::CreateCall{2, 3,4,5} had been
removed, so I needed to change that bit of code.

My experience, however, is that it's not that often that things change.

--
Mats

On 14 June 2015 at 03:26, Marcello Maggioni <mmaggioni at apple.com> wrote:

> There will always be unexpected API changes and there’s no way to get
> around that. You will have to use the API of course.
>
> If you want to follow top of tip you need to setup some kind of
> automerging environment that merges with master every night and in the
> morning if you are lucky you have everything working and if you are unlucky
> somebody changed the number of parameters of the constructor of some
> classes you use and you will need to fix that to continue the merge.
> Some changes are more subtle … the API remains the same, but the semantic
> of some parameter changes and you will get probably test errors you will
> have to figure out why started failing.
>
> Doing it daily is the best thing in my experience to keep it going. There
> are bad periods and good periods with resepect to changes. Certainly though
> if you leave it unmerged for two or more months and then you want to try
> and merge just wait to find yourself in a lot of pain … (experience again
> :P )
>
> Of course if you are working alone and diligent enough you can do it
> manually every day, but setting up something automatic always helps in
> keeping up with your initial proposal :)
>
> Cheers,
> Marcello
>
> > On 13 Jun 2015, at 18:53, rzaghi at mosaic3dx.com wrote:
> >
> > Hey everyone on cfe-dev
> >
> > New list member but an old admirer of your great work here.
> >
> > I am planning the implementation of a set of C++ language extensions
> which we hope to be used in a [non-compiler related] research project at
> the University of Cambridge next year.
> >
> > Naturally, I chose Clang to do this. However, I have an "engineering"
> question.
> >
> > The extensions are, as you would imagine, not part of the standard - and
> I had like to add the word "yet", hehe.
> >
> > Given the potential invasiveness of some of the features and the pace of
> changes to the code base, I am left with no answer as to how I can keep up
> with the pace of the change and whether such requirements have been taken
> into account in the internal design of the front end, by any chances?
> >
> > Basically, I do not want to be in a position where we have working
> version of the extensions next year but based on a version of the front end
> which is one year old.
> >
> > It may help to give you a flavour of what some of these changes may look
> like.
> >
> > As an example, the extension would allow us to "tag" some identifiers in
> the code as follows:
> >
> > class CLXYZ {
> > public:
> >  int <tag1> x;
> > };
> >
> > The identifier tagged as such is later picked at one of the phases and
> operated on.
> >
> > So what is the best practice here? Other than rebasing every so often?
> >
> > Appreciate your input and advice.
> > - Ramin
> >
> >
> > (ps, not so related to my question but we call this "tagged-programming"
> paradigm. Actually we hope that the combination of these extensions can
> eventually help programmers in scenarios as the very question I am asking
> above!).
> >
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150614/83856b15/attachment.html>