similar to: [RFC] changing variable naming rules

[just so i don't end up with "why haven't you spoken up"] On Sun, Sep 8, 2019 at 1:32 AM Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I do not support this. I feel the benefit is low, and the churn cost is high. > > I'm not strongly opposed or anything, I just don't believe this is worthwhile. Same thoughts. > Philip Roman

What cost do you see here? Rui has done a significant amount of work to make this effectively zero cost. The improvements are meaningful, and (as was discussed on the other threads) pretty much every large scale change in the LLVM world has been shot down with objections like “it is too much churn”. This is a huge problem, because it leads to stagnation in the codebase and does not allow

Personally I think the benefit-cost ratio is quite low here, and changing the rules would bring little value to me. Maybe I just don’t see that much benefits of changing the naming rules, having got used to the current naming scheme after a few years with LLVM. I'm a little bit curious to hear more about the experiences from the changes in LLD. I’m thinking about things like: - ongoing

Hi Rui, all, Yesterday I brought the variable-renaming commits in to Sony's downstream LLD. We have a merge-based flow rather than continually rebasing our patch set, but it went reasonably smoothly nevertheless. The one snag I hit is that the tool initially missed variables mentioned in assert()s. I didn't put much time in to investigating this, but I presume it's because my

Hi Rui, Is your tool in a good state to be run on people's downstream repositories? It would be nice to be able to update variable names there too at the same time. James On Tue, 9 Jul 2019 at 08:24, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks, Chris. > > Looks like everybody is at least mildly comfortable with my variable name > renaming change,

Hi Denis, On Fri, Jul 19, 2019 at 6:55 AM Bakhvalov, Denis <denis.bakhvalov at intel.com> wrote: > Hello Rui, all, > > We recently went through the LLD renaming process at Intel and it went > reasonably well too. > Very glad to hear that! > However I encountered one case when the tool seems not to work: > > > > int foo() > > { > > int A = 1;

Good point, too. I believe I can find lines starting with `@parameter` and apply the same name conversion rules to identifiers after `@parameter`. Since lld doesn't use doxygen comments, it is fine for now, but before moving forward, I'll address that. Thank you for pointing that out. On Wed, Jul 10, 2019 at 8:20 PM Alex Brachet-Mialot < alexbrachetmialot at gmail.com> wrote: >

This looks really great to me Rui, and I’m also pleased to see the positive comments on the review thread. Thank you for driving this forward! -Chris > On Jul 4, 2019, at 9:50 PM, Rui Ueyama <ruiu at google.com> wrote: > > Hi all, > > I wrote a tool <https://reviews.llvm.org/D64123> to batch-rename variable names so that they are in camelCase, and I applied the

On Jul 29, 2019, at 10:58 AM, JF Bastien <jfbastien at apple.com> wrote: >> I think that Rui rolled this out in an incredibly great way with LLD, incorporating a lot of community feedback and discussion, and (as you say) this thread has accumulated many posts and a lot of discussion, so I don’t see the concern about lack of communication. > > I think there’s lack of proper

This thread is not active for a while, but I'm still interested in seeing a change. Reading through this thread, looks like we can agree that we want to change the local variable naming scheme so that they start with a lowercase letter. Besides that, there were discussions about lower_case, camelCase, m_ prefix, and each argument seems as convincing as others. I'm not sure what is the

Hi folks, Git is on its way to learning how to ignore commits, allowing us to do variable renaming and other small refactorings without breaking git blame. It's like git-hyper-blame [1] but significantly more powerful as it uses fuzzy matching to match lines, including lines that may have been split or joined. A preview release of Git with this new feature is at:

On Mon, Jun 10, 2019 at 6:27 PM Michael Platings <Michael.Platings at arm.com> wrote: > Hi Rui, > > > > As per the provisional plan [1] we’re still at step 1: improving git > blame. The status of this is that there are some fairly mature patches in > the Git project’s queue [2], and I’m hopeful that it will be accepted in > something close to its current form. >

Hi Rui, I’m totally positive on switching to camelCase convention. In fact I have been always uncomfortable with the current naming approach. My only suggestion/concern is that we should provide a transition path not only for the trunk code in the repository, but for eventual out-of-trunk code with implementations of custom architectures. I have currently a custom backend implemented on top of

Rui, I have created D64474 to change comments explicitly stating the parameter names for constants ( /*parameterName=*/<constant> ). I did this by hand to match the new variable names. Do you know if there would be a way to update these comments with a tool similar to what you used to change these names? Perhaps it would be much more difficult, I'm guessing clang's AST doesn't

On Mon, 11 Feb 2019 at 23:20, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I don't care about the convention, but I'm really not sure it's worth the churn which would result in the code base. The hurtle which needs cleared here is not "is it a better naming style", but "is the disruption implied by changing to the new convention

On Mon, Feb 18, 2019 at 2:16 AM Michael Platings via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Regarding a plan for conversion, I'm keen to avoid perfect being the enemy > of better. It seems a bit early to discuss conversion given there’s not consensus on a style. For example: If we imagine that over time it evolves such that 50% of the variables have > been renamed

Hi Mehdi! I think the value to upstream (of doing mass reformatting in fewer commits) has to do with the intrusion of nonfunctional commits into `git blame` kinds of research. Every line that someone touches for a formatting reason necessarily obscures the history of functional changes in that block of code. The fewer of those that people have to work around, the better. I admit this is a

On Jul 23, 2019, at 9:17 AM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> On Jul 23, 2019, at 8:30 AM, James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> As a very frequent explorer of history, I really don't think this is >> as big an issue as it may seem. Even absent refactorings, you often >> run into the

> On Sep 9, 2019, at 4:24 AM, Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.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

> On Jul 18, 2019, at 6:09 PM, Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Jul 18, 2019, at 3:49 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> And one more question: >> >> What is the plan of renaming variables in llvm and clang? Will it be