►
Description
Hacking rustc: Contributing to the Compiler by Esteban Kuber
Compilers are very often treated as a daunting "black box" that only a select few can understand. In reality compilers are "just" another type of program. As long as you know the language the compiler is written in, the language the compiler compiles, and have the time, you too can work on them. If you ever were intrigued about modifying a compiler, or you encountered a bug that you really want fixed soon, this is your chance to roll your sleeves and do it yourself, as we go over the basics of hacking on rustc.
A
A
lot
of
people
have
this
perception
of
compilers
that
they
are
black
boxes
that
run
on
magic
and
pixie
dust
and,
as
you
get
involved,
you
need
to
be
unusually
technically
competent
in
multiple
fields.
At
the
same
time,
there
is
this
idea
that
only
elite
programmers
can
play
with
compilers,
I'm
here
today
as
living
proof
that
this
is
absolutely
and
fundamentally
incorrect.
A
You
don't
need
to
know
or
understand
every
aspect
of
a
compiler
to
meaningfully
contribute.
You
don't
need
to
know
how
optimization
passes
work
to
modify
the
parser.
You
don't
need
to
know
how
the
parser
works
to
understand
how
type
inference
operates,
and
you
don't
need
to
understand
how
type
inference
operates
to
learn,
how
lifetime
analysis
works,
and
even
though
I
just
used
a
bunch
of
jargon
just
now
that
may
be
confusing,
opaque
or
even
intimidating.
A
A
Essentially,
it
takes
text
files,
it's
just
them
in
the
pipeline
and
delivers
either
a
running
binary
or
a
bunch
of
error
messages
that
I
hope
have
been
helpful,
but
that's
it.
Of
course,
there
is
nuance
and
very
advanced
aspects
of
the
compiler,
but
the
vast
majority
of
it
is
straightforward
and
well
modularized.
A
A
You
may
already
know
something
you
want
changed
because
you
encounter
a
bug
like
an
internal
compiler
or
bad
behavior,
or
there
is
a
feature
you
want
in
the
language
for
new
features.
There
is
an
rfc
and
major
change
proposal
process
that
requires
sign-off
by
the
relevant
teams,
usually
the
language
team
for
anything
that
affects
the
semantics
of
how
rust
works
or
the
compiler
theme
when
it's
changed
to
some
implementation
detail,
specifically,
if
it's
user
visible.
A
This
helps
us
organize
ourselves
and
avoid
people
spending
too
much
time
implementing
a
feature
in
a
certain
way
when
the
teams
may
already
have
plans
in
that
area.
Otherwise,
you
can
check
the
backlog
and
look
for
bugs
that
have
been
identified
or
feature
requests
and
pick
the
one
you
want
to
tackle.
A
You
don't
need
to
go
through
the
entire
5000
plus
tickets
to
find
something
that
will
pick
your
interest.
You
can
refine
your
search
using
labels
to
narrow
the
results
to
a
pool
that
best
aligns
with
your
interests
and
or
area
of
expertise.
There
are
three
labels
in
particular
that
I
find
useful
for
newcomer
contributors.
A
The
first
one
is
emender,
which
groups
all
tickets
that
have
an
expert
in
the
subject
matter
who
is
available
to
help
and
guide
you
through
the
process
or
who
has
already
written
mentoring
instructions
that
you
can
follow
as
you
navigate
the
compiler
codebase.
The
second
variable
I
find
helpful
is
easy.
A
A
A
Paradoxically,
that
lower
level
of
urgency
means
that
the
pressure
people
feel
when
taking
them
on
is
much
more
relaxed.
You
can
take
your
time
to
get
yourself
up
to
speed
without
the
fear
that,
let's
say
a
stable
release
is
going
to
go
out
with
a
regression.
If
you
don't
act
quickly,
if
you're
feeling
more
ambitious,
you
can
look
at
recently
accepted
rfcs
and
their
corresponding
tracking
need
items
where
you
may
be
able
to
help
bring
new
features
to
nightly
or
stabilize
existing
nightly
features.
A
We
have
prioritization
labels
labels
to
mark
what
team
should
be
concerned
with
a
given
ticket
and
labels
marking
what
part
of
the
compiler
or
feature
the
ticket
is
concerned
with
we
take
pride
in
having
a
relatively
well-groomed
backlog,
so
finding
the
right
thing
should
be
easy,
and
this
is
an
area
where
people
can
help
beyond
just
writing.
Code.
Writing.
Documentation
and
maintaining
backlog
are
good,
well
appreciated
contributions.
A
A
You
need
several
dozen
gigabytes
of
disk
available
and
the
fastest
cpu
you
can
get
your
hands
on
the
reality.
Is
that
not
all
of
us
have
access
to
that?
Thankfully,
the
project
is
currently
in
the
process
of
procuring
cloud
desktops
for
compiler
development,
to
which
contributors
at
large
should
have
access
stay
tuned
for
further
announcements
in
this
area.
A
A
Because
of
this,
there
is
one
gatekeeping
attribute
to
thrive
when
contributing
the
compiler.
You
need
patience
depending
on
your
operative
system.
Your
setup
will
be
more
or
less
involved.
The
first
thing
you
need
is
getting
git
working
cloning,
the
compiler
repo
in
your
environment
of
choice
and
have
cmake
and
python
installed
x.
Dot
pi
is
the
main
access
point
to
work
in
the
compiler.
It
lets
you
orchestrate
the
build
of
processes,
run
different
types
of
tests
and
how
to
format
the
code
base
it's
pretty
much
equivalent
to
cargo,
but
exclusively
for
the
compiler.
A
The
first
time
you
do.
This
is
probably
a
good
time
to
put
the
kettle
on.
The
next
thing
to
do
is
to
set
yourself
up
for
testing
with
ad
hoc
files.
I
would
encourage
you
to
use
rastapp
to
link
the
compiler
you
just
made
as
a
new
toolchain
accessible
elsewhere
in
your
system.
That
way,
you
can
write,
draw
c
plus
dev
anywhere
in
your
machine,
and
it
will
use
your
compiler.
A
A
A
lot
of
us
have
slowly
gravitated
towards
bs
code,
which
will
likely
be
the
easiest
environment
to
set
up
in
order
to
use
a
debugger
on
your
compiler.
You
will
need
to
enable
debug
symbols
and,
depending
on
your
operative
system,
you
may
have
to
enable
a
few
other
things
too.
There
is
a
single
config.thermal
file
that
lets
you
configure
all
of
this
fair
warning.
We
are
still
having
some
issues
with
bugger
support
when
working
on
the
compiler,
due
to
a
combination
of
some
macro
trigger.
A
A
Let's
say
you've
done
all
of
these
things.
You
should
be
ready
to
code
now,
let's
figure
out
how
to
actually
go
about
finding
where
to
make
the
changes
to
help
you
figure
out,
which
part
of
the
compiler
you
need
to
work
on.
I'd
like
to
point
to
three
main
resources
that
I
highly
encourage
you
to
tap
the
russ
c
dev
guide,
which
provides
much
detail
on
a
lot
of
the
compiler
internals
and
expands
on
what
the
workflow
can
look
like.
A
A
A
You
can
use
git
blame
to
identify
people
who
have
already
worked
in
modules
you're
looking
at,
and
you
can
also
use
the
export
map,
which
is
a
hand
curated
list
of
experts
for
the
different
high
level
modules.
And,
finally,
you
can
also
look
at
merge,
pull
requests
and
close
tickets.
They
are
good
source
of
context
when
working
on
something
similar
to
existing
features.
A
One
thread
I
like
to
pull
on
to
untangle
the
sweater
that
is
the
compiler
is
to
look
at
error
messages.
It
gives
you
something
to
grab
for,
or
you
can
use
the
flag
treat
errors
bag,
which
is
nightly
only
to
get
the
exact
place
where
it
is
being
emitted
and
slowly
work.
Your
way
backwards
from
there.
A
A
A
Once
we
have
an
ast,
we
transform
it
into
another,
very
similar
looking
tree
in
a
high
level,
intermediate
representation,
or
here
this
tree
has
extra
information
in
it.
That
makes
it
easier
to
evaluate
correctness
and
reference.
Other
parts
of
the
code
you
may
already
know
about
expressions
is
the
smallest
useful
unit.
You
will
find
inside
functions
if
you
have
one
plus
one.
That's
three
expressions:
a
binary
operation
expression,
which
owns
two
literal
expressions
for
the
numbers.
A
A
These
two
are
the
fundamental
building
blocks
of
all
the
code
we
write
and
if
you're
changing
code
in
graph
c
you'll
be
interacting
with
them
extensively.
Luckily,
they
hold
a
very
straightforward
relationship
with
the
code
they
represent.
So
if
you
already
know
rust,
you
will
easily
figure
out
what
is
that,
once
the
hair
tree
is
populated,
the
compiler
can
start
doing
its
other
passes.
A
It
does
type
checking,
which
is
making
sure
that
you
really
don't
use
a
signed,
32-bit
integer
when
accessing
an
index
in
a
vector
it
does
straight
resolution,
which
means
figuring
out
what
traits
a
given
type
implements,
and
what
trait
a
method
call
corresponds
to.
This
also
has
to
account
for
trade
balance,
which
has
its
own
very
complex
level
of
evaluation
for
trade
balance
and
associated
types,
russ
c
models
both
as
obligations
which
need
to
be
satisfied.
A
A
If
any
of
those
cases
match,
then
we
can
provide
a
more
targeted
error
and
those
are
the
ones
that
you
normally
see.
If
you
can
come
up
with
cases
where
the
general
error
is
being
displayed,
adding
a
case
to
handle
your
special
case,
wouldn't
be
that
hard
to
do.
We
just
need
to
figure
out
how
to
detect
it.
A
After
all
of
these
are
all
the
things
that
compiler
does
like
lvm
intermediate
representation
code
generation,
invoking
linkers
stirring
intermediate
metadata
from
the
previous
steps
for
incremental
compilation.
All
of
those
steps
are
aided
by
an
on-demand
query
system,
a
bunch
of
macros
that
allow
us
to
avoid
recalculating
things.
We've
done
already
by
caching
them
on
demand.
A
All
of
these
parts
are
fractally
complex.
You
can
deep
dive
into
specific
parts
of
a
single
compiler
pass
and
have
enough
things
to
do
to
last.
A
lifetime
but
doing
useful
and
fun
things
don't
require
digging
that
deep
when
I
started
contributing
was
because
there
was
one
error
that
annoyed
me,
and
here
I
am
six
years
later,
still
contributing
to
the
compiler.
A
Once
you
pull
the
curtain
and
realize
you
can
change
things
well,
it's
hard
to
stop
now.
15
minutes
aren't
enough
to
show
the
whole
development
process
and
working
on
big
rust
code
bases
like
the
compiler
is
time
consuming,
but
it
is
also
a
very
rewarding
experience.
It
is
a
great
way
of
learning
how
a
tool
we
all
use
works.
A
It
lets
you
improve
it
whenever
you
want
and
it
lets
you
pull
back
some
of
the
artifacts
of
language
design
to
have
a
more
accurate
understanding
of
how
the
language
actually
works.
So,
if
what
you
saw
made,
you
think
this
isn't
that
hard
and
have
the
time
to
jump
in.
Please
do
remember
you're,
not
alone.
We
are
all
looking
forward
to
helping
you
make
your
mark
on
the
project.