| <!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> |
