►
From YouTube: rust-analyzer type-checker overview by flodiebold
Description
flodiebold introduces how the rust-analyzer type checker works, and we discuss various possible next steps towards integrating chalk with RLS 2.0.
A
A
A
Some
of
the
chalk
support
four
traits
in
with
it,
and
in
my
ideal
world
we
could
have
some
kind
of
shared
library
that
represents
types
which
can
be
used
by
chalk
and
by
RLS
2.0,
and
that
that
same
library
then
we
can
maybe
share
some
code
for
sort
of
trait
lowering,
basically
the
chalk
eye
our
generation
and
the
talks
over
and
thus
kind
of
pushed
a
little
bit
past
the
state
of
the
art
world.
We
might
have
been
able
to
do
with
rusty
leapfrog
ahead
and
longer
term.
A
B
Or
maybe
just
as
a
general
idea
where
we
are
currently
so
we
have
basic
type
of
parents,
including
generators
and
so
on,
of
course,
not
trade
sorting
and
in
general
the
goal
has
been
to
kept
mostly
for
completion
going,
so
we
don't
do
any
Diagnostics
or
anything.
We
just
try
to
understand
as
much
as
possible
about
the
types
of
so.
B
So,
for
example,
if
we
want
to
get
some
completions
in
the
functioning,
the
completion
code
requires
a
function
on
the
inner
function
and
get
back,
and
then
parents
with
eyes
which
basically
contains
some
types
of
foreign
expressions
and
patterns
and
some
more
tables
to
including
information
about
resolutions
of
methods
and
so
on.
This.
A
B
Yeah,
and
so
this
uses
these
other
queries
that
are
around
here,
most
importantly,
this
body,
curry,
which
I
think
Alexia
shorted,
either
so
text.
We
is
video
already,
but
basically
deep,
its
intermediate
representation
between
the
full
syntax
trees,
which
contain
one
the
whitespace
and
ranges
and
so
on.
B
A
B
B
B
These
already
so
these
become
the
highest
type,
which
is
the
actual
type
structure
we
use
in
the
pattern
parents,
but
this
is
already
name,
is
so
yes
basic,
yet
let's
go
to
this
next
set.
So
this
is
the
representation
of
types
we
use
doing
type
inference,
and
so
this
is
basically
the
main
inspiration
for
this
is
the
I
think
called
the
PI
kind,
young
and
Rafi.
B
B
B
B
B
A
B
B
B
B
Yeah,
we
have
to
know
in
step
which
takes
definitions
and
references
to
types
and
lowers
them
to
occupy.
This
is
basically
two
big
parts
with
the
one.
Is
this
this
type
for
destiny,
which
I
showed
the
other
is
the
function?
F,
takes
reference
of
two
types
and
mainly
convicted
type
of
it's
by
resolving
events.
B
B
B
B
B
B
B
A
B
B
B
B
B
B
A
B
B
B
B
B
Basically,
almost
all
tests
for
the
type
inference
currently
has
been
protests
where
we
just
have
some
source
file,
and
you
make
a
sentence
which
contains
all
types
of
one
expression
Sigma.
We
just
like
to
see
more
for
for
a
lot
of
different
expressions
of
what
the
type
is
implementing
change
reading,
which
we
get
y
to
the
HK,
visible
ball.
A
A
Just
know
it
happens
to
be,
you
know,
a
pain
point
in
rusty
as
well,
but
I
mean
one
of
the
things
I'm
thinking
listening
to
all
this
is
that
it
would
be
kind
of
interesting
and
valuable,
maybe
to
walk
through
some
of
what
we
were
doing
in
lark
when
we're
like
Jonathan
and
I
were
playing
around
there,
because
we
did
similar
things
but
different
in
a
lot
of
cases.
I,
don't
we
could
might
be
a
good
thing
to
do
for
a
different
time.
Something
I
would
want
to
think
about
going
forward.
A
A
Has
that
been
any
kind
of
performance
issue,
and
do
you
make
any
effort,
for
example,
to
deduplicate
like
if
you
have
a
whole
bunch
of
boolean
I,
don't
know
that
slices
the
boolean
types
or
something
like
that?
Okay,
so
you
know,
are
you
doing
anything
to
kind
of
deduplicate
or
you're,
just
allocating
fresh
copies
of
those
types?
Each
time.
B
B
A
B
A
B
B
A
A
A
Trying
to
decide
we
could
talk
a
little
bit
about
what
what
it
might
look
like
if
we
had
a
shared
library
for
types
and
like
what
I
had
in
mind
there,
we
could
talk
a
little
bit
about
some
of
the
stuff
we
did
in
lark.
That
differs,
although
I
didn't
really
look
at
that
code
in
a
while,
so
I'd
probably
be
pretty
sloppy,
there
might
be
better
to
not
do
that.
Latter,
one
until
I'd
be
interested
in
going
over
it.
At
some
point,
B.
A
So
I
guess
we
could
talk
a
little
bit
about
types,
I,
I
think
what
I
was
thinking.
So
if
you
like,
your
definition
of
types
is
fairly
similar
to
russy's
and
one
thing
I've
been
wondering
about
is
trying
to
get
a
much
simpler
definition
in
some
sense.
Basically,
because
it
turns
out
that
you
know
most
of
those
types
that
are
in
there
like
insane
boolean's
and
whatever
else
all
right,
some
sense,
no
different
from
like
a
fresh
struct.
A
You
know
for
most
parts
of
the
system,
they
don't
care,
they're,
just
they're,
just
a
type
and
so
I
I
think
I'm
hoping
we
could
get
it
down
so
that
we
have
basically
only
a
few
variants.
You
know
kind
of
one
would
be
like
some
named
type
with
some
number
of
substitutions
given
to
it,
and
one
would
be
sort
of
a
for
all
kind
of
type
and
then
an
inner
type,
and
maybe
a
few
more
I
have
to
go
look
Struck's
definition.
A
B
A
A
A
A
Have
something
this
would
be
like
that,
give
you
32
or
you
32
or
stream
a
projection
would
be
some
some
associated
type
projection.
Unselected
projection.
That's
that's
kind
of
an
interesting
point.
So
actually
what
projection
really
represents
is
something
where
the
trait
is
known
and
you
haven't
dealt
with
this
kind
of
stuff
yet.
But
you
know,
of
course,
most
of
the
time
you
just
write
something
like
this
in
rust
today,
right
and
so
the
idea
of
unselected
projection
in
rust,
see
we
have
a
kind
of
hack
that
uses
a
the
basically
converts.
A
If
you,
if
you
tied,
tikal
and
call
an
item,
it
tries
to
figure
out,
you
know
the
trait
automatically
via
some
heuristics
and
off.
Sometimes
it
fails
and
that's
when
you
have
to
write
the
full
form
out
what
what
truck
is
trying
to
do
instead
is
to
have
that
be
a
first
sort
of
a
first
class
thing
where
you
say:
I'm,
pretty
I'm,
writing
te,
:
:
item,
but
I
didn't
say
what
straight
it
is,
and
it'll
figure
out
which
trait
it
could
have
been.
Essentially
for
all
this
is
sort
of
in
rust.
A
You
can
only
have
these
for
all
binders
on
functions,
but
in
chocolates
a
little
more
generic,
so
you
know
when
you
have
like
a
function
that
can
be
called
with
a
reference
of
any
lifetime
in
chalk.
That
would
be
composed
of
two
things
essentially,
and
then
these
parts
are
the
entrance,
so
inference
bar
is
an
inference
variable,
and
this
is
a
this
is
actually
a
for
all
variable
like
to
get
the
example
above.
A
A
Arenas,
I,
don't
think
that's
a
very
good
fit
for
an
IDE
like
setting
but
I.
Maybe
it
doesn't
really
matter
too
much,
but
I
do
feel
like
we
can
probably
do
better
than
arcs.
It
hasn't
proven
to
be
a
compilation
time
hit
for
you
all
I
guess
primarily
because
it
probably
doesn't
affect
responsiveness
too
much
in
small
functions,
but
I
think
if
you're
trying
to
find
all
the
errors
in
a
project
or
something
you
will
start
to
notice
it.
On
the
other
hand,
maybe
it's
premature
optimization
to
worry
about
it.
A
I
don't
know,
but
it
feels
like
the
kind
of
thing
that
we
want
to
at
least
think
a
little
bit
about
since
it'll
be
a
pain
in
the
neck
to
change
it
later
in
lark.
What
we
did
was
we
used
into
interning
scheme
pretty
universally,
but
but
so
basically
they
passed
on
integers
and
had
a
way
into
given
a
database.
You
could
you
could
kind
of
get
back
the
what
the
integer
represents
just
kind
of
nice
because
everything's
copy,
but
so
that's
one
part
of
it,
but.
A
Now
I'm
realizing
well,
you
know,
I
think
the
other
ideas
that
I
have
I
would
rather
go
into
by
walking
through
some
of
what
we
did
with
Larkin
I.
Think
I'd
rather
schedule
a
follow-up
session,
but
maybe
that's
a
good
thing
to
close
on
is
talking
a
little
bit
about
like
what
the
next
steps
you
were
thinking
about
are
and
what
you
know
what
we
should
do
next
overall
to
start
with,
is
this
slot
kind
of
good?
A
B
Mean
there
has
to
various
details
on
the
same.
Like
I
mentioned
that
type
of
entities-
words,
we
don't
implement
finding
notes,
for
example,
currently,
so
there
are
still
some
missing
parts
in
the
parts
we
have,
but
I
was
also
already
thinking
about
how
to
start
and
contain
the
train
system.
I
think
it
will
probably
a
lot
name
things
and
filling
in
the
details.
Right
now,
yeah.
A
B
A
A
So,
like
okay,
we
were
discussing
kind
of
next
steps
for
the
rust
analyzer
itself
and
it
would
basically
be
there
are
some
gaps
to
fill
in
which
we
view
is
sort
of
low
priority.
You're
saying
or
you
view,
and
then
there's
the
trade
system,
integration
and
kind
of
presenting
errors,
and
what
I
was
going
to
say
about
presenting
errors
is
that
there
is
certainly
a
certain
amount
of
work,
just
tracking
formatting,
etc.
The
ears
there's
also
gonna,
be
I.
Think
a
lot
more
like
the
completeness
metric
is
gonna,
be
pretty
different.
A
B
A
I
mean
so,
let's
see
just
random
note.
One
of
the
things
that
we
did
in
mark
is
when
we
wrote
unit
tests,
one
of
the
one
of
the
modes
was
to
say
kind
of
an
annotation.
That
would
say
okay.
What
what
is
the
type
of
the
thing
that
I'm
pointing
out
here
and
so
instead
of
just
dumping
the
types
for
everything
you
could
dump
the
types
for
specific
things
it
seems
like
we
could
investigate,
adding
that
into
a
that,
doesn't
actually
seem
too
hard
a
kind
of
option
to
say
get
in
this
location.
A
B
A
A
So
especially
because,
like
if
we
kind
of
fill
in
a
little
of
what
I
said
before
on
this
long-term
vision
of
like
a
separate
library
for
a
type-checking
which
I
think
is
fairly
far
down
the
road.
But
that
would
really
certainly
by
then
we
would
want
some
way
to
like
compare
our
behavior
against
rusty
right.
A
A
So
we
did
a
few
things
which
may
or
may
not
have
been
great
but
they're
kind
of
interesting,
like
using
different
type
families
using
the
type
checker
to
make
sure
that
you
get
generics
right,
for
example,
and
don't
forget
to
apply
a
substitution
and
stuff
like
that,
so
kind
of
more
variations
on
what
a
type
is
depending
on
where
it
is
in
the
system.
We
also
had
a
type
checker
that
ignored.
We
have
different
for
the
same
type.
A
A
A
Think
I
would
rather
not
but
like
I
would.
Rather,
if
we
can
plan
out
a
more
ambitious
chocolate
invasion
plan,
I'm,
not
exactly
sure
what
that
means.
I
think
it
would
mean
basically
starting
out,
probably
starting
out
by
trying
to
share
a
representation
of
types
and
try
to
share
some
of
the
lower
income.