►
Description
IDE support is one of Rust’s most requested features. From the 2017 State of Rust Survey: roughly 30% of Rust users are looking forward to IDE support more than any other feature in 2017 and for 22% of non-users, lack of IDE support is their main reason for not using Rust. In this talk, I’ll cover what it took to support Cargo workspaces in the RLS and I’ll explain how the RLS leverages existing tooling, including Cargo and the compiler. I’ll demonstrate the current state of Rust programming with an IDE, and how you can benefit from using an IDE with your Rust projects.
About Igor Matuszewski:
Igor is studying Computer Science at the University of Warsaw, Poland. Having worked on a AAA game and various smaller ones, he grew tired of the repetitiveness of the process and started a journey to find a language that would aid in building better abstractions. He discovered Rust and decided to help further the IDE story, so the development process would be more enjoyable. He was accepted onto the Google Summer of Code 2017 as a student and has been working to improve the RLS and IDE support.
A
A
So
the
plan
for
this
talk
is
to
first
talk
about
the
architecture
of
the
rust
language
server,
which
currently
is
the
officially
kind
of
support
away
the
way
to
have
your
ID
features
and
for
your
favorite
editor
of
choice,
then
I
plan
to
demonstrate
very
quickly
how
such
features
work
then
I'll
talk
about
how
Karger
coordinates,
builds
and
why
the
RLS
should
bother,
and
finally,
I'll
talk
about
supporting
cargo
workspaces
and
the
RLS
itself.
So
without
further
ado,
let
us
begin
so.
First,
the
architecture.
A
So,
as
the
name
suggests
rust,
language
server
is
actually
a
language
smartness
server,
as
in
it's
not
a
monolithic
ID.
Let's
say
the
compiler
is
not
embedded
in
the
ID
itself,
but
rather
it
serves
to
be
sort
of
a
standalone
server
with
with
different
IDs
or
text.
Editors
can
communicate
with
and
they
communicate
with
it
via
a
custom.
Interposes
protocol
called
the
LSP
and
the
LSP
has
been
developed
by
Microsoft.
A
It's
the
full
name
is
language
server
protocol,
and
so
it
aims
to
abstract
away
all
it
aims
to
be
as
language
agnostic
as
possible
as
in
it
does
not
even
try
to
define
any
semantics
of
a
language.
So,
for
example,
it
does
not
know
what
let's
say,
class
or
interface
or
structures.
It
mostly
deals
with
text,
buffers
and
texts
and
the
most
abstract
thing
to
define,
let's
say
a
symbol
for
language
as
a
symbol
or
a
reference,
and
that's
it
and
that's
it.
A
So
why
even
start
using
LSB?
Why
not
just
create
another
ID
such
as
visual
studio
for
n
languages
and
n
editors?
We
can
see
that
we
get
M
times
n
different
implementations
for
different
language
supports
in
different
editors
and
by
being
as
language
agnostic
as
possible
and
by
abstracting
away
the
of
the
protocol
at
a
communication
we
only
need
to
implement
only
a
single
client
for
each
editor
and
only
a
single
LSB
server
for
each
language.
A
We
want
to
support,
and
in
this
example,
if
let's
say
we
use
LSP
compliant
client
and
let's
see
then
that
can
talk
to
let's
say
Rus
language
server,
which
aims
to
support
rust.
We
can
see
that
they
can
interrupt
very
easily.
So
with
this,
the
number
of
implementations
goes
down
to
well
M
plus
n.
Only
so
this
is
very
convenient.
A
So
what
may
be
the
responsibilities
of
a
set
server?
Well,
first
of
all,
it
has
to
coordinate
and
schedule.
Different
analysis
builds.
So
let's
say
users
starts
typing
or
modifying
a
file.
The
RLS
shouldn't
really
try
to.
Let's
say
you
run
cargo
check
or
run
cargo
build
with
every
keystroke,
that's
not
optimal,
to
say
the
least,
so
it
has
to
coordinate
that
it
also
has
to
manage
all
the
announces
data
that
let's
say
it's
a
small
database
that
contains
all
the
references
to
the
symbols
and
whatnot.
A
So
it
has
to
know
how
to
answer
all
the
let's
say:
final
references
week
was
accordingly
and
lastly,
well
it's
LSP
servers,
so
it
has
to
respond
using
the
LSP
queries
respond
to
all
the
speakers,
so
it
actually
aims
to
reuse
all
the
existing
tools
and
it's
probably
a
bad
idea
to
just
try
and
reimplementation
ality
again
inside
a
different
tool.
While
we
have
all
these
awesome
tools
that
are
existent
and
supported
and
the
rust
ecosystem.
A
So,
for
example,
when
you
want
to
format
your
document,
you
can
use
rust
format
for
that
or
when
you
want
to
analyze
project
structure,
you
can
use
card,
go
in
the
library,
auto-completion,
racer,
etc,
etc.
So
in
this
regard
are
less
actually
aims
to
serve
as
a
single
point
of
entry
for
all
the
ID
features
you
might
want,
and
you
can
get
it
now
easily
I
assume
almost
everyone
has
rust
of
installed.
A
So
the
only
thing
you
need
to
do
is
to
run
rust
of
component
odds
are
less
and
if
you
have
a
less
be
compliant
extension,
let's
say,
and
an
editor
you're
good
to
go.
They're
also
like
different
extensions
that
are
more
rust
and
are
less
oriented,
as
in
you
can
click
your
where
you
click
your
way
through
and
they
will
install
rasta
for
you,
the
appropriate
tool
chain
and
the
component
itself.
So
right
now
for
Visual
Studio
code,
the
officially
supported
one
is
rust
RLS
and
from
last
time,
I
checked.
A
You
get
the
same
functionality
installing
the
IDE
rust
package
for
atom,
okay,
so
the
capabilities
and
I'm
going
to
demo
that
using
Visual
Studio
codes,
because
it's
mostly
supported
I
mean
you
can
probably
get
the
most
support
from
the
RLS
right
now
and
I
recorded
videos
because
I
don't
want
to
do
live
coding
because
there
are
a
lot
of
new
and
try
a
new
dimension
for
screw-ups
with
that.
So,
let's
see
if
it
works.
A
Okay,
so
first
I'm
going
to
talk
about
Diagnostics
and
it's
probably
very
easily
overlooked,
but
it's
just
simple
but
the
most
essential
feature
as
in
it's
probably
the
embodiment
of
the
edits
and
cargo
check
cycle,
you
must
probably
find
ourselves
in
so
when
you
edit
your
code,
you
want
to
run
cargo
check
to
see.
If
you
have
any
errors
or
warnings,
then
you
fix
them,
editor
code
again,
etc,
etc.
A
Okay,
you
can
believe
me
that
deers
are
the
same
for
the
rusty
and
they
were
the
one
that
was
displayed
and
the
ID
itself,
so
the
next
functionality
that
LSB
also
offers
is
horror.
So
let's
say
you
have
your
definition:
let's
see
a
structure
or
a
function
and
it
has
an
associate
documentation
whether
it's
the
dark
comments.
These
are
also
served
by
the
LSP
and
the
RLS
itself.
So
when
you
hover
over
the
function,
let's
say
you
also
get
an
a
tooltip,
the
documentation
and
markdown.
So
that's
really
convenient.
A
A
Next
thing,
we
have
go
to
definition,
so
it's
also
very
convenient
to
be
able
to
jump
to
where
a
given
structure
or
function
is
defined.
Most
importantly,
to
see,
for
example,
how
a
structure
is
defined,
what
are
the
members
possibly
there's?
Also
an
in
block
nearby
or
in
which
context
the
given
function
is
defined,
and
this
also
allows
us
to
strengthen
the
kind
of
mental
connections,
the
metal
model
of
our
project
that
we
work
on.
A
Straightforward
we
have
mix,
we
issued,
go
to
definition
and
we
automatically
jump
to
a
module
containing
that
definition.
Also,
we
have
find
references.
This
is
also
handy
to
realize
what
may
be
the
interdependencies
between
modules.
So
let's
say
we
work
on
another
module
and
we
want
to
see
in
which
other
modules
or
parts
of
the
codebase
the
symbols
are
full
then,
and
so
it's
also
very
convenient
thing
to
have.
C
A
A
So
this
is
a
very
simple
example,
as
I
said
we
are
served.
This
is
part
by
racer
and
we
are
served
the
suggestions
for
all
the
symbols
that
were
defined
locally
in
this.
In
this
context,
and
for
example,
after
we
type
dot
and
after
the
structure,
we
are
served
the
data
members
and
the
functions
that
are
valid
for
that
structure,
and
we
can
check
that
these
are,
in
fact
the
ones
that
all
that
are
valid
and
we
can
double
check
that
these
suggestions
are
in
fact
valid
and
they
work
and
the
program
compiles
and
works.
A
Ok,
so
with
the
demo
uttered
way,
let's
talk
about
how
cargo
coordinates
builds,
but
first
of
all
to
talk
about
the
RLS,
not
cargo.
So
why
should
our
less
butter?
Well?
First
of
all,
as
I
said,
it
leverages
all
the
existing
tools,
which
is
cargo,
also
its
uses
it
to
analyze
a
project,
structure
and
schedule
it
built,
and
it's
good
to
know
about
that.
So
we
can
reuse
all
the
results
to
cache
it
and
then
reduce
the
latency
for
the
user,
so
the
user
doesn't
have
to
wait
three
seconds.
You
can
right
now.
Wait.
A
Okay,
so
very
simply
I'm
going
to
talk
about
from
the
RLS
point
of
view
what
cargo
does
and
even
then
I'm
going
to
simplify
a
little
bit
to
extract
the
gist
of
it.
So
what
cargo
does
is
it
looks
at
the
declared
package
dependencies
with
using
several
constraints.
So
let's
say
we
can
declare
our
dependency
saying:
okay,
I
need
exactly
version,
1.2
point
O
for
a
given
dependency
or
any
other
compatible
with
it.
So,
with
this
information,
with
these
dependency
constraints,
we
get
a
constraint
graph
dependency
graph.
A
So
what
we
do
later
is
we
resolve
the
constraints
to
actually
specify
packages.
There
are
the
resulting
data
structure,
is
a
dependency
directed
acyclic
graph
between
packages
and,
let's
delve
deeper,
what
it
means
and
what
it
is.
So,
let's
take
an
example:
web
render,
which
consists
of
three
packages
wrench
web,
render
and
would
render
API.
So
the
graph
has
to
be
between
packages,
at
least
at
this
point.
It
has
to
be
directed
because
dependency
is
very
directed
in
its
nature.
A
So
the
graph
has
to
be
a
cyclic,
and
these
properties
actually
guarantee
that
we
can
achieve
a
topological
sorting
of
a
graph,
so
topological
sorting
what
it
is
simply
put
from
a
build
system.
Point
of
view:
the
order,
the
linear
order
of
a
graph
of
how,
in
which
order,
can
the
packages
be
compelled.
So
that's
no
point
of
time
we
are
compiling
a
package
for
which
its
dependencies
were
not
build
before.
Basically,
so
in
this
example,
we
can
take
web
render
API
first,
because
it
does
not
depend
on
anything
else.
A
Then
we
render
and
then
we
can't
build
rent.
Yet
we
have
to
build
Sri
before
and
after
that,
as
you
can
see,
the
numbers
create
the
linear
ordering
of
a
given
graph
and
there's
no
only
one
ordering
for
a
given
graph.
Most
often
there
are
many
but
I
guess
you
can
pick
one
and
then,
when
we
have
that
we
need
to
transform
it
into
a
dependency
dag
between
package
targets.
So
we
have
to
go
lever
down,
let's
say
more
fine-grained
on
a
more
fine-grained
level.
A
So
we
can
sure
that,
as
I
said,
then
we
get
the
ordering
of
package
targets
and
how
this
is
very
convenient
is
that
this
almost
Maps
one
to
one
to
appropriate
receipt
and
vacations.
So
after
we
did
that,
the
only
thing
cargo
still
has
to
do
is
to
schedule
and
spawn
Russy
process
and
processes,
that's
the
data,
coordinated,
etc.
A
Okay.
So,
with
this
out
of
the
way,
let's
talk
about
supporting
cargo
workspaces,
but
first
of
all,
what's
a
workspace.
So
let's
take
a
look:
what
cargo
new
creates
by
default,
so
by
default?
It
creates
a
single
package
project,
so
there's
a
cargo
door
lock
file
with
all
the
resolve
dependencies,
which
is
basically
the
resolve
dependency
graph.
That
I
told
you
about,
and
the
target
directory
for
the
build
artifacts
that
are
created
during
the
build
and
obviously
also
there
is
an
actual
package
with
its
manifest
file
apartment
amo.
A
So
how
workspaces
differ
from
the
single
package
project
is
that
we
still
have
the
same
lock
file
and
the
target
directory.
But
now
the
main
package
is
optional
and
we
can
explicitly
specify
all
the
member
packages
inside
a
project,
so
it
can
host
multiple
packages
so
how
the
RLS
operated
up
and
up
until
this
point
is
that
it's
supported
only
a
single
package
target
which
is
quite
limiting,
as
you
can
guess,
because
even
a
single
package
can
contain
binary
and
library.
A
So,
even
if
you
want
to
work
on
your
library,
you
only
get
the
Diagnostics
the
warnings
and
the
ID
features
only
for
the
library,
but,
as
is
most
most
often
the
case.
The
package
is
split
into
binary
and
library
and
library
hosts.
Almost
all
of
the
implementation
and
binary
is
mostly
a
thin
wrapper
around
that.
So
when
we
switch
to
actually
supporting
bin,
we
lose
all
the
ID
features
for
the
lip,
which
is
the
most
part
of
the
program.
So
it's
very
limiting
at
this
point.
A
So
how
did
how
it
works
in
this
mode
is
that
it
runs
cargo
procedure
first
when
analyzing
a
project
and
it
stores
the
final
compiler
invocation
that
cargo
issued
and
you
can
configure
it
right
now
with
rust,
dot,
build
underscore
bin
andross
build
underscore
live
options.
Obviously
any
LSP
supporting
clients
that
support
the
configuration
API
will
do,
but
right
now,
I
think
only
the
rusts
extension
for
the
vs
code
does
so,
let's
see
how
that
works
and
that
we
get
this
between
binary
and
library.
A
So
we
have
Diagnostics
only
for
library
here
as
we
can
see.
This
is
a
simple
package
that
is
split
into
a
Lib
and
bin,
so
we
changed
the
configuration
to
analyze
the
binary
and,
as
we
can
see
it
flipped
to
for
the
Diagnostics
for
the
binary,
so
we
lost
all
the
information
and
the
Diagnostics
for
the
library
and
the
newly
implemented
mode,
which
is
still
experimental
and
your
mileage
may
vary
as
the
workspace
mode.
So
how
does
that
differ
from
the
previous
one?
A
Is
that
I
told
you
the
previous
one,
only
caches
the
last
invocation,
while
in
the
workspace
mode
we
teach
are
less
about
the
interdependencies
between
packets
targets
and
thus
between
packages.
So
we
are
able
to
fetch
all
the
Diagnostics
data
for
each
target
and
end
result
for
each
package
and
because
it's
still
unstable
you
need
to
enable
its
feature,
is
behind
a
future
gate.
:
stable
features,
so
you
need
to
enable
both
the
stable
features
and
the
workspace
mode.
A
A
Their
first
one
depends
on
the
second
one,
as
you
can
see
in
the
manifest
file,
and
the
code
obviously
should
not
compile,
but
we
are
not
fed
any
diagnostics
and
we
can
use
any
features
for
it.
So,
let's
try
flipping
the
switch
to
on
for
the
workspace
mode
and
sits
in
sits
since
it's
unstable,
sometimes
it's
best
to
just
reload
it
and
restart
it
with
the
workspace
mode
on,
and
we
need
to
wait
a
bit,
and
here
we
go.
We
are
served
diagnostics
and
we
also
get
the
outer
completion
inside
a
workspace.
A
Okay,
so
simply,
how
does
it
work?
How
the
how
is
the
workspace
mode
implemented
and
how
does
it
differ?
Well,
first
of
all,
we
need
to
cache
the
structure
that
is
used
by
cargo,
that
cargo
generates
between
packets
targets
and
when
we
have
that,
we
can
then
easily
map
the
dirty
packages,
sort
the
result
and
get
the
appropriate
compiler
invocations
that
the
RLS
can
actually
execute
and
fetch
the
data
and
analysis
from
so
first,
as
I
said,
we
use
a
heuristic.
A
We
map
dirty
files
since
last
successful
analysis
built
for
appropriate
package
targets
inside
a
graph.
So
in
this
example
we
modified
the
library
of
web
render.
Then,
when
we
modify
in
quick
succession,
let's
say
bill
script
of
wrench.
We
also
mark
that
mark
that
and
then,
after
the
build,
is
scheduled
and
actually
executed.
We
have
to
perform
another
step
which
is
mark
all
the
transitive
dependencies,
because
in
this
case,
when
we
let's
say
when
we
have
analysis
data,
we
modify
the
both
scripts.
A
We
still
have
to
recompile
and
fetch
results
from
the
binary
which
depends
on
it
because
it
might
be
invalidated
by
any
recompilation
of
the
build
script.
So
when
we
have
that
when
we
have
diagraph,
we
can
then
easily
topologically
sorted
again.
We
get
the
same
ordering
we
had
when,
with
what
cargo
did
previously,
we
use
the
cached
compiler
invocations,
which
we
captured
during
running
cargo,
build
procedure,
and
then
we
actually
have
to
run
in
process
compiler.
So
how
does
that?
How
does
that
differ
from
what
cargo
does?
A
Is
that
cargo
spawns
new
processes
for
each
compiler
invocation?
And
this
actually
won't
do
for
the
our
last
case,
because
there's
a
significant
overhead
for
when
we
want
to
omit
the
safe
analysis,
data,
which
is
an
annotation
love
to
the
disk,
only
to
be
read
later
so
we're
talking
about
Meg's
of
text
data
that
is
only
written
to
disk
without
any
purpose.
So
we
passed
that
in
memory.
So
there
is
a
small
caveat
here
also.
A
A
A
B
D
So
at
the
start,
you
said
with
the
RLS
and
the
LSP:
don't
need
n
times
and
plugins
and
plus
n,
but
then
you
said
you
should
install
the
vs
code,
RLS
plug-in
how
like
how
big
is
the
specific
plugin
for
virtual
studio?
Is
it
just
a
small
shim
to
like
setting
up,
or
is
there
actually
law
code
in
it?
No.
A
So
actually,
Microsoft
developed
the
standard
because
the
the
LSP
actually
is
developing
Microsoft.
They
also
developed
vs
code,
so
it
was
actually
very
handy
and
convenient
for
them
to
implement
a
generic
LSP
client
first
and
they
expose
it
as
a
library.
So
how
the
rust
extension
works
is
that
it
loads
a
bulk
of
the
LSP.
It
uploads
all
the
LSP
responsibilities
to
the
library,
that's
created
by
Microsoft
and
I.
Think
the
rust
specific
parts
are
like
5%
10%
of
the
overall
size
of
the
extension
I
guess
so
not
not
much.
A
C
So
my
question:
is
you
mentioned
that
you
use
rusty
and
cargo
itself
already,
but
it
sounds
like
you
do
a
lot
of
the
tasks
that
would
be
the
job
of
those
things
instead
in
RLS
itself,
specifically
the
compilation
ordering
and
stuff
like
that.
So
is
that
something
you
do
in
RLS
or
is
that
something
that
rusty
does,
which.