mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Mahler <benjamin.mah...@gmail.com>
Subject Re: Mesos Style Guideline Adjustments
Date Fri, 06 Nov 2015 19:30:48 GMT
+benh

I seem to recall benh having something in emacs that formatted his comments
nicely, which I think formed the basis for thinking about jaggedness and
wrapping at 70 vs 80.

On Fri, Nov 6, 2015 at 11:26 AM, Joris Van Remoortere <joris@mesosphere.io>
wrote:

> @ben Is "jaggedness" the only *formatting* influence on the readability of
> the comments? If so, would it be possible to make a simple github.io page
> where we can paste comments, and they get formatted for minimal jaggedness
> based on some simple math? This would help provide consistency between
> contributions, and likely better results than humans trying to optimize the
> jaggedness equation.
>
> This way we can focus on the content of the comments when reviewing, rather
> than the format. Later one we might even be able to incorporate this in
> more intelligent editor friendly formatting tools.
>
> If there is more than some simple math involved, this may not be a viable
> solution.
>
> Joris
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
> On Fri, Nov 6, 2015 at 11:10 AM, Benjamin Mahler <
> benjamin.mahler@gmail.com>
> wrote:
>
> > I raise this because there is a ton of value in keeping our codebase as
> > readable as possible. Having had to navigate and maintain the code base
> for
> > the past few years, this _is_ a "real issue" that deserves the
> contributors
> > spending their mental resources on. I realize this seems very subtle, but
> > it is of critical importance for the maintainability of the project that
> > folks are paying attention to how their code and comments will be read by
> > others.
> >
> > I think about this as follows: we'll always have "soft" rules that cannot
> > be enforced by these style checkers but require mentorship to communicate
> > as we grow the community. These tools cannot tell you how to structure
> your
> > code in a simple form. They also can't tell you how to write a comment
> in a
> > way that is clear to others.
> >
> > To Alex's example, two comments:
> >
> > (1) The second comment is poorly written, did no one even notice this??
> > That's a "real issue" :(
> > (2) It's important not to isolate the comments from the code. The
> comments
> > live with the code and a major reason why long line length paragraphs are
> > irregular is because the majority of code lines do not approach 80
> > characters.
> > (3) We tend to separate "multiple logical parts" of a comment with an
> empty
> > // line, which helps readability.
> > (4) I'm not saying wrap at 70 or at 80, but (a) write and wrap to reduce
> > "jaggedness" (or to increase "regularity") and (b) long line lengths (80)
> > for large paragraphs are harder to read.
> >
> > I just don't want the formatter to become a crutch that causes folks to
> > think less about the implications of how they write their comments. Do
> the
> > soft rules in (a) and (b) seem reasonable? We already need to be diligent
> > in reviews to ensure that comments are well-written.
> >
> > On Fri, Nov 6, 2015 at 8:44 AM, Benjamin Bannier <
> > benjamin.bannier@mesosphere.io> wrote:
> >
> > > Hi,
> > >
> > > just to echo Alexander’s point, for newbies like me being able to
> > delegate
> > > formatting decisions to tools as much as possible frees up a lot of
> > mental
> > > resources for tackling the real issues.
> > >
> > >
> > > Cheers,
> > >
> > > Benjamin
> > >
> > > ps. Also looking forward to an updated and expanded clang-format
> config.
> > >
> > >
> > > > On Nov 6, 2015, at 1:44 PM, Alexander Rojas <alexander@mesosphere.io
> >
> > > wrote:
> > > >
> > > > I think one of the main reasons we move to having 80 as the limit for
> > > both code and comments is the ability it gives us to use tools (e.g.
> > > clang-format) to enforce formatting rules, so personally I rather have
> us
> > > putting effort towards that goal. On that note, the developer branch of
> > > clang-format allows a much closer formatting options to the ones we
> use.
> > On
> > > OS X it can be installed using `brew install --HEAD clang-format`.
> > > >
> > > > Right now I’m working on setting the config file to be as close as
> > > possible to our style.
> > > >
> > > >> On 06 Nov 2015, at 10:09, Alex Rukletsov <alex@mesosphere.com>
> wrote:
> > > >>
> > > >> I think jaggedness in the example you provide comes mainly from the
> > fact
> > > >> that the second comment has multiple logical blocks. I have
> formatted
> > > both
> > > >> comments at 70 and at 80, here is the outcome:
> > > http://pastebin.com/nRQB0nCD
> > > >>
> > > >> While the first comment indeed looks better when wrapped at 70, I
> > can't
> > > say
> > > >> the same about the second one.
> > > >>
> > > >> I would say, that the longer a line could be, the less jagged the
> > > comment
> > > >> block is. The ratio (`averageWordLength` / `maxLineLength`)
> approaches
> > > 0 as
> > > >> `maxLineLenght` approaches infinity, which means wrapping a long
> word
> > > right
> > > >> before the line end should be perceived less jagged : ).
> > > >>
> > > >> Also, the longer an individual line can be, the less total lines are
> > > needed
> > > >> for a comment block, which reduces jaggedness and makes code a
> little
> > > bit
> > > >> more readable.
> > > >>
> > > >> But my strongest argument is that having a separate soft rule for
> > > comments
> > > >> is hard to enforce. I think what we can do is to encourage
> > contributors
> > > /
> > > >> committers to wrap comments in the most logical way—like the first
> > > comment
> > > >> in the example you provide—even if the line length is not fully
> > > utilized.
> > > >> Having said that, I would rather keep a single number: hard limit
at
> > 80
> > > for
> > > >> simplicity.
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Nov 5, 2015 at 10:15 PM, Benjamin Mahler <
> > > benjamin.mahler@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> This has come up in a couple of reviews, seems like we should
add
> > some
> > > soft
> > > >>> guidelines around how to format comments for readability.
> > > >>>
> > > >>> In particular, the reason that we wrapped at 70 in the past was
for
> > > >>> readability, so it would be great to continue doing so as a soft
> > > stylistic
> > > >>> rule. The other thing we've been doing for readability is reducing
> > > >>> "jaggedness" (variability in line lengths).
> > > >>>
> > > >>> It would be great to establish these as soft rules and encourage
> new
> > > >>> contributors / committers to follow them. Compare these two
> comments
> > in
> > > >>> Master::updateTask. The first one wraps at 70 and reduces
> jagedness,
> > > the
> > > >>> second wraps at 80 and is more jagged:
> > > >>>
> > > >>>
> > >
> https://github.com/apache/mesos/blob/0.25.0/src/master/master.cpp#L6057
> > > >>>
> > >
> https://github.com/apache/mesos/blob/0.25.0/src/master/master.cpp#L6072
> > > >>>
> > > >>> I can provide more examples to help clarify. If no one objects,
> I'll
> > > follow
> > > >>> up with an update to the style guide. Thoughts appreciated!
> > > >>>
> > > >>> On Thu, Sep 10, 2015 at 8:59 AM, Bernd Mathiske <
> bernd@mesosphere.io
> > >
> > > >>> wrote:
> > > >>>
> > > >>>> +1
> > > >>>>> On Sep 10, 2015, at 4:21 PM, tommy xiao <xiaods@gmail.com>
> wrote:
> > > >>>>>
> > > >>>>> +1
> > > >>>>>
> > > >>>>> 2015-09-10 9:44 GMT+08:00 Marco Massenzio <marco@mesosphere.io>:
> > > >>>>>
> > > >>>>>> +1
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Thanks, Michael!
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> —
> > > >>>>>> Sent from my iPhone, which is not as good as you'd
hope to fix
> > > trypos
> > > >>> n
> > > >>>>>> abbrvtn.
> > > >>>>>>
> > > >>>>>> On Wed, Sep 9, 2015 at 6:23 PM, Michael Park <mcypark@gmail.com
> >
> > > >>> wrote:
> > > >>>>>>
> > > >>>>>>> I've removed the 70 column restriction on comments
from the
> style
> > > >>>> guide:
> > > >>>>>>>
> > > >>>>>>
> > > >>>>
> > > >>>
> > >
> >
> https://github.com/apache/mesos/commit/f9c2604ea97b91f8a9ec3b2863317761679b1c86
> > > >>>>>>> Also, based on the comments, it seems like we
should allow 80
> > > column
> > > >>>>>>> comments but omit the sweeping change.
> > > >>>>>>> Thanks,
> > > >>>>>>> MPark.
> > > >>>>>>> On Wed, Aug 12, 2015 at 6:13 PM Marco Massenzio
<
> > > marco@mesosphere.io
> > > >>>>
> > > >>>>>> wrote:
> > > >>>>>>>> On Wed, Aug 12, 2015 at 4:09 AM, Bernd Mathiske
<
> > > >>> bernd@mesosphere.io>
> > > >>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Like BenM,
> > > >>>>>>>>>
> > > >>>>>>>>> +1 on allowing 80 column comments
> > > >>>>>>>>>
> > > >>>>>>>> +1
> > > >>>>>>>> (it really IS annoying having to keep an eye
on the bottom
> > column
> > > >>>>>> counter
> > > >>>>>>>> when typing comments :)
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>> -1 on sweeping changes; incremental changes
when touching old
> > > >>>> comments
> > > >>>>>>>>> will do IMHO
> > > >>>>>>>>>
> > > >>>>>>>>> +1 on the -1? :)
> > > >>>>>>>> Incremental changes are good and I doubt anyone
will be
> > "confused"
> > > >>> by
> > > >>>>>> them.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>> Bernd
> > > >>>>>>>>>
> > > >>>>>>>>>> On Aug 12, 2015, at 12:51 AM, Michael
Park <
> mcypark@gmail.com
> > >
> > > >>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>> Ben, thanks for your input!
> > > >>>>>>>>>>
> > > >>>>>>>>>> Another update on this topic: the
patches around break
> before
> > > >>> braces
> > > >>>>>>>> for
> > > >>>>>>>>>> *enum* style and overloaded operators
have been committed.
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Tue, Aug 11, 2015 at 6:23 PM Benjamin
Mahler <
> > > >>>>>>>>> benjamin.mahler@gmail.com>
> > > >>>>>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> We already don't necessarily wrap
at 70 characters (often
> we
> > > wrap
> > > >>>>>>>>> before 70
> > > >>>>>>>>>>> to reduce "jaggedness" or to make
it look cleaner).
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> So with the change to 80, this
still makes all existing
> > > comments
> > > >>>>>>>> valid.
> > > >>>>>>>>> We
> > > >>>>>>>>>>> can still encourage folks to write
paragraphs in a way that
> > is
> > > >>>>>> easy to
> > > >>>>>>>>>>> digest for the reader. That is,
I think we should still be
> > > trying
> > > >>>>>> not
> > > >>>>>>>> to
> > > >>>>>>>>>>> write jagged paragraphs of comments,
it's just not a hard
> > > >>> stylistic
> > > >>>>>>>>>>> violation given we don't have
an algorithm for this.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> So +1 to relaxing the hard 70
character rule, but -1 to
> > > sweeping
> > > >>>>>>>> across
> > > >>>>>>>>> all
> > > >>>>>>>>>>> the comments or doing wrapping
based only on line length
> > rather
> > > >>>>>> than
> > > >>>>>>>>>>> jaggedness going forward.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Sat, Aug 8, 2015 at 3:25 PM,
Joris Van Remoortere <
> > > >>>>>>>>> joris@mesosphere.io>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> I will volunteer to update
all the comments to wrap at 80
> if
> > > we
> > > >>>>>> agree
> > > >>>>>>>>> to
> > > >>>>>>>>>>>> keep the code base consistent.
> > > >>>>>>>>>>>> Naturally that is also my
vote ;-)
> > > >>>>>>>>>>>> Joris
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Aug 8, 2015, at 1:40
PM, Michael Park <
> > mcypark@gmail.com>
> > > >>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> An update on this topic
since we covered it at the
> > community
> > > >>>>>>>> developer
> > > >>>>>>>>>>>> sync.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> 1. We will adopt *Mozilla*'s
*BreakBeforeBraces* style as
> > > their
> > > >>>>>>>> style
> > > >>>>>>>>>>>> is
> > > >>>>>>>>>>>>> equivalent to ours. The
only change this entails for our
> > > >>>>>> codebase
> > > >>>>>>>> is
> > > >>>>>>>>>>> to
> > > >>>>>>>>>>>>> consistently wrap the
braces for *enum* definitions, as
> > we're
> > > >>>>>>>>>>> currently
> > > >>>>>>>>>>>>> inconsistent. I've taken
on the work involved in this
> > change:
> > > >>>>>>>>>>>>>  - stout: https://reviews.apache.org/r/37258
> > > >>>>>>>>>>>>>  - libprocess: https://reviews.apache.org/r/37259
> > > >>>>>>>>>>>>>  - mesos: https://reviews.apache.org/r/37260
> > > >>>>>>>>>>>>>  2. We will drop the rule
for adding spaces around
> > overloaded
> > > >>>>>>>>>>>>> operators. We'll simply
do a sweep of the codebase to
> > update
> > > >>>>>> all of
> > > >>>>>>>>>>>> them
> > > >>>>>>>>>>>>> consistently. Artem has
kindly taken action on this
> > already:
> > > >>>>>>>>>>>>>  - stout: https://reviews.apache.org/r/37018/
> > > >>>>>>>>>>>>>  - libprocess: https://reviews.apache.org/r/37017/
> > > >>>>>>>>>>>>>  - mesos: https://reviews.apache.org/r/37013/
> > > >>>>>>>>>>>>>  3. We will drop the rule
for wrapping comments at 70
> > > >>>>>> characters.
> > > >>>>>>>>>>> We
> > > >>>>>>>>>>>>> have a few options to
proceed here:
> > > >>>>>>>>>>>>>  - Keep all the existing
comments in tact, and simply
> allow
> > > >>>>>> new
> > > >>>>>>>>>>>>>  comments to wrap at 80,
this is less work.
> > > >>>>>>>>>>>>>  - Update all instances
of the comments wrapping at 70 to
> > be
> > > >>>>>>>>>>> wrapped
> > > >>>>>>>>>>>>>  at 80, so that we can
be consistent.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I proposed that we simply
allow new comments to wrap at
> 80,
> > > >>> but I
> > > >>>>>>>> have
> > > >>>>>>>>>>>>> heard arguments to update
the existing comments, so that
> we
> > > can
> > > >>>>>> be
> > > >>>>>>>>>>>>> consistent across the
codebase. If you have a
> > > >>> suggestion/opinion
> > > >>>>>> on
> > > >>>>>>>>> how
> > > >>>>>>>>>>>> we
> > > >>>>>>>>>>>>> should proceed with (3),
please share!
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> MPark.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Mon, Aug 3, 2015 at
2:01 PM Alexander Rojas <
> > > >>>>>>>>>>> alexander@mesosphere.io>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> I also vote up for
that! I rather change our guidelines
> a
> > > >>> little
> > > >>>>>>>> bit
> > > >>>>>>>>>>>> than
> > > >>>>>>>>>>>>>> waiting for months
> > > >>>>>>>>>>>>>> to get our changes
into the clang-format source without
> > any
> > > >>>>>>>> security
> > > >>>>>>>>>>>> that
> > > >>>>>>>>>>>>>> it will actually land.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On 31 Jul 2015,
at 09:31, Alex Rukletsov <
> > > >>> alex@mesosphere.com>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> I think automation
is very important. If we should
> > slightly
> > > >>>>>> change
> > > >>>>>>>>>>> our
> > > >>>>>>>>>>>>>>> style in order
to set-up easily enforceable rules, I
> vote
> > > >>> with
> > > >>>>>>>> both
> > > >>>>>>>>>>>> hands
> > > >>>>>>>>>>>>>>> for that.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Fri, Jul
31, 2015 at 3:25 AM, Michael Park <
> > > >>>>>> mcypark@gmail.com
> > > >>>>>>>>>
> > > >>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Oops, sorry
I was so excited that this could just
> solve
> > > the
> > > >>>>>> issue
> > > >>>>>>>>>>>> that I
> > > >>>>>>>>>>>>>>>> forgot to
answer your question.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> In general,
the clang-format strives to adopt widely
> > used
> > > >>>>>> styles,
> > > >>>>>>>>>>>> which
> > > >>>>>>>>>>>>>> I'm
> > > >>>>>>>>>>>>>>>> not sure if
we would be considered widely used. Aside
> > from
> > > >>>>>> that,
> > > >>>>>>>>>>>> another
> > > >>>>>>>>>>>>>>>> concern was
that it could take a while for our style
> > > >>>>>> proposals to
> > > >>>>>>>>>>> make
> > > >>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>> upstream and
for it to be useful.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Thu,
Jul 30, 2015, 6:12 PM Michael Park <
> > > >>>>>> mcypark@gmail.com>
> > > >>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Is it
worth adding our own style?
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> I noticed
other have (LLVM, Google, Chromium,
> Mozilla,
> > > >>>>>> WebKit.).
> > > >>>>>>>>>>> How
> > > >>>>>>>>>>>>>>>>>> hard
is it?
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> I was
just looking into this again and *Mozilla* was
> > > added
> > > >>> as
> > > >>>>>>>> the
> > > >>>>>>>>>>>>>> newest
> > > >>>>>>>>>>>>>>>>> *BreakBeforeBraces*
style. It breaks before braces on
> > > enum,
> > > >>>>>>>>>>> function,
> > > >>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>> record
definitions (struct, class, union). I think we
> > can
> > > >>>>>>>> actually
> > > >>>>>>>>>>>> use
> > > >>>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>> one and
be done with it. Having looked through the
> > > >>> codebase,
> > > >>>>>> we
> > > >>>>>>>>>>> wrap
> > > >>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> braces
for *enum* for about half of the cases. It
> would
> > > be
> > > >>>>>> about
> > > >>>>>>>>> 35
> > > >>>>>>>>>>>>>>>>> instances
that we have to fix from what I can see in
> > our
> > > >>>>>>>> codebase.
> > > >>>>>>>>>>>> What
> > > >>>>>>>>>>>>>>>> do
> > > >>>>>>>>>>>>>>>>> you think?
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Thu,
Jul 30, 2015 at 5:14 PM Benjamin Mahler <
> > > >>>>>>>>>>>>>>>> benjamin.mahler@gmail.com>
> > > >>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Is
it worth adding our own style?
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> I
noticed other have (LLVM, Google, Chromium,
> Mozilla,
> > > >>>>>>>> WebKit.).
> > > >>>>>>>>>>> How
> > > >>>>>>>>>>>>>>>> hard
> > > >>>>>>>>>>>>>>>>>> is
it?
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On
Thu, Jul 30, 2015 at 4:23 PM, Michael Park <
> > > >>>>>>>> mcypark@gmail.com
> > > >>>>>>>>>>
> > > >>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
There are a few syntactical Mesos style guidelines
> > > that I
> > > >>>>>>>> would
> > > >>>>>>>>>>>> like
> > > >>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>
propose to drop. They are:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
1. Open braces for namespace should not be wrapped.
> > > >>>>>>>>>>>>>>>>>>>
*NOTE*: The Google style guide does not wrap the
> > brace
> > > >>>>>> after
> > > >>>>>>>>>>>>>>>>>>>
*namespace*,
> > > >>>>>>>>>>>>>>>>>>>
and the Mesos style guide does not mention a rule
> at
> > > all.
> > > >>>>>> But
> > > >>>>>>>> it
> > > >>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>>>
consistent throughout the codebase.
> > > >>>>>>>>>>>>>>>>>>>
2. Overloaded operators should be padded with
> spaces.
> > > >>>>>>>>>>>>>>>>>>>
3. Comments should be wrapped at 70 characters.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
The main motivation is that as a community we would
> > > like
> > > >>> to
> > > >>>>>>>>>>> reduce
> > > >>>>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>>>>
discrepancy between what *clang-format* produces.
> > This
> > > >>> is a
> > > >>>>>>>> dual
> > > >>>>>>>>>>>>>>>>>> effort,
as
> > > >>>>>>>>>>>>>>>>>>>
we work on improving *clang-format* to support some
> > of
> > > >>> our
> > > >>>>>>>> style
> > > >>>>>>>>>>>>>> which
> > > >>>>>>>>>>>>>>>>>> is
> > > >>>>>>>>>>>>>>>>>>>
popular in the C++ community as well. Wrapping the
> > > >>> function
> > > >>>>>>>>>>>> arguments
> > > >>>>>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>>>>
avoid "jaggedness" for example is a feature request
> > > which
> > > >>>>>> is
> > > >>>>>>>>>>> being
> > > >>>>>>>>>>>>>>>>>> tracked
> > > >>>>>>>>>>>>>>>>>>>
at: https://llvm.org/bugs/show_bug.cgi?id=23422
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
Going forward, the proposal is to update all of the
> > > >>>>>> instances
> > > >>>>>>>> of
> > > >>>>>>>>>>>> (1)
> > > >>>>>>>>>>>>>>>> and
> > > >>>>>>>>>>>>>>>>>>>
(2) at once. For (3), we can simply relax the
> > > constraint
> > > >>>>>> from
> > > >>>>>>>> 70
> > > >>>>>>>>>>> to
> > > >>>>>>>>>>>>>> 80
> > > >>>>>>>>>>>>>>>>>>>
without touching the existing comments.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
Does anyone have any strong opinions about dropping
> > any
> > > >>> of
> > > >>>>>>>> the 3
> > > >>>>>>>>>>>>>> rules
> > > >>>>>>>>>>>>>>>>>>>
above?
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
Thanks,
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
MPark.
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> Deshi Xiao
> > > >>>>> Twitter: xds2000
> > > >>>>> E-mail: xiaods(AT)gmail.com
> > > >>>>
> > > >>>>
> > > >>>
> > > >
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message