On Sun, Oct 5, 2014 at 9:37 AM, Renato Golin <renato.golin at linaro.org> wrote:> On 5 October 2014 07:19, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > > So with that in mind, I would like to ask, would it be possible to > consider > > switching to LLVM style for lld? > > We don't usually enforce code styles on side projects because it > doesn't make sense to do so.This is not completely accurate. Both LLD and LLDB were given specific exemptions from the coding standards, but Clang wasn't and I wouldn't expect a new subproject to *necessarily* get such an exemption. It might, it might not. I consider the current state with both LLD and LLDB a bug rather than a feature because it creates pointless and non-trivial disruption for developers to move between LLVM, Clang, LLD, and LLDB. You can argue that coding standards are like fashion, but *changing* coding standards is a much more pragmatic and real concern. At least one important point of LLVM's standards (in my mind and I suspect other developers' minds) is to drive consistency both within projects and across projects.> Code style changes with time. If the majority of lld developers agree > with you that the current style is bad and needs to be changed (to a > more LLVM-ish style),Figuring out whether most LLD devs want to switch seems like the point of the email?> than future commits should move lld's style > towards that. Not by adding new styles to one line inside an old > function, but by deprecating style when you deprecate code, and > creating style when you create code. >That is one option. But the developers of LLD may be willing to more aggressively convert. We should let them speak for themselves rather than hypothesizing here.> > It's also very likely that, by the time you have converted all old > code with new style, the preferred style will have changed, and you'll > want to do it all over again. To avoid that pointless race against > nothing, we tend to keep the style that was in the original > file/function and not mind much. >This has not been my experience in any part of the LLVM project. The coding standards are extremely stable these days. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141005/5650c965/attachment.html>
I think we should format code using LLVM coding conventions, much easier to follow and maintain. I think lldb also could consider moving towards one coding convention style. On Sun, Oct 5, 2014 at 1:46 PM, Chandler Carruth-2 [via LLVM] < ml-node+s1065342n73136h99 at n5.nabble.com> wrote:> > On Sun, Oct 5, 2014 at 9:37 AM, Renato Golin <[hidden email] > <http://user/SendEmail.jtp?type=node&node=73136&i=0>> wrote: > >> On 5 October 2014 07:19, Saleem Abdulrasool <[hidden email] >> <http://user/SendEmail.jtp?type=node&node=73136&i=1>> wrote: >> > So with that in mind, I would like to ask, would it be possible to >> consider >> > switching to LLVM style for lld? >> >> We don't usually enforce code styles on side projects because it >> doesn't make sense to do so. > > > This is not completely accurate. Both LLD and LLDB were given specific > exemptions from the coding standards, but Clang wasn't and I wouldn't > expect a new subproject to *necessarily* get such an exemption. It might, > it might not. > > I consider the current state with both LLD and LLDB a bug rather than a > feature because it creates pointless and non-trivial disruption for > developers to move between LLVM, Clang, LLD, and LLDB. You can argue that > coding standards are like fashion, but *changing* coding standards is a > much more pragmatic and real concern. At least one important point of > LLVM's standards (in my mind and I suspect other developers' minds) is to > drive consistency both within projects and across projects. > > >> Code style changes with time. If the majority of lld developers agree >> with you that the current style is bad and needs to be changed (to a >> more LLVM-ish style), > > > Figuring out whether most LLD devs want to switch seems like the point of > the email? > > >> than future commits should move lld's style >> towards that. Not by adding new styles to one line inside an old >> function, but by deprecating style when you deprecate code, and >> creating style when you create code. >> > > That is one option. But the developers of LLD may be willing to more > aggressively convert. We should let them speak for themselves rather than > hypothesizing here. > > >> >> It's also very likely that, by the time you have converted all old >> code with new style, the preferred style will have changed, and you'll >> want to do it all over again. To avoid that pointless race against >> nothing, we tend to keep the style that was in the original >> file/function and not mind much. >> > > This has not been my experience in any part of the LLVM project. The > coding standards are extremely stable these days. > > _______________________________________________ > LLVM Developers mailing list > [hidden email] <http://user/SendEmail.jtp?type=node&node=73136&i=2> > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://llvm.1065342.n5.nabble.com/lld-coding-style-tp73133p73136.html > To start a new topic under LLVM - Dev, email > ml-node+s1065342n3h76 at n5.nabble.com > To unsubscribe from LLVM - Dev, click here > <http://llvm.1065342.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3&code=c2hhbmthcmtlQGdtYWlsLmNvbXwzfDY4NzQ5MzE3NQ==> > . > NAML > <http://llvm.1065342.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >-- View this message in context: http://llvm.1065342.n5.nabble.com/lld-coding-style-tp73133p73138.html Sent from the LLVM - Dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141005/c198d7b6/attachment.html>
On 5 October 2014 19:45, Chandler Carruth <chandlerc at google.com> wrote:> This is not completely accurate. Both LLD and LLDB were given specific > exemptions from the coding standards, but Clang wasn't and I wouldn't expect > a new subproject to *necessarily* get such an exemption. It might, it might > not.Why exemptions are made is beyond the point, once it's made, there are mainly two ways to move to a common point: one big clang-format in the tree, or a slow moving change on new functions or small refactorings when moving things around. My point is that the former breaks the history of the project, while the latter is hard to do without making it a little worse during the move, which can cause even more pain.> I consider the current state with both LLD and LLDB a bug rather than a > feature because it creates pointless and non-trivial disruption for > developers to move between LLVM, Clang, LLD, and LLDB.Meh. I have seen so many different coding standards that for me they're all alike.> You can argue that > coding standards are like fashion, but *changing* coding standards is a much > more pragmatic and real concern. At least one important point of LLVM's > standards (in my mind and I suspect other developers' minds) is to drive > consistency both within projects and across projects.A fine goal, but IMO, not at the cost of pointlessly tainting the commit history. Again, my *humble* opinion, which is the only thing I can offer.> Figuring out whether most LLD devs want to switch seems like the point of > the email?Indeed. To which I gave my personal opinion. If people felt setback, I apologise, it wasn't my intent. I have no stake in lld, and I trusted lld developers would easily trump and disregard my comments if they weren't relevant to them.> That is one option. But the developers of LLD may be willing to more > aggressively convert. We should let them speak for themselves rather than > hypothesizing here.Again, they're absolutely free to do so, and I don't believe I have any power in stopping them to. My opinions are as good as they want it to be.> This has not been my experience in any part of the LLVM project. The coding > standards are extremely stable these days.That is a good point. I take that back. cheers, --renato
> than future commits should move lld's style > towards that. Not by adding new styles to one line inside an old > function, but by deprecating style when you deprecate code, and > creating style when you create code. > > > That is one option. But the developers of LLD may be willing to more > aggressively convert. We should let them speak for themselves rather > than hypothesizing here. >Polly did a bulk convert using clang-format if I remember correctly, that solved the coding style discrepancies in just a few commits. They now run clang-format on any commit and that keeps things nice and tidy. I'm not familiar with LLD though and its codebase could be much larger than that of polly at the time... - Roel
On 5 October 2014 21:05, Roel Jordans <r.jordans at tue.nl> wrote:> Polly did a bulk convert using clang-format if I remember correctly, that > solved the coding style discrepancies in just a few commits. They now run > clang-format on any commit and that keeps things nice and tidy.I'm interested in learning how you guys cope with trying to find out changes past the big move. Is this a problem at all? How long ago was that? It might be just my own pre-conceptions and past experiences talking, but I remember having to checkout a pre-move tree on another project I was working on to keep following the changes. Though that wasn't at all common. All in all, I'd be very happy to prove myself wrong about that once and for all. :) cheers, --renato
On 10/05, Roel Jordans wrote:> > than future commits should move lld's style > > towards that. Not by adding new styles to one line inside an old > > function, but by deprecating style when you deprecate code, and > > creating style when you create code. > > > > > >That is one option. But the developers of LLD may be willing to more > >aggressively convert. We should let them speak for themselves rather > >than hypothesizing here. > > > > Polly did a bulk convert using clang-format if I remember correctly, that > solved the coding style discrepancies in just a few commits. They now run > clang-format on any commit and that keeps things nice and tidy. I'm not > familiar with LLD though and its codebase could be much larger than that of > polly at the time...First, I don't know what to do with LLD but I like the way Polly is maintained now. If other projects want to go the same way we can provide the arcanist linter [1] together with the clang format script [2]. This helps a lot keeping the tree formated and minimizes the number of "[Format]" commits after something got accidentally messed up. (We also run the format check on the buildbots to get immediate feedback.) [1] http://reviews.llvm.org/D4916 [2] https://github.com/llvm-mirror/polly/blob/master/utils/check_format.sh -- Johannes Doerfert Researcher / PhD Student Compiler Design Lab (Prof. Hack) Saarland University, Computer Science Building E1.3, Room 4.26 Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de Fax. +49 (0)681 302-3065 : http://www.cdl.uni-saarland.de/people/doerfert -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141005/14b10162/attachment.sig>
On Sun, Oct 5, 2014 at 12:47 PM, Renato Golin <renato.golin at linaro.org> wrote:> On 5 October 2014 19:45, Chandler Carruth <chandlerc at google.com> wrote: > > This is not completely accurate. Both LLD and LLDB were given specific > > exemptions from the coding standards, but Clang wasn't and I wouldn't > expect > > a new subproject to *necessarily* get such an exemption. It might, it > might > > not. > > Why exemptions are made is beyond the point, once it's made, there are > mainly two ways to move to a common point: one big clang-format in the > tree, or a slow moving change on new functions or small refactorings > when moving things around. My point is that the former breaks the > history of the project, while the latter is hard to do without making > it a little worse during the move, which can cause even more pain.Can't the history be re-written? Would something like the following work? 1) Format the initial commit and commit it to a new repository with matching header information (date/time, author, etc) 2) For each formatted commit F, find the corresponding unformatted commit U. Determine the set of all files modified between U and U+1, and reformat all of these files, placing them in the working copy of the new repository. Commit this patch to the new repository using the commit information from U+1. 3) Delete the old repository and rename the new repository to the old repository. Note that variable names are outside the scope of this. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141007/b950975b/attachment.html>