►
From YouTube: 2020-10-26 Lang Team Triage Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
so
we've
got.
A
You've
got
two
pending
proposals
restrict
promotion
to
infallible
operations
which
has
been
in
fcp
for
a
while.
Are
there
any
updates
on?
This
looks
like
it's
ready
to
merge.
A
A
Yeah,
we'll
let
it
wait.
It's
fine.
Usually
I've
just
been
closing
at
the
meeting
after,
but
no
big
deal.
Okay,
linkedin
project
board
updates
skim
along
here,
so
we
already
dealt
with
these.
Are
there
any
updates
along
here,
const.
A
The
update
is
that
that
me
and
lcnr
spend
some
I'll
type
I
won't
type
and
talk.
At
the
same
time,
we
sat
and
worked
out
a
bunch
of
test
cases
covering
sort
of
the
range
that
we
of
surface
behavior
that
we
expect
to
stabilize.
I
think
there's
been
some
conversation
I
haven't
caught
up
on
since
then,
but
we're
working
towards
producing
those
tests,
and
that
was
helpful.
I
think
the
question
I
guess
is:
there's
been
no
rfc
or
other
like
from
the
lying
team
point
of
view.
A
What
kind
of
process
do
we
expect
here?
I
feel
like
we
need
to
describe
somewhere
this
stable
subset
of
constant
eric's
that
we're
enabling
I'm
curious
what
people
think
an
rfc,
a
stabilization
report,
a
blog
post.
I
don't
know
what
the
best
way
forward.
D
So
I
would
think
that
if
it's
over
stabilizing,
then
a
stabilization
report
sounds
right,
but
the
problem
is
it
currently.
Stabilization
reports
are
just
like
random
github
issues
on
the
rust
repo
that
are
impossible
to
find
in
the
future
they're.
Not
they
don't
really
get
preserved
in
any
meaningful
way.
D
A
B
A
D
D
A
A
Yeah-
let's
just
we'll
re-center
this
well,
I
think
we
can
leave
it
at
that
and
come
back
to
this
like
we'll
think
about
it
and
writing
it
out
regardless
it
has,
we
have
to
start
doing
a
little
write-up.
I
think
that
is
drawing
on
the
blog
post
and
you
know
whatever
has
been
uncovered
in
the
meantime,
and
once
that
right
up
there,
we
can
kind
of
decide
how
we
want
to
wrap
it
up
and
get
it
out,
but
slow
and
steady
progress.
A
Very
well,
okay
project,
safe
transmute
or
I
don't
know
we'll,
go
through
the
list-
async
foundations.
I
don't
think,
there's
anything
new.
Besides
this
there's
still
this
draft
rfc
available
and
people
get
a
chance
to
look
at
it.
Great
any
comments
on
that.
So
far,.
A
A
And
project
safe
transit-
I
haven't
been
able
to
follow
the
rfc.
I'm
curious
to
hear
from
the
folks
who
have
been
if
there's
been
any
activity.
A
Rfc2229
this
is
these
are
all
implementation.
I
think
the
short
answer,
since
I'm
I'm
kind
of
shepherding
all
of
them
is
the
implementation
proceeds
for
all
of
them.
In
particular,
this
is
the
closure
capture
rfc,
and
that
is
one
where
the
implementation
is
going
quite
well.
Actually,
maybe
I'll
take
a
moment
just
to
add
a
few
notes
here
that
we
did
uncover
a
few
interesting
like
over
the
course
of
this
work.
A
We
covered
a
few
interesting
guides
around
closures
that
we
hadn't
thought
about,
like
one
of
them
is,
let
me
post
the
update
in
here
easier.
No,
I
don't
have
it
set
up
for
that.
Yet
one
of
the
things
we
discovered
is
around
the
behavior
of
closures,
where
you
don't
they're
like
captures
that
have
no
semantic
meaning
but
which
still
occur
today.
So
an
example
would
be
this.
A
Closure
would
borrow
x
today
because
there's
no
actual
use
of
x
here,
but
it
does
get
mentioned
under
this
rfc,
where
we're
actually
looking
at
more
deeply
at
how
closures
get
used.
We,
I
think,
would
not
borrow
this
at
all.
The
plan
is
to
bring
this
in
a
new
edition,
because
it's
going
to
make
some
other
changes
to
how
we
capture
anyway,
and
so
that
these
kinds
of
cases
will
slightly
change
behavior
when
we'll
have
to
add
a
lint
around
migration.
A
We
could
prefer
behavior
in
this
case.
If
we
really
wanted
not
clear
why
we
would.
A
A
A
A
A
A
A
I
am
willing,
I
think,
but
I
wouldn't
mind
if
someone
else
wants
to,
but
I
would
like
a
few
tips
on
like
what
people
have
been
following.
What
kind
of.
A
D
So
I
think
that
the
big
desire
is
some
way
of
programmatically
dealing
with
the
v
table
of
a
trade
and
then
there's
also
sort
of
a
vacant
concern
about
being
for
compatible
with
eventual
custom.
Dst's.
D
A
Right
so
maybe
there
so
immediate
desire
is
to
be
able
to
manipulate
representation
of
trade
objects,
but
want
to
be
forwards
compatible
with
future
developments
like
custom,
dsp,
dna
plus
b
et
cetera.
So
maybe
that
suggests
that
we
would
want
to
summarize
some
of
those
in
their
implications.
A
A
A
A
A
A
A
And
local
thor
did
a
good
job
summarizing,
so
people
should
read
that
and
or
the
paper
november
11th
or
no,
the
18th.
A
The
last
thing
I
wanted
to
say
is:
I
want
to
change
to
the
compiler
team's
processor
on
this
around
the
scheduling,
design
meetings,
but
I'll
talk
about
that.
But
the
short
version
is
every
four
weeks.
We
have
a
planning
meeting
where
we
discuss
what
to
do
and
look
over
the
ideas,
and
we
can
do
that,
maybe
on
zooloop
or
something,
but
that
basically
just
seems
to
work
for
the
compiler
team
and
I
feel
constantly
confused
about
how
we're
doing.
A
Good
point:
we
do
not
have
a
plan,
I
think
bonanza
is
a
good
idea.
B
B
It
would
be
potentially
awesome
to
move
either
this
meeting
or
the
design
meeting
to
tuesday,
so
that
the
meetings
were
adjacent
in
the
week
trying
to
create
more
uninterrupted
blocks
of
time,
and
I
know
that
people
have
in
the
past
expressed
some
concerns
with
either
this
meeting
time
or
the
design
meeting
time.
So
I
thought
I'd
ask
there's
a
threat
on
zulup.
We
can
continue
discussing
it
there,
but
I
wanted
to
call
attention
to
it.
B
I
believe
it's
in
tealing
private,
but
I
can
move
it
to
tealing
so
that
we
can
include
more
people
who
attend
the
meetings.
Actually,
okay,.
A
A
D
C
D
F
A
Cool,
so
we
had
this
long
running
discussion
about
having
forbidden
worms
in
the
same
scope
and
mark
you
prepared
a
comment.
Do
you
want
to
summarize
what
it
said.
E
Sure
so
in
general,
the
behavior
here
has
changed
in
relatively
narrow
way,
with
the
pr
that
felix
originally
wrote.
So,
to
summarize,
I
think,
there's
sort
of
two
things
that
are
sort
of
wrong
right
now
that
the
first
thing
is,
we
don't
have
any
warning.
If
you
put
like
deny
and
then
after
that
you
put
allow
on
the
same
level,
it
just
gets
the
first
one
gets
silently
ignored
with
any
lint
level,
except
for
forbid
after
the
pr
in
question,
and
then
so.
E
My
proposal
is
that
we
probably
want
a
warning
of
some
kind
when
you're
ignoring
an
attribute
which
has
historically
been
sort
of
a
pain
point
in
general
on
the
compiler.
But
here
it's
sort
of
another
instance
of
that,
and
then
the
second
thing
is
to
continue
with
the
similar
behavior,
which
is
introduced
by
the
pr
but
modify
it
slightly
to,
instead
of
being
a
hard
error,
be
a
forbid
by
default
lint,
which
would
mean
that
you
can't
disable
it
locally
within
your
crate.
E
A
Not
something
we've
ever
done
before,
but
it's
clever
idea.
C
A
E
E
For
I,
I
guess
I
think
it's
an
open
question
whether
we
want
to
treat
forbid
differently
from
all
other
attributes
in
terms
of
like,
if
you
list
forbid
and
then
allow
at
the
same
level
whether
that
should
be
actually
a
error,
or
we
should
do
the
same
thing
we
do
for
every
other
attribute
where
we
only
consider
the
sort
of
latest
one.
You
say.
E
B
F
E
It
here
act,
let
me
check
again,
but
I
I
did
not
intend
to
weaken
behavior
okay.
A
E
It
is
a
hard
error
to
override
in
nested
scopes
today
in
any
compiler,
so
stable
and
nightly.
A
C
So
I'll
toss
out
one
other
thing
that
would
be
okay
by
me
and
slightly
weaker.
If
we
wanted
as
long
as
forbid
is
what
applies
to
that
scope,
I
would
be
okay,
even
if
it's
not
a
forbid
by
default,
about
having
multiple
different
ones.
If
you
say
to
me,
if
you
said
allow
for
bid
deny
and
warn
at
the
same
scope,
you
would
then
get
a
bunch
of
warnings
about
unused
attributes,
but
the
behavior
of
the
whole
thing
would
be
that
it's
forbidden
inside
that
scope
and
that
would
be
okay
by
me.
B
C
C
Okay,
yeah,
yes,
you
could
run
your.
You
could
run
your
unit
test,
even
though
you
said
forbid
and
worn
on
unsafe
code
as
long
as
you
didn't
actually
use
any
unsafe
code
by
trying
to
allow
it
somewhere
right,
which
I
think
is
okay,
because
it's
basically
okay,
you
have
dead
code
in
your
attributes,
but
we
don't
need
to
forbid
that
code
in
attributes
necessarily.
E
C
G
This
this
whole
thing
is
a
regression
that,
but
one
of
the
one
of
the
issues
was
this
whole
thing
about.
We
don't
have
code
in
place
to
sort
of
pick
the
you
know
strongest
condition
or
to
pick
for
bid
when
it
occurs
anywhere
and
that's
probably
not
hard
to
implement,
but
I
remember
part
of
the
thing
we
talked
about
last
week.
I
think
was
just
this
issue
that
we
need
to
get
something
done
about
this
quickly
right
or
relatively
quickly,
so
I
just
want
to
make
sure
we
pick
a
solution.
A
E
I
I
feel,
like
I
have
a
pretty
good
sense
for
the
constraints
yeah.
I
would
be
willing
to
spend
a
bit
of
time
trying
to
work
out
an
implementation
here
and
sort
of
see
what
falls
out.
Naturally,.
A
C
And
I
don't
think
I
have
a
problem
with
the
trying
to
override
for
bid
as
a
forbid
by
default,
either
necessarily
depending
on
what
you
come
up
with.
That
seems
like.
A
A
Never
consider
that
so,
okay,
there's
a
bunch
of
nominated
prs
around
and
not
many
appears
in
issues.
I
kind
of
went
through
and
tried
to
outline
some
of
the
like
points
about
them.
I'm
gonna
jump
a
little
bit.
I
think
there
was
some
that
I
thought
were
higher
prices
yeah
I
want
to
jump
down
to
should
have
reordered
them,
but
this
one
used
up
one
foo
as
depth.
One
is
completely
ambiguous.
A
If
you
recall
our
this,
this
good
old
friend
this
used
to
be
accepted,
it
became
an
error.
This
affects
some
code.
The
new
update
is
that
mark
posted
this
update
that
several
crates
were
broken
and
proposed
that
we
should
not
break
them
short
unless
we
want
to
do
it
over
an
addition
and
petrochenkov
indicated
that
it
would
not
be
very
hard
to
retain
this
behavior
if
we
wanted
to
it
just
kind
of
gives
us
some
less
flexibility
going
forward.
A
E
Yeah
in
particular,
it
seems
like
there
is
sort
of
enough
use
cases
that
don't
seem
immediately
like
sort
of
trivial,
one-off
examples,
and
I
could
see
myself
writing
the
same
code
sort
of
naturally
without
thinking.
Oh
no.
This
is
like
really
weird
yeah.
A
A
Now
there
is
sort
of
which
depth
one
are
you
talking
about.
I
suspect
this
is
already
an
error
for
probably
various,
probably
for
multiple
reasons
like
exporting
the
same
name
more
than
once,
for
example,
so
that
it's
really
only
the
case
that
it's
exactly
in
the
self
selection
case.
Then
it
seems
like
it.
It's
also,
okay
to.
A
G
G
A
A
Very
good
I,
unless
anyone
objects
now
I
would
say
I'll
post
a
comment
saying
that
we
agree
with
mark
and
we
should.
We
should.
A
A
A
A
The
only
problem
was,
if
there's
no,
if
all
the
types
in
the
rep
are
transparent,
are
of
size
0
and
have
a
alignment,
one
kind
of
what
is
the
behavior?
What
should
it
be?
I
went
ahead
and
wrote
up
some
rules
and
did
an
scp
merge,
basically
saying
based
on
the
thread
above.
A
If
you
have
one
one
zst
is
this
means
a
zst
of
alignment,
one
so
zero
psi,
zero
alignment,
one
you
can
have
any
number
of
those
and
at
most
one
other
field
and
that
t
behaves
like
you
and
if,
if
there's
only
one
zst
types,
then
it
behaves
like
unit
which
probably
doesn't
matter
because
passing
the
avi.
A
In
other
words,
you
had
some
marker
zst
that
you
wanted
to
behave
like,
for
example,
it
also
happened
to
have
size
0
and
alignment
1,
but
in
some
other
way
was
special.
C
It's
pointer
api,
regardless
anyway
right
right,
right,
yeah
and
see.
Apparently
it's
ub
to
have
an
empty
structure
c,
which
is
very
c
but.
A
A
Right,
well,
I
don't
know,
maybe
who
knows
anyway,
here's
another
regression
to
call
attention
to.
So
let's
pull
that
one
out
mark.
Did
you
have
some
notes
on
this?
I
didn't
get
time
to
begin.
E
Not
in
particular,
it's
another
case
of
us
limiting
more
stringently
on
attributes
that
were
in
sort
of
weird
places.
F
E
They
definitely
like
the
cases
here
definitely
seem
like
something
where
the
author
is
definitely
not
getting
the
behavior
they
expected.
That
said,
it's
sort
of
ambiguous
whether
we
want
to
break
or
not.
Here
I.
E
To
flag
that,
potentially
there
is
some
t
compiler
policy
here
that
needs
to
be
discussed
in
terms
of
like.
I
don't
think
the
pr
in
question
was
ever
raised
with
lane
team
and
I
think,
we've
sort
of
oscillated
over
time
on
whether
that's
necessary
or
not,
but.
A
It's
a
good
question
I
feel
like
this
is
yeah,
I'm
trying
to
decide
what
I
think
it
seems
like
this
is
not
a
policy.
This
was
a
bug
fix
which
usually
we
have
held
out,
doesn't
really
require
a
link
team.
We
are
talking
about
the
resulting
production,
so
I
don't
know
we
should
make
a
design
meeting
mark
you
and
I
should
sit
down
and
talk
about
a
regression
policy,
since
it
seems
like
something
we
both
care
about
and
try
to
make
a
proposal
and
a
meeting
around
it.
A
C
I
feel
like
coming
at
this
from
a
totally
naive
side.
It
feels
like
the
there's,
an
attribute
that
doesn't
get
denied
in
the
approp
in
every
place
that
it
possibly
could
happens
a
lot.
A
G
It
seems
like
we
get
a
lot
of
these
issues.
I
mean
in
theory.
You
think
that
the
fact
we
have
the
unused
attribute
mechanisms
in
the
compiler.
You
would
think
that
we
have
the
code
would
for
for
most
attributes.
You
have
checking
the
pads
that
either
it's
used
somewhere
in
the
code
pads,
that's
applied
and
thus,
like
you
know,
you'll
get
the
appropriate
like
there
is
some
behavior
attached
there
and
if
it's
being
applied
somewhere
is
not
used,
you'd
get
the
unused
attribute
warning
right.
A
E
It
is
not
no.
The
the
problem
with
like
the
compiler
is
really
bad
at
tracking,
whether
it's
actually
using
something
or
not
in
terms
of
attributes,
mostly
because
the
code
is
like
spread
out
and
each
pass
does
it
on
its
own.
Essentially,.
A
A
G
E
Yeah,
I
am
inclined
to
permit
this.
As
I
said.
A
E
No,
we
only
test
on
x86
64,
unknown
linux,
new
yeah,
okay,.
A
A
Okay,
then
I'm
just
going
to
jump
back
to
the
top.
So
I
think
that
was
all
the
regressions
that
I
saw
we'll
go
down
so
there
was
this
target,
has
atomic
config
tracking
issue,
I'm
not
actually
sure
exactly
what
this
is
tracking.
I
think
it's
tracking
the
like
atomic
i32
and
then
y64
types
and
I
nominated
it
or
I
didn't
nominate
this
person
did
to
bring
it
to
our
attention.
A
B
E
E
Atomics
then,
this
is
entirely
useless
and
you're
likely
to
get
errors.
If
you
know,
stoods
config
is
not
precisely
this
one
which
presumably
it
isn't,
but
maybe
I'm
wrong.
B
A
A
A
A
Specifically,
I
guess
there's
no
specific
comment
for
me
to
highlight
here
so
I'll,
just
jump
back,
but
there's
been
some
discussion,
especially
around
dot
dot
x,
and
whether
we
want
to
accept
that,
because
it's
a
little
confusing
since
dot
dot
x,
could
start
from
zero
or
could
start
from
the
minimum
type
value
for
your
type
and
principle
and.
A
Right
so
for
people
who
didn't
read
it
like
we've
already
standardized
like
already
stabilized
this
behavior
for
better
or
worse,
it
behaves
in
a
certain
way,
and
so
it
might
be
nice
to
offer
it
in
the
form
of
a
pattern
as
well,
so
that
you
can
say.
A
I
mean
that
I
guess
this
won't
literally
work
with
x.
Let
me
change
it
to
a
constant.
B
B
C
B
True,
so
I
think
one
of
the
really
common
cases
I
mentioned
this
on
the
thread
is
that
one
of
the
most
common
cases
other
than
patterns
where
people
run
into
ranges,
are
uses
with
things
like
vectors
and
slices
like.
I
want
to
take
this
vector
and
slice
out
a
subset
of
it,
or
I
want
to
drain
some
subset
of
it
or
similar,
and
for
that
purpose
there
are
no
negative
indexes
in
a
vector.
B
C
I
think
I
have
trouble
figuring
out
when
that
would
cost
someone
a
problem,
though,
because
we
have
that
really
good
integer
overlap,
checking
and
warning
now.
So
if
you
do
have
something
that,
if
you
try
and
write
any
other
arm
that
tries
to
handle
those
negatives,
you'll
get
a
warning
from
the
compiler
and
it
will
tell
you:
hey,
no
you've
already
handled
all
those.
B
I
think
I'd
be
more
concerned
about
if
you
write,
if
you
don't
write
an
arm
that
is
intending
to
catch,
that
negative
is
wrong.
Like
an
example
that
was
given
at
one
point
was:
oh,
I
want
to
handle
time.
So
I'm
doing
you
know
dot
59
for
seconds
and
the
person
who
posted
that
specifically
said
come
to
think
of
it.
I
think
these
things
are
signed
and
we
actually
don't
have
any
handling
for
the
negative
case,
and
that
immediately
made
me
think.
Okay,
maybe
this
isn't
a
good
idea.
B
B
B
That
has
potential.
It's
also
worth
noting
the
concerns
I
have
apply.
Only
to
half
open
on
the
left
intervals
range
two.
I
have
no
concerns
whatsoever
about
stabilizing
range
from
or
range
from,
inclusive
or
sorry
range
from
and
range
from
two
inclusive
and
similar.
C
B
I'm
not
sure
we
actually
have
a
dot.
Equal
open
ended
like
that.
B
A
Yeah,
okay
yeah,
so
this
case,
specifically
we're
saying,
is
fine.
B
A
B
One
other
related
note.
I
did
see
people
mention
that
the
only
real
like
at
least
one
person
mentioned
that
the
only
real
reason
they
don't
want
to
have
to
write.
That
out
is
that
then
they
have
to
write
like
I-32,
colin
cohen
man
or
u-64
colon
cone,
man
or
similar,
and
that
it's
nice
to
not
have
to
think
about
what
the
type
is.
B
In
that
context,
has
there
been
any
discussion
about
associated
constants
recently
in
terms
of
like
we
could
have
a
numeric
type
for
which,
like
bounded
numeric
types,
for
which
there
is
a
man
and
a
max,
and
you
could
just
name
men
and
it
works
for
anything,
that's
bounded.
A
That's
interesting
we
have
not
so
supporting
the
supporting
associated
constants
in
match
is
complicated.
B
But
doing
the
type
inference,
because
is
this
a
thing
that
is
this
type
yeah?
So
when
you're
proposing.
A
A
B
Yeah,
I
will
avoid
bike
shedding
naming,
but
yes,
that
would
be
the
concept
yeah
right.
Theoretically,
you
might
also
be
able
to
import
the
associated
constant
so
that
it
was
implicitly
available.
A
The
challenge
is
that
at
least
today
we
have
problems
with
this,
because
the
way
we
implement
constants
and
pattern
matching
kind
of
requires
us
to
really
know
the
value
of
the
constant
before
monomorphizing,
and
since
we
wouldn't,
we
would
be
in
trouble
and
it
makes
things
like
exhaustiveness
checking
harder.
For
obvious
reasons.
A
A
But
anyway,
all
right,
so
I
think
we
have
agreement
on
this
step,
so
I
would
propose
that
we,
somebody
summarizes
this
comment
and
puts
this
as
a
call
to
action.
A
Let's
we'll
leave
the
rest
of
these
for
next
time.
Everybody.
C
One
thing
to
toss
up
that
probably
don't
have
to
talk
about
now
but
related
to
safe
transmute,
there's
a
interesting
conversation
with
ralph
about
whether
you
can
safe
transmute
integers
to
pointers
and
vice
versa.
C
B
Yes,
it's
worth
noting
that
isn't
specific
to
safe
transmute.
The
discussion
was
effectively.
Can
you
transmute
between
integers
and
pointers,
and
if
you
do
so,
is
that
introducing
ub?
Obviously,
if
it
introduces
ub,
you
can't
do
it
safely
or
unsafely.
B
To
the
best
of
my
knowledge,
it
would
not
impact
the
safe
transmute
interface
correct.
It
would
only
impact
what
is
actually
implemented
agreed.