►
From YouTube: incr-comp kick-off meeting 2020-08-05
Description
Kick-off meeting for the Incremental Compilation Domain Working Group! We are a group of Rust Compiler Contributors who are interested in making the compile times faster by improving the incremental compilation subsystem. This is the first of our weekly synchronous meetings.
A
Okay,
so
we
made
a
set
of
agenda
topics
on
the
fly
and
we've
just
reviewed
the
charter
and
revised
it
slightly
and
then
all
sort
of
approved
it.
So
these
links
are
up
there
and
in
the
zulu
chat
and
I'm
I'm
gonna
put
in
the
actual
chat
session,
the
the
actual
links
to
the
two
things
or,
if
I
can
find
them
actually
could
someone
else
post
in
the
chat.
A
The
two
do
you
know
if
a
meeting
recordings,
if
it
helps
to
post
in
the
chat
with
me
recordings
I've
never
looked
at
a
zoom
meeting,
recording
to
to
know
like
whether
the
chat
messages
show
up
in
some
fashion
in
the
recording.
So
maybe
this
is
not
a
useful
way.
I've
been
wondering
how
one
can
send
text.
B
A
C
A
C
A
Obviously
I
don't
know
enough
about
this
to
be
to
use
it
usefully
it's.
Okay,
we've
got
information
in
the
zoom
in
the
zulu
stream
topic
about
this.
So
let's
see
here.
The
other
thing
then
so
is
that
we
yeah
we
said
we
made
a
selection
of
the
charter
and
now
we're
gonna
move
on
the
next
agenda
topic.
Oh,
we
talked
a
little
about
alternate
this.
A
This
meeting
cycle,
we've
all
sort
of
agreed,
we'll
try
a
bi-weekly,
a
weekly
meeting,
but
the
timing
will
alternate
each
week
so
that
effectively
we'll
expect
to
see
nick
here
every
other
week,
and
hopefully
we'll
see
david
here
on
the
alternating
weeks.
We
haven't
established
the
alternate
meeting
time
yet
I'll
make
an
action
item
to
let's
see
here
actually
actually
items.
We
need
to
actually
come
up
with
the
second
meeting
time
for
the
second
meeting
to
accommodate
david's
wpa
co.
A
B
Maybe
we
can
start
with
wesley,
so
I
guess
I'm
coming
at
this,
mostly
from
the
mirror
optimization
perspective.
We
are
trying
to
land
various
mirror
optimizations
and
we
often
run
into
issues
with
our
incremental,
at
least
our
incremental
benchmarks.
So
I
know
we
had.
We
had
a
meeting
was
that,
probably
about
a
month
ago
or
two
months
ago,
kind
of
talking
through
what
the
current
issues
are
with
that?
I
don't
think
we
really
got
to
solutions
in
that
meeting.
B
So
I
think
for
me,
I
personally
would
be
interested
in
trying
to
figure
out
you
know
what
can
we
do
with
our
cogen,
specifically
to
kind
of
minimize
some
of
the
issues
that
the
mirror
opt
teams
is
running
into?
I
feel
like
there's
honestly,
some
probably
low-hanging
fruit
there
if
we
can
find
the
right
tweaks
to
make
to
the
current
algorithm.
So
that's
something
that
I'm
I'm
kind
of
focusing
on,
but
would
definitely
appreciate
input
and
ideas,
and
things
like
that,
so
that
might
be
an
appropriate
project
group
to
spin
up.
D
I
also
feel
that
we
we
have
we.
We
should
have
something
big
to
gain
somewhere,
hopefully
low
hanging
from
the
coast
and
partitioning
schemes,
and
I
depending
on
uni,
because
I
I
I
am
waiting
on
bureau
bureaucracy.
I
should
be
starting
my
thesis
on
mirops
soon-ish,
I
hope,
but
I
I
want
to
help.
I
want
to
help
you
wesley,
at
least
at
least
brainstorming.
I
don't
know
so.
A
Okay,
all
right
and
from
my
perspective
I
I
also
have
been
interested
in
the
code
genuine
stuff,
but
I'm
happy
to
let
other
people
take
focus
on
that,
because
the
other
big
one
is
the
purification
work
to
try
to
make
more
parts
the
compiler
make
use
of
the
query
system
and
to
identify
maybe
problems
that
are
arising
where
the
queer
system
isn't
acting
as
incremental
as
it
should
be.
So
I've
been
meaning
to
sort
of.
A
Understand
that
part
of
the
system
better
and
I'd
be
happy
to
try
to
fire
off
a
project
there.
I
know
because
in
particular,
because
I
know
that
there's
some
work
there's
some
other
people
that
have
either
made
pull
requests
or
proposals
for
major
changes
involving
the
query
system
that
would
be
relevant
here.
So
that's
sort
of
the
other
big
area
that
I
think
I've
been
I've
been
strongly
encouraged.
A
B
I
think
sort
of
related
to
that
I've.
I've
definitely
seen
a
small
handful
of
prs
that
have
tweaked
what
things
are
included
in
the
incremental
cache,
like
which
query
results
are
included
in
the
incremental
cache
and
which
ones
are
not,
and
sometimes
it's
faster
to
recompute
things
than
it
is
to
actually
serialize
them
to
disk
and
deserialize
them
back
or
vice
versa.
So
there's
there's
potentially
some
improvements
to
be
made
there
as
well.
Okay,
okay,.
E
So
my
motivation
is
just
compile
times
in
general
and
I
don't
have
much
in
the
way
of
preconceived
notions
other
than
I
just
have
this
gut
feeling
that
incremental
isn't
working
as
well
as
it
could
yeah.
Just
like
you
know
you
do
a
full
compile
and
it
takes
a
certain
amount
of
time
and
then
you
change
one
line
and
it
takes
half
as
long
maybe-
and
it
just
seems
like
that,
doesn't
seem
right
yeah.
Maybe
it's
like
there's
room
for
so
I
think
that's.
A
I'm
curious
to
know
like
whether
those
changes
you
should
make
to
our
instrumentation
in
some
fashion,
to
make
profiling
more
useful
for
stuff
in
their
comments?
Well,
I
don't
know
wesley
you've
done
a
lot
of
work
with
like
the
self-profile
stuff.
So
maybe
you
have
a
better
idea
here
of
what
the
problems
are,
but
something
that
came
to
my
mind
is
something
we
might
need
to
look
at,
though
I
know
nothing
about
what
we
might
do.
B
I
mean
I
so
I'm
definitely
interested
to
hear
what
what
nick
has
to
say,
but
at
least
from
my
perspective,
there's
not
necessarily
a
ton
of
information
exposed
to
our
self
profiler
about
incremental
performance
other
than
just
kind
of
high-level
metrics
like
how
long
it's
taking
to
serialize
or
deserialize
stuff,
or
how
long
code
gen's
taking
or
whatever
kind
of
related.
To
my
first
point
it
would
they're,
like
the
project
group
that
I
kind
of
want
to
spin
up.
B
It
would
be
useful
for
me
to
have
easier
to
understand,
or
at
least
easier
to
look
at
information
in
maybe
an
unstable.
You
know
debug
option
or
whatever
about
what's
going
in
the
cogen
units
and
how
big
they
are
and
how
long
they're
taking
to
compile
you
can
get
a
lot
of
that
with
tracing
with
the
right.
You
know
rusty
log
trace
flags
or
whatever,
but
it's
kind
of
painful
to
sift
through,
especially
if
you're
trying
to
figure
out
you
know.
Where
did
where
did
this
thing?
B
B
B
E
So
I
haven't
done
very
much
profiling
that
sort
of
of
incremental,
like
a
like,
if
you
look
at
incremental
with
external
tools,
I
haven't
used
the
self
profile
that
much
like
you
get
the
obvious
things
like:
there's,
hashing
costs
and
there's
serialization
costs,
and
I've
done
some
stuff
to
speed
those
up.
But,
like
I
haven't,
looked
into
the
actual,
what
incremental
is
doing
and
like
trying
to
just
work
out
is:
is
it
recomputing
things
that
it
shouldn't
or
is
it
you
know?
E
A
A
Well,
it
sounds
then,
like
the
most
immediate
things
to
look
at
are
the
the
you
know
the
cogen
partitioning
and,
like
I
said,
the
query
system
and
then,
if
we
can
on
the
along
the
way,
discover
other
potential
projects
that
spin
up.
We
can
do
that,
but
most
obviously
that
seems
like
wesley
and
felix.
I
don't
know
probably
another
way
to
refer
to
if
you
and
I
feel
like
it's
our
first
name's,
not
credit.
How
do
you
pronounce.
D
A
Yeah,
like
not,
we
have
to
use
last
names.
I
just
figured.
You
know
great
some
way
to
get
our
references
here.
Okay,
oh
santiago,
is
there
anything
that
you
any
other
things
you
thought
you
might
like
to
explore
or
any
of
these
other
things
we've
talked
about
that
you
might
like
to
be
involved
with.
C
A
A
A
Not,
but
somebody
who
was
working,
I
believe
there
was
somebody
who
had
was
doing
work
to
try
to
address
this.
I
can't
remember
the
name
of
the
contributor.
I
think
they
actually,
I
think
they
were
expressed
interested
in
in
being
part
of
you
know
this,
this
stream-
or
maybe
I
just
really-
I
invited
them.
I
can't
remember
now
where
they
actually
responded,
but
I
this
is
something
that
someone's
put
work
into
trying
to
fix
okay,
but
it
has
not
been
fixed.
I'm
pretty
sure
that
seems
like
maybe
another.
D
D
I
I
I
have
a,
I
have
a
question
for
you
guys,
because
you,
you
probably
know
a
lot
more
about
this
than
me.
How
so
in
theory
like
assuming
everything,
is
like
much
better
than
it
is
right
now?
How
long
should
it
take
to
recompile
a
project?
If
you
add
one
line
like
and
take
take
the
the
worst
case
line
that
you
can
think
of
like
how
long
should
it
take
like?
Should
it
be
like
sort
of
constant
should
it
be
like
bounded.
A
A
E
I
think
it's
a
good
question,
though,
because
I
have,
I
have
very
little
sense
of
this
too,
and
if
there
are
like
different
kinds
of
changes
that
would
have
different
kinds
of
effects,
that
sort
of
thing
that
might
be
useful
to
know
or
have
written
down
in
a
document.
Perhaps
that's
true
like
if
it's
if
it's
a
single
line
within
a
function
is
that
different
to
if
you
change
the
function,
signature
or
I
you
know,
I'm
just
guessing
here.
E
D
Yeah,
because
I
have
the
feeling
that
I
don't
know
if
you,
if
you
change
greater
than
to
a
greater
or
equal
than
in
an
if
and
that's
it,
that
that's
all
that
you
do,
the
change
like
the
the
the
cost
of
recon
recompilation
should
be
very
small
right,
and
so,
but
I
I
that's,
that's
the
notion
that
I'm
missing
like
how
how
how
small
should
a
trivial
like
I
I
did
nothing.
So
I
expect
the
the
compiler
to
take
no
time
almost
right.
A
That's
actually
interesting,
because
I
don't
think
any
of
our
benchmarks
today
that
the
greater
than
degree
or
than
equal,
you
know,
I
don't
know
if
any
of
our
benchmarks,
better
change
like
that,
we
do
things
like
adding
a
print
line
which
you
know
actually
is
pretty
expensive
in
terms
of
amount
of
code
associated
with
that
ends
up,
you
know
being
generated
for
that,
but
the
idea
of
just
changing
a
greater
than
degree
that
equals
a
much
more
is
a
very
interesting,
really
minimal
delta.
To
explore.
E
So
so
for
the
benchmarks,
like
quite
a
lot
of
our
benchmarks,
we
have
one
incremental
thing
where
we
add
a
print
line.
Basically,
there's
one
rig
x,
where
we
have
something
like
eight
different
incremental
scenarios,
so
that's
sort
of
like
the
deep
example.
Quite
a
few
benchmarks
have
been
added
and
like
an
incremental
scenario,
just
didn't
get
just
didn't
get
added,
so
some
of
them
don't
have
an
incremental
thing
at
all
other
than
just
you
know,
built
from
scratch.
The
benchmarking
story
for
incremental
is
probably
weaker
than
it
could
be.
B
I
think
I
personally
would
like
to
see
more
kind
of
user
scenario
driven
incremental
benchmarks.
Like
you
know,
pick
pick,
some
sort
of
a
representative
test
of
a
user
is
working
on
a
crate
or
whatever,
and
they
do
something.
You
know
that
would
that
would
make
sense,
and
then
they
build.
How
long
does
that
take
and
then
they
make
another
change?
How
long
does
that
take
and
they
make
another
change?
How
long
does
that
take
the
print
line
seems
kind
of
artificially
contrived.
I
mean
there's.
B
There's
definitely
use
cases
for
doing
that,
but
you
know
I
think,
kind
of
to
to
feel
like
911gr's
point
like
you
know,
if
you
are
fixing
a
bug
in
a
function
and
that's
the
only
change
you
make,
how
long
does
that
take
to
build
where
you
change
the
body
of
a
private
function
somewhere
in
the
crate?
How
long
does
it
take
to
build
so.
A
Yeah,
okay,
so
that's
something
we
should
perhaps
look
at.
I
don't
know
I
hesitate
to
say
we
spin
up
a
whole
project
over
on
this,
but
at
the
same
time
it's
a.
It
is
a
super
important
thing
and
it's
gonna
dictate
a
lot
of
the
other
work
we
do
so
yeah.
Let's,
I
think
we
we
probably
could
deal
with
exploring
this
a
little
bit
better.
You
know,
maybe
it's
an
action
for
a
week
from
first.
You
know
for
our
meeting
two
weeks
from
now.
A
A
Okay,
but
yeah.
No,
that's
a
really
good
point!
I
don't
remember
if
I
said
this
in
any
of
the
bullets
when
I
was
writing
random
stuff
for
our
for
the
meeting,
but
the
benchmarking
is
definitely
something
that
we
should
be
addressing.
I
guess
I
did
have
that
somewhere
here.
Up
on
my
I
have
a
whiteboard
over
here
that
I'm
looking
at
no,
no,
I
did.
I
did
write
this
down
at
some
point.
The
performance
benchmarks
should
be
at
least
reviewed.
A
Okay,
all
right.
Well,
this
is
enough
stuff.
This
is
a
paradise
that
for
us
to
at
least
chew
on
in
the
in
the
short
term.
Next
item
for
the
meeting
tonight
was
the
documentation.
What
extreme
documentation
do
we
have
that
we
could
point.
You
know
collectively
point
each
other
at
cause.
I
had
thought
when
that
came
up,
that
the
rusty
dev
guide
had
something
here,
but
then,
when
I
looked
quickly,
I
didn't
see
anything
in
it
that
seemed
relevant.
So
I
I
might
be
just
wrong.
A
It
might
have
only
been
the
query
system,
that's
documented,
in
the
in
the
dev
guide
and
not
actually
incremental.
I
think.
Oh,
no,
there's
a
there,
isn't
an
incredible
compilation,
detail
chapter
that
says:
let's
see
the
criminal
violation
in
detail.
Let
me
link
this
in
the
I
see
it's
part
of
the
it's.
It's
part
of
the
book.
A
That's
about
query
systems,
so
I've
just
posted
a
link
that
at
least
has
the
docs
from
some
point
of
time
that
talks
about
incremental
compiler
and
it's
it's
it's
overall
structure
and
yeah.
I
don't
know
offhand
how
much
of
this
is
out
of
date.
I
think
most
of
it
is
probably
still
pretty
up-to-date.
We
haven't
made
huge
changes.
There
were
some
changes
that
were
proposed,
but
I
don't
think
we've
made
anything,
that's
big
enough
that
wouldn't
validate
what
I
see
here
skipping
over
it.
A
It's
okay,
so
this
is,
there
is
documentation
of
the
compiler
good,
because
I
was
I
was
not
sure.
If
that
was
the
case,
and
of
course
there
is
the
obvious
approach
of
just
looking
at
the
bugs
that
are
currently
tagged
with
the
label
for
violation
in
the
rust
issue
database,
which
would
be
a
query
like
like
this,
that
I'll
post
in
zoolift
and
there's
102
such
bugs
open.
A
Obviously
a
number
of
them
are
probably
ices,
so
if
we
just
get
rid
of
that,
because
that's
not
I
mean,
while
those
are
things
to
fix,
they
aren't
like
the
kind
of
enhancements
that
I
would
maybe
want
to
talk
about
as
things
that
we
could
look
at
doing.
No,
even
this
approach
is
not
quite
what
I
wanted
there
was.
A
In
any
case,
there's
definitely
things
here
that
talk
about
like
things
that
michael
worster
pointed
out
as
being
shortcomings
in
the
in
the
internal
compilation
system
years
ago,
and
so
there's
potential
there
for
things
to
look
at
and
oh
yeah.
So,
for
example,
there's
this
bug
that
someone
earlier,
I
think
was
wesley
mentioned
about
spans
being
a
problem.
So
as
an
example
of
a
bug
that's
filed
about
this.
A
There
is
this
bug
that
michael
filed
over
two
years
ago
about
becoming
spans
in
a
more
robust
way,
and
I
think
that
likewise
there
is
there's
been
work
in
this
area
as
recently
as
may,
but
I
don't
know
yeah,
that's,
okay,
that's
the
person!
I
was
trying
to
think
of
there's
this
pr
remove
spans
from
here.
B
Yeah,
actually,
if
you
look
at,
if
you
look
at
issues
tagged,
I
guess
incremental
filed
by
michael
morrisser,
there's
a
pretty
good
set
of
enhancements
there.
I
guess
not,
I
guess
I'm
just
looking
at
all
of
his
bugs,
but
there's
a
there's
quite
a
bit
of
overlap
with
probably
the
goals
of
our
group
yeah.
I
would.
I
would
not
describe
that
at
all.
A
A
What
I
posted
before
so
adding
like
the
conjunction
of
incremental
and
c
enhancement,
gets
us
a
fair
amount
of
interesting
stuff
but,
like
you
said,
also
adding
michael
werster
there's
the
author
of
the
issue
might
also
have
a
very
targeted
set
of
well-written,
well-written
bugs
okay.
So
these
are
things
to
look
at.
C
Okay,
there
are
a
lot
of
issues
and
some
of
the
stuff
is
hard
to
like
to
reproduce
if
at
least,
if
I'm
correct.
So
I
was
wondering
if
like
is
there
some
something
that
we
can
come
up,
that
more
or
less
that
we
can
paste
on
issues
when
when
they
show
up
and
say
to
like
to
the
reporter,
hey
try
to
do
this
and
this,
and
that
and
you
would
you
would
give
giving
us
some
important
information
or
something
that
we
can
implement
that
make
the
reporters
in
some
way.
A
So
I
definitely
have
okay,
so
there's
two
separate
things
here:
one
is
improving
the
the
protocols
in
place,
either
through
robots
or
human
effort
in
terms
of
how
we
can
get
quicker
responses
to
people
who
file
internal
issues
so
that
we
might
get
because
oftentimes
by
the
time
they
respond
to
that
they've
already
deleted
the
cash
that
we
need
to.
Actually,
you
know
get
make
progress
in
the
bug.
So
that's
one
topic
is
that
about
that.
A
That
was
sort
of
one
thing
it
sounded
like
you
were
touching
on,
but
there
is
a
separate
topic
of
ways
we
could
change
the
compiler
itself
to
make
it
easier
to
reproduce
these
bugs.
In
particular,
I've
been
used
about
trying
to
store
information
about
the
previous
or
the
last
build,
or
something
like
that.
C
A
I
agree,
I
think,
would
be
good.
It's
true
and
you
make
the
good
point
that
I
in
my
head,
I
always
for
some
reason
associated
this
thing
that
we
put
in
the
compiler,
but
you
make
the
point
now
that
it
doesn't
necessarily
have
to
be
in
the
compiler.
It
could
be
something
that's
part
of
cargo
which
might
make
it
easier
to
develop
and
land.
So
it's
tooling,
I
think,
could
be
useful
here
because
it
is
so
difficult
to
reproduce
these
bugs
and
it's
obviously
a
big
time
sink
and
a
big.
A
I
think
we
often
just
say
we
can't
do
it.
If
the
person's
lost
the
contacts,
then
we
can't
reduce
it.
We
just
give
up
so
yeah.
I
think
that
that's
something
I'd
like
to
see
work
done
on.
I
I
didn't
propose
as
a
project
group,
because
it's
sort
of
the
problem
is,
it
doesn't
serve
the
goals
of
it.
It
directly
serves
the
goals
of
making
you
know,
violation
develop
easier
to
do,
but
it
doesn't
directly
make
incremental
motion
better.
A
If
anything,
it
might
make
it
worse
in
terms
of
the
extra
overhead
that
it
might
take
to
store
the
information
depending
on
how
it's
done,
and
you
know
it
might
add,
overheads
that
we
don't
want
to
pay.
So
that's
one
reason
why
I
didn't
propose
it
concretely,
but
at
the
same
time,
I'd
love
to
see
work
done
on
it.
So
I
think
it's
a
good.
I
think
it's
a
good
thing
to
explore.
A
I
just
don't
know
if
I
it's
tough
I'd
love
to
see
worked
on
it.
I'm
sitting
here
saying
I
can't
justify
spending
time
on
it
myself.
I
think,
which
means
I
have
a
hard
time
asking
someone
else
to
do
so
right,
but
I
don't
know
the
the
fact
that
you
just
bring
up
broadcasted
cargo
being
in
charge
of
it.
Maybe
that
improves
the
the
development
time
such
that
it
would
actually
be
reasonable
to
hack
something
up
yeah
that.
B
I
I
feel
like
it
might
be
worth
investing
some
amount
of
time
to
try
to
figure
out
why
we're
getting
ice
like
I
would.
I
would
expect,
though,
the
incremental
cash
just
doesn't
get
used,
because
it's
not
valid
or
right
this
or
whatever.
But
what
we're
actually
seeing
looks
like
we
tried
to
load
stuff
out
of
the
incremental
cache
and
we
got
bad
data
and
then
the
process
explodes
sometimes.
A
It's
something
that
one
case
has
been
something
where
there's
some
invariant
in
their
income:
cash,
that
you
know,
people
have
claimed
this
invariant
should
hold
and
it
doesn't
hold
and
therefore
we
want
an
ice
here.
That's
and
there
have
been
situations
where
I
said,
but
we
could.
We
could
just
you
know
not
here
and
we'd,
be
able
to
compile
successfully.
Something
and,
like
you
said,
ignore
the
incremental
cache
and
the
problem
is
that
then
we're
gonna
have
people
that
aren't
gonna,
get
incremental
compilation
right,
we're
not
gonna
know
it.
A
So
I
I
would
like
perhaps
it'd
be
perhaps
good
to
have
a
situation
where
we
didn't
ice
in
these
situations,
but
rather,
like
you
said,
stop
using
the
cash
but
also
admit
a
diagnostic
saying,
hey
like
we.
We
tried
to
use
incremental
here,
but
something
went
wrong
if
you
could
file
up
like
if
you
can
do
is
if
you
can
repeat
this,
if
you
can
get
this
like,
if
you
can
reproduce
this
case,
yeah
smile,
a
bug
but
have
something
where
it
doesn't
cause
the
whole
compilation
to
error
out.
A
They
could
well
be
things
that
we
can't
always
detect
and
so
we're
better
off
actually
trying
to
fix
the
real
bug
and
not
letting
I
don't
know
enough
off
the
top
of
my
head
for
all
these
cases,
where
there's
some
places
where
we
truly
can
ignore
it
versus
ones
where
no,
the
fact
this
is
happening
means
that
we
don't
even
know
whether
well,
I
don't
know
I
was
about
to
say
we
don't
know
whether
we
compile
successfully
or
not.
But
your
point
is
that
we
could
just
say
we're
not
used.
B
Yeah
I
mean
I
I
guess
where
I'm
coming
from
is,
I
feel
like
it's
better
for
c
to
be
slow
than
it
is
for
it
to
crash,
and
so,
and
the
impression
I
have
is
that
our
our
users
in
general
are
pretty
willing
to
file
issues.
You
know
if
we
ask
them
to
so,
even
if
it
doesn't
fail
to
build,
but
there's
a
big
warning
message
that
says:
hey:
could
you
zip
this
stuff
up
and
post
it
in
an
issue?
B
I
think
we
would
get
a
lot
of
people
do
that,
but
it
would
certainly
look
better,
I
think,
than
if
you
just
get
an
icd
and
a
compiler
boards,
especially
like.
Sometimes
this
happens
like
it's
ci
and
then
that's
kind
of
extra
annoying,
because
you
know
you
have
people
submit
a
pr
or
something
and
then
it
fails
because
rusty
died
and
it's
not
really
related
to
their
pr
at
all.
You
know
not.
A
A
A
The
problem
is
the
problem
with
them.
Is
that
faults
that
are
tolerated,
don't
get
fixed,
and
so
this
is
the
question
that
we
would.
We
trust
our
you
know
our
community
to
actually
still
take
the
effort
to
report
in
when
these
things
are
failing
or
whether
they
just
these
things
that
are
soundly
not
working.
We
wouldn't
even
know
and
people
just
people
just
communicate.
The
compiler
is
too
slow,
but
that's
the
thing
that
the
plugs
will
get
as
the
compiler
is
too
slow
and
then
we'll
hopefully,
then
find
out.
Okay.
B
Then
it
feels
like
there's
a
possibility,
we're
opening
the
door
for
miss
compilations,
because
we're
only
getting
lucky
that
we
tried
to
read
out
of
bounds
of
a
slice
or
something
right
if
we
actually
read
the
wrong
data,
but
it
was
all
in
bounds.
You
could
get
like
anything
could
happen
right
so
definitely
works
right.
D
Yeah
that
that's
that's
a
that's
a
really
good
point,
because,
like
we
should
try
to
to
have
incremental
compilation,
be
correct
right,
like
in
the
sense
that
it
it
it
works
like
it
gives
the
correct
output
and-
and
I
think
that
is
that
that
is
actually
a
very,
very
important
objective.
I
don't
know.
D
A
Let's
explore
this,
I
think
that,
if
nothing
else,
I
would
love,
as
somebody
you
know,
has
to
deal
with
compiler
triage
to
suddenly
get
rid
of
the
influx
of
isis
from
the
interval
compilation,
because
they're
always
a
headache
and
and
really
the
approach
I
was
thinking
of-
was
to
make
it
easier
to
debunk
those
touch
isis
but
wesley
your
suggestion
of
just
stop
doing
it.
Stop
icing
in
some
way
and
let
the
compiler
at
least
finish
with
a
correct
answer:
that's
pretty
attractive,
I
mean.
B
I
know
I
don't
I
don't
know,
are
we?
Are
we
getting
these
issues
because
we're
catching
a
lot
of
these
ics
I've
seen
our
stuff
like
we
tried
to
read
way
out
of
bounds
on
a
slice,
and
it
makes
me
think
that,
like
we
just
you
know,
we
took
these
bites
off
disc
and
we
stuffed
them
into
the
structure
and
it
was
actually
a
totally
different
structure.
B
So
we
got
some
crazy
thing
like
this
slices,
16
gigabytes,
long
or
whatever
right.
We
tried
to
remove
it,
and
that
makes
me
think
that
we
aren't
doing
enough
validation.
If
the.
If
the
ics
we're
getting
are
from
the
validation,
then
maybe
we
shouldn't
actually
mess
with
them.
Maybe
we
should,
you
know,
actually
actually
fix
whatever
the
underlying
cause
is
there,
but
a
lot
of
the
stuff
I've
seen
makes
me
think
we're
we're
not
doing.
A
Some
validations,
it
depends
so
yeah.
Some
of
the
ices
are
about
the
internals
of
the
of
the
violation
system.
Things
about
like
you
know.
I
found
a
red.
No,
when
a
queen
was
expected
right.
That's
the
kind
of
thing
that
I
encountered
where
that
is
an
internal
invariant
of
the
compiler
that
it's
detecting
itself
and
could,
I
think,
like
you
say,
be
just
stop
trying
to
communicate,
but
the
case
you're
talking
about
where
it's
a
out
of
bounds
axis.
A
That's
it
you're
right,
it's
a
different
story
and
we
probably
should
categorize,
maybe
a
good
task
to
categorize
the
ices
into
those
two
buckets
right:
things
that
are
internal
and
variance
and
ones
that
are
invalid
states
that
we
need
to
be
validating
somehow
or
do
something
to
prevent
or
or
just
accept
that
we
have
to
fix
them.
Okay,.
E
A
Jeez,
thank
you.
Thank
you
very
much,
okay.
Well
I,
this
has
been
really
useful
so
and
we
basically
have
finished.
I
mean
there's,
there's
a
question
with
the
github
group,
but
I
I
think
I
just
needed.
Actually
a
great
great
group
create
a
reuse
and
I'll
all
put
that
so
I'll.
Take
on
the
two
actions
I've
written
down
so
far,
which
is
you
know,
working
out
the
meeting
time
for
the
second
alternating
meeting
and
then
create
or
reuse
the
github
action
group
you
have
group.
A
So
the
only
other
question
is
about
these
other
project
groups
that
we've
sort
of
been
talking
about
so
well.
Let's,
let's
wrap
it
up
here,
we've
sort
of
got
an
idea
of
who
I
think
I
think
wesley
and
felix
youtube
will
sort
of
look
into
the
cogen
unit
stuff,
and
maybe
you
can
fire
up
a
proposal
for
a
project
group.