►
From YouTube: OMR Architecture Meeting 20191121
Description
Agenda:
* Centralize the definition of Op Code lists in OMR (#4519) [ @dibyendumajumdar ]
* Use Clang to format the OMR source (#4577) [ @fjeremic ]
B
Welcome
everyone
to
this
week's
Omar
architecture
meeting
today
we
have
two
topics:
one
a
compiler
topic
and
one
broader
to
the
the
Omar
project
itself.
So
the
first
one
today
is
issue
45:15,
that's
right,
4519
from
Debian
you
so
he's
on
the
line.
He'll!
It's
going
to
take
us
through
that.
So
please
take
it
away
to
be
in
do
I.
C
Can
you
hear
me
yep
sorry,
yeah
well,
I'm,
just
going
to
introduce
the
topic
really
because
I
haven't
done
anything
any
particular
research
on
it.
You
know
just
wanted
to,
and
so
basically,
as
you
know,
I
have
got
my
own
project,
which
is
based
on
Omar
I,
just
a
cut
down
version
of
Omar
and
so
I've
noticed
that
obviously
I've
got
to
replicate
the
list
of
op
codes
that
Omar
has
and
so
maintaining.
C
That
is
a
problem,
because,
obviously,
if
op
codes
change,
then
I've
got
to
update
my
list
as
well
and
make
sure
every
time
I
think
changes.
I
have
to
compare
the
op
codes
to
make
sure
that
there's
no
discrepancy,
and
so
when
I
was
looking
at.
That
I
obviously
felt
that
this
is
a
problem
and
I
was
looking
at
a
way
of
improving.
C
That
and
I
noticed
that
basically,
the
opcodes
are
defined
in
a
header
file,
but
then
they're
also
repeated
I
mean
not
exactly
repeated,
but
the
same
sequence
of
codes
are
present
in
a
multiple
places
and
there's
a
common
way
of
handling
this
and
many
projects
I
think
one
of
them
was
mentioned
in
the
issue
as
well:
Mozilla
I
think
Firefox.
Was
it
a
can't
remember,
but
but.
C
Instead
of
defining
the
opcodes
in
a
header
file
in
the
header
file,
we
can
just
define
kind
of
a
macro
invocation,
so
you
know
it
can
be
anything
but
some
all
the
various
places
where
we
need
these
opcode.
They
associated
parameters
we
just
put
in
a
single
header
file,
but
we
don't
define
the
macro.
There
recently
invoked
a
macro
for
each
opcode,
passing
all
the
various
parameters
field
and
then
everywhere
we
want
to
use
these
op
codes.
We
define
the
macro
to
expand
what
we
need.
C
So
you
know,
for
example,
if
they
were
all
total.
That
said,
we
need
ten
fields.
Then
each
of
these
ten
fields
would
be
passed
in
the
macro
invocation,
but
then,
if
the,
if
the
location
there
is
like,
for
example,
if
I
mean
you
just
need
the
opcode
I
don't
need
anything
else,
then
I
would
define
the
macro
well,
I
mean
I,
need
it
and
I'd
expand
it
to
just
the
opcode,
and
so
therefore,
everywhere
we
just
defined
the
macro
locally.
C
Where
you
want
to
use
it,
and
so
the
expansion
is
in
your
control
in
the
location.
You
want
that,
but
you're
guaranteed
that
it's
the
same
list
everywhere
in
the
same
order,
so
that
was
the
proposal.
I
haven't
really
done
any
research
to
see
I
had
a
quick
look
because
in
the
opcodes
had
a
file
there
is
a
there's,
a
list
of
places
where
op
codes
are
defined.
So
I
had
a
quick
look
to
see
whether
this
was
a
viable
approach.
C
So,
in
my
brief
look
I
think
I
thought
it
was
viable,
but
you
know:
I'm
not
familiar
with
the
and
I
haven't
really
dug
deep
into
it.
So
you
guys
might
know
better
that
it's
not
viable
or
something,
but
from
what
I
saw
it
seemed
viable
to
me
and
I
feel
also.
That
does
not
need
to
make
immediate
changes
to
upstream
projects
like
they
can
consume,
because
when
the
upstream
project
uses
the
header
file
I
guess
he
only
had
a
file
they
might
use.
C
Is
the
standard
one,
the
opcodes
one
I'm,
not
sure
if
they
use
other
header
files
again,
so
you
can
have
I
guess
you
could
have,
because
the
expansion
would
apply
to
the
upstream
project
as
well.
So
they
would
see
the
expanded
form.
So
from
that
point
of
view
they
would
not
see
any
change
if
you
see
what
I
mean
so,
yes,
after
I,
tried
to
explain
what
I
would
have
been
trying
to
propose,
but
hopefully
it's
clear.
If
it's
not,
then
please
shout
yeah.
B
Yeah,
so
thanks
for
raising
this
issue,
so
we
have
done
some
experimentation
within
the
compiler
already
with
the
similar.
A
similar
technique
is
this.
So
if
you
look
in
the
x86
code,
generator
the
way
that
the
instructions
and
their
properties
and
and
other
things
are
defined,
it's
it
uses
sort
of
a
similar
macro
approach
as
well.
So
it's
so
this
I
guess
this
using
this
approach.
Isn't
that
unprecedented
for
OMR?
There
certainly
are
some
benefits
to
it.
B
The
one
little
wrinkle
in
some
of
this
as
well
is
the
way
that
we
have
to
so
the
way
that
some
of
these
op
codes
are
being
used
in
projects
it.
The
the
table
that
actually
gets
synthesized
is
actually
amalgamated
from
multiple,
like
a
contribution
for
a
while
or
a
contribution
from
a
downstream
project
like
like
open
drain,
I
mean,
for
example,
and
we
put
those
two
bits
of
information
together
into
the
same
table.
B
B
E
B
Don't
think
they
should
go
there.
I
think
I
really,
don't
think
that
the
OP
code,
like
the
properties
of
the
op
codes,
yes,
the
handlers
for
any
particular
op
code
need
may
need
to
vary
depending
on
the
project
right
you,
you
may
want
to
change
it.
You
know
in
January,
for
example,
the
handler
for
a
particular
op
code
may
be
a
different
entry
function
that
then
delegates
up
to
the
parent
I
think
we
need
to
try
and
keep
there
if
we
go
with
this
approach.
B
D
B
What
I'm
saying
is
that
at
the
OMR
level
you
mean
you
can
declare
a
handler
table
right
and
that
handler
table
will
have
entries
that
correspond
to
the
Omar
codes.
Now,
whether
we
have
extensible
op
codes
or
not
I'm,
going
to
leave
that
aside,
when
open
j9
consumes
OMR,
they
may
have
additional
semantics
or
additional
things
that
they
wish
to
do
when
they
process
a
particular
op
code.
Call,
for
example,
would
be
a
good
example,
but.
B
B
D
D
B
D
B
I
could
I
could
buy
something
like
you
know.
We
synthesize
it
by
doing
some
token
pasting
of
like
the
operator
name
with
the
word
evaluator
and
we
regularize
the
frontline
names
became
better
and
then
you
could
just
have
an
extensible
class
with
static
functions
on
it
or
something
that
you
could
override
it.
If
you
oh
yeah
or
a
non
extensible
class,
you
do
therefore
devil,
and
you
overrides
I'm,
using
virtual
and
there's
trying
to
avoid
having
to
maintain
five
different
tables.
B
Okay,
right
right,
but
I,
don't
think
that
we
should
function
like
if
you
want
to
derive
the
table
from
the
macro
name
like
the
opcode
name
or
whatever
the
hell
you
choose
to
do
with
it.
I'm
fine,
but
I,
don't
want
about
putting
function,
pointers
or
names
of
functions
to
be
turn
into
function,
pointers
into
the
actual
opcode
table.
It's
also
not
very
extensible,
because
the
more
foundation
that
you
write
that
need
to
process
all
the
opcodes,
the
more.
D
B
Yeah
I
think
it's
more
like
what
you
want
it
like
in
the
review
process
that
we
would
want
for
changes
to
those
particular
files
or
to
that
area
of
the
code.
There's
almost
certainly
different
than
if
you
were
proposing
some
changes
to
how
the
handlers
are
structured,
right
and
being
able
to
say
if
you're
doing
and
commit,
but
touches
these
files.
A
certain
set
of
rules
or
procedures
or
review
has
to
apply,
is
easier
to
maintain.
B
So
yeah
building,
but
what
you
would
do
is
you
it
you
would
do
so
when
you
go
to
define
the
array
of
function
pointers,
you
would
write
the
start
of
the
Declaration
of
the
array.
Immediately
then,
ahead
of
that
you
would
have
the
you
would
do
the
define
of
the
macro.
You
would
include
the
header
so
that
when
with
that
macro
defined,
it
will
expand
and
what
it
would
expand
to
is
just
the
name
of
the
opcode,
and
you
can
toke
and
paste
that
name
with
whatever
suffix
you
wish
to
apply
to
it.
B
And
then
you
just
generate
a
list
of
tokens
essentially
which
become
identified,
functions
and
that's
how
LLVM
does
that
kind
of
thing
use
macro
token
pasting
to
joining
a
felon
whose
table
Jen
so
parts
of
it,
it's
all,
being
rewritten
to
use
table
Jen
the
part
that
we're
using
that
took
and
pasting
approach
before.
That's
because
they're
yeah.
F
D
I
guess
it
depends
on
how
exactly
you
want
to
do
it.
If
you
want
to
do
it
with
the
extensible
class
method,
what
you
do
is
you
would
have
a
base
class
that
has
all
of
these
methods
on
it.
With
the
default
blank
dummy
implementations
that
I'm
you
would
inherit
for
that
and
override
the
ones
you
want,
whether
that's
that
done
statically
or
with
virtual
methods
as
sort
of
an
implementation,
but
you
would
only
override
the
ones
that
you
want
subtle,
behavior,.
C
B
B
B
Another
example
would
be
the
simplifier,
the
simplifier
here,
there's
a
number
of
things
in
the
optimizer,
where
you
want
to
define
behavior
her
op
codes,
so
you're
going
to
have
a
handler
for
each
particular
op
code.
That's
going
to
do
something
and
you're
going
to
implement
one
of
those
functions
per
opcode
to
do
whatever
supposed
to
do
for
that
off
code.
B
C
B
Personally,
I
do
implementation
for
most
codes,
there's
usually
some
kind
of
default,
which
is
bit
like
so
for
the
simplifier,
for
example,
some
of
the
off
notes
there
isn't
anything
that
we
want
to
do
other
than
to
simplify
the
children
of
that
node.
So
there's
actually
a
default
simplifier
function,
which
simplifies
just
said,
simplify
my
children
and
then
return,
and
that
default
gets
put
into
a
number
of
entries
in
the
table.
B
C
Sure
and
I
agree
with
what
you
were
saying
before
is
that
the
macro
list
isn't
gonna
solve
this
problem.
It's
not
meant
to
be
kind
of
a
mapping
from
say
opcode
to
handler
I
think
that
needs
to
be
done
by
each
each
place
where
you
want
to
use
the
so
yeah.
So
I
agree
with
what
you
were
saying
before:
I.
B
B
So
if
you
look
at
simplifier,
for
example,
there's
a
number
of
places
where
we
just
use
default
simplifier,
which
just
says,
simplify
the
children
and
carry
on
right,
there's
nothing
special
to
do
for
this
guy
and
all
of
those
currently
are
all
represented
by
one
function:
not
one
function
for
each
that
just
simplifies
the
children.
We
may
have
to
think
a
little
bit
more
about
how
maybe
doing
something
a
little
more
so
kated
with
the
macro
to
avoid
having
to
expand
a
number
of
functions
to
one
per
opcode.
C
Yes,
so
the
way
I
was
seeing
it
is
that
I
was
seeing
it
more
as
something
where
you
don't
have
any
impact
on
the
current
consumers
of
these
opcodes,
which
means
that
they
see
exactly
what
they
see
now.
So
it's
slightly
controlling.
So
at
the
moment
you
have
I
think
six
or
seven
places
like
whether
the
list
of
these
opcode
related
things
right
and
they
all
have
to
be
in
the
same
order,
I
guess
and
they
all
have
to
match
the
opcode
list.
C
B
The
other
problem,
though,
is
that
if
you
go
and
add
an
OP
code
in
Omar
at
the
moment,
you
need
to
know
where
all
of
the
Omar
tables
are
that
are
derived
from,
but
I
have
to
match
that
OP
code
list
so,
like
you
were
asking
before
and
I
just
said,
pp
and
simplify
right
off
the
top
of
my
head.
I
know
you
need
to
go
and
modify
those.
B
That
says
these
are
ones
that
have
custom
handlers
if
it's
not
in
there
use
default
whatever,
and
that
will
just
map
to
the
default
which
just
does
whatever.
The
simple
thing
is
right,
like
simplify
the
children
or
constrain
the
children
and
carry
on
ideally,
whatever
solution
we
pick
I
think
would
address
both
of
those
problems.
C
Sure
so,
to
take
a
specific
example,
I've
just
been
looking
at
this
file
called
OMR,
simplify
our
table,
enum,
dot,
HPP
right
and
in
that
table.
You've
got
a
list
of
values
against
each
of
the
opcodes,
like
DFT,
simplifier
maps
to
bad
IL
off
and
then
DFT
simplified
to
a
Const
and
const
simplified
to
iconst
and
so
on,
yeah
yeah.
B
Was
objecting
to
was
putting
that
as
a
thing
into
the
opcode
table.
The
opcodes
should
not
be
coupled
to
the
optimisation
handlers.
The
better
way
to
do
it
is
to
derive
the
names
of
the
handlers
from
the
opcode,
and
you
can
then
do
that
using
macros
and
and
pasting
so
that
you
don't
have
to
embed
the
handlers
into
the
opcode.
C
You
know
it's
not
gonna
work
right
because,
for
example,
if
you're
talking
about
the
same
table
that
I'm
looking
at
then
the
multiple
of
course
map
to
the
same
value,
and
you
can't
just
derive
that
from
any
using
any
logic.
Can
you
so
in
a
simple
expansion
will
not
be
able
to
expand
it
to
the
right
value
if.
B
F
C
F
D
The
kinds
of
concerns
that
I
would
have
if
we
start
putting
function,
pointers
into
the
OP
code
table
itself,
is
what
happens
if
a
derived
project
want
that
its
own
optimization?
That
also
has
this
behavior.
They
can't
modify
om,
r's
opcode
table
to
add
a
new
field
for
every
single
aapke.
That's
how
I
knew
you.
B
D
B
Name:
entry
in
the
Yaak
row
right,
so,
if
you,
if
you
go
and
say
the
hands
of
the
VP
handler
for
this
particular
opcode-
is
named
whatever
right
and
the
simplifier
handler
for
this
thing
is
whatever.
If
in
a
derived
project,
I
want
to
create
what
Ben
was
saying
of
a
per
opcode
handler
in
an
optimization
that
does
not
exist
in
all
our
adding.
That
is
practically
impossible
in
that
model
right.
B
So
you
can
derive
the
name
of
the
handler
and
have
a
macro
mechanism
where
we
could
default
right
so
that
if
you
don't
specifically
say
that
you're
going
to
handle
one
right
through
the
macro
egg
mechanism,
but
you're
just
going
to
get
a
default,
that's
going
to
require
a
little
bit
more
thought
on
how
to
make
that
expansion
work,
but
I
think
it
macro.
The
macros
are
essentially
turn
complete
almost
anyway,
so
they're,
not
quite
the
templates,
are
everything.
A
A
A
It
so
would
be
a
compilation
error
and
it's
very
clear
which
thing
is
missing
and
you
wouldn't
necessarily
have
to
implement
it
in
a
list
and
make
sure
that
it's
in
the
same
order,
but
you
would
still
have
to
implement
it
manually
right.
So,
if
there's
kind
of
an
it
I
think
we
should
have
a
towards
a
solution.
D
B
D
G
G
B
B
B
It
would
the
thing
anything
that
is
based
on
like
an
enum
range
check
at
the
moment,
should
be
converted
into
a
proper
property
that
can
be
tested
on
the
the
opcode
itself
right
and
you
might
have
to
grow
some
extra
bits
to
do
it,
but
that
would
be
far
safer
and
more
expensive.
Alif.
We're
really
true
worried
about
the
extensibility
and
the
ability
to,
and
this
stuff
we're
lying
on.
Coup
on
adjacency
in
the
enum
seems
like
the
most
fragile
thing
you
could
possibly
do.
D
B
So
did
the
in
do
I
think
that
the
the
general
consensus
here
is
that
it's
a
it's
a
good
design
pattern
for
us
to,
for
us
to
adopt
more
broadly
within
within
the
code
base.
I
think
that
there
are
some
areas
that
we
do
need
to
explore
here.
I'm
wondering
is
this
something
that
you're
willing
to
experiment
with
and
perhaps
propose
a
like
a
nap
in
a
pull
request,
some
some
ideas
or.
C
C
B
C
B
C
C
One-To-One
mapping
is
easy
enough,
because
you
can
just
follow
pattern
right,
yeah
or
you
could
implement
it
by
saying
it's
always
one-to-one
mapping
and
any
any
and
individually
those
mappings
have
to
forward
those
handlers
have
to
forward
to
a
common
handler
if
they
wish
to
use
a
common
handler.
You
could.
B
B
Create
the
concern
that
I'd
expressed
about
that
which
does
need
to
be
addressed.
This
in
course
blow
tight.
So,
oh
you
do
it
well.
Is
that
but
the
size
of
the
binary
by
the
compiler,
because
the
open,
j9
project
and
other
projects
do
care
about.
How
big
is
the
project
is
when
it's
built
it's
fairly
weight
as
it
has
in
it
a
little
bit
more
overweight
is
not
going
to
in
dearest
to
anybody
yeah
and
the
other
I.
C
C
Yes,
so
I
was
originally
thinking
of
is
to
just
include
the
name
of
the
handler,
obviously,
without
realizing
that
it's
the
handler
I
just
saw
it
as
a
list.
I
didn't
realize
that
it
was
a
handler
which
is
the
name
of
a
function
or
whatever,
but
obviously
I
originally
thought
it'd
be
a
parameter
to
the
macro.
Now
that
potentially,
is
I.
Think
what
you
guys
are
saying
is
that
could
cause
a
problem
for
say,
open,
j9,
right,
yep.
D
Last
point
I
was
got
me
fact
that
we
should
probably
do
some
archeology
to
see
if
we
can
find
the
issues
items
that
that
Lea
would
have
opened
when
he
was
going
through
this
last
time
in
creating
the
OP
code
table
that
there
now,
because
he
may
have
evaluated
some
other
options
as
the
part
of
that
process,
and
we
should
at
least
recover
understand
what
thought
process
he
went
through.
If
we
can.
Okay,
that
plays
out
barring
any
way,
we'd.
B
E
Okay,
so
we're
back
here?
A
year
later,
we
had
a
short
initiative
last
year
to
try
to
introduce
some
claim
formatting
into
the
code
base,
never
really
made
it
to
production
or
one
reason
or
another,
and
here
we're
trying
to
resurrect
that
that
project.
So
in
45,
77
listed
some
background
information
and
a
couple
of
discussion
points
which
we
can
talk
about
during
here.
E
I,
don't
expect
us
to
shool
of
this
or
even
make
any
decisions
here,
I'm
just
going
to
take
notes
on
an
especially
discussed
on
and
even
have
a
community
retrospect
after
the
fact.
So
the
whole
idea
here
is
to
introduce
some
automation
to
format
our
source
code
into
consistent
and
documented
style,
which
will
be
tool
checked
on
debatable,
something
we'll
have
to
discuss
and
some
of
the
some
of
the
benefits
of
automatically
formatted
code.
I
listed
a
couple
of
projects
down
at
the
bottom
case.
Studies
politically
Mozilla
is
going
through.
This
right
now
go
format.
E
E
So
I
guess
in
in
summary,
I
wrote
a
couple
things
on.
Why
I
think
we
should
form
our
code
into
a
consistent
style,
it's
easier
to
write
and
you
don't
have
to
worry
about
formatting,
install
the
tool
and
your
favorite
editor
and
format
your
code
and
as
soon
as
you're
done
writing
it.
It
easier
to
read.
The
core
base
is
consistent
from
pending
on
what
component
working
on,
whether
it's
GC
or
the
VM
or
the
compiler,
or
each
individual
koujun
within
the
compiler.
E
If
things
are
consistent,
you
know
exactly
what
to
expect
and
you
won't
be
caught
off
by
close
formatting
inconsistencies
between
the
components
you're.
Looking
at
it's
also
easier
to
maintain
I
noticed
many
times
when
we
make
our
changes.
We
have
our
editors
configure
to
eliminate
white
space,
so
introduce
tab
basis.
Yada
yada,
we
all
some
of
us
formats
code
files
that
at
the
same
time,
so
introduce
a
whole
bunch
of
I
needed
white
base
changes
all
around
here,
your
code,
which
is
just
noise
in
the
TR.
E
If
we
settle
on
a
particular
style,
we
never
have
to
argue
about
code
stylist
and
NPR's,
and
we
can
just
avoid
that
the
tool
will
do
it
for
us
and
we
can
focus
on
the
semantics
of
the
contribution
rather
than
in
style.
So
there's
some
of
the
points,
I
guess
the
pros
towards
it.
Of
course,
this
is
going
to
be
a
pain.
It's
a
controversial
subject:
I
tried
to
show
you
the
subject
work
for
some
developers,
so
we
need
really
a
community
contestant
contestants
before
we
head
down
this
path.
E
C
C
F
B
C
B
If
statements
are
highly
complex
and
at
the
moment
the
formatting
of
those
things
is
being
done
with
some
care
by
the
people
who
went
and
put
them
in
to
try
and
eighth
the
comprehension
of,
what's
going
on
now,
I'm,
not
saying
that
that
cannot
be
preserved
by
a
tool.
But
things
like
hard
column
limits.
Rigidly
enforced
sort
of
ways
of
some
of
the
things
being
indented
and
formatted
can
significantly
hamper
reading
some
of
the
more
complex
parts
of
this
compiler.
Because
of
the
nature
of
that
code.
B
Now,
I'm
not
saying
that
we
can't
overcome
that
with
an
appropriate
style
and
I'm
certainly
willing
to
consider
it
just
saying
just
saying
that
there's
a
file
and
forcibly
applying
it
without
looking
at
what
happens
in
these
parts
of
the
code
is
negligent,
because
it
will
significantly
hamper
the
ability
to
find
and
fix
problems
in
this
code
and
to
understand
what
it's
doing.
Format
will
be
consistent,
but
it
will
be
unreadable
consistent,
Andrew.
B
Don't
know
that
it
is
an
argument
for
incremental
'no,
sits
an
argument
for
some
careful
consideration
of
the
style
choices
that
are
made
and
looking
at
how
they
affect
the
most
complex
parts
of
the
code,
the
interpreter
and
in
the
JIT
we're
going
to
style
both
of
them.
We
need
to
make
sure
that
your
ugliest
thorniest
nastiest
most
nested
parts
of
the
code,
with
the
biggest
condition
for
matches
well
and
the
stuff
deep
inside
the
chip
formats.
Well,
I
really
worry
that
we're
going
to
have
a
much
harder
time
reading
some
of
those
conditions.
B
H
A
F
We
should
do
that
any
I
mean
good
my
my
opinion
here
isn't
every
time.
Somebody
goes
down
this
road,
a
ton
of
time
how
we
should
do
it
style.
Somebody
in
the
past
has
tried
to
match
it
up
the
current
tester
of
the
file,
and
somebody
has
done
this
and
that
such
a
waste
of
time
and
I
you
know
I
agree
that
there
are
places
where
we
have
conditionals
that
are
tough
to
read
that
need
careful
formatting
to
make
them
readable.
F
B
B
I
One
of
the
approaches
we've
taken
to
this
with
thee
with
the
g9
code
base
before
it
was
open
sourced,
was
we
wrote
up
a
coding
standard
on
what
the
rule
should
look
like
and
applying
it
incrementally
as
we
modify
code,
so
anything
that
was
modified
got
adapted
to
what
our
new
rules
were.
Anything
that
was
pre-existing
was
left
and
this
significantly
decreased
the
risk,
because
you
were
only
reformatting
and
modifying
the
pieces
that
were
actively
being
worked
on
anyways.
E
D
It
for
us
or
I,
can't
have
a
tool
to
check,
there's
parts
that
are
never
gonna
get
touched,
yeah
yeah
for
years
and
we'll
actually
be
in
a
worse
state
while
we're
in
flux,
because
we'll
have
both
the
old
and
the
new
in
places
that
I
plus
the
new
in
places
where
we're
not
happy
with
it,
not
sure
that
sounds
like
a
less
risky
it
also.
It's.
E
E
C
So
I
think
I
think
you
know
I
think
if
you
care
about
the
formatting,
which
has
been
done
specifically
in
certain
places,
then
just
tell
clang,
because
you
can
tell
client
not
to
format
certain
bits.
So
this
just
put
some
trying
instructions
to
say:
don't
format
this
file
and
that's
it
and
I'm
suspect
that
there'll
be
a
handful
of
such
files.
There,
probably
only
a
few,
the
rest,
you
probably
don't
care
about
right.
E
C
Only
where
somebody
says
I
really
have
formatted
this
in
a
specific
way
and
I
care
so
much
about
it.
I
can't
lose
it
like
what
was
being
said
a
short
while
ago,
only
so
only
when
somebody
explicitly
says
that
they
want
this
to
be
absolutely
formatted
in
this
way.
No,
the
way
you
could
start
by
saying:
okay,
let's
just
section
this
code
off,
say
to
clang,
don't
touch
this
code
and
that's
it.
The
rest
of
the
code
base
just
gets
reformatted
personally
I
think
it's
a
no
brainer.
Really.
C
D
D
My
line
in
the
sand,
so
I'm
not
I'm,
also
not
interested
in
talking
about
any
of
the
details
of
how
to
format
the
code
and
whether
it's
tabs
or
spaces
or
whatever,
for
clang
or
Mozilla
or
whatever
format.
I.
Don't
know
you
guys
can
figure
that
out.
I'm
sure
I
have
great
confidence
and
everybody's
ability
to
figure
that
out
and
I
have
pretty
good
confidence
in
my
ability
to
be
able
to
read
whatever
code.
D
Is
there
in
front
of
me,
so
not
that
I
have
to
do
it
as
much
as
you
guys
do,
I
think
I'm,
agreeing
I
guess
with
the
frustration
over
the
amount
of
time
that
we've
spent
discussing
this
and
considering
it
in.
In
my
opinion,
the
benefits
outweigh
the
costs
as
long
as
we're
cognizant
that
there
may
be
places
where
we
need
to
undo
this
in
order
to
make
it
practical
to
work
with
a
code
base.
Marc.
D
F
D
E
The
automation
discussion
comes
in.
Do
we
want
to
have
automation
built
around
this,
which
is
already
available
in
tons
of
other
open
source
projects,
for
example,
get
a
book
which
will
guard
checking
in
code,
which
is
does
not
fit
the
formatting
style
until
just
be
up
with
a
copyright
check.
Failure
it's
like
a
job
on
end
commuters
will
not
merge
your
change
unless
it's
properly
formatted.
E
B
The
idea
of
a
of
a
pull
request
check
for
the
formatting.
This
like
Peter,
said
I,
also
think
that
the
before
you
deliver
your
code,
I
think
actually
running
something
locally
to
actually
do
the
formatting.
So
you
can
see
it
yourself.
If
something
very
bizarre
is
happening,
I
mean
trip.
I
would
think
that,
for
the
most
part
your
code
is
going
to
match,
but
the
formatting
more
or
less
of
spaces
where
but
or
maybe
the
brace,
is
on
a
different
line.
I
A
Of
a
principle
projects,
do
this
I
think
there's
an
expectation
in
general
if
you
contribute
to
a
project
you're
going
to
follow
their
guidelines
and
whether,
if
you
don't
follow
them,
whether
that
results
in
like
a
tool
telling
you,
you
did
something
wrong
or
a
committer
telling
you.
You
did
something
wrong
in
a
comment
like
either
way.
I,
don't
think
it
really
changes
that
much.
I
E
A
E
D
C
Me
they're
saying
to
me:
it's
a
no-brainer,
really
I
mean
I,
always
have
and
format
I
mean
all
modern
tools
like
Visual,
Studio
or
sea
lion
or
I
use,
Scylla
and
visual
studio
or
vs
code.
They
all
support,
plan
format,
out-of-the-box
and
the
moment
they
see
a
plan
format
file.
They
will
format
your
code,
they
using
the
crank
format.
So
I
don't
see,
I
mean
to
me
it's
a
no-brainer,
really
I,
don't
see
why
it's
a
problem.
If,
if
people
are
using
VI,
maybe
I
don't
know
it's
such
a
pain.
C
C
Match
it
is
such
a
nightmare,
because
your
IDE
keeps
messing
it
up
because
it
doesn't
know
about
your
formatting,
how
you
want
it.
So
it's
a
nightmare,
I'm
telling
you
where
the
solution
is
so
simple:
just
have
plan
format
there.
It
does
it
for
you
and
you
can
have
something.
If
you're
really
concerned,
you
can
have
commit
hoax
or
whatever,
so
that
every
time
somebody
pushes
a
change
it
automatically
reformat
so
I
think
some
projects
do
that
I've
not
done
that
personally,
but
I
always
use
crank
format
for
all
code.
E
Looked
into
other
project
which
do
formatting
as
a
post
commit
so
what
they
would
do
is
they
would
take
your
entire
PR
change
and
format
the
emerging
from
it
and
then
create
another
commit
from
that.
The
issue
with
that
is
I
found
is
that
people
complain
that
it
introduces
your
local
repo,
no
longer
man.
C
E
D
A
D
I,
don't
I
don't
buy
the
over
making
it
harder
for
people
to
contribute
to
Omar
either
I
mean
the
the
alternative
buzzing
claim
or
not,
which
isn't
that
hard
to
get
is
read
and
process
and
diagnose.
It
gets
a
1500
line,
markdown
file
that
describes
our
coding
standard
right
now.
That's
kind
of
absurd
in
a
way
I
mean
not
followed,
they're,
all
relatively
well
justified
and
all
that.
So
it's
not
just
like
there's
lots
of
stuff
in
there.
That's
not
strictly
speaking,
documenting
the
coding
rules
format,
but
given
the.
J
A
G
I
H
B
In
terms
of
the
the
parts
of
Omar
that
have
had
the
most
external
contributions
to
it,
I
think
that
the
compiler
and
JIT
builder
have
had
them
the
most
external
moment.
I
mean
when
I,
say
external
I
mean
outside
of
IBM
contribution,
so
those
are
the
ones
that
tend
to
get
the
most
feedback
about
style
and
and
and
and
editing,
and
that
and
that
sort
of
thing.
B
E
Very
common
I
think
if
anyone
has
concerns
about
formatting,
an
entire
large
code
base,
I'm
talking
a
million
lines
plus
have
a
look
at
some
of
the
case
studies
and
read
some
of
the
blog
posts
from
the
other
engineering
teams
who
have
been
through
this
and
some
of
the
feedback
that
was
received
after
the
fact.
I
think
it's
enlightening
at
the
very
least,
to
get
some
perspective
from
another
project
on
rather
than
based
on
assumptions
off
of
what
we
think.
D
E
G
H
E
B
E
Has
a
blog
post
on
handling
that
specifically,
so
they
have
a
Rick
way
of
solving
that
by
creating
an
extra
commit
which
people
can
merge
onto
it
cleanly.
Okay,
so
it's
a
problem:
they
they
started
down
on.
They
realized
it
was
going
to
be
an
issue
and
they
found
a
way
to
fix
it
and
have
a
detailed,
step-by-step
instructions
on
credit
projects
on
how
it
is
because
everyone's
code,
that's
in
flight
right
now,
it
will
be
having
merge
cost
later
after
this
d-day,
I'm
good.
G
B
I
would
suggest,
if
we're
going
to
pick
a
date
in
December,
that
we
respect
the
be
cut
date
for
open,
j9
January
release,
because
we'll
be
a
bunch
of
stuff
that
people
want
to
merge
ahead.
In
fact,
each
your
complete
date
stuff
that
will
go
into
Omar
as
part
of
their
contribution,
minimize
their
pain.
What
is
a
December.
D
E
D
This
all
those
streaks
means
the
kind
of
thing
we
should
do
in
a
visual
committer
votes
on
to
get
everybody
on
record,
having
either
an
airport
or
not
support
whatever
and
like
get
it
on
record
in
essentially
right,
because
this
is
a
something
that
will
have
a
broad
effect
on
the
project
so
yeah.
We
can't
beside
that
here
could
design
it
in
the
issue,
but
I
think
we
should
call
for
a
committer
vote
this
once
we're
comfortable
that
we
know
what
it
is
being
proposed.
That's
the
key
thing
right
now.
B
G
D
E
D
D
I
D
E
D
I
A
Mean
I
think
specifically
with
something
like
Frank
format.
If
we're
talking
about
local
development,
there's
nothing
that
going
to
require
people
to
install
crying
format
on
their
local
machine
if
they
want
to
just
write
their
codes
so
that
it
follows
the
coding
style
right
and
there's
like
no
need
for
them
to
vocally,
have
cranked
format
installed.
B
E
H
G
G
Equal
some
of
these
files
that
people
are
concerned
about
might
work
better
with
certain
styles.
That's
one
phase
two
except
some
of
the
feedbacks
that
come
during
the
call
ask
people
for
one
or
two
files
that
they're
particularly
concerned
about
maybe
test
out
some
of
these
main
formatting
options.
Auditing
sounds
and
runners
find
those
people.
A
A
One
question
I
had:
is
there
a
friend
yet
or
how
we're
going
to
roll
this
out,
like
ideally,
I
would
like
to
have
the
automation
setup
before
we
do
the
formatting
kind
of
having
all
of
that
set
up
ahead
of
time,
so
that
then,
when
we
do
format
the
entire
code
base,
it's
all
ready
to
go
and
we
don't
have
to
scramble
to
figure
out.
Why
that
the
automation
isn't
working
I
would.