search for: zhanyong

Hi, I uploaded a patch for the "*Kind enum" rule to http://codereview.appspot.com/3402041 and attached it to this message too. Would you please take a look? Thanks, On Wed, Dec 1, 2010 at 9:19 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote: > Thanks, Chris and John.  Committed in r120689.  I'll try to add the > *Kind rule in a separate patch.  Cheers, > > On Wed, Dec 1, 2010 at 5:18 PM, Chris Lattner <clattner at apple.com> wrote: >> >> On Nov 30, 2010, at...

On Dec 1, 2010, at 9:32 PM, Zhanyong Wan (λx.x x) wrote: > Hi, > > I uploaded a patch for the "*Kind enum" rule to > > http://codereview.appspot.com/3402041 > > and attached it to this message too. Would you please take a look? Thanks, Applied, thanks! After applying it, I went through and restru...

On Nov 30, 2010, at 11:29 PM, Zhanyong Wan (λx.x x) wrote: > Hi Chris, > > I've uploaded a new patch to http://codereview.appspot.com/3264041. > It's also attached to this message. This patch looks great to me, please apply, thanks! > I think I've addressed all your comments, except "when in doubt, an...

+llvmdev Thanks for the comments, Chris. On Mon, Nov 22, 2010 at 11:08 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 22, 2010, at 5:16 PM, Zhanyong Wan (λx.x x) wrote: > >> Hi guys, >> >> Based on our discussion last week, I put together a new coding style >> rule regarding the naming of types/functions/variables.  I've uploaded >> the patch to >> >> http://codereview.appspot.com/3264041 >&gt...

Thanks, Chris and John. Committed in r120689. I'll try to add the *Kind rule in a separate patch. Cheers, On Wed, Dec 1, 2010 at 5:18 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 30, 2010, at 11:29 PM, Zhanyong Wan (λx.x x) wrote: > >> Hi Chris, >> >> I've uploaded a new patch to http://codereview.appspot.com/3264041. >> It's also attached to this message. > > This patch looks great to me, please apply, thanks! > >> I think I've addressed all your comm...

On Mon, Nov 22, 2010 at 11:41 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote: > +llvmdev > > Thanks for the comments, Chris. > > On Mon, Nov 22, 2010 at 11:08 PM, Chris Lattner <clattner at apple.com> wrote: >> >> On Nov 22, 2010, at 5:16 PM, Zhanyong Wan (λx.x x) wrote: >> >>> Hi g...

On Tue, Nov 30, 2010 at 5:07 PM, Chris Lattner <clattner at apple.com> wrote: > > On Nov 30, 2010, at 5:02 PM, Zhanyong Wan (λx.x x) wrote: > >> Thanks for the comments, Chris!  Glad that we are making progress. >> >> I'll make most of the edits you suggested later today.  Before that, >> there are a couple of high-level points I'd like to go over with you. >> >> 1. I t...

...s me as a bit ad hoc for the coding standards. Do we really want it? If you feel that's important, I'll add it -- but it will need some clarification, as the Kind suffix clearly doesn't fit all enums. What is it that you really have in mind? Thanks, On Tue, Nov 30, 2010 at 5:18 PM, Zhanyong Wan (λx.x x) <wan at google.com> wrote: > On Tue, Nov 30, 2010 at 5:07 PM, Chris Lattner <clattner at apple.com> wrote: >> >> On Nov 30, 2010, at 5:02 PM, Zhanyong Wan (λx.x x) wrote: >> >>> Thanks for the comments, Chris!  Glad that we are making progress....

Hi, I enjoyed the new coding style in recent patches. Camel case makes it easy to pick a descriptive name. Starting functions and variables with lower cases reduces chances to conflict with a type name. 2010/11/23 Zhanyong Wan (λx.x x) <wan at google.com> > On Mon, Nov 22, 2010 at 11:41 PM, Zhanyong Wan (λx.x x) <wan at google.com> > wrote: > > +llvmdev > > > > Thanks for the comments, Chris. > > > > On Mon, Nov 22, 2010 at 11:08 PM, Chris Lattner <clattner at apple...

...ere a more profound reason? So far, I've heard that some people like lowerCase ivars (clear distinction from types, etc), and some people don't think that helps much. However, I'm yet to hear why UpperCase ivars are considered *better* than lowerCase, so I'm curious. Thanks. -- Zhanyong

On Tue, Nov 23, 2010 at 10:15 AM, Bo Persson <bop at gmb.dk> wrote: >  > > > ----- Original Message ----- > From: Chandler Carruth > To: Zhanyong Wan (λx.x x) > Cc: Argyrios Kyrtzidis ; clang-dev Developers > Sent: Tuesday, November 23, 2010 6:40 AM > Subject: Re: [cfe-dev] draft rule for naming types/functions/variables > On Mon, Nov 22, 2010 at 9:36 PM, Zhanyong Wan (λx.x x) <wan at google.com> > wrote: >> >&g...

Hi Doug, While refactoring clang::FileManager to use llvm::sys::path, I had a need for a function to test whether a char is a path separator. I think it would be generally useful. Would you be able to review it? You can see http://codereview.appspot.com/4186045 or the attachment. Thanks, -- Zhanyong -------------- next part -------------- A non-text attachment was scrubbed... Name: is_separator.patch Type: text/x-patch Size: 2482 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110211/54ad4b7d/attachment.bin>

Zhanyong Wan (λx.x x) wrote: > If possible, I'd prefer that all variable names have the same style. > I'm afraid that we'll end up with the current inconsistent style if > we > leave it to people to interpret whether a name is metasyntactic and > thus should be lower-case. > &...

...ke MI. I agree that 'mi' is not a great name either in this case. In fact, it's not even camel case. How about instr? Or, perhaps a name that clarifies its role (jumpInstr, nextInstr, etc)? Or, if this is a short-lived local variable, I'd be fine with 'mi'. Cheers, -- Zhanyong

On Nov 30, 2010, at 5:02 PM, Zhanyong Wan (λx.x x) wrote: > Thanks for the comments, Chris! Glad that we are making progress. > > I'll make most of the edits you suggested later today. Before that, > there are a couple of high-level points I'd like to go over with you. > > 1. I totally agree that the bigg...

On Nov 29, 2010, at 11:07 AM, Zhanyong Wan (λx.x x) wrote: > C++ is such a complex language that no single naming convention will > be able to cover all cases. Therefore we aim at a reasonable default > that works for the majority of the cases. As Chris put at the > beginning of the coding standards, "no coding standa...

...only bigger change I made is to group the sections about iostream and raw_ostream together, as they are logically related. I had to edit the text a little bit after the move, in order to reduce the repetition. The patch is also attached to this message. Would you please take a look? Thanks! -- Zhanyong -------------- next part -------------- A non-text attachment was scrubbed... Name: coding-standards.patch Type: text/x-patch Size: 11699 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101115/9ab62536/attachment.bin>

On 29 nov 2010 03:47 "Xu Zhongxing" <xuzhongxing at gmail.com> wrote: > Hi, > I enjoyed the new coding style in recent patches. Camel case makes it > easy to pick a descriptive name. Starting functions and variables with > lower cases reduces chances to conflict with a type name. On the other hand, having names that only differ in the case of a single character, is not

> I enjoyed the new coding style in recent patches. Camel case makes it easy > to pick a descriptive name. Starting functions and variables with lower > cases reduces chances to conflict with a type name. Honestly speaking, I don't. Especially in the cases when varname is made from an acronym. E.g. MachineInstr *MI looks much better than MachineInstr *mi, etc. See latest Rafael's