[llvm-dev] [RFC] changing variable naming rules

[Rui Ueyama via llvm-dev]

Ah, that is true. Thank you for pointing that out. I'm not pushing this
idea too much, but in theory, if there's a tool that does the reverse
conversion, we might be able to backport patches from a newer tree to an
old tree without breaking the API and ABI, but I can see that that can be
tricky.

On Mon, Sep 9, 2019 at 10:42 PM Hans Wennborg <hans at chromium.org> wrote:

> The even bigger issue is that X.1 is supposed to be API and ABI
> compatible with X.0.
>
> On Mon, Sep 9, 2019 at 3:35 PM Rui Ueyama <ruiu at google.com> wrote:
> >
> > Hypothetically assume that we have an LLVM release X and want to rename
> variables in the next major release Y. In order to backport patches from Y
> to X.1 smoothly, I think we could first apply the automated renaming tool
> to X and then cherry-pick patches from Y. The obvious issue of doing this
> is, even though X.1 is a dot release, a very large number of lines would be
> changed from X, though.
> >
> > On Mon, Sep 9, 2019 at 10:21 PM Hans Wennborg <hans at chromium.org> wrote:
> >>
> >> On Mon, Sep 9, 2019 at 3:03 PM Rui Ueyama <ruiu at google.com> wrote:
> >> >
> >> > On Mon, Sep 9, 2019 at 8:25 PM Hans Wennborg <hans at chromium.org>
> wrote:
> >> >>
> >> >> On Fri, Sep 6, 2019 at 6:17 PM Björn Pettersson A via llvm-dev
> >> >> <llvm-dev at lists.llvm.org> wrote:
> >> >> > I'm a little bit curious to hear more about the experiences from
> the changes in LLD.
> >> >> > I’m thinking about things like:
> >> >> [..]
> >> >> > - merging of bugfixes to older release branches (I doubt that the
> script supports doing the reverse rewrite as well)
> >> >>
> >> >> As someone who does a lot of these merges, this is the aspect that
> >> >> worries me the most.
> >> >
> >> >
> >> > How large is a typical patch to merge that is backported from the
> next major release to a previous dot release?
> >>
> >> The diffs are usually fairly small, but there can be many. For 8.0.1
> >> there were about 60 patches merged (git log
> >> llvmorg-8.0.0..llvmorg-8.0.1 --oneline | wc -l). (For 9.0.0 I think
> >> we're approaching 200 merges.)
> >>
> >> Depending on when the rename happens, I guess it could affect merges
> >> either for a major release or for a dot release, and it would mean a
> >> lot of extra work unless there was some tool available to help. Maybe
> >> if the rename happens after a dot release ships and before the next
> >> major release process begins, it would not affect any merges at all,
> >> but that's a pretty slim window, and downstream users might have other
> >> release processes.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190909/0ef6f84e/attachment.html>