506 lines
27 KiB
HTML
506 lines
27 KiB
HTML
<!DOCTYPE HTML>
|
|
<html lang="en" class="light sidebar-visible" dir="ltr">
|
|
<head>
|
|
<!-- Book generated using mdBook -->
|
|
<meta charset="UTF-8">
|
|
<title>Procedures for breaking changes - 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/bug-fix-procedure.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="procedures-for-breaking-changes"><a class="header" href="#procedures-for-breaking-changes">Procedures for breaking changes</a></h1>
|
|
<ul>
|
|
<li><a href="#motivation">Motivation</a>
|
|
<ul>
|
|
<li><a href="#what-qualifies-as-a-bug-fix">What qualifies as a bug fix?</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#detailed-design">Detailed design</a>
|
|
<ul>
|
|
<li><a href="#tracking-issue">Tracking issue</a></li>
|
|
<li><a href="#issuing-future-compatibility-warnings">Issuing future compatibility warnings</a></li>
|
|
<li><a href="#helpful-techniques">Helpful techniques</a></li>
|
|
<li><a href="#crater-and-cratesio">Crater and crates.io</a></li>
|
|
<li><a href="#is-it-ever-acceptable-to-go-directly-to-issuing-errors">Is it ever acceptable to go directly to issuing errors?</a></li>
|
|
<li><a href="#stabilization">Stabilization</a></li>
|
|
<li><a href="#removing-a-lint">Removing a lint</a></li>
|
|
<li><a href="#remove-the-lint">Remove the lint.</a></li>
|
|
<li><a href="#add-the-lint-to-the-list-of-removed-lints">Add the lint to the list of removed lints.</a></li>
|
|
<li><a href="#update-the-places-that-issue-the-lint">Update the places that issue the lint</a></li>
|
|
<li><a href="#update-tests">Update tests</a></li>
|
|
<li><a href="#all-done">All done!</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
<p>This page defines the best practices procedure for making bug fixes or soundness
|
|
corrections in the compiler that can cause existing code to stop compiling. This
|
|
text is based on
|
|
<a href="https://github.com/rust-lang/rfcs/blob/master/text/1589-rustc-bug-fix-procedure.md">RFC 1589</a>.</p>
|
|
<h1 id="motivation"><a class="header" href="#motivation">Motivation</a></h1>
|
|
<p>From time to time, we encounter the need to make a bug fix, soundness
|
|
correction, or other change in the compiler which will cause existing code to
|
|
stop compiling. When this happens, it is important that we handle the change in
|
|
a way that gives users of Rust a smooth transition. What we want to avoid is
|
|
that existing programs suddenly stop compiling with opaque error messages: we
|
|
would prefer to have a gradual period of warnings, with clear guidance as to
|
|
what the problem is, how to fix it, and why the change was made. This RFC
|
|
describes the procedure that we have been developing for handling breaking
|
|
changes that aims to achieve that kind of smooth transition.</p>
|
|
<p>One of the key points of this policy is that (a) warnings should be issued
|
|
initially rather than hard errors if at all possible and (b) every change that
|
|
causes existing code to stop compiling will have an associated tracking issue.
|
|
This issue provides a point to collect feedback on the results of that change.
|
|
Sometimes changes have unexpectedly large consequences or there may be a way to
|
|
avoid the change that was not considered. In those cases, we may decide to
|
|
change course and roll back the change, or find another solution (if warnings
|
|
are being used, this is particularly easy to do).</p>
|
|
<h3 id="what-qualifies-as-a-bug-fix"><a class="header" href="#what-qualifies-as-a-bug-fix">What qualifies as a bug fix?</a></h3>
|
|
<p>Note that this RFC does not try to define when a breaking change is permitted.
|
|
That is already covered under <a href="https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md">RFC 1122</a>. This document assumes that the
|
|
change being made is in accordance with those policies. Here is a summary of the
|
|
conditions from RFC 1122:</p>
|
|
<ul>
|
|
<li><strong>Soundness changes:</strong> Fixes to holes uncovered in the type system.</li>
|
|
<li><strong>Compiler bugs:</strong> Places where the compiler is not implementing the specified
|
|
semantics found in an RFC or lang-team decision.</li>
|
|
<li><strong>Underspecified language semantics:</strong> Clarifications to grey areas where the
|
|
compiler behaves inconsistently and no formal behavior had been previously
|
|
decided.</li>
|
|
</ul>
|
|
<p>Please see <a href="https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md">the RFC</a> for full details!</p>
|
|
<h1 id="detailed-design"><a class="header" href="#detailed-design">Detailed design</a></h1>
|
|
<p>The procedure for making a breaking change is as follows (each of these steps is
|
|
described in more detail below):</p>
|
|
<ol>
|
|
<li>Do a <strong>crater run</strong> to assess the impact of the change.</li>
|
|
<li>Make a <strong>special tracking issue</strong> dedicated to the change.</li>
|
|
<li>Do not report an error right away. Instead, <strong>issue forwards-compatibility
|
|
lint warnings</strong>.
|
|
<ul>
|
|
<li>Sometimes this is not straightforward. See the text below for suggestions
|
|
on different techniques we have employed in the past.</li>
|
|
<li>For cases where warnings are infeasible:
|
|
<ul>
|
|
<li>Report errors, but make every effort to give a targeted error message
|
|
that directs users to the tracking issue</li>
|
|
<li>Submit PRs to all known affected crates that fix the issue
|
|
<ul>
|
|
<li>or, at minimum, alert the owners of those crates to the problem and
|
|
direct them to the tracking issue</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>Once the change has been in the wild for at least one cycle, we can
|
|
<strong>stabilize the change</strong>, converting those warnings into errors.</li>
|
|
</ol>
|
|
<p>Finally, for changes to <code>rustc_ast</code> that will affect plugins, the general policy
|
|
is to batch these changes. That is discussed below in more detail.</p>
|
|
<h3 id="tracking-issue"><a class="header" href="#tracking-issue">Tracking issue</a></h3>
|
|
<p>Every breaking change should be accompanied by a <strong>dedicated tracking issue</strong>
|
|
for that change. The main text of this issue should describe the change being
|
|
made, with a focus on what users must do to fix their code. The issue should be
|
|
approachable and practical; it may make sense to direct users to an RFC or some
|
|
other issue for the full details. The issue also serves as a place where users
|
|
can comment with questions or other concerns.</p>
|
|
<p>A template for these breaking-change tracking issues can be found
|
|
<a href="https://github.com/rust-lang/rust/issues/new?template=tracking_issue_future.md">here</a>. An example of how such an issue should look can be <a href="https://gist.github.com/nikomatsakis/631ec8b4af9a18b5d062d9d9b7d3d967">found
|
|
here</a>.</p>
|
|
<h3 id="issuing-future-compatibility-warnings"><a class="header" href="#issuing-future-compatibility-warnings">Issuing future compatibility warnings</a></h3>
|
|
<p>The best way to handle a breaking change is to begin by issuing
|
|
future-compatibility warnings. These are a special category of lint warning.
|
|
Adding a new future-compatibility warning can be done as follows.</p>
|
|
<pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
|
|
</span><span class="boring">fn main() {
|
|
</span>// 1. Define the lint in `compiler/rustc_middle/src/lint/builtin.rs`:
|
|
declare_lint! {
|
|
pub YOUR_ERROR_HERE,
|
|
Warn,
|
|
"illegal use of foo bar baz"
|
|
}
|
|
|
|
// 2. Add to the list of HardwiredLints in the same file:
|
|
impl LintPass for HardwiredLints {
|
|
fn get_lints(&self) -> LintArray {
|
|
lint_array!(
|
|
..,
|
|
YOUR_ERROR_HERE
|
|
)
|
|
}
|
|
}
|
|
|
|
// 3. Register the lint in `compiler/rustc_lint/src/lib.rs`:
|
|
store.register_future_incompatible(sess, vec![
|
|
...,
|
|
FutureIncompatibleInfo {
|
|
id: LintId::of(YOUR_ERROR_HERE),
|
|
reference: "issue #1234", // your tracking issue here!
|
|
},
|
|
]);
|
|
|
|
// 4. Report the lint:
|
|
tcx.lint_node(
|
|
lint::builtin::YOUR_ERROR_HERE,
|
|
path_id,
|
|
binding.span,
|
|
format!("some helper message here"));
|
|
<span class="boring">}</span></code></pre></pre>
|
|
<h4 id="helpful-techniques"><a class="header" href="#helpful-techniques">Helpful techniques</a></h4>
|
|
<p>It can often be challenging to filter out new warnings from older, pre-existing
|
|
errors. One technique that has been used in the past is to run the older code
|
|
unchanged and collect the errors it would have reported. You can then issue
|
|
warnings for any errors you would give which do not appear in that original set.
|
|
Another option is to abort compilation after the original code completes if
|
|
errors are reported: then you know that your new code will only execute when
|
|
there were no errors before.</p>
|
|
<h4 id="crater-and-cratesio"><a class="header" href="#crater-and-cratesio">Crater and crates.io</a></h4>
|
|
<p><a href="./tests/crater.html">Crater</a> is a bot that will compile all crates.io crates and many
|
|
public github repos with the compiler with your changes. A report will then be
|
|
generated with crates that ceased to compile with or began to compile with your
|
|
changes. Crater runs can take a few days to complete.</p>
|
|
<p>We should always do a crater run to assess impact. It is polite and considerate
|
|
to at least notify the authors of affected crates the breaking change. If we can
|
|
submit PRs to fix the problem, so much the better.</p>
|
|
<h4 id="is-it-ever-acceptable-to-go-directly-to-issuing-errors"><a class="header" href="#is-it-ever-acceptable-to-go-directly-to-issuing-errors">Is it ever acceptable to go directly to issuing errors?</a></h4>
|
|
<p>Changes that are believed to have negligible impact can go directly to issuing
|
|
an error. One rule of thumb would be to check against <code>crates.io</code>: if fewer than
|
|
10 <strong>total</strong> affected projects are found (<strong>not</strong> root errors), we can move
|
|
straight to an error. In such cases, we should still make the "breaking change"
|
|
page as before, and we should ensure that the error directs users to this page.
|
|
In other words, everything should be the same except that users are getting an
|
|
error, and not a warning. Moreover, we should submit PRs to the affected
|
|
projects (ideally before the PR implementing the change lands in rustc).</p>
|
|
<p>If the impact is not believed to be negligible (e.g., more than 10 crates are
|
|
affected), then warnings are required (unless the compiler team agrees to grant
|
|
a special exemption in some particular case). If implementing warnings is not
|
|
feasible, then we should make an aggressive strategy of migrating crates before
|
|
we land the change so as to lower the number of affected crates. Here are some
|
|
techniques for approaching this scenario:</p>
|
|
<ol>
|
|
<li>Issue warnings for subparts of the problem, and reserve the new errors for
|
|
the smallest set of cases you can.</li>
|
|
<li>Try to give a very precise error message that suggests how to fix the problem
|
|
and directs users to the tracking issue.</li>
|
|
<li>It may also make sense to layer the fix:
|
|
<ul>
|
|
<li>First, add warnings where possible and let those land before proceeding to
|
|
issue errors.</li>
|
|
<li>Work with authors of affected crates to ensure that corrected versions are
|
|
available <em>before</em> the fix lands, so that downstream users can use them.</li>
|
|
</ul>
|
|
</li>
|
|
</ol>
|
|
<h3 id="stabilization"><a class="header" href="#stabilization">Stabilization</a></h3>
|
|
<p>After a change is made, we will <strong>stabilize</strong> the change using the same process
|
|
that we use for unstable features:</p>
|
|
<ul>
|
|
<li>
|
|
<p>After a new release is made, we will go through the outstanding tracking
|
|
issues corresponding to breaking changes and nominate some of them for <strong>final
|
|
comment period</strong> (FCP).</p>
|
|
</li>
|
|
<li>
|
|
<p>The FCP for such issues lasts for one cycle. In the final week or two of the
|
|
cycle, we will review comments and make a final determination:</p>
|
|
<ul>
|
|
<li>Convert to error: the change should be made into a hard error.</li>
|
|
<li>Revert: we should remove the warning and continue to allow the older code to
|
|
compile.</li>
|
|
<li>Defer: can't decide yet, wait longer, or try other strategies.</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
<p>Ideally, breaking changes should have landed on the <strong>stable branch</strong> of the
|
|
compiler before they are finalized.</p>
|
|
<p><a id="guide"></a></p>
|
|
<h3 id="removing-a-lint"><a class="header" href="#removing-a-lint">Removing a lint</a></h3>
|
|
<p>Once we have decided to make a "future warning" into a hard error, we need a PR
|
|
that removes the custom lint. As an example, here are the steps required to
|
|
remove the <code>overlapping_inherent_impls</code> compatibility lint. First, convert the
|
|
name of the lint to uppercase (<code>OVERLAPPING_INHERENT_IMPLS</code>) ripgrep through the
|
|
source for that string. We will basically by converting each place where this
|
|
lint name is mentioned (in the compiler, we use the upper-case name, and a macro
|
|
automatically generates the lower-case string; so searching for
|
|
<code>overlapping_inherent_impls</code> would not find much).</p>
|
|
<blockquote>
|
|
<p>NOTE: these exact files don't exist anymore, but the procedure is still the same.</p>
|
|
</blockquote>
|
|
<h4 id="remove-the-lint"><a class="header" href="#remove-the-lint">Remove the lint.</a></h4>
|
|
<p>The first reference you will likely find is the lint definition <a href="https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L171-L175">in
|
|
<code>rustc_session/src/lint/builtin.rs</code> that resembles this</a>:</p>
|
|
<pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
|
|
</span><span class="boring">fn main() {
|
|
</span>declare_lint! {
|
|
pub OVERLAPPING_INHERENT_IMPLS,
|
|
Deny, // this may also say Warning
|
|
"two overlapping inherent impls define an item with the same name were erroneously allowed"
|
|
}
|
|
<span class="boring">}</span></code></pre></pre>
|
|
<p>This <code>declare_lint!</code> macro creates the relevant data structures. Remove it. You
|
|
will also find that there is a mention of <code>OVERLAPPING_INHERENT_IMPLS</code> later in
|
|
the file as <a href="https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc/lint/builtin.rs#L252-L290">part of a <code>lint_array!</code></a>; remove it too.</p>
|
|
<p>Next, you see <a href="https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc_lint/lib.rs#L202-L205">a reference to <code>OVERLAPPING_INHERENT_IMPLS</code> in
|
|
<code>rustc_lint/src/lib.rs</code></a>. This is defining the lint as a "future
|
|
compatibility lint":</p>
|
|
<pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
|
|
</span><span class="boring">fn main() {
|
|
</span>FutureIncompatibleInfo {
|
|
id: LintId::of(OVERLAPPING_INHERENT_IMPLS),
|
|
reference: "issue #36889 <https://github.com/rust-lang/rust/issues/36889>",
|
|
},
|
|
<span class="boring">}</span></code></pre></pre>
|
|
<p>Remove this too.</p>
|
|
<h4 id="add-the-lint-to-the-list-of-removed-lints"><a class="header" href="#add-the-lint-to-the-list-of-removed-lints">Add the lint to the list of removed lints.</a></h4>
|
|
<p>In <code>compiler/rustc_lint/src/lib.rs</code> there is a list of "renamed and removed lints".
|
|
You can add this lint to the list:</p>
|
|
<pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
|
|
</span><span class="boring">fn main() {
|
|
</span>store.register_removed("overlapping_inherent_impls", "converted into hard error, see #36889");
|
|
<span class="boring">}</span></code></pre></pre>
|
|
<p>where <code>#36889</code> is the tracking issue for your lint.</p>
|
|
<h4 id="update-the-places-that-issue-the-lint"><a class="header" href="#update-the-places-that-issue-the-lint">Update the places that issue the lint</a></h4>
|
|
<p>Finally, the last class of references you will see are the places that actually
|
|
<strong>trigger</strong> the lint itself (i.e., what causes the warnings to appear). These
|
|
you do not want to delete. Instead, you want to convert them into errors. In
|
|
this case, the <a href="https://github.com/rust-lang/rust/blob/085d71c3efe453863739c1fb68fd9bd1beff214f/src/librustc_typeck/coherence/inherent.rs#L300-L303"><code>add_lint</code> call</a> looks like this:</p>
|
|
<pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
|
|
</span><span class="boring">fn main() {
|
|
</span>self.tcx.sess.add_lint(lint::builtin::OVERLAPPING_INHERENT_IMPLS,
|
|
node_id,
|
|
self.tcx.span_of_impl(item1).unwrap(),
|
|
msg);
|
|
<span class="boring">}</span></code></pre></pre>
|
|
<p>We want to convert this into an error. In some cases, there may be an
|
|
existing error for this scenario. In others, we will need to allocate a
|
|
fresh diagnostic code. <a href="./diagnostics/error-codes.html">Instructions for allocating a fresh diagnostic
|
|
code can be found here.</a> You may want
|
|
to mention in the extended description that the compiler behavior
|
|
changed on this point, and include a reference to the tracking issue for
|
|
the change.</p>
|
|
<p>Let's say that we've adopted <code>E0592</code> as our code. Then we can change the
|
|
<code>add_lint()</code> call above to something like:</p>
|
|
<pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
|
|
</span><span class="boring">fn main() {
|
|
</span>struct_span_code_err!(self.dcx(), self.tcx.span_of_impl(item1).unwrap(), E0592, msg)
|
|
.emit();
|
|
<span class="boring">}</span></code></pre></pre>
|
|
<h4 id="update-tests"><a class="header" href="#update-tests">Update tests</a></h4>
|
|
<p>Finally, run the test suite. These should be some tests that used to reference
|
|
the <code>overlapping_inherent_impls</code> lint, those will need to be updated. In
|
|
general, if the test used to have <code>#[deny(overlapping_inherent_impls)]</code>, that
|
|
can just be removed.</p>
|
|
<pre><code>./x test
|
|
</code></pre>
|
|
<h4 id="all-done"><a class="header" href="#all-done">All done!</a></h4>
|
|
<p>Open a PR. =)</p>
|
|
<!-- -Links--------------------------------------------------------------------- -->
|
|
|
|
</main>
|
|
|
|
<nav class="nav-wrapper" aria-label="Page navigation">
|
|
<!-- Mobile navigation buttons -->
|
|
<a rel="prev" href="conventions.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="external-repos.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="conventions.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="external-repos.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>
|