►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
The Rust Borrow Checker - A Deep Dive - Nell Shamrell-Harrington, Microsoft
The Rust compiler's borrow checker is critical for ensuring safe Rust code. Even more critical, however, is how the borrow checker provides useful, automated guidance on how to write safe code when the check fails. Early in your Rust journey it may feel like you are fighting the borrow checker. Come to this talk to learn how you can transition from fighting the borrow checker to using its guidance to write safer and more powerful code at any experience level. Walk away not only understanding the what and the how of the borrow checker - but why it works the way it does - and why it is so critical to both the technical functionality and philosophy of Rust.
A
A
A
However,
as
you
watch,
people
get
more
experience
and
rust,
they
tend
to
come
around
to
the
borrow
checker
and
realize
what
it
protects
them
from
doing.
So.
In
answer
to
the
question:
is
the
borrow
checker,
a
friend
or
a
foe?
I
say
the
borrow
checker
will
become
your
friend
through
experience
and
along
with
gaining
experience
with
it.
A
It's
also
very
helpful
to
understand
how
it
works
and
why
it
does
the
things
it
does
we're
going
to
dive
deep
into
that,
but
before
we
do,
let's
briefly
cover
who
I
am
I'm
nell
shamrell
harrington,
I'm
a
principal
software
engineer
at
microsoft,
I'm
also
a
board
director
of
the
rust
foundation.
I'm
the
lead
editor
of
this
week
in
rust,
if
you're
not
subscribed.
I
hope
you
subscribe
right
after
this
to
keep
up
with
all
the
wonderful
things
the
rust
community
is
doing.
A
A
A
So
let's
go
ahead
and
run
this
code
using
cargo
and
as
expected,
we
see
the
numbers
1
through
5
printed
out
on
the
screen
seems
pretty
simple.
Cargo
builds
and
runs
the
piece
of
code
for
us,
but
there
is
a
lot
that
happens
underneath
the
surface
in
the
compiler.
When
cargo
is
building
it,
there
are
five
general
stages
to
compiling
a
piece
of
code.
A
A
A
Going
back
to
the
stages
of
compilation,
let's
start
with
the
first
one
here:
lexical
analysis
during
lexical
analysis,
a
program
within
the
compiler
called
alexa
takes
the
raw
rust
source
code
called
a
lexeme
and
analyzes.
It
then
splits
the
code
into
tokens
to
make
it
easier
for
the
compiler
to
parse,
and
that
brings
us
the
next
stage
of
compilation
called
parsing
in
this
stage,
a
program
within
the
compiler
called
a
parser
analyzes,
the
tokens
generated
by
the
lecter
and
translates
them
into
an
abstract,
syntax
tree
or
ast.
A
Having
the
tokens
in
this
data
structure
makes
it
much
quicker
and
easier
for
the
compiler
to
do
the
rest
of
its
work
at
this
stage
before
it
moves
on
to
the
next
stage
of
compilation.
The
rust
compiler
takes
that
abstract
syntax
tree
generated
by
the
parser
and
first
expands
any
macros
included
in
the
code.
A
A
It
also
de-sugars
some
of
the
syntactic
sugar
that
makes
riding
rust
so
delightful.
For
example,
in
rust,
the
for
loop
is
a
piece
of
syntactic
sugar
for
an
iterator.
If
we
were
to
de-sugar
this
section
of
code,
it
would
consist
of
both
a
match
statement
and
a
loop.
The
functionality
of
this
code
is
identical,
but
de-sugaring.
It
makes
it
easier
for
the
compiler
to
understand
it
and
optimize
it
at
this
time.
The
compiler
also
resolves
any
imports
in
the
code.
A
A
This
is
identified
by
an
hr.
This
is
identified
by
an
h-I-r-I-d
and
that
node
belongs
to
a
definition.
A
definition
is
an
item
in
the
crate
we
are
compiling.
These
are
primarily
top
level
items
within
the
crate.
This
is
identified
by
a
deaf
id
and
a
definition
is
owned
by
a
crate.
This
is
the
crate
we
are
compiling
with
with
rust.
It
stores
the
contents
of
the
crate.
We
are
compiling
and
creates
a
number
of
maps
and
other
things
that
help
organize
the
content
for
easier
access.
A
Throughout
the
compilation
process,
this
crate
is
identified
with
a
great
number.
This
is
the
original
rust
source
code.
We
are
compiling
and
let's
take
a
focus
on
this
section
here-
the
for
loop-
that
iterates
through
the
numbers
vector,
remember
this
for
loop
d,
sugars
into
a
match
statement
and
a
loop.
A
A
A
The
definition
is
some
top
level
item
in
the
crate
and
that
definition,
data
structure
is
owned
by
a
crate
data
structure.
So
our
for
loop
is
a
node
within
a
definition
within
our
crate.
That's
how
we
can
identify
where
this
node
corresponds
to
our
original
code.
What
this
also
helps
us
do
is
we
use
something
called
a
span.
A
A
If
we
encounter
a
problem
with
the
code
after
it
is
de-sugared
and
optimized,
we
still
want
to
be
able
to
show
the
user
where,
in
their
original
source
code,
that
the
error
was
generated.
If
we
were
to
show
them
the
d-sugar
code,
which
is
different
from
the
code,
they
wrote,
it
wouldn't
mean
much
to
them.
A
A
A
A
Let's
go
back
to
our
d
sugar
code
and
let's
focus
on
this
match
statement
which
is
assigned
to
a
variable
called
result.
If
we
looked
at
the
mir
for
this
piece
of
code,
it
would
look
similar
to
this.
I've
simplified
it
for
the
sake
of
appearing
on
a
slide
up
here
on
the
top
left.
We
have
our
basic
block
identified
here
as
bb2,
and
then
we
have
what
is
called
a
local.
A
A
local
in
the
mir
represents
a
place
in
memory
or,
more
specifically,
a
place
on.
The
stack
frame
in
this
case
underscore
5
corresponds
to
the
value
of
the
variable
result
and
like
in
the
nodes
in
the
hir.
We
have
a
span
the
piece
of
the
original
rust
source
code
that
each
node
in
the
mir
corresponds
to
again.
A
This
is
where
the
compiler
tries
to
figure
out
what
the
programmer
is
trying
to
do
in
a
way
the
compiler
can
understand
it
and
then
translate
it
into
machine
code,
and
at
this
point
after
it's
lowered
the
hir
into
the
mir,
the
compiler
will
run
several
checks,
including
the
borrow
checker
and
we'll
come
back
and
dive
deep
into
the
borrow
checker
in
just
a
few
minutes.
But
for
now,
let's
focus
on
these
last
two
stages
of
compilation,
optimization
and
code
generation.
A
These
stages
are
where
the
code
is
transformed
into
an
executable
binary
and
the
rust
compiler
we
use
llvm
to
do
this.
For
us,
llvm
is
a
commonly
used
collection
of
modular
and
reusable
compiler
and
toolchain
technologies.
The
rest
compiler
uses
it
to
further
optimize
the
code
and
generate
the
machine
code
to
run
it
before
it
uses
llvm.
The
rust
compiler
takes
the
mir
we
created
earlier
and
lowers
it
into
the
llvm
intermediate
representation
or
llvmir,
and
the
llvm
ir
honestly
is
pretty
unreadable
to
humans.
But
it
looks
something
like
this.
A
A
A
A
A
Now,
let's
look
at
this
line
where
we
attempt
to
create
the
variable
y
and
assign
it
to
the
value
of
x.
This
line
is
where
the
value
of
x
is
moved
to
y.
If
we
look
at
the
mir
created
for
this
line
of
code,
we'll
see
that
y
is
assigned
to
the
local
underscore
3.,
remember,
a
local
represents
a
place
in
memory
and
underscore
3
is
given
the
type
string.
A
A
Something
I'd
like
to
specifically
call
out
is
how
the
compiler
shows
where
the
error
was
generated
from
in
the
original
source
code
through
a
span.
Even
though
we
had
lowered
this
code
to
mir
or
mid-level
representation,
we
still
tracked
what
items
in
the
mir
correspond
to
what
places
in
the
original
rus
code.
A
A
If
we
run
this
command,
we
see
not
only
an
explanation
of
the
error,
but
also
a
piece
of
example
code
that
would
generate
it.
Then
the
message
gives
you
even
more
information
about
how
to
fix
it.
This
suggests
using
a
reference
to
borrow
a
value
rather
than
attempting
to
move
the
value,
which
is
what
we
saw
done
in
the
mir
representation
of
our
code.
So
let's
do
this
and
change
this
line,
so
that
y
is
assigned
to
a
reference
to
the
value
of
x
rather
than
moving
the
value
of
x
into
y.
A
A
A
Another
word
for
referring
to
the
lifetime
of
a
value
is
referring
to
the
variable
scope.
Let's
see
how
this
plays
out
in
our
code,
and
let's
start
with
this
first
line,
where
we
assign
the
value
of
x,
as
this
string
at
this
point
x
is
live.
Its
lifetime
begins
here
when
we
get
to
here
and
move
the
value
of
x
into
y.
This
is
the
end
of
x's
lifetime.