►
Description
How are Rust’s best-in-class error messages constructed? To figure that out, we’ll be digging through parts of rustc to uncover tidbits of this process. We’ll also take a high-level look at how some other programming languages construct error messages to compare and contrast these approaches.
More at https://rustfest.global/session/5-the-anatomy-of-error-messages-in-rust/
A
B
B
B
B
So
I
think
really
these
are
rust's.
Error
messages
are
one
of
the
I
suppose
one
of
its
killer
features,
even
though
sometimes
I
also
think
they're
a
little
bit.
That's
what
I'm
looking
for
they're,
just
not
given
as
much
credit
as
as
usual
or
they're,
just
not
in
the
limelight
as
much,
I
suppose,
and
if
I
had
to
go
ahead
and
kind
of
rank,
different
programming,
languages,
kind
of
on
a
tier
list
of
the
quality
of
their
error
messages.
B
I'd
probably
go
ahead,
and
do
it
something
like
this,
where
I
would
put
rust
in
s
tier-
and
I
think
kind
of
the
only
other
language
that
I
would
also
say
is
kind
of
in
the
same
class
would
be
elm
because
I
know
elm
also
the
community.
There
also
cares
a
lot
about
having
their
error
messages,
be
really
helpful
and
and
unintimidating
and
then
kind
of
everything
else
going
down
something
like
this.
By
the
way.
B
B
So
that
being
all
said,
the
norm
here
with
error
messages.
So
here's
an
example
of
like
a
c
plus
error
message,
but
kind
of
the
the
norm
with
error
messages
for
developers
for
programmers
is
like
there's
something
that
we
have
to
decipher
right
like
we
have
to
kind
of
figure
out
how
to
read
them.
I
think
a
lot
of
us
have
gotten
pretty
good
or
I've
gotten
a
lot
of
practice
with
running
this
kind
of
internal
algorithm
in
our
heads.
B
B
This
is
a
little
bit
of
a
of,
I
suppose,
an
egregious
example,
but
you
know
it's
not
just
c
plus
plus
you
see
this
in
lots
of
other
languages
as
well.
Like
here's,
a
python
example,
it's
you
know
it
doesn't
exactly
tell
you
straight
up
what
the
problem
is
right
again,
you
kind
of
have
to
look
at
this
and
try
to
figure
out
what
the
interpreter
is
telling
you
and
then,
of
course,
in
javascript.
B
I
just
want
to
bring
this
one
up
in
particular,
because
you
get
the
infamous
undefined
is
not
a
function,
error
message
that
is
so
unhelpful
right,
so
so
the
norm
with
a
lot
of
error
messages
and
a
lot
of
different
programming
language
ecosystems
is
just
like
they're.
They
leave
a
lot
to
be
desired
right
and
again
as
programmers.
We
have
to
kind
of
learn
to
decipher
them,
and
especially
for
me,
as
someone
who
teaches
neophyte
programmers,
you
know,
like
error.
B
Messages
are
very
intimidating
for
newcomers,
for
people
trying
to
get
into
programming
for
the
first
time,
and
especially
even
for
me,
I
can
remember
when
I
first
started
to
learn
programming,
which
was
in
javascript,
so
that
was
kind
of
like
my
first
language
that
I
really
tried
to
learn.
But
when
an
error
message
popped
up
like
I
was
just
so
intimidated
that
I
wouldn't
even
I
wouldn't
even
read
it
right.
B
I
was
just
kind
of
like
that
overwhelmed
by
every
time
I
saw
an
error
message
and
I'd
actually
just
go
and
like
poke
someone
who
I
thought,
knew
what
they
were
doing
and
asked
them
like.
Hey.
Can
you
like
decipher
this
for
me,
because
I'm
too
scared
to
read
it
all
this
to
say,
though
it's
not
like.
You
have
perfect
error
messages
in
rust,
right,
here's,
a
here's,
a
rust
example!
B
So,
but
that
being
said,
I
think,
most
of
the
time
you're
going
to
get
something
a
little
bit
more
seen
a
little
bit
more
straightforward,
hopefully
a
little
bit
less
intimidating,
where
you
know
you
where's,
very
straightforward
right
and
it
paints
a
lot
of
helpful
ascii
art
to
tell
you
hey.
This
is
the
offending
line.
This
is
the
location.
B
B
So
the
question
that
I
kind
of
wanted
to
pose
during
this
talk
is
this:
this
delta,
between
the
best
in
class,
error,
messages
and
kind
of
everyone
else,
I
suppose
is-
is
this
like?
Is
this
a
result
of
of
culture
within
those
ecosystems,
or
is
it
a
question
of
technology,
and
I
guess
what
I
mean
by
that
is:
is
there
just
some
crazy
kind
of
like
architecture
or
technology
or
algorithmic
trick
that
is
going
on
in
like
the
rust
compiler?
That
makes
these
error
messages
possible
or
makes
them
easier
to
be?
B
Like
is
this
a
question
of
technology
or
is
it
a
question
of
culture
so
to
start
off,
if
we
can
kind
of
distill
down
error
messages
into
kind
of
this
nice
standard
format
where
up
at
the
top
here,
you
can
see
is
what's
called
the
level
where
it
tells
you
is
this
an
error
or
it
could
be
a
warning
or
it
could
be
a
lint.
For
example,
you
have
the
error
code,
which
is
you
might
hear
it
called
like
the
error
index.
B
So
there's
like
this
nice
error
index
documentation
kind
of
classifying
the
error
by
this
index.
So
you
can
go
ahead
and
like
take
this
error
code,
if
rusty
gives
it
to
you,
it
doesn't
give
you
an
error
code
for
every
single
error
message,
but
for
the
ones
that
it
does
give
you.
You
can
go
ahead
and
take
that
and
basically
look
that
up
inside
of
the
error
index
to
get
some
more
context.
B
Some
more
information
on
this
type
of
error
that
you're
seeing.
Then,
of
course,
you
have
the
main
error
message:
the
location,
the
code
in
question,
all
the
nice
ascii
art,
that's
pointing
straight
at
the
code
in
question
and
then
notes
as
well
as
any
sub
diagnostics,
to
try
to
be
helpful
and
provide
you
with
a
little
bit
more
context
as
to
what
what
the
error
is
in
your
code.
B
So
there's
this
nice
kind
of
standard
format
and
kind
of
the
the
type
or
the
structure
that
deals
with
this
at
the
end
of
the
day
inside
of
rusty
itself.
Is
this
diagnostic
type,
and
so
again
we
can
see
there's
like
a
nice
kind
of
one-to-one
mapping
of
everything
we
just
saw
in
that
kind
of
standard
error
message
format.
B
So
the
way
error
messages
are
kind
of
surfaced
in
russ
c.
Well,
first
off
we
have
to
talk
a
little
bit
real,
quick
about
how
rusty
even
compiles
your
code
and
actually
runs
it.
So
there's
actually
multiple
phases
to
when
the
rust
compiler
is
running
your
code.
But
first
off
is
the
parsing
phase.
It
takes
your
source
code
and
needs
to
go
ahead
and
parse
that
into
some
internal
representation.
B
So
that's
called
the
parsing
phase
and
there
are
certain
types
of
errors
that
are
caught
within
the
parsing
phase,
so
we
can
go
ahead
and
look
at
an
example
like
this
just
trying
to
go
ahead
and
collect
some
numbers
into
a
vector
of
unsigned
32-bit
integers,
and
if
you
stare
at
this
code
hard
enough,
you
might
realize
oh
we're.
We
need
a
turbo
fish
or
basically,
we
didn't
correctly
write
the
the
turbo
fish
in
this
case.
B
So
when
we're
going
ahead
and
collecting-
and
we
use
a
turbo
fish
to
denote
what
kind
of
collection
we
want
to
collect
into,
we
would
use
a
turbo
fish
to
denote
that,
and
in
this
case
we
just
didn't
use
the
correct,
syntax
and
rust
c
tells
us
hey.
You
forgot
the
the
turbo
fish.
My
suggestion
is
to
go
ahead
and
add
those
right.
B
This
parse.suffix
function
down
here
we
can
see
this
function
here.
That's
called
check,
turbo
fish
missing
angle
brackets,
so
a
plus
naming
there
on
the
function-
and
here
is
the
actual
body
of
the
function
itself,
and
it's
basically
checking
it
basically
tries
to
what
it
tries
to
do
is
actually
it.
It
assumes
whatever
is
after
the
two
colons
of
the
collect.
B
It
actually
tries
to
parse
that
as
a
valid
statement,
and
if
it
sees
that
that
is
actually
a
correct
expression
or
an
expression
that
makes
sense,
then
it
will
go
ahead
and
surface
the
error
of
oh.
This
makes
sense
to
me
if
I
put
in
angle
brackets.
So
that's
what
the
problem
is.
You
didn't
put
angle
brackets
in
so
I'm
going
to
go
ahead
and
suggest
that
you
put
those
in
it.
Also.
B
So
this
is
just
kind
of
like
one
example
of
a
type
of
error.
That's
surfaced
during
parsing
and
the
thing
with
when
you're
actually
going
ahead
and
parsing
there's
this
one
data
structure.
That
is
responsible
for
the
entire
parsing
phase,
which
is
called
the
parse
session
here,
and
so
we
can
see
kind
of
up
here
at
this
type
at
the
top
of
this
type
here
the
span
diagnostic
is
what
is
kind
of
responsible
for
holding
on
to
all
of
the
different
error,
messages
or
diagnostics.
B
I
should
say
that
crop
up
during
the
parsing
session,
specifically
other
sorts
of
error
messages
that
can
crop
up,
so
I
or
I
should
say
different
phases
of
the
compilation
process
where
of
course,
other
errors,
other
sorts
of
error
messages
can
crop
up
right.
Of
course,
you
have
one
example
here
that
we'll
look
at
immutability
right,
so
there's
a
separate
phase
after
parsing
when
rusty
is
running
through
your
code,
that
specifically
checks
for
mutability.
B
B
B
There
is,
of
course,
a
function
inside
of
rust
c
that
specifically
handles
this,
this
error
class
and
we
can
find
that
function
here
called
report,
mutability
error
and
again
this
happens
during
the
borrow
checking
phase,
and
I
definitely
could
not
take
a
screenshot
of
the
entirety
of
this
function.
It
was
something
like
434
lines
of
code,
so
it
was
pretty
big
but
of
course,
during
the
borrowed
checking
phase
as
well.
B
That's
going
to
go
ahead
and
yell
at
us
for
saying:
hey
these
references,
don't
live
long
enough
because
they
get
dropped
at
the
end
of
this
closure
and
then
this
particular
class
of
error
then
is
handled
by
this
function
again
with
a
plus
naming
called
report.
Borrowed
value
does
not
live
long
enough,
and
so
these
two
errors
that
we
just
looked
at
again.
B
When
I
was
doing
research
for
this
talk,
one
thing
that
kind
of
kept
one
word
that
kept
kind
of
cropping
up
into
my
head.
While
I
was
looking
through
all
the
stuff
and
then
having
fun
digging
through
russia,
but
the
thing
that
again
cropped
up
in
my
mind.
The
word
that
I
would
kind
of
attribute
all
this
to
is
eagerness.
B
And
so
what
I
mean
by
that
is
well
both.
We
can
look
at
this
both
in
kind
of
the
programming
context,
as
well
as
the
more
general
context
of
what
eagerness
means
right.
So
if
we
think
of
eagerness
in
just
a
programming
context
right,
that's
kind
of
like
the
opposite
of
laziness,
which
is
to
say
every
chance
we
get
to
go
ahead
and
do
a
thing.
We're
gonna.
B
Do
it
versus
laziness
beyond
the
opposite
end
of
the
spectrum,
where
we're
only
going
to
do
a
thing
at
the
last
minute
when
we
can
no
longer
get
away
with
not
doing
it
anymore
right.
So,
in
the
programming
context,
eagerness
is
kind
of
showcased
when
diagnostics
are
constructed
in
russia
because
it
turns
out
every
time
something
could
go
wrong,
as
in
some
kind
of
diagnostic
can
be
created
to
address
some
error.
That's
happening
in
the
compilation
process.
Rusty
will
go
ahead
and
do
it,
and
actually
one
of
the
methods
on
the
diagnostic
class.
B
Is
this
cancel
method?
And
so
what's
actually
going
on?
Is
it's
basically
any
chance?
It
gets
to
start
creating
a
diagnostic
because
it
thinks
something
might
be
going
wrong
during
the
compilation
process,
it'll
go
ahead
and
do
it
and
then,
at
the
end
of
the
day,
right
rusty
only
wants
to
surface
the
relevant
errors.
B
It
speaks
to
again
the
question
that
we
had
coming
into
this
talk,
which
was
was
this
culture
or
technology?
This
to
me
really
speaks
about
culture
right
rusty
and
the
the
developers
who
worked
on
rusty
right
they're,
all
in
that
way,
eager
to
help
you
they're,
eager
to
provide
helpful
context
provided
hopeful
errors
to
make
your
job
your
workflow
as
a
developer,
easier
right
like
if
you're,
if
you
have
to
spend
less
time
thinking
about
deciphering
error
messages,
that's
more
time
that
you
can
be
productive
on
what
you're.
B
B
I
think
technology
takes
a
little
bit
of
a
back
seat
because
really,
I
think,
at
the
end
of
the
day,
even
though
all
this
stuff
that
we
saw
when
we
were
just
going
through
all
of
these
code.
Examples
like
it
is,
it
is
cool
and
it's
it's
probably
ingenious
in
a
sense,
but
at
the
end
of
the
day,
I
don't
think
it
is
more
complex
or
more
crazy
or
more
ingenious
than
anything
else
inside
of
russia
at
the
end
of
the
day.
B
B
And
it's
been
really
interesting
as
well,
seeing
some
other
research
specifically
around
kind
of
like
culture
and
error
messages,
and
how
the
two
kind
of
have
this
feedback
loop.
So
one
thing
I
actually
found
interesting
was
a
research
paper
done
in
2011
by
some
researchers
who
looked
at
racket,
so
they
actually
well.
I
should
say
they:
they
did
a
bunch
of
research
on
students
looking
into
what
is
how
helpful
better
error
messages
are
basically
and
again
the
takeaway
there.
B
No
surprise
really,
but
you
know
better
error
messages
led
to
a
better
learning
experience
and
a
smoother
learning
curve
for
students,
new
students
getting
into
programming
in
this
case-
and
so
you
know
this
was
done
in
2011,
but
I
think
really,
the
takeaway
of
this
particular
research
was
well.
You
know
it's,
it's
not
a
question
of
technology.
The
technology
is
all
there
to
actually
make
it
happen.
Really.
I
I
think
it
is
just
a
question
of
increasing
the
priority
of
or
or
you
know,
yeah
basically
making
error
messages.
B
B
B
It's
you
know
super
great
makes
for
a
much
better
workflow.
I
think
some
other
languages
I'll
also
quickly
mention
like
swift
and
also
typescript.
These
languages
are
doing
some
interesting
things
as
well.
They're,
I
would
say,
taking
a
slightly
different
approach,
but
that's
mostly
because
swift
and
typescript
both
have
really
nice
integrations
with
ides.
So
you
know
swift,
with
xcode
and
typescript
with
vs
code,
there's
some
really
cool
ide
stuff
that
they
can
do
there.
So
that's
kind
of
another,
really
nice
and
streamlined
way
to
surface
error
messages.
B
I
would
say
they
also
have
kind
of
embraced
this-
this
notion
of
improving
the
culture
around
error
messages
and
are
doing
some
cool
things
there
as
well.
But,
ultimately
you
know,
I
think
it
would
be
super
great,
as
this
culture
of
just
trying
to
be
more
helpful
to
developers
trying
to
be
more
helpful
to
new
learners
of
a
programming
language
as
that
culture
kind
of
like
makes
its
way
into
other
language
ecosystems
as
well.
B
Hopefully,
eventually
we'll
get
to
a
point
where
we
have
something
that
looks
more
like
this
and
overall,
at
the
end
of
the
day.
I
think
that
would
be
super
great
for
everybody
and
yeah.
That's
my
talk.
I
hope
you
found
that
insightful
and
just
some
references
as
well
in
case
so
like
the
paper
that
I
talked
about,
is
here
as
well
as
evan's
blog
post
that
I
mentioned
as
well
as
the
rusty
dev
guide
up
at
the
top.
C
B
I
know
they've
had
some
pretty
cool
ideas
such
as
like,
if
hey,
if
we
had
better
integrations
into
some
kind
of
ide,
then
we'd
be
able
to
do
some
of
the
things
that
swift
and
type
typescript
are
also
doing
so
that
would
be
really
cool.
I
don't
know
if
rust
analyzer
is
working
on
some
of
that
stuff,
but
that
would
be
great
but
yeah.
B
It's
been
interesting
as
well,
seeing
if
you
actually
go
back
and
look
at
some
of
the
earlier
pull
requests
for
how
to
kind
of
improve
rust's
error
messages
so
like
I'm
just
I
was
thinking
of
some
names
and
I
totally
blanking
but
anyways.
Sorry
yeah,
like
there
have
been
some
pretty
interesting
ideas
that
people
contributors
to
rust
have
kind
of
thought
of
before
for
how
to
go
ahead
and
improve
error,
handling
or
air
handling
and
rusty,
specifically
like
yeah,
I
can.
B
B
Yeah,
that's
that's
a
little
bit,
that's
a
little
hard
for
me
to
say
to
be
honest,
especially
the
point
about
clippy,
because
even
though
I
think
it
would
be
interesting
to
kind
of
like
fold
clippy
into
rust
c.
At
the
same
time,
I
do
also
know
there's
this
very
deliberate
there's
a
very
deliberate
thing
where
you
know
a
lot
of
where
the
philosophy
of
rust
is
just
like.
We
want
most
things
to
be
in
libraries
and
not
folded
directly
into
the
standard
library
or
folded
into
the
compiler
itself,
so
yeah.
B
B
Handling
working
group
is
kind
of
more
targeting
that
specifically
like
disseminating
this
culture
of
improving
error
messages
to
to
outside
rusty.
Because
again,
I
think,
even
though
this
was
a
really
cool
kind
of
spelunking
tour
for
the
most
part,
I
think
I
don't
worry
too
much
about
the
state
of
air
handling
in
rusty
itself.
I
think
you
know
again
people
really
care
about
that
in
the
core
team,
and
so
I
think,
that's
probably
as
good
a
spot
as
it's
going
to
get.