466 lines
26 KiB
HTML
466 lines
26 KiB
HTML
<!DOCTYPE HTML>
|
||
<html lang="en" class="light sidebar-visible" dir="ltr">
|
||
<head>
|
||
<!-- Book generated using mdBook -->
|
||
<meta charset="UTF-8">
|
||
<title>Variance - 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/variance.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="variance-of-type-and-lifetime-parameters"><a class="header" href="#variance-of-type-and-lifetime-parameters">Variance of type and lifetime parameters</a></h1>
|
||
<ul>
|
||
<li><a href="#the-algorithm">The algorithm</a></li>
|
||
<li><a href="#constraints">Constraints</a>
|
||
<ul>
|
||
<li><a href="#dependency-graph-management">Dependency graph management</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#addendum-variance-on-traits">Addendum: Variance on traits</a>
|
||
<ul>
|
||
<li><a href="#variance-and-object-types">Variance and object types</a></li>
|
||
<li><a href="#trait-variance-and-vtable-resolution">Trait variance and vtable resolution</a></li>
|
||
<li><a href="#variance-and-associated-types">Variance and associated types</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
<p>For a more general background on variance, see the <a href="./appendix/background.html">background</a> appendix.</p>
|
||
<p>During type checking we must infer the variance of type and lifetime
|
||
parameters. The algorithm is taken from Section 4 of the paper <a href="https://people.cs.umass.edu/~yannis/variance-extended2011.pdf">"Taming the
|
||
Wildcards: Combining Definition- and Use-Site Variance"</a> published in
|
||
PLDI'11 and written by Altidor et al., and hereafter referred to as The Paper.</p>
|
||
<p>This inference is explicitly designed <em>not</em> to consider the uses of
|
||
types within code. To determine the variance of type parameters
|
||
defined on type <code>X</code>, we only consider the definition of the type <code>X</code>
|
||
and the definitions of any types it references.</p>
|
||
<p>We only infer variance for type parameters found on <em>data types</em>
|
||
like structs and enums. In these cases, there is a fairly straightforward
|
||
explanation for what variance means. The variance of the type
|
||
or lifetime parameters defines whether <code>T<A></code> is a subtype of <code>T<B></code>
|
||
(resp. <code>T<'a></code> and <code>T<'b></code>) based on the relationship of <code>A</code> and <code>B</code>
|
||
(resp. <code>'a</code> and <code>'b</code>).</p>
|
||
<p>We do not infer variance for type parameters found on traits, functions,
|
||
or impls. Variance on trait parameters can indeed make sense
|
||
(and we used to compute it) but it is actually rather subtle in
|
||
meaning and not that useful in practice, so we removed it. See the
|
||
<a href="#addendum">addendum</a> for some details. Variances on function/impl parameters, on the
|
||
other hand, doesn't make sense because these parameters are instantiated and
|
||
then forgotten, they don't persist in types or compiled byproducts.</p>
|
||
<blockquote>
|
||
<p><strong>Notation</strong></p>
|
||
<p>We use the notation of The Paper throughout this chapter:</p>
|
||
<ul>
|
||
<li><code>+</code> is <em>covariance</em>.</li>
|
||
<li><code>-</code> is <em>contravariance</em>.</li>
|
||
<li><code>*</code> is <em>bivariance</em>.</li>
|
||
<li><code>o</code> is <em>invariance</em>.</li>
|
||
</ul>
|
||
</blockquote>
|
||
<h2 id="the-algorithm"><a class="header" href="#the-algorithm">The algorithm</a></h2>
|
||
<p>The basic idea is quite straightforward. We iterate over the types
|
||
defined and, for each use of a type parameter <code>X</code>, accumulate a
|
||
constraint indicating that the variance of <code>X</code> must be valid for the
|
||
variance of that use site. We then iteratively refine the variance of
|
||
<code>X</code> until all constraints are met. There is <em>always</em> a solution, because at
|
||
the limit we can declare all type parameters to be invariant and all
|
||
constraints will be satisfied.</p>
|
||
<p>As a simple example, consider:</p>
|
||
<pre><code class="language-rust ignore">enum Option<A> { Some(A), None }
|
||
enum OptionalFn<B> { Some(|B|), None }
|
||
enum OptionalMap<C> { Some(|C| -> C), None }</code></pre>
|
||
<p>Here, we will generate the constraints:</p>
|
||
<pre><code class="language-text">1. V(A) <= +
|
||
2. V(B) <= -
|
||
3. V(C) <= +
|
||
4. V(C) <= -
|
||
</code></pre>
|
||
<p>These indicate that (1) the variance of A must be at most covariant;
|
||
(2) the variance of B must be at most contravariant; and (3, 4) the
|
||
variance of C must be at most covariant <em>and</em> contravariant. All of these
|
||
results are based on a variance lattice defined as follows:</p>
|
||
<pre><code class="language-text"> * Top (bivariant)
|
||
- +
|
||
o Bottom (invariant)
|
||
</code></pre>
|
||
<p>Based on this lattice, the solution <code>V(A)=+</code>, <code>V(B)=-</code>, <code>V(C)=o</code> is the
|
||
optimal solution. Note that there is always a naive solution which
|
||
just declares all variables to be invariant.</p>
|
||
<p>You may be wondering why fixed-point iteration is required. The reason
|
||
is that the variance of a use site may itself be a function of the
|
||
variance of other type parameters. In full generality, our constraints
|
||
take the form:</p>
|
||
<pre><code class="language-text">V(X) <= Term
|
||
Term := + | - | * | o | V(X) | Term x Term
|
||
</code></pre>
|
||
<p>Here the notation <code>V(X)</code> indicates the variance of a type/region
|
||
parameter <code>X</code> with respect to its defining class. <code>Term x Term</code>
|
||
represents the "variance transform" as defined in the paper:</p>
|
||
<blockquote>
|
||
<p>If the variance of a type variable <code>X</code> in type expression <code>E</code> is <code>V2</code>
|
||
and the definition-site variance of the corresponding type parameter
|
||
of a class <code>C</code> is <code>V1</code>, then the variance of <code>X</code> in the type expression
|
||
<code>C<E></code> is <code>V3 = V1.xform(V2)</code>.</p>
|
||
</blockquote>
|
||
<h2 id="constraints"><a class="header" href="#constraints">Constraints</a></h2>
|
||
<p>If I have a struct or enum with where clauses:</p>
|
||
<pre><code class="language-rust ignore">struct Foo<T: Bar> { ... }</code></pre>
|
||
<p>you might wonder whether the variance of <code>T</code> with respect to <code>Bar</code> affects the
|
||
variance <code>T</code> with respect to <code>Foo</code>. I claim no. The reason: assume that <code>T</code> is
|
||
invariant with respect to <code>Bar</code> but covariant with respect to <code>Foo</code>. And then
|
||
we have a <code>Foo<X></code> that is upcast to <code>Foo<Y></code>, where <code>X <: Y</code>. However, while
|
||
<code>X : Bar</code>, <code>Y : Bar</code> does not hold. In that case, the upcast will be illegal,
|
||
but not because of a variance failure, but rather because the target type
|
||
<code>Foo<Y></code> is itself just not well-formed. Basically we get to assume
|
||
well-formedness of all types involved before considering variance.</p>
|
||
<h3 id="dependency-graph-management"><a class="header" href="#dependency-graph-management">Dependency graph management</a></h3>
|
||
<p>Because variance is a whole-crate inference, its dependency graph
|
||
can become quite muddled if we are not careful. To resolve this, we refactor
|
||
into two queries:</p>
|
||
<ul>
|
||
<li><code>crate_variances</code> computes the variance for all items in the current crate.</li>
|
||
<li><code>variances_of</code> accesses the variance for an individual reading; it
|
||
works by requesting <code>crate_variances</code> and extracting the relevant data.</li>
|
||
</ul>
|
||
<p>If you limit yourself to reading <code>variances_of</code>, your code will only
|
||
depend then on the inference of that particular item.</p>
|
||
<p>Ultimately, this setup relies on the <a href="./queries/incremental-compilation.html">red-green algorithm</a>. In particular,
|
||
every variance query effectively depends on all type definitions in the entire
|
||
crate (through <code>crate_variances</code>), but since most changes will not result in a
|
||
change to the actual results from variance inference, the <code>variances_of</code> query
|
||
will wind up being considered green after it is re-evaluated.</p>
|
||
<p><a id="addendum"></a></p>
|
||
<h2 id="addendum-variance-on-traits"><a class="header" href="#addendum-variance-on-traits">Addendum: Variance on traits</a></h2>
|
||
<p>As mentioned above, we used to permit variance on traits. This was
|
||
computed based on the appearance of trait type parameters in
|
||
method signatures and was used to represent the compatibility of
|
||
vtables in trait objects (and also "virtual" vtables or dictionary
|
||
in trait bounds). One complication was that variance for
|
||
associated types is less obvious, since they can be projected out
|
||
and put to myriad uses, so it's not clear when it is safe to allow
|
||
<code>X<A>::Bar</code> to vary (or indeed just what that means). Moreover (as
|
||
covered below) all inputs on any trait with an associated type had
|
||
to be invariant, limiting the applicability. Finally, the
|
||
annotations (<code>MarkerTrait</code>, <code>PhantomFn</code>) needed to ensure that all
|
||
trait type parameters had a variance were confusing and annoying
|
||
for little benefit.</p>
|
||
<p>Just for historical reference, I am going to preserve some text indicating how
|
||
one could interpret variance and trait matching.</p>
|
||
<h3 id="variance-and-object-types"><a class="header" href="#variance-and-object-types">Variance and object types</a></h3>
|
||
<p>Just as with structs and enums, we can decide the subtyping
|
||
relationship between two object types <code>&Trait<A></code> and <code>&Trait<B></code>
|
||
based on the relationship of <code>A</code> and <code>B</code>. Note that for object
|
||
types we ignore the <code>Self</code> type parameter – it is unknown, and
|
||
the nature of dynamic dispatch ensures that we will always call a
|
||
function that is expected the appropriate <code>Self</code> type. However, we
|
||
must be careful with the other type parameters, or else we could
|
||
end up calling a function that is expecting one type but provided
|
||
another.</p>
|
||
<p>To see what I mean, consider a trait like so:</p>
|
||
<pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
|
||
</span><span class="boring">fn main() {
|
||
</span>trait ConvertTo<A> {
|
||
fn convertTo(&self) -> A;
|
||
}
|
||
<span class="boring">}</span></code></pre></pre>
|
||
<p>Intuitively, If we had one object <code>O=&ConvertTo<Object></code> and another
|
||
<code>S=&ConvertTo<String></code>, then <code>S <: O</code> because <code>String <: Object</code>
|
||
(presuming Java-like "string" and "object" types, my go to examples
|
||
for subtyping). The actual algorithm would be to compare the
|
||
(explicit) type parameters pairwise respecting their variance: here,
|
||
the type parameter A is covariant (it appears only in a return
|
||
position), and hence we require that <code>String <: Object</code>.</p>
|
||
<p>You'll note though that we did not consider the binding for the
|
||
(implicit) <code>Self</code> type parameter: in fact, it is unknown, so that's
|
||
good. The reason we can ignore that parameter is precisely because we
|
||
don't need to know its value until a call occurs, and at that time (as
|
||
you said) the dynamic nature of virtual dispatch means the code we run
|
||
will be correct for whatever value <code>Self</code> happens to be bound to for
|
||
the particular object whose method we called. <code>Self</code> is thus different
|
||
from <code>A</code>, because the caller requires that <code>A</code> be known in order to
|
||
know the return type of the method <code>convertTo()</code>. (As an aside, we
|
||
have rules preventing methods where <code>Self</code> appears outside of the
|
||
receiver position from being called via an object.)</p>
|
||
<h3 id="trait-variance-and-vtable-resolution"><a class="header" href="#trait-variance-and-vtable-resolution">Trait variance and vtable resolution</a></h3>
|
||
<p>But traits aren't only used with objects. They're also used when
|
||
deciding whether a given impl satisfies a given trait bound. To set the
|
||
scene here, imagine I had a function:</p>
|
||
<pre><code class="language-rust ignore">fn convertAll<A,T:ConvertTo<A>>(v: &[T]) { ... }</code></pre>
|
||
<p>Now imagine that I have an implementation of <code>ConvertTo</code> for <code>Object</code>:</p>
|
||
<pre><code class="language-rust ignore">impl ConvertTo<i32> for Object { ... }</code></pre>
|
||
<p>And I want to call <code>convertAll</code> on an array of strings. Suppose
|
||
further that for whatever reason I specifically supply the value of
|
||
<code>String</code> for the type parameter <code>T</code>:</p>
|
||
<pre><code class="language-rust ignore">let mut vector = vec!["string", ...];
|
||
convertAll::<i32, String>(vector);</code></pre>
|
||
<p>Is this legal? To put another way, can we apply the <code>impl</code> for
|
||
<code>Object</code> to the type <code>String</code>? The answer is yes, but to see why
|
||
we have to expand out what will happen:</p>
|
||
<ul>
|
||
<li>
|
||
<p><code>convertAll</code> will create a pointer to one of the entries in the
|
||
vector, which will have type <code>&String</code></p>
|
||
</li>
|
||
<li>
|
||
<p>It will then call the impl of <code>convertTo()</code> that is intended
|
||
for use with objects. This has the type <code>fn(self: &Object) -> i32</code>.</p>
|
||
<p>It is OK to provide a value for <code>self</code> of type <code>&String</code> because
|
||
<code>&String <: &Object</code>.</p>
|
||
</li>
|
||
</ul>
|
||
<p>OK, so intuitively we want this to be legal, so let's bring this back
|
||
to variance and see whether we are computing the correct result. We
|
||
must first figure out how to phrase the question "is an impl for
|
||
<code>Object,i32</code> usable where an impl for <code>String,i32</code> is expected?"</p>
|
||
<p>Maybe it's helpful to think of a dictionary-passing implementation of
|
||
type classes. In that case, <code>convertAll()</code> takes an implicit parameter
|
||
representing the impl. In short, we <em>have</em> an impl of type:</p>
|
||
<pre><code class="language-text">V_O = ConvertTo<i32> for Object
|
||
</code></pre>
|
||
<p>and the function prototype expects an impl of type:</p>
|
||
<pre><code class="language-text">V_S = ConvertTo<i32> for String
|
||
</code></pre>
|
||
<p>As with any argument, this is legal if the type of the value given
|
||
(<code>V_O</code>) is a subtype of the type expected (<code>V_S</code>). So is <code>V_O <: V_S</code>?
|
||
The answer will depend on the variance of the various parameters. In
|
||
this case, because the <code>Self</code> parameter is contravariant and <code>A</code> is
|
||
covariant, it means that:</p>
|
||
<pre><code class="language-text">V_O <: V_S iff
|
||
i32 <: i32
|
||
String <: Object
|
||
</code></pre>
|
||
<p>These conditions are satisfied and so we are happy.</p>
|
||
<h3 id="variance-and-associated-types"><a class="header" href="#variance-and-associated-types">Variance and associated types</a></h3>
|
||
<p>Traits with associated types – or at minimum projection
|
||
expressions – must be invariant with respect to all of their
|
||
inputs. To see why this makes sense, consider what subtyping for a
|
||
trait reference means:</p>
|
||
<pre><code class="language-text"><T as Trait> <: <U as Trait>
|
||
</code></pre>
|
||
<p>means that if I know that <code>T as Trait</code>, I also know that <code>U as Trait</code>. Moreover, if you think of it as dictionary passing style,
|
||
it means that a dictionary for <code><T as Trait></code> is safe to use where
|
||
a dictionary for <code><U as Trait></code> is expected.</p>
|
||
<p>The problem is that when you can project types out from <code><T as Trait></code>, the relationship to types projected out of <code><U as Trait></code>
|
||
is completely unknown unless <code>T==U</code> (see #21726 for more
|
||
details). Making <code>Trait</code> invariant ensures that this is true.</p>
|
||
<p>Another related reason is that if we didn't make traits with
|
||
associated types invariant, then projection is no longer a
|
||
function with a single result. Consider:</p>
|
||
<pre><code class="language-rust ignore">trait Identity { type Out; fn foo(&self); }
|
||
impl<T> Identity for T { type Out = T; ... }</code></pre>
|
||
<p>Now if I have <code><&'static () as Identity>::Out</code>, this can be
|
||
validly derived as <code>&'a ()</code> for any <code>'a</code>:</p>
|
||
<pre><code class="language-text"><&'a () as Identity> <: <&'static () as Identity>
|
||
if &'static () < : &'a () -- Identity is contravariant in Self
|
||
if 'static : 'a -- Subtyping rules for relations
|
||
</code></pre>
|
||
<p>This change otoh means that <code><'static () as Identity>::Out</code> is
|
||
always <code>&'static ()</code> (which might then be upcast to <code>'a ()</code>,
|
||
separately). This was helpful in solving #21750.</p>
|
||
|
||
</main>
|
||
|
||
<nav class="nav-wrapper" aria-label="Page navigation">
|
||
<!-- Mobile navigation buttons -->
|
||
<a rel="prev" href="method-lookup.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="coherence.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="method-lookup.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="coherence.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>
|