439 lines
23 KiB
HTML
439 lines
23 KiB
HTML
<!DOCTYPE HTML>
|
||
<html lang="en" class="light sidebar-visible" dir="ltr">
|
||
<head>
|
||
<!-- Book generated using mdBook -->
|
||
<meta charset="UTF-8">
|
||
<title>Trait solving - Rust Compiler Development Guide</title>
|
||
|
||
|
||
<!-- Custom HTML head -->
|
||
|
||
<meta name="description" content="A guide to developing the Rust compiler (rustc)">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1">
|
||
<meta name="theme-color" content="#ffffff">
|
||
|
||
<link rel="icon" href="../favicon.svg">
|
||
<link rel="shortcut icon" href="../favicon.png">
|
||
<link rel="stylesheet" href="../css/variables.css">
|
||
<link rel="stylesheet" href="../css/general.css">
|
||
<link rel="stylesheet" href="../css/chrome.css">
|
||
<link rel="stylesheet" href="../css/print.css" media="print">
|
||
|
||
<!-- Fonts -->
|
||
<link rel="stylesheet" href="../FontAwesome/css/font-awesome.css">
|
||
<link rel="stylesheet" href="../fonts/fonts.css">
|
||
|
||
<!-- Highlight.js Stylesheets -->
|
||
<link rel="stylesheet" id="highlight-css" href="../highlight.css">
|
||
<link rel="stylesheet" id="tomorrow-night-css" href="../tomorrow-night.css">
|
||
<link rel="stylesheet" id="ayu-highlight-css" href="../ayu-highlight.css">
|
||
|
||
<!-- Custom theme stylesheets -->
|
||
|
||
|
||
<!-- Provide site root and default themes to javascript -->
|
||
<script>
|
||
const path_to_root = "../";
|
||
const default_light_theme = "light";
|
||
const default_dark_theme = "navy";
|
||
</script>
|
||
<!-- Start loading toc.js asap -->
|
||
<script src="../toc.js"></script>
|
||
</head>
|
||
<body>
|
||
<div id="body-container">
|
||
<!-- Work around some values being stored in localStorage wrapped in quotes -->
|
||
<script>
|
||
try {
|
||
let theme = localStorage.getItem('mdbook-theme');
|
||
let sidebar = localStorage.getItem('mdbook-sidebar');
|
||
|
||
if (theme.startsWith('"') && theme.endsWith('"')) {
|
||
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
|
||
}
|
||
|
||
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
|
||
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
|
||
}
|
||
} catch (e) { }
|
||
</script>
|
||
|
||
<!-- Set the theme before any content is loaded, prevents flash -->
|
||
<script>
|
||
const default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? default_dark_theme : default_light_theme;
|
||
let theme;
|
||
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
|
||
if (theme === null || theme === undefined) { theme = default_theme; }
|
||
const html = document.documentElement;
|
||
html.classList.remove('light')
|
||
html.classList.add(theme);
|
||
html.classList.add("js");
|
||
</script>
|
||
|
||
<input type="checkbox" id="sidebar-toggle-anchor" class="hidden">
|
||
|
||
<!-- Hide / unhide sidebar before it is displayed -->
|
||
<script>
|
||
let sidebar = null;
|
||
const sidebar_toggle = document.getElementById("sidebar-toggle-anchor");
|
||
if (document.body.clientWidth >= 1080) {
|
||
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
|
||
sidebar = sidebar || 'visible';
|
||
} else {
|
||
sidebar = 'hidden';
|
||
}
|
||
sidebar_toggle.checked = sidebar === 'visible';
|
||
html.classList.remove('sidebar-visible');
|
||
html.classList.add("sidebar-" + sidebar);
|
||
</script>
|
||
|
||
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
|
||
<!-- populated by js -->
|
||
<mdbook-sidebar-scrollbox class="sidebar-scrollbox"></mdbook-sidebar-scrollbox>
|
||
<noscript>
|
||
<iframe class="sidebar-iframe-outer" src="../toc.html"></iframe>
|
||
</noscript>
|
||
<div id="sidebar-resize-handle" class="sidebar-resize-handle">
|
||
<div class="sidebar-resize-indicator"></div>
|
||
</div>
|
||
</nav>
|
||
|
||
<div id="page-wrapper" class="page-wrapper">
|
||
|
||
<div class="page">
|
||
<div id="menu-bar-hover-placeholder"></div>
|
||
<div id="menu-bar" class="menu-bar sticky">
|
||
<div class="left-buttons">
|
||
<label id="sidebar-toggle" class="icon-button" for="sidebar-toggle-anchor" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
|
||
<i class="fa fa-bars"></i>
|
||
</label>
|
||
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
|
||
<i class="fa fa-paint-brush"></i>
|
||
</button>
|
||
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
|
||
<li role="none"><button role="menuitem" class="theme" id="default_theme">Auto</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="light">Light</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
|
||
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
|
||
</ul>
|
||
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
|
||
<i class="fa fa-search"></i>
|
||
</button>
|
||
</div>
|
||
|
||
<h1 class="menu-title">Rust Compiler Development Guide</h1>
|
||
|
||
<div class="right-buttons">
|
||
<a href="../print.html" title="Print this book" aria-label="Print this book">
|
||
<i id="print-button" class="fa fa-print"></i>
|
||
</a>
|
||
<a href="https://github.com/rust-lang/rustc-dev-guide" title="Git repository" aria-label="Git repository">
|
||
<i id="git-repository-button" class="fa fa-github"></i>
|
||
</a>
|
||
<a href="https://github.com/rust-lang/rustc-dev-guide/edit/master/src/traits/resolution.md" title="Suggest an edit" aria-label="Suggest an edit">
|
||
<i id="git-edit-button" class="fa fa-edit"></i>
|
||
</a>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div id="search-wrapper" class="hidden">
|
||
<form id="searchbar-outer" class="searchbar-outer">
|
||
<input type="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
|
||
</form>
|
||
<div id="searchresults-outer" class="searchresults-outer hidden">
|
||
<div id="searchresults-header" class="searchresults-header"></div>
|
||
<ul id="searchresults">
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
|
||
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
|
||
<script>
|
||
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
|
||
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
|
||
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
|
||
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
|
||
});
|
||
</script>
|
||
|
||
<div id="content" class="content">
|
||
<main>
|
||
<h1 id="trait-resolution-old-style"><a class="header" href="#trait-resolution-old-style">Trait resolution (old-style)</a></h1>
|
||
<ul>
|
||
<li><a href="#major-concepts">Major concepts</a></li>
|
||
<li><a href="#overview">Overview</a></li>
|
||
<li><a href="#selection">Selection</a>
|
||
<ul>
|
||
<li><a href="#candidate-assembly">Candidate assembly</a>
|
||
<ul>
|
||
<li><a href="#winnowing-resolving-ambiguities">Winnowing: Resolving ambiguities</a></li>
|
||
<li><a href="#where-clauses"><code>where</code> clauses</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#confirmation">Confirmation</a></li>
|
||
<li><a href="#selection-during-codegen">Selection during codegen</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<p>This chapter describes the general process of <em>trait resolution</em> and points out
|
||
some non-obvious things.</p>
|
||
<p><strong>Note:</strong> This chapter (and its subchapters) describe how the trait
|
||
solver <strong>currently</strong> works. However, we are in the process of
|
||
designing a new trait solver. If you'd prefer to read about <em>that</em>,
|
||
see <a href="./chalk.html"><em>this</em> subchapter</a>.</p>
|
||
<h2 id="major-concepts"><a class="header" href="#major-concepts">Major concepts</a></h2>
|
||
<p>Trait resolution is the process of pairing up an impl with each
|
||
reference to a trait. So, for example, if there is a generic function like:</p>
|
||
<pre><code class="language-rust ignore">fn clone_slice<T:Clone>(x: &[T]) -> Vec<T> { ... }</code></pre>
|
||
<p>and then a call to that function:</p>
|
||
<pre><code class="language-rust ignore">let v: Vec<isize> = clone_slice(&[1, 2, 3])</code></pre>
|
||
<p>it is the job of trait resolution to figure out whether there exists an impl of
|
||
(in this case) <code>isize : Clone</code>.</p>
|
||
<p>Note that in some cases, like generic functions, we may not be able to
|
||
find a specific impl, but we can figure out that the caller must
|
||
provide an impl. For example, consider the body of <code>clone_slice</code>:</p>
|
||
<pre><code class="language-rust ignore">fn clone_slice<T:Clone>(x: &[T]) -> Vec<T> {
|
||
let mut v = Vec::new();
|
||
for e in &x {
|
||
v.push((*e).clone()); // (*)
|
||
}
|
||
}</code></pre>
|
||
<p>The line marked <code>(*)</code> is only legal if <code>T</code> (the type of <code>*e</code>)
|
||
implements the <code>Clone</code> trait. Naturally, since we don't know what <code>T</code>
|
||
is, we can't find the specific impl; but based on the bound <code>T:Clone</code>,
|
||
we can say that there exists an impl which the caller must provide.</p>
|
||
<p>We use the term <em>obligation</em> to refer to a trait reference in need of
|
||
an impl. Basically, the trait resolution system resolves an obligation
|
||
by proving that an appropriate impl does exist.</p>
|
||
<p>During type checking, we do not store the results of trait selection.
|
||
We simply wish to verify that trait selection will succeed. Then
|
||
later, at codegen time, when we have all concrete types available, we
|
||
can repeat the trait selection to choose an actual implementation, which
|
||
will then be generated in the output binary.</p>
|
||
<h2 id="overview"><a class="header" href="#overview">Overview</a></h2>
|
||
<p>Trait resolution consists of three major parts:</p>
|
||
<ul>
|
||
<li>
|
||
<p><strong>Selection</strong>: Deciding how to resolve a specific obligation. For
|
||
example, selection might decide that a specific obligation can be
|
||
resolved by employing an impl which matches the <code>Self</code> type, or by using a
|
||
parameter bound (e.g. <code>T: Trait</code>). In the case of an impl, selecting one
|
||
obligation can create <em>nested obligations</em> because of where clauses
|
||
on the impl itself. It may also require evaluating those nested
|
||
obligations to resolve ambiguities.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Fulfillment</strong>: The fulfillment code is what tracks that obligations
|
||
are completely fulfilled. Basically it is a worklist of obligations
|
||
to be selected: once selection is successful, the obligation is
|
||
removed from the worklist and any nested obligations are enqueued.
|
||
Fulfillment constrains inference variables.</p>
|
||
</li>
|
||
<li>
|
||
<p><strong>Evaluation</strong>: Checks whether obligations holds without constraining
|
||
any inference variables. Used by selection.</p>
|
||
</li>
|
||
</ul>
|
||
<h2 id="selection"><a class="header" href="#selection">Selection</a></h2>
|
||
<p>Selection is the process of deciding whether an obligation can be
|
||
resolved and, if so, how it is to be resolved (via impl, where clause, etc).
|
||
The main interface is the <code>select()</code> function, which takes an obligation
|
||
and returns a <code>SelectionResult</code>. There are three possible outcomes:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>Ok(Some(selection))</code> – yes, the obligation can be resolved, and
|
||
<code>selection</code> indicates how. If the impl was resolved via an impl,
|
||
then <code>selection</code> may also indicate nested obligations that are required
|
||
by the impl.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Ok(None)</code> – we are not yet sure whether the obligation can be
|
||
resolved or not. This happens most commonly when the obligation
|
||
contains unbound type variables.</p>
|
||
</li>
|
||
<li>
|
||
<p><code>Err(err)</code> – the obligation definitely cannot be resolved due to a
|
||
type error or because there are no impls that could possibly apply.</p>
|
||
</li>
|
||
</ul>
|
||
<p>The basic algorithm for selection is broken into two big phases:
|
||
candidate assembly and confirmation.</p>
|
||
<p>Note that because of how lifetime inference works, it is not possible to
|
||
give back immediate feedback as to whether a unification or subtype
|
||
relationship between lifetimes holds or not. Therefore, lifetime
|
||
matching is <em>not</em> considered during selection. This is reflected in
|
||
the fact that subregion assignment is infallible. This may yield
|
||
lifetime constraints that will later be found to be in error (in
|
||
contrast, the non-lifetime-constraints have already been checked
|
||
during selection and can never cause an error, though naturally they
|
||
may lead to other errors downstream).</p>
|
||
<h3 id="candidate-assembly"><a class="header" href="#candidate-assembly">Candidate assembly</a></h3>
|
||
<p><strong>TODO</strong>: Talk about <em>why</em> we have different candidates, and why it needs to happen in a probe.</p>
|
||
<p>Searches for impls/where-clauses/etc that might
|
||
possibly be used to satisfy the obligation. Each of those is called
|
||
a candidate. To avoid ambiguity, we want to find exactly one
|
||
candidate that is definitively applicable. In some cases, we may not
|
||
know whether an impl/where-clause applies or not – this occurs when
|
||
the obligation contains unbound inference variables.</p>
|
||
<p>The subroutines that decide whether a particular impl/where-clause/etc applies
|
||
to a particular obligation are collectively referred to as the process of
|
||
<em>matching</em>. For <code>impl</code> candidates <!-- date-check: Oct 2022 -->,
|
||
this amounts to unifying the impl header (the <code>Self</code> type and the trait arguments)
|
||
while ignoring nested obligations. If matching succeeds then we add it
|
||
to a set of candidates. There are other rules when assembling candidates for
|
||
built-in traits such as <code>Copy</code>, <code>Sized</code>, and <code>CoerceUnsized</code>.</p>
|
||
<p>Once this first pass is done, we can examine the set of candidates. If
|
||
it is a singleton set, then we are done: this is the only impl in
|
||
scope that could possibly apply. Otherwise, we can <strong>winnow</strong> down the set
|
||
of candidates by using where clauses and other conditions. Winnowing uses
|
||
<code>evaluate_candidate</code> to check whether the nested obligations may apply.
|
||
If this still leaves more than 1 candidate, we use <code> fn candidate_should_be_dropped_in_favor_of</code>
|
||
to prefer some candidates over others.</p>
|
||
<p>If this reduced set yields a single, unambiguous entry, we're good to go,
|
||
otherwise the result is considered ambiguous.</p>
|
||
<h4 id="winnowing-resolving-ambiguities"><a class="header" href="#winnowing-resolving-ambiguities">Winnowing: Resolving ambiguities</a></h4>
|
||
<p>But what happens if there are multiple impls where all the types
|
||
unify? Consider this example:</p>
|
||
<pre><code class="language-rust ignore">trait Get {
|
||
fn get(&self) -> Self;
|
||
}
|
||
|
||
impl<T: Copy> Get for T {
|
||
fn get(&self) -> T {
|
||
*self
|
||
}
|
||
}
|
||
|
||
impl<T: Get> Get for Box<T> {
|
||
fn get(&self) -> Box<T> {
|
||
Box::new(<T>::get(self))
|
||
}
|
||
}</code></pre>
|
||
<p>What happens when we invoke <code>get(&Box::new(1_u16))</code>, for example? In this
|
||
case, the <code>Self</code> type is <code>Box<u16></code> – that unifies with both impls,
|
||
because the first applies to all types <code>T</code>, and the second to all
|
||
<code>Box<T></code>. In order for this to be unambiguous, the compiler does a <em>winnowing</em>
|
||
pass that considers <code>where</code> clauses
|
||
and attempts to remove candidates. In this case, the first impl only
|
||
applies if <code>Box<u16> : Copy</code>, which doesn't hold. After winnowing,
|
||
then, we are left with just one candidate, so we can proceed.</p>
|
||
<h4 id="where-clauses"><a class="header" href="#where-clauses"><code>where</code> clauses</a></h4>
|
||
<p>Besides an impl, the other major way to resolve an obligation is via a
|
||
where clause. The selection process is always given a <a href="../typing_parameter_envs.html">parameter
|
||
environment</a> which contains a list of where clauses, which are
|
||
basically obligations that we can assume are satisfiable. We will iterate
|
||
over that list and check whether our current obligation can be found
|
||
in that list. If so, it is considered satisfied. More precisely, we
|
||
want to check whether there is a where-clause obligation that is for
|
||
the same trait (or some subtrait) and which can match against the obligation.</p>
|
||
<p>Consider this simple example:</p>
|
||
<pre><code class="language-rust ignore">trait A1 {
|
||
fn do_a1(&self);
|
||
}
|
||
trait A2 : A1 { ... }
|
||
|
||
trait B {
|
||
fn do_b(&self);
|
||
}
|
||
|
||
fn foo<X:A2+B>(x: X) {
|
||
x.do_a1(); // (*)
|
||
x.do_b(); // (#)
|
||
}</code></pre>
|
||
<p>In the body of <code>foo</code>, clearly we can use methods of <code>A1</code>, <code>A2</code>, or <code>B</code>
|
||
on variable <code>x</code>. The line marked <code>(*)</code> will incur an obligation <code>X: A1</code>,
|
||
while the line marked <code>(#)</code> will incur an obligation <code>X: B</code>. Meanwhile,
|
||
the parameter environment will contain two where-clauses: <code>X : A2</code> and <code>X : B</code>.
|
||
For each obligation, then, we search this list of where-clauses. The
|
||
obligation <code>X: B</code> trivially matches against the where-clause <code>X: B</code>.
|
||
To resolve an obligation <code>X:A1</code>, we would note that <code>X:A2</code> implies that <code>X:A1</code>.</p>
|
||
<h3 id="confirmation"><a class="header" href="#confirmation">Confirmation</a></h3>
|
||
<p><em>Confirmation</em> unifies the output type parameters of the trait with the
|
||
values found in the obligation, possibly yielding a type error.</p>
|
||
<p>Suppose we have the following variation of the <code>Convert</code> example in the
|
||
previous section:</p>
|
||
<pre><code class="language-rust ignore">trait Convert<Target> {
|
||
fn convert(&self) -> Target;
|
||
}
|
||
|
||
impl Convert<usize> for isize { ... } // isize -> usize
|
||
impl Convert<isize> for usize { ... } // usize -> isize
|
||
|
||
let x: isize = ...;
|
||
let y: char = x.convert(); // NOTE: `y: char` now!</code></pre>
|
||
<p>Confirmation is where an error would be reported because the impl specified
|
||
that <code>Target</code> would be <code>usize</code>, but the obligation reported <code>char</code>. Hence the
|
||
result of selection would be an error.</p>
|
||
<p>Note that the candidate impl is chosen based on the <code>Self</code> type, but
|
||
confirmation is done based on (in this case) the <code>Target</code> type parameter.</p>
|
||
<h3 id="selection-during-codegen"><a class="header" href="#selection-during-codegen">Selection during codegen</a></h3>
|
||
<p>As mentioned above, during type checking, we do not store the results of trait
|
||
selection. At codegen time, we repeat the trait selection to choose a particular
|
||
impl for each method call. This is done using <code>fn codegen_select_candidate</code>.
|
||
In this second selection, we do not consider any where-clauses to be in scope
|
||
because we know that each resolution will resolve to a particular impl.</p>
|
||
<p>One interesting twist has to do with nested obligations. In general, in codegen,
|
||
we only need to figure out which candidate applies, and we do not care about nested obligations,
|
||
as these are already assumed to be true. Nonetheless, we <em>do</em> currently fulfill all of them.
|
||
That is because it can sometimes inform the results of type inference.
|
||
That is, we do not have the full substitutions in terms of the type variables
|
||
of the impl available to us, so we must run trait selection to figure
|
||
everything out.</p>
|
||
|
||
</main>
|
||
|
||
<nav class="nav-wrapper" aria-label="Page navigation">
|
||
<!-- Mobile navigation buttons -->
|
||
<a rel="prev" href="../type-inference.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
||
<i class="fa fa-angle-left"></i>
|
||
</a>
|
||
|
||
<a rel="next prefetch" href="../traits/hrtb.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
||
<i class="fa fa-angle-right"></i>
|
||
</a>
|
||
|
||
<div style="clear: both"></div>
|
||
</nav>
|
||
</div>
|
||
</div>
|
||
|
||
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
||
<a rel="prev" href="../type-inference.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
||
<i class="fa fa-angle-left"></i>
|
||
</a>
|
||
|
||
<a rel="next prefetch" href="../traits/hrtb.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
||
<i class="fa fa-angle-right"></i>
|
||
</a>
|
||
</nav>
|
||
|
||
</div>
|
||
|
||
|
||
|
||
|
||
<script>
|
||
window.playground_copyable = true;
|
||
</script>
|
||
|
||
|
||
<script src="../elasticlunr.min.js"></script>
|
||
<script src="../mark.min.js"></script>
|
||
<script src="../searcher.js"></script>
|
||
|
||
<script src="../clipboard.min.js"></script>
|
||
<script src="../highlight.js"></script>
|
||
<script src="../book.js"></script>
|
||
|
||
<!-- Custom JS scripts -->
|
||
<script src="../mermaid.min.js"></script>
|
||
<script src="../mermaid-init.js"></script>
|
||
|
||
|
||
</div>
|
||
</body>
|
||
</html>
|