test2.xml (108261B)
1 <?xml version="1.0" encoding="utf-8"?> 2 <feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en"> 3 <generator uri="https://blog.rust-lang.org/" version="0.1.0">Rust Blog</generator> 4 <link href="https://blog.rust-lang.org/feed.xml" rel="self" type="application/atom+xml" /> 5 <link href="https://blog.rust-lang.org/" rel="alternate" type="text/html" /> 6 <id>https://blog.rust-lang.org/</id> 7 <title>Rust Blog</title> 8 <subtitle>Empowering everyone to build reliable and efficient software.</subtitle> 9 <author> 10 <name>Maintained by the Rust Teams.</name> 11 <uri>https://github.com/rust-lang/blog.rust-lang.org/</uri> 12 </author> 13 <updated>2024-06-26T23:17:01+00:00</updated> 14 15 <entry> 16 <title>Types Team Update and Roadmap</title> 17 <link rel="alternate" href="https://blog.rust-lang.org/2024/06/26/types-team-update.html" type="text/html" title="Types Team Update and Roadmap" /> 18 <published>2024-06-26T00:00:00+00:00</published> 19 <updated>2024-06-26T00:00:00+00:00</updated> 20 <id>https://blog.rust-lang.org/2024/06/26/types-team-update.html</id> 21 <content type="html" xml:base="https://blog.rust-lang.org/2024/06/26/types-team-update.html"><p>It has been more than a year since <a href="https://blog.rust-lang.org/2023/01/20/types-announcement.html">the initial blog post</a> announcing the Types team, and our initial set of goals. For details on what the team is, why it was formed, or our previously-stated overarching goals, go check out that blog post. In short the Types team's purview extends to the parts of the Rust language and compiler that involve the type system, e.g. type checking, trait solving, and borrow checking. Our short and long term goals effectively work to make the type system sound, consistent, extensible, and fast.</p> 22 <p>Before getting into details, it's worth sharing a quick point: the team over the last year has been very successful. Oftentimes, it's hard to measure impact, particularly when long-term roadmap goals are hard to quantify progress on and various short-term goals either are hit or aren't. But, there is one clear statistic that is somewhat indicative of the team's progress: over the last year or so, <a href="https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3AT-types+label%3Adisposition-merge+is%3Amerged+closed%3A%3E2023-01-20+sort%3Acreated-asc+">more than 50 user-facing changes</a> have landed, each separately approved by Types Team consensus through FCP.</p> 23 <p>The changes lie at the boundary between language design and implementation, and the Types Team (which is a subteam of both the Language and Compiler Teams) existing means that not only does the Rust Project have the bandwidth to make these decisions but we also have enough people with the knowledge and experience of the type system to make informed decisions that overall make the language better.</p> 24 <h2><a href="#the-priorities-of-the-types-team" aria-hidden="true" class="anchor" id="the-priorities-of-the-types-team"></a>The priorities of the types team</h2> 25 <p>To evaluate our progress over the last year and our roadmap going forward, 26 lets start with our main priorities in order of importance. We will refer 27 to them during the remainder of this post. To reach our goals, we need a 28 a healthy group of maintainers which have the expertise and capacity to 29 react to issues and to implement complex changes.</p> 30 <h3><a href="#the-type-system-should-be-sound" aria-hidden="true" class="anchor" id="the-type-system-should-be-sound"></a>The type system should be Sound</h3> 31 <p>One of the main promises of Rust is that there cannot be undefined behavior when using 32 only safe code. It might surprise you that there are currently <a href="https://github.com/orgs/rust-lang/projects/44/views/1">known type system 33 bugs</a> which break these guarantees. Most of these issues were found by people familiar with 34 the inner workings of the compiler by explicitly looking for them and we generally do not expect 35 users to encounter these bugs by accident. Regardless, we deeply care about fixing them 36 and are working towards a fully sound and ideally verified type system.</p> 37 <h3><a href="#the-type-system-should-be-consistent" aria-hidden="true" class="anchor" id="the-type-system-should-be-consistent"></a>The type system should be Consistent</h3> 38 <p>The type system should be easy to reason about. We should avoid rough edges and 39 special-cases if possible. We want to keep both the implementation and user-facing behavior 40 as simple as possible. Where possible we want to consider the overall design instead of 41 providing local targeted fixes. This is necessary to build trust in the soundness of the 42 type system and allows for a simpler mental model of Rust.</p> 43 <h3><a href="#the-type-system-should-be-extensible" aria-hidden="true" class="anchor" id="the-type-system-should-be-extensible"></a>The type system should be Extensible</h3> 44 <p>Rust is still evolving and we will be required to extend the type system to enable new 45 language features going forward. This requires the type system to be extensible and 46 approachable. The design of the language should not be adapted to work around 47 short-comings of its current type system implementation. We should collaborate with 48 other teams and users to make sure we're aware of their problems and consider possible 49 future extensions in our implementation and design.</p> 50 <h3><a href="#the-type-system-should-be-fast" aria-hidden="true" class="anchor" id="the-type-system-should-be-fast"></a>The type system should be Fast</h3> 51 <p>We care about the compile times of Rust and want to consider the impact on compile times 52 of our designs. We should look for effective approaches to speed up the existing implementation, 53 by improving caching or adding fast paths where applicable. We should also be aware of the 54 compile time impact of future additions to the type system and suggest more performant 55 solutions where possible.</p> 56 <h2><a href="#updates" aria-hidden="true" class="anchor" id="updates"></a>Updates</h2> 57 <p>We have been very active over the last year and made some significant progress. There 58 are also a few non-technical updates we would like to share.</p> 59 <h2><a href="#organizational-updates" aria-hidden="true" class="anchor" id="organizational-updates"></a>Organizational updates</h2> 60 <p>First, a huge welcome to the two new members to team since the announcement post: <a href="https://github.com/boxyuwu">@BoxyUwU</a> and <a href="https://github.com/aliemjay">@aliemjay</a>. <a href="https://github.com/boxyuwu">@BoxyUwU</a> has been doing a lot of work on const generics and made significant contributions to the design of the next generation trait solver. <a href="https://github.com/aliemjay">@aliemjay</a> has been working on some very subtle improvements to opaque types - <code>impl Trait</code> - and to borrow checking. They are both invaluable additions to the team.</p> 61 <p>We also organized another in-person Types Team meetup last October, immediately prior to EuroRust. We discussed the state of the team, looked at current implementation challenges and in-progress work, and reviewed and updated <a href="https://blog.rust-lang.org/2023/01/20/types-announcement.html#roadmap">the roadmap from the previous meetup</a>. Most of this will be covered in this blog post.</p> 62 <p>Finally, as discussed in the <a href="https://rust-lang.github.io/rfcs/3254-types-team.html">RFC</a>, we would like to have leads rotate out regularly, largely to help share the burden and experience of leads' work. So with that being said, <a href="https://github.com/nikomatsakis">@nikomatsakis</a> is rotating out and <a href="https://github.com/lcnr">@lcnr</a> is joining to co-lead alongside <a href="https://github.com/jackh726/">@jackh726</a>.</p> 63 <h2><a href="#roadmap-progress-and-major-milestones" aria-hidden="true" class="anchor" id="roadmap-progress-and-major-milestones"></a>Roadmap progress and major milestones</h2> 64 <h3><a href="#the-next-generation-trait-solver" aria-hidden="true" class="anchor" id="the-next-generation-trait-solver"></a>The next-generation trait solver</h3> 65 <p>There has been <a href="https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3AWG-trait-system-refactor+-label%3Arollup+is%3Amerged+closed%3A%3E2023-01-20+sort%3Acreated-asc+">a lot of work</a> on the <a href="https://github.com/rust-lang/trait-system-refactor-initiative/">next-generation trait solver</a>. 66 The initiative posted <a href="https://blog.rust-lang.org/inside-rust/2023/12/22/trait-system-refactor-initiative.html">a separate update</a> at the end of last year. While 67 we would have liked to <a href="https://github.com/rust-lang/rust/pull/121848">stabilize its use in coherence</a> a few months ago, 68 this surfaced additional small behavior regressions and hangs, causing delays. We are working on fixing these issues and intend to merge the stabilization PR soon. We are getting close to compiling the standard library 69 and the compiler with the new solver enabled everywhere, after which will be able to run 70 crater to figure out the remaining issues. We expect there to be a long tail of minor issues 71 and behavioral differences from the existing implementation, so there's still a lot to do 72 here. There are also open design questions which we will have to resolve before stabilizing 73 the new implementation.</p> 74 <h3><a href="#async-and-impl-trait" aria-hidden="true" class="anchor" id="async-and-impl-trait"></a>Async and <code>impl Trait</code></h3> 75 <p>We stabilized <code>async</code>-fn in traits (AFIT) and return-position <code>impl Trait</code> in 76 traits (RPITIT) in version 1.75 thanks to a significant effort by <a href="https://github.com/compiler-errors">@compiler-errors</a> and 77 <a href="https://github.com/spastorino">@spastorino</a>. <a href="https://github.com/cjgillot">@cjgillot</a> greatly improved the way generators, and therefore async functions, 78 are represented in the type system<sup class="footnote-ref"><a href="#fn-107421" id="fnref-107421" data-footnote-ref>1</a></sup>. This allowed us to support recursive 79 <code>async</code>-functions without too much additional work<sup class="footnote-ref"><a href="#fn-117703" id="fnref-117703" data-footnote-ref>2</a></sup>.</p> 80 <p>Designing the next-generation trait solver surfaced issues and future-compatibility challenges 81 of our type-alias <code>impl Trait</code> (TAIT) implementation using the old trait solver. We are 82 currently reworking the design and implementation. <a href="https://github.com/oli-obk">@oli-obk</a> is spear-heading this effort. 83 This also impacts RPIT edge-cases, forcing us to be careful to avoid accidental breakage. 84 There are some open language design questions for TAIT, so we plan to 85 stabilize associated type position <code>impl Trait</code> (ATPIT) as it avoids these language design 86 questions while still closing the expressiveness gap.</p> 87 <h3><a href="#a-mir-formality" aria-hidden="true" class="anchor" id="a-mir-formality"></a><code>a-mir-formality</code></h3> 88 <p>We made limited progress on <a href="https://github.com/rust-lang/a-mir-formality"><code>a-mir-formality</code></a> over the last year, mostly 89 because we were able to allocate less time than expected towards this work. 90 We have used it as the foundation towards an intuitive approach to 91 coinductive traits which are necessary for many of the remaining unsound 92 issues.</p> 93 <h3><a href="#fixing-soundness-issues" aria-hidden="true" class="anchor" id="fixing-soundness-issues"></a>Fixing soundness issues</h3> 94 <p>We fixed multiple long-standing unsound issues, see <a href="https://github.com/rust-lang/rust/issues?q=is%3Aissue+label%3AI-unsound+label%3AT-types+-label%3Arequires-nightly+is%3Aclosed+closed%3A%3C2024-06-20+">the full list of closed issues</a>. The most most notable of which was <a href="https://github.com/rust-lang/rust/issues/80176">#80176</a>. This subtle issue caused us to accept methods in trait implementations whose function signature had outlives requirements not present in the trait definition. These requirements were then never proven when calling the trait method. As there were some crates which relied on this pattern by accident, even if it their usages didn't exploit this unsoundness, we first merged a <a href="https://github.com/rust-lang/rust/issues/105572">future-compatibility lint</a> which we then moved to a hard error after a few versions.</p> 95 <p>We've also spent time on <a href="https://github.com/orgs/rust-lang/projects/44/views/1">categorizing the remaining open issues</a> and integrating 96 them into our longterm planning. Most of the remaining ones are blocked on the 97 next-generation trait solver as fixing them relies on coinductive trait semantics 98 and improvements to implied bounds. There are some remaining issues which can be at 99 least partially fixed right now, and we intend to work through them as we go. 100 Finally, there are some issues for which we still haven't figured out the best 101 approach and which require some further considerations.</p> 102 <h2><a href="#going-forward" aria-hidden="true" class="anchor" id="going-forward"></a>Going forward</h2> 103 <p>We made significant progress during the last year but we are not done! This section covers our goals for the rest of 2024. For each item we also link to the project goals that we have proposed as part of the Rust Project's <a href="https://blog.rust-lang.org/inside-rust/2024/05/07/announcing-project-goals.html">experimental new roadmap process</a>.</p> 104 <h3><a href="#-znext-solver" aria-hidden="true" class="anchor" id="-znext-solver"></a><code>-Znext-solver</code></h3> 105 <ul> 106 <li><a href="https://rust-lang.github.io/rust-project-goals/2024h2/next-solver.html">Next-generation trait solver project goal</a></li> 107 </ul> 108 <p>Our biggest goal is to use the <a href="https://github.com/rust-lang/trait-system-refactor-initiative/">next-generation trait solver</a> 109 everywhere by default and to fully replace the existing implementation. We are currently 110 finalizing the stabilization of <a href="https://github.com/rust-lang/rust/pull/121848">its use in coherence checking</a>. This should 111 already fix multiple unsound issues and fix a lot of smaller issues and inconsistencies of 112 the current implementation. See the stabilization report for more details.</p> 113 <p>We are also working on extracting its implementation into a separate library 114 outside of the compiler itself. We would like to share the trait solver with 115 rust-analyzer by the end of this year. They currently use <a href="https://github.com/rust-lang/chalk/">chalk</a> which is no longer 116 actively maintained. Using the next-generation trait solver in rust-analyzer 117 should result in a lot of additional testing for the solver while also improving 118 the IDE experience by positively impacting performance and correctness.</p> 119 <p>We intend to slowly roll out the solver in other areas of the compiler until we're able 120 to fully remove the existing implementation by the end of 2025. This switch will fix 121 multiple unsound issues by itself and will unblock a significant amount of future work. 122 It will generally cleanup many rough edges of the type system, such as associated types 123 in higher-ranked types. There are many unsound issues which can only be fixed once we exclusively 124 use the new implementation.</p> 125 <h3><a href="#a-mir-formality-1" aria-hidden="true" class="anchor" id="a-mir-formality-1"></a><code>a-mir-formality</code></h3> 126 <ul> 127 <li><a href="https://rust-lang.github.io/rust-project-goals/2024h2/a-mir-formality.html"><code>a-mir-formality</code> project goal</a></li> 128 </ul> 129 <p>We intend to more actively develop <code>a-mir-formality</code> this year to use it in our design process. 130 Using it to model parts of the type system has already been incredibly impactful and we want 131 to build on that. We are working on more effective testing of <code>a-mir-formality</code> by enabling its 132 use for actual Rust code snippets and by adding fuzzing support. This will allow us to gain 133 additional confidence in our model of the type system and will guide its future development.</p> 134 <p>We plan to fully formalize some components of the type system this year. Coherence is fairly 135 self-contained, very subtle, and soundness-critical. This has prevented us from making significant 136 improvements to it in the past. We also intend to formalize coinductive trait semantics, which are 137 difficult to reason about and necessary to fix many longstanding soundness issues.</p> 138 <h3><a href="#language-changes-and-polonius" aria-hidden="true" class="anchor" id="language-changes-and-polonius"></a>Language changes and polonius</h3> 139 <ul> 140 <li><a href="https://rust-lang.github.io/rust-project-goals/2024h2/ATPIT.html">Associated Type Position Impl Trait (ATPIT) project goal</a></li> 141 <li><a href="https://rust-lang.github.io/rust-project-goals/2024h2/Polonius.html">Polonius on Nightly project goal</a></li> 142 </ul> 143 <p>We intend to get the internal implementation of opaque types ready for the stabilization 144 of TAIT and ATPIT this year. We are also hoping to land significant improvements to our 145 handling of associated types in coherence checking this year.</p> 146 <p>Our other goal is to get <a href="https://blog.rust-lang.org/inside-rust/2023/10/06/polonius-update.html">Polonius</a>, the next generation borrow checker, available on nightly, which would put us in a position to stabilize in 2025 once we have time to do more optimization and testing.</p> 147 <p>We also intend to support the development of other language features, such as <code>async</code>-closures, which are part of the <a href="https://rust-lang.github.io/rust-project-goals/2024h2/async.html">async project goal</a>, 148 and <code>dyn</code>-trait upcasting, which will hopefully get stabilized in the near future.</p> 149 <h2><a href="#roadmap" aria-hidden="true" class="anchor" id="roadmap"></a>Roadmap</h2> 150 <h3><a href="#eoy-2024" aria-hidden="true" class="anchor" id="eoy-2024"></a>EOY 2024</h3> 151 <ul> 152 <li>next-generation trait solver 153 <ul> 154 <li>stable in coherence</li> 155 <li>used by rust-analyzer</li> 156 </ul> 157 </li> 158 <li>ATPIT stabilized</li> 159 <li>a-mir-formality 160 <ul> 161 <li>support for fuzzing and testing Rust snippets</li> 162 <li>complete model of coherence and coinductive trait semantics</li> 163 </ul> 164 </li> 165 <li>full polonius implementation available on nightly</li> 166 </ul> 167 <h3><a href="#eoy-2025" aria-hidden="true" class="anchor" id="eoy-2025"></a>EOY 2025</h3> 168 <ul> 169 <li>next-generation trait solver used everywhere by default</li> 170 <li>TAIT stabilized</li> 171 <li>polonius stabilized</li> 172 </ul> 173 <h2><a href="#eoy-2027" aria-hidden="true" class="anchor" id="eoy-2027"></a>EOY 2027</h2> 174 <ul> 175 <li>next-generation trait solver 176 <ul> 177 <li>support for coinduction and (implicit) where-bounds on <code>for&lt;'a&gt;</code></li> 178 <li>enable perfect derive</li> 179 </ul> 180 </li> 181 <li>a-mir-formality fully model soundness critical parts of Rust</li> 182 <li>all known type system unsoundnesses fixed</li> 183 </ul> 184 <section class="footnotes" data-footnotes> 185 <ol> 186 <li id="fn-107421"> 187 <p>stabilized in <a href="https://github.com/rust-lang/rust/issues/107421">https://github.com/rust-lang/rust/issues/107421</a> <a href="#fnref-107421" class="footnote-backref" data-footnote-backref data-footnote-backref-idx="1" aria-label="Back to reference 1">↩</a></p> 188 </li> 189 <li id="fn-117703"> 190 <p>stabilized in <a href="https://github.com/rust-lang/rust/issues/117703">https://github.com/rust-lang/rust/issues/117703</a> <a href="#fnref-117703" class="footnote-backref" data-footnote-backref data-footnote-backref-idx="2" aria-label="Back to reference 2">↩</a></p> 191 </li> 192 </ol> 193 </section> 194 </content> 195 196 <author> 197 <name>lcnr</name> 198 </author> 199 </entry> 200 <entry> 201 <title>Announcing Rust 1.79.0</title> 202 <link rel="alternate" href="https://blog.rust-lang.org/2024/06/13/Rust-1.79.0.html" type="text/html" title="Announcing Rust 1.79.0" /> 203 <published>2024-06-13T00:00:00+00:00</published> 204 <updated>2024-06-13T00:00:00+00:00</updated> 205 <id>https://blog.rust-lang.org/2024/06/13/Rust-1.79.0.html</id> 206 <content type="html" xml:base="https://blog.rust-lang.org/2024/06/13/Rust-1.79.0.html"><p>The Rust team is happy to announce a new version of Rust, 1.79.0. Rust is a programming language empowering everyone to build reliable and efficient software.</p> 207 <p>If you have a previous version of Rust installed via <code>rustup</code>, you can get 1.79.0 with:</p> 208 <pre><code class="language-console">$ rustup update stable 209 </code></pre> 210 <p>If you don't have it already, you can <a href="https://www.rust-lang.org/install.html">get <code>rustup</code></a> from the appropriate page on our website, and check out the <a href="https://doc.rust-lang.org/nightly/releases.html#version-1790-2024-06-13">detailed release notes for 1.79.0</a>.</p> 211 <p>If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (<code>rustup default beta</code>) or the nightly channel (<code>rustup default nightly</code>). Please <a href="https://github.com/rust-lang/rust/issues/new/choose">report</a> any bugs you might come across!</p> 212 <h2><a href="#whats-in-1790-stable" aria-hidden="true" class="anchor" id="whats-in-1790-stable"></a>What's in 1.79.0 stable</h2> 213 <h3><a href="#inline-const-expressions" aria-hidden="true" class="anchor" id="inline-const-expressions"></a>Inline <code>const</code> expressions</h3> 214 <p><code>const { ... }</code> blocks are now stable in expression position, permitting 215 explicitly entering a const context without requiring extra declarations (e.g., 216 defining <code>const</code> items or associated constants on a trait).</p> 217 <p>Unlike const items (<code>const ITEM: ... = ...</code>), inline consts are able to make 218 use of in-scope generics, and have their type inferred rather than written explicitly, making them particularly useful for inline code snippets. For example, a pattern like:</p> 219 <pre><code class="language-rust">const EMPTY: Option&lt;Vec&lt;u8&gt;&gt; = None; 220 let foo = [EMPTY; 100]; 221 </code></pre> 222 <p>can now be written like this:</p> 223 <pre><code class="language-rust">let foo = [const { None }; 100]; 224 </code></pre> 225 <p>Notably, this is also true of generic contexts, where previously a verbose trait declaration with an associated constant would be required:</p> 226 <pre><code class="language-rust">fn create_none_array&lt;T, const N: usize&gt;() -&gt; [Option&lt;T&gt;; N] { 227 [const { None::&lt;T&gt; }; N] 228 } 229 </code></pre> 230 <p>This makes this code much more succinct and easier to read.</p> 231 <p>See the <a href="https://doc.rust-lang.org/nightly/reference/expressions/block-expr.html#const-blocks">reference documentation</a> for details.</p> 232 <h3><a href="#bounds-in-associated-type-position" aria-hidden="true" class="anchor" id="bounds-in-associated-type-position"></a>Bounds in associated type position</h3> 233 <p>Rust 1.79 stabilizes the associated item bounds syntax, which allows us to put 234 bounds in associated type position within other bounds, i.e. 235 <code>T: Trait&lt;Assoc: Bounds...&gt;</code>. This avoids the need to provide an extra, 236 explicit generic type just to constrain the associated type.</p> 237 <p>This feature allows specifying bounds in a few places that previously either 238 were not possible or imposed extra, unnecessary constraints on usage:</p> 239 <ul> 240 <li><strong><code>where</code> clauses</strong> - in this position, this is equivalent to breaking up the bound into two (or more) <code>where</code> clauses. For example, <code>where T: Trait&lt;Assoc: Bound&gt;</code> is equivalent to <code>where T: Trait, &lt;T as Trait&gt;::Assoc: Bound</code>.</li> 241 <li><strong>Supertraits</strong> - a bound specified via the new syntax is implied when the trait is used, unlike where clauses. Sample syntax: <code>trait CopyIterator: Iterator&lt;Item: Copy&gt; {}</code>.</li> 242 <li><strong>Associated type item bounds</strong> - This allows constraining the <em>nested</em> rigid projections that are associated with a trait's associated types. e.g. <code>trait Trait { type Assoc: Trait2&lt;Assoc2: Copy&gt;; }</code>.</li> 243 <li><strong>opaque type bounds (RPIT, TAIT)</strong> - This allows constraining associated types that are associated with the opaque type without having to <em>name</em> the opaque type. For example, <code>impl Iterator&lt;Item: Copy&gt;</code> defines an iterator whose item is <code>Copy</code> without having to actually name that item bound.</li> 244 </ul> 245 <p>See <a href="https://github.com/rust-lang/rust/pull/122055/#issue-2170532454">the stabilization report</a> for more details.</p> 246 <h3><a href="#extending-automatic-temporary-lifetime-extension" aria-hidden="true" class="anchor" id="extending-automatic-temporary-lifetime-extension"></a>Extending automatic temporary lifetime extension</h3> 247 <p>Temporaries which are immediately referenced in construction are now 248 automatically lifetime extended in <code>match</code> and <code>if</code> constructs. This has the 249 same behavior as lifetime extension for temporaries in block constructs.</p> 250 <p>For example:</p> 251 <pre><code class="language-rust">let a = if true { 252 ..; 253 &amp;temp() // used to error, but now gets lifetime extended 254 } else { 255 ..; 256 &amp;temp() // used to error, but now gets lifetime extended 257 }; 258 </code></pre> 259 <p>and</p> 260 <pre><code class="language-rust">let a = match () { 261 _ =&gt; { 262 ..; 263 &amp;temp() // used to error, but now gets lifetime extended 264 } 265 }; 266 </code></pre> 267 <p>are now consistent with prior behavior:</p> 268 <pre><code class="language-rust">let a = { 269 ..; 270 &amp;temp() // lifetime is extended 271 }; 272 </code></pre> 273 <p>This behavior is backwards compatible since these programs used to fail compilation.</p> 274 <h3><a href="#frame-pointers-enabled-in-standard-library-builds" aria-hidden="true" class="anchor" id="frame-pointers-enabled-in-standard-library-builds"></a>Frame pointers enabled in standard library builds</h3> 275 <p>The standard library distributed by the Rust project is now compiled with 276 <code>-Cforce-frame-pointers=yes</code>, enabling downstream users to more easily profile 277 their programs. Note that the standard library also continues to come up with 278 line-level debug info (e.g., DWARF), though that is <a href="https://blog.rust-lang.org/2024/03/21/Rust-1.77.0.html#enable-strip-in-release-profiles-by-default">stripped by default</a> in Cargo's release profiles.</p> 279 <h3><a href="#stabilized-apis" aria-hidden="true" class="anchor" id="stabilized-apis"></a>Stabilized APIs</h3> 280 <ul> 281 <li><a href="https://doc.rust-lang.org/stable/core/primitive.i32.html#method.unchecked_add"><code>{integer}::unchecked_add</code></a></li> 282 <li><a href="https://doc.rust-lang.org/stable/core/primitive.i32.html#method.unchecked_mul"><code>{integer}::unchecked_mul</code></a></li> 283 <li><a href="https://doc.rust-lang.org/stable/core/primitive.i32.html#method.unchecked_sub"><code>{integer}::unchecked_sub</code></a></li> 284 <li><a href="https://doc.rust-lang.org/stable/core/primitive.slice.html#method.split_at_unchecked"><code>&lt;[T]&gt;::split_at_unchecked</code></a></li> 285 <li><a href="https://doc.rust-lang.org/stable/core/primitive.slice.html#method.split_at_mut_unchecked"><code>&lt;[T]&gt;::split_at_mut_unchecked</code></a></li> 286 <li><a href="https://doc.rust-lang.org/stable/core/primitive.slice.html#method.utf8_chunks"><code>&lt;[u8]&gt;::utf8_chunks</code></a></li> 287 <li><a href="https://doc.rust-lang.org/stable/core/str/struct.Utf8Chunks.html"><code>str::Utf8Chunks</code></a></li> 288 <li><a href="https://doc.rust-lang.org/stable/core/str/struct.Utf8Chunk.html"><code>str::Utf8Chunk</code></a></li> 289 <li><a href="https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.is_aligned"><code>&lt;*const T&gt;::is_aligned</code></a></li> 290 <li><a href="https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.is_aligned-1"><code>&lt;*mut T&gt;::is_aligned</code></a></li> 291 <li><a href="https://doc.rust-lang.org/stable/core/ptr/struct.NonNull.html#method.is_aligned"><code>NonNull::is_aligned</code></a></li> 292 <li><a href="https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.len"><code>&lt;*const [T]&gt;::len</code></a></li> 293 <li><a href="https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.len-1"><code>&lt;*mut [T]&gt;::len</code></a></li> 294 <li><a href="https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.is_empty"><code>&lt;*const [T]&gt;::is_empty</code></a></li> 295 <li><a href="https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.is_empty-1"><code>&lt;*mut [T]&gt;::is_empty</code></a></li> 296 <li><a href="https://doc.rust-lang.org/stable/core/ptr/struct.NonNull.html#method.is_empty"><code>NonNull::&lt;[T]&gt;::is_empty</code></a></li> 297 <li><a href="https://doc.rust-lang.org/stable/core/ffi/c_str/struct.CStr.html#method.count_bytes"><code>CStr::count_bytes</code></a></li> 298 <li><a href="https://doc.rust-lang.org/stable/std/io/struct.Error.html#method.downcast"><code>io::Error::downcast</code></a></li> 299 <li><a href="https://doc.rust-lang.org/stable/core/num/struct.NonZero.html"><code>num::NonZero&lt;T&gt;</code></a></li> 300 <li><a href="https://doc.rust-lang.org/stable/std/path/fn.absolute.html"><code>path::absolute</code></a></li> 301 <li><a href="https://doc.rust-lang.org/stable/proc_macro/struct.Literal.html#method.byte_character"><code>proc_macro::Literal::byte_character</code></a></li> 302 <li><a href="https://doc.rust-lang.org/stable/proc_macro/struct.Literal.html#method.c_string"><code>proc_macro::Literal::c_string</code></a></li> 303 </ul> 304 <p>These APIs are now stable in const contexts:</p> 305 <ul> 306 <li><a href="https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicUsize.html#method.into_inner"><code>Atomic*::into_inner</code></a></li> 307 <li><a href="https://doc.rust-lang.org/stable/std/io/struct.Cursor.html#method.new"><code>io::Cursor::new</code></a></li> 308 <li><a href="https://doc.rust-lang.org/stable/std/io/struct.Cursor.html#method.get_ref"><code>io::Cursor::get_ref</code></a></li> 309 <li><a href="https://doc.rust-lang.org/stable/std/io/struct.Cursor.html#method.position"><code>io::Cursor::position</code></a></li> 310 <li><a href="https://doc.rust-lang.org/stable/std/io/fn.empty.html"><code>io::empty</code></a></li> 311 <li><a href="https://doc.rust-lang.org/stable/std/io/fn.repeat.html"><code>io::repeat</code></a></li> 312 <li><a href="https://doc.rust-lang.org/stable/std/io/fn.sink.html"><code>io::sink</code></a></li> 313 <li><a href="https://doc.rust-lang.org/stable/std/panic/struct.Location.html#method.caller"><code>panic::Location::caller</code></a></li> 314 <li><a href="https://doc.rust-lang.org/stable/std/panic/struct.Location.html#method.file"><code>panic::Location::file</code></a></li> 315 <li><a href="https://doc.rust-lang.org/stable/std/panic/struct.Location.html#method.line"><code>panic::Location::line</code></a></li> 316 <li><a href="https://doc.rust-lang.org/stable/std/panic/struct.Location.html#method.column"><code>panic::Location::column</code></a></li> 317 </ul> 318 <h3><a href="#other-changes" aria-hidden="true" class="anchor" id="other-changes"></a>Other changes</h3> 319 <p>Check out everything that changed in <a href="https://github.com/rust-lang/rust/releases/tag/1.79.0">Rust</a>, <a href="https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-179-2024-06-13">Cargo</a>, and <a href="https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-179">Clippy</a>.</p> 320 <h2><a href="#contributors-to-1790" aria-hidden="true" class="anchor" id="contributors-to-1790"></a>Contributors to 1.79.0</h2> 321 <p>Many people came together to create Rust 1.79.0. We couldn't have done it without all of you. <a href="https://thanks.rust-lang.org/rust/1.79.0/">Thanks!</a></p> 322 </content> 323 324 <author> 325 <name>The Rust Release Team</name> 326 </author> 327 </entry> 328 <entry> 329 <title>Faster linking times on nightly on Linux using `rust-lld`</title> 330 <link rel="alternate" href="https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html" type="text/html" title="Faster linking times on nightly on Linux using `rust-lld`" /> 331 <published>2024-05-17T00:00:00+00:00</published> 332 <updated>2024-05-17T00:00:00+00:00</updated> 333 <id>https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html</id> 334 <content type="html" xml:base="https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html"><p>TL;DR: rustc will use <code>rust-lld</code> by default on <code>x86_64-unknown-linux-gnu</code> on nightly to 335 significantly reduce linking times.</p> 336 <h4><a href="#some-context" aria-hidden="true" class="anchor" id="some-context"></a>Some context</h4> 337 <p>Linking time is often a big part of compilation time. When rustc needs to build a binary or a shared 338 library, it will usually call the default linker installed on the system to do that (this can be 339 changed on the command-line or by the target for which the code is compiled).</p> 340 <p>The linkers do an important job, with concerns about stability, backwards-compatibility and so on. 341 For these and other reasons, on the most popular operating systems they usually are older programs, 342 designed when computers only had a single core. So, they usually tend to be slow on a modern 343 machine. For example, when building ripgrep 13 in debug mode on Linux, roughly half of the time is 344 actually spent in the linker.</p> 345 <p>There are different linkers, however, and the usual advice to improve linking times is to use one of 346 these newer and faster linkers, like LLVM's <a href="https://lld.llvm.org/"><code>lld</code></a> or Rui Ueyama's 347 <a href="https://github.com/rui314/mold"><code>mold</code></a>.</p> 348 <p>Some of Rust's wasm and aarch64 targets already use <code>lld</code> by default. When using rustup, rustc ships 349 with a version of <code>lld</code> for this purpose. When CI builds LLVM to use in the compiler, it also builds 350 the linker and packages it. It's referred to as <code>rust-lld</code> to avoid colliding with any <code>lld</code> already 351 installed on the user's machine.</p> 352 <p>Since improvements to linking times are substantial, it would be a good default to use in the most 353 popular targets. This has been discussed for a long time, for example in issues 354 <a href="https://github.com/rust-lang/rust/issues/39915">#39915</a> and 355 <a href="https://github.com/rust-lang/rust/issues/71515">#71515</a>, and rustc already offers nightly flags to 356 use <code>rust-lld</code>.</p> 357 <p>By now, we believe we've done all the internal testing that we could, on CI, crater, and our 358 benchmarking infrastructure. We would now like to expand testing and gather real-world feedback and 359 use-cases. Therefore, we will enable <code>rust-lld</code> to be the linker used by default on 360 <code>x86_64-unknown-linux-gnu</code> for nightly builds.</p> 361 <h4><a href="#benefits" aria-hidden="true" class="anchor" id="benefits"></a>Benefits</h4> 362 <p>While this also enables the compiler to use more linker features in the future, the most immediate 363 benefit is much improved linking times.</p> 364 <p>Here are more details from the ripgrep example mentioned above: linking is reduced 7x, resulting in 365 a 40% reduction in end-to-end compilation times.</p> 366 <p><img src="../../../../images/2024-05-17-enabling-rust-lld-on-linux/ripgrep-comparison.png" alt="Before/after comparison of a ripgrep debug build" /></p> 367 <p>Most binaries should see some improvements here, but it's especially significant with e.g. bigger 368 binaries, or when involving debuginfo. These usually see bottlenecks in the linker.</p> 369 <p>Here's <a href="https://perf.rust-lang.org/compare.html?start=b3e117044c7f707293edc040edb93e7ec5f7040a&amp;end=baed03c51a68376c1789cc373581eea0daf89967&amp;stat=instructions%3Au&amp;tab=compile">a 370 link</a> 371 to the complete results from our benchmarks.</p> 372 <p>If testing goes well, we can then stabilize using this faster linker by default for 373 <code>x86_64-unknown-linux-gnu</code> users, before maybe looking at other targets.</p> 374 <h4><a href="#possible-drawbacks" aria-hidden="true" class="anchor" id="possible-drawbacks"></a>Possible drawbacks</h4> 375 <p>From our prior testing, we don't really expect issues to happen in practice. It is a drop-in 376 replacement for the vast majority of cases, but <code>lld</code> is not <em>bug-for-bug</em> compatible with GNU ld.</p> 377 <p>In any case, using <code>rust-lld</code> can be disabled if any problem occurs: use the <code>-Z linker-features=-lld</code> flag to revert to using the system's default linker.</p> 378 <p>Some crates somehow relying on these differences could need additional link args. For example, we 379 saw &lt;20 crates in the crater run failing to link because of a different default about <a href="https://lld.llvm.org/ELF/start-stop-gc">encapsulation 380 symbols</a>: these could require 381 <code>-Clink-arg=-Wl,-z,nostart-stop-gc</code> to match the legacy GNU ld behavior.</p> 382 <p>Some of the big gains in performance come from parallelism, which could be undesirable in 383 resource-constrained environments.</p> 384 <h4><a href="#summary" aria-hidden="true" class="anchor" id="summary"></a>Summary</h4> 385 <p>rustc will use <code>rust-lld</code> on <code>x86_64-unknown-linux-gnu</code> nightlies, for much improved linking times, 386 starting in tomorrow's rustup nightly (<code>nightly-2024-05-18</code>). 387 Let us know if you encounter problems, by <a href="https://github.com/rust-lang/rust/issues/new/choose">opening an 388 issue</a> on GitHub.</p> 389 <p>If that happens, you can revert to the default linker with the <code>-Z linker-features=-lld</code> flag. 390 Either by adding it to the usual <code>RUSTFLAGS</code> environment variable, or to a project's 391 <a href="https://doc.rust-lang.org/cargo/reference/config.html"><code>.cargo/config.toml</code></a> configuration file, 392 like so:</p> 393 <pre><code class="language-toml">[target.x86_64-unknown-linux-gnu] 394 rustflags = [&quot;-Zlinker-features=-lld&quot;] 395 </code></pre> 396 </content> 397 398 <author> 399 <name>Rémy Rakic</name> 400 </author> 401 </entry> 402 <entry> 403 <title>Rust participates in OSPP 2024</title> 404 <link rel="alternate" href="https://blog.rust-lang.org/2024/05/07/OSPP-2024.html" type="text/html" title="Rust participates in OSPP 2024" /> 405 <published>2024-05-07T00:00:00+00:00</published> 406 <updated>2024-05-07T00:00:00+00:00</updated> 407 <id>https://blog.rust-lang.org/2024/05/07/OSPP-2024.html</id> 408 <content type="html" xml:base="https://blog.rust-lang.org/2024/05/07/OSPP-2024.html"><p>Similar to our <a href="https://blog.rust-lang.org/2024/02/21/Rust-participates-in-GSoC-2024.html">previous</a> <a href="https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html">announcements</a> of the Rust Project's participation in Google Summer of Code (GSoC), we are now announcing our participation in <a href="https://summer-ospp.ac.cn/">Open Source Promotion Plan (OSPP) 2024</a>.</p> 409 <p>OSPP is a program organized in large part by The Institute of Software Chinese Academy of Sciences. Its goal is to encourage college students to participate in developing and maintaining open source software. The Rust Project is <a href="https://summer-ospp.ac.cn/org/orgdetail/11769be7-d00a-4931-be95-13595ac181e4?lang=en">already registered</a> and has a number of projects available for mentorship:</p> 410 <ul> 411 <li><a href="https://summer-ospp.ac.cn/org/prodetail/241170274">C codegen backend for rustc</a></li> 412 <li><a href="https://summer-ospp.ac.cn/org/prodetail/241170275">Extend annotate-snippets with features required by rustc</a></li> 413 <li><a href="https://summer-ospp.ac.cn/org/prodetail/241170277">Improve bootstrap</a></li> 414 <li><a href="https://summer-ospp.ac.cn/org/prodetail/241170528">Modernize the libc crate</a></li> 415 <li><a href="https://summer-ospp.ac.cn/org/prodetail/241170529">Improve infrastructure automation tools</a></li> 416 </ul> 417 <p>Eligibility is limited to students and there is a <a href="https://summer-ospp.ac.cn/help/en/student/">guide</a> for potential participants. Student registration ends on the 3rd of June with the project application deadline a day later.</p> 418 <p>Unlike GSoC which allows students to propose their own projects, OSPP requires that students only apply for one of the registered projects. We do have an <a href="https://rust-lang.zulipchat.com/#narrow/stream/436418-ospp">#ospp</a> Zulip stream and potential contributors are encouraged to join and discuss details about the projects and connect with mentors.</p> 419 <p>After the project application window closes on June 4th, we will review and select participants, which will be announced on June 26th. From there, students will participate through to the end of September.</p> 420 <p>As with GSoC, this is our first year participating in this program. We are incredibly excited for this opportunity to further expand into new open source communities and we're hopeful for a productive and educational summer.</p> 421 </content> 422 423 <author> 424 <name>Amanieu d'Antras, Jack Huey, and Jakub Beránek</name> 425 </author> 426 </entry> 427 <entry> 428 <title>Automatic checking of cfgs at compile-time</title> 429 <link rel="alternate" href="https://blog.rust-lang.org/2024/05/06/check-cfg.html" type="text/html" title="Automatic checking of cfgs at compile-time" /> 430 <published>2024-05-06T00:00:00+00:00</published> 431 <updated>2024-05-06T00:00:00+00:00</updated> 432 <id>https://blog.rust-lang.org/2024/05/06/check-cfg.html</id> 433 <content type="html" xml:base="https://blog.rust-lang.org/2024/05/06/check-cfg.html"><p>The Cargo and Compiler team are delighted to announce that starting with Rust 1.80 (or nightly-2024-05-05) every <em>reachable</em> <code>#[cfg]</code> will be <strong>automatically checked</strong> that they match the <strong>expected config names and values</strong>.</p> 434 <p>This can help with verifying that the crate is correctly handling conditional compilation for different target platforms or features. It ensures that the cfg settings are consistent between what is intended and what is used, helping to catch potential bugs or errors early in the development process.</p> 435 <p>This addresses a common pitfall for new and advanced users.</p> 436 <p>This is another step to our commitment to provide user-focused tooling and we are eager and excited to finally see it fixed, after more than two years since the original <a href="https://github.com/rust-lang/rfcs/pull/3013">RFC 3013</a><sup class="footnote-ref"><a href="#fn-1" id="fnref-1" data-footnote-ref>1</a></sup>.</p> 437 <h2><a href="#a-look-at-the-feature" aria-hidden="true" class="anchor" id="a-look-at-the-feature"></a>A look at the feature</h2> 438 <p>Every time a Cargo feature is declared that feature is transformed into a config that is passed to <code>rustc</code> (the Rust compiler) so it can verify with it along with <a href="https://doc.rust-lang.org/nightly/rustc/check-cfg.html#well-known-names-and-values">well known cfgs</a> if any of the <code>#[cfg]</code>, <code>#![cfg_attr]</code> and <code>cfg!</code> have unexpected configs and report a warning with the <code>unexpected_cfgs</code> lint.</p> 439 <p><em><code>Cargo.toml</code></em>:</p> 440 <pre><code class="language-toml">[package] 441 name = &quot;foo&quot; 442 443 [features] 444 lasers = [] 445 zapping = [] 446 </code></pre> 447 <p><em><code>src/lib.rs</code>:</em></p> 448 <pre><code class="language-rust">#[cfg(feature = &quot;lasers&quot;)] // This condition is expected 449 // as &quot;lasers&quot; is an expected value 450 // of the `feature` cfg 451 fn shoot_lasers() {} 452 453 #[cfg(feature = &quot;monkeys&quot;)] // This condition is UNEXPECTED 454 // as &quot;monkeys&quot; is NOT an expected 455 // value of the `feature` cfg 456 fn write_shakespeare() {} 457 458 #[cfg(windosw)] // This condition is UNEXPECTED 459 // it's supposed to be `windows` 460 fn win() {} 461 </code></pre> 462 <p><em><code>cargo check</code></em>:</p> 463 <p><img src="../../../../images/2024-05-06-check-cfg/cargo-check.svg" alt="cargo-check" /></p> 464 <h2><a href="#expecting-custom-cfgs" aria-hidden="true" class="anchor" id="expecting-custom-cfgs"></a>Expecting custom cfgs</h2> 465 <p><em>UPDATE: This section was added with the release of nightly-2024-05-19.</em></p> 466 <blockquote> 467 <p>In Cargo point-of-view: a custom cfg is one that is neither defined by <code>rustc</code> nor by a Cargo feature. Think of <code>tokio_unstable</code>, <code>has_foo</code>, ... but not <code>feature = &quot;lasers&quot;</code>, <code>unix</code> or <code>debug_assertions</code></p> 468 </blockquote> 469 <p>Some crates might use custom cfgs, like <code>loom</code>, <code>fuzzing</code> or <code>tokio_unstable</code> that they expected from the environment (<code>RUSTFLAGS</code> or other means) and which are always statically known at compile time. For those cases, Cargo provides via the <code>[lints]</code> table a way to statically declare those cfgs as expected.</p> 470 <p>Defining those custom cfgs as expected is done through the special <code>check-cfg</code> config under <code>[lints.rust.unexpected_cfgs]</code>:</p> 471 <p><em><code>Cargo.toml</code></em></p> 472 <pre><code class="language-toml">[lints.rust] 473 unexpected_cfgs = { level = &quot;warn&quot;, check-cfg = ['cfg(loom)', 'cfg(fuzzing)'] } 474 </code></pre> 475 <h2><a href="#custom-cfgs-in-build-scripts" aria-hidden="true" class="anchor" id="custom-cfgs-in-build-scripts"></a>Custom cfgs in build scripts</h2> 476 <p>On the other hand some crates use custom cfgs that are enabled by some logic in the crate <code>build.rs</code>. For those crates Cargo provides a new instruction: <a href="https://doc.rust-lang.org/nightly/cargo/reference/build-scripts.html#rustc-check-cfg"><code>cargo::rustc-check-cfg</code></a><sup class="footnote-ref"><a href="#fn-2" id="fnref-2" data-footnote-ref>2</a></sup> (or <code>cargo:rustc-check-cfg</code> for older Cargo version).</p> 477 <p>The syntax to use is described in the <a href="https://doc.rust-lang.org/nightly/rustc/">rustc book</a> section <a href="https://doc.rust-lang.org/nightly/rustc/check-cfg.html">checking configuration</a>, but in a nutshell the basic syntax of <code>--check-cfg</code> is:</p> 478 <pre><code>cfg(name, values(&quot;value1&quot;, &quot;value2&quot;, ..., &quot;valueN&quot;)) 479 </code></pre> 480 <p>Note that every custom cfgs must always be expected, regardless if the cfg is active or not!</p> 481 <h3><a href="#buildrs-example" aria-hidden="true" class="anchor" id="buildrs-example"></a><code>build.rs</code> example</h3> 482 <p><code>build.rs</code>:</p> 483 <pre><code class="language-rust">fn main() { 484 println!(&quot;cargo::rustc-check-cfg=cfg(has_foo)&quot;); 485 // ^^^^^^^^^^^^^^^^^^^^^^ new with Cargo 1.80 486 if has_foo() { 487 println!(&quot;cargo::rustc-cfg=has_foo&quot;); 488 } 489 } 490 </code></pre> 491 <blockquote> 492 <p>Each <code>cargo::rustc-cfg</code> should have an accompanying <strong>unconditional</strong> <code>cargo::rustc-check-cfg</code> directive to avoid warnings like this: <code>unexpected cfg condition name: has_foo</code>.</p> 493 </blockquote> 494 <h3><a href="#equivalence-table" aria-hidden="true" class="anchor" id="equivalence-table"></a>Equivalence table</h3> 495 <table> 496 <thead> 497 <tr> 498 <th><code>cargo::rustc-cfg</code></th> 499 <th><code>cargo::rustc-check-cfg</code></th> 500 </tr> 501 </thead> 502 <tbody> 503 <tr> 504 <td><code>foo</code></td> 505 <td><code>cfg(foo)</code> or <code>cfg(foo, values(none()))</code></td> 506 </tr> 507 <tr> 508 <td><code>foo=&quot;&quot;</code></td> 509 <td><code>cfg(foo, values(&quot;&quot;))</code></td> 510 </tr> 511 <tr> 512 <td><code>foo=&quot;bar&quot;</code></td> 513 <td><code>cfg(foo, values(&quot;bar&quot;))</code></td> 514 </tr> 515 <tr> 516 <td><code>foo=&quot;1&quot;</code> and <code>foo=&quot;2&quot;</code></td> 517 <td><code>cfg(foo, values(&quot;1&quot;, &quot;2&quot;))</code></td> 518 </tr> 519 <tr> 520 <td><code>foo=&quot;1&quot;</code> and <code>bar=&quot;2&quot;</code></td> 521 <td><code>cfg(foo, values(&quot;1&quot;))</code> and <code>cfg(bar, values(&quot;2&quot;))</code></td> 522 </tr> 523 <tr> 524 <td><code>foo</code> and <code>foo=&quot;bar&quot;</code></td> 525 <td><code>cfg(foo, values(none(), &quot;bar&quot;))</code></td> 526 </tr> 527 </tbody> 528 </table> 529 <p>More details can be found in the <a href="https://doc.rust-lang.org/nightly/rustc/check-cfg.html"><code>rustc</code> book</a>.</p> 530 <h2><a href="#frequently-asked-questions" aria-hidden="true" class="anchor" id="frequently-asked-questions"></a>Frequently asked questions</h2> 531 <h3><a href="#can-it-be-disabled" aria-hidden="true" class="anchor" id="can-it-be-disabled"></a>Can it be disabled?</h3> 532 <p>For Cargo users, the feature is <strong>always on</strong> and <em>cannot</em> be disabled, but like any other lints it can be controlled: <code>#![warn(unexpected_cfgs)]</code>.</p> 533 <h3><a href="#does-the-lint-affect-dependencies" aria-hidden="true" class="anchor" id="does-the-lint-affect-dependencies"></a>Does the lint affect dependencies?</h3> 534 <p>No, like most lints, <code>unexpected_cfgs</code> will only be reported for local packages thanks to <a href="https://doc.rust-lang.org/rustc/lints/levels.html#capping-lints">cap-lints</a>.</p> 535 <h3><a href="#how-does-it-interact-with-the-rustflags-env" aria-hidden="true" class="anchor" id="how-does-it-interact-with-the-rustflags-env"></a>How does it interact with the <code>RUSTFLAGS</code> env?</h3> 536 <p>You should be able to use the <code>RUSTFLAGS</code> environment variable like it was before. 537 <em>Currently <code>--cfg</code> arguments are not checked, only usage in code are.</em></p> 538 <p>This means that doing <code>RUSTFLAGS=&quot;--cfg tokio_unstable&quot; cargo check</code> will not report any warnings, unless <code>tokio_unstable</code> is used within your local crates, in which case crate author will need to make sure that that custom cfg is expected with <code>cargo::rustc-check-cfg</code> in the <code>build.rs</code> of that crate.</p> 539 <h3><a href="#how-to-expect-custom-cfgs-without-a-buildrs" aria-hidden="true" class="anchor" id="how-to-expect-custom-cfgs-without-a-buildrs"></a>How to expect custom cfgs without a <code>build.rs</code>?</h3> 540 <p><em>UPDATE: Cargo with nightly-2024-05-19 now provides the <code>[lints.rust.unexpected_cfgs.check-cfg]</code> config to address the statically known custom cfgs.</em></p> 541 <p><del>There is <strong>currently no way</strong> to expect a custom cfg other than with <code>cargo::rustc-check-cfg</code> in a <code>build.rs</code>.</del></p> 542 <p>Crate authors that don't want to use a <code>build.rs</code> and cannot use <code>[lints.rust.unexpected_cfgs.check-cfg]</code>, are encouraged to use Cargo features instead.</p> 543 <h3><a href="#how-does-it-interact-with-other-build-systems" aria-hidden="true" class="anchor" id="how-does-it-interact-with-other-build-systems"></a>How does it interact with other build systems?</h3> 544 <p>Non-Cargo based build systems are not affected by the lint by default. Build system authors that wish to have the same functionality should look at the <code>rustc</code> documentation for the <a href="https://doc.rust-lang.org/nightly/rustc/check-cfg.html"><code>--check-cfg</code></a> flag for a detailed explanation of how to achieve the same functionality.</p> 545 <section class="footnotes" data-footnotes> 546 <ol> 547 <li id="fn-1"> 548 <p>The stabilized implementation and RFC 3013 diverge significantly, in particular there is only one form for <code>--check-cfg</code>: <code>cfg()</code> (instead of <code>values()</code> and <code>names()</code> being incomplete and subtlety incompatible with each other). <a href="#fnref-1" class="footnote-backref" data-footnote-backref data-footnote-backref-idx="1" aria-label="Back to reference 1">↩</a></p> 549 </li> 550 <li id="fn-2"> 551 <p><code>cargo::rustc-check-cfg</code> will start working in Rust 1.80 (or nightly-2024-05-05). From Rust 1.77 to Rust 1.79 <em>(inclusive)</em> it is silently ignored. In Rust 1.76 and below a warning is emitted when used without the unstable Cargo flag <code>-Zcheck-cfg</code>. <a href="#fnref-2" class="footnote-backref" data-footnote-backref data-footnote-backref-idx="2" aria-label="Back to reference 2">↩</a></p> 552 </li> 553 </ol> 554 </section> 555 </content> 556 557 <author> 558 <name>Urgau</name> 559 </author> 560 </entry> 561 <entry> 562 <title>Announcing Rustup 1.27.1</title> 563 <link rel="alternate" href="https://blog.rust-lang.org/2024/05/06/Rustup-1.27.1.html" type="text/html" title="Announcing Rustup 1.27.1" /> 564 <published>2024-05-06T00:00:00+00:00</published> 565 <updated>2024-05-06T00:00:01+00:00</updated> 566 <id>https://blog.rust-lang.org/2024/05/06/Rustup-1.27.1.html</id> 567 <content type="html" xml:base="https://blog.rust-lang.org/2024/05/06/Rustup-1.27.1.html"><p>The Rustup team is happy to announce the release of Rustup version 1.27.1. 568 <a href="https://rustup.rs">Rustup</a> is the recommended tool to install <a href="https://www.rust-lang.org">Rust</a>, a programming language that is empowering everyone to build reliable and efficient software.</p> 569 <p>If you have a previous version of Rustup installed, getting Rustup 1.27.1 is as easy as stopping any programs which may be using Rustup (e.g. closing your IDE) and running:</p> 570 <pre><code class="language-console">$ rustup self update 571 </code></pre> 572 <p>Rustup will also automatically update itself at the end of a normal toolchain update:</p> 573 <pre><code class="language-console">$ rustup update 574 </code></pre> 575 <p>If you don't have it already, you can <a href="https://rustup.rs">get Rustup</a> from the appropriate page on our website.</p> 576 <h2><a href="#whats-new-in-rustup-1271" aria-hidden="true" class="anchor" id="whats-new-in-rustup-1271"></a>What's new in Rustup 1.27.1</h2> 577 <p>This new Rustup release involves some minor bug fixes.</p> 578 <p>The headlines for this release are:</p> 579 <ol> 580 <li>Prebuilt Rustup binaries should be working on older macOS versions again.</li> 581 <li><code>rustup-init</code> will no longer fail when <code>fish</code> is installed but <code>~/.config/fish/conf.d</code> hasn't been created.</li> 582 <li>Regressions regarding symlinked <code>RUSTUP_HOME/(toolchains|downloads|tmp)</code> have been addressed.</li> 583 </ol> 584 <p>Full details are available in the <a href="https://github.com/rust-lang/rustup/blob/stable/CHANGELOG.md">changelog</a>!</p> 585 <p>Rustup's documentation is also available in <a href="https://rust-lang.github.io/rustup/">the Rustup Book</a>.</p> 586 <h2><a href="#thanks" aria-hidden="true" class="anchor" id="thanks"></a>Thanks</h2> 587 <p>Thanks again to all the contributors who made Rustup 1.27.1 possible!</p> 588 <ul> 589 <li>Anas (0x61nas)</li> 590 <li>cuiyourong (cuiyourong)</li> 591 <li>Dirkjan Ochtman (djc)</li> 592 <li>Eric Huss (ehuss)</li> 593 <li>eth3lbert (eth3lbert)</li> 594 <li>hev (heiher)</li> 595 <li>klensy (klensy)</li> 596 <li>Chih Wang (ongchi)</li> 597 <li>Adam (pie-flavor)</li> 598 <li>rami3l (rami3l)</li> 599 <li>Robert (rben01)</li> 600 <li>Robert Collins (rbtcollins)</li> 601 <li>Sun Bin (shandongbinzhou)</li> 602 <li>Samuel Moelius (smoelius)</li> 603 <li>vpochapuis (vpochapuis)</li> 604 <li>Renovate Bot (renovate)</li> 605 </ul> 606 </content> 607 608 <author> 609 <name>The Rustup Team</name> 610 </author> 611 </entry> 612 <entry> 613 <title>Announcing Rust 1.78.0</title> 614 <link rel="alternate" href="https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html" type="text/html" title="Announcing Rust 1.78.0" /> 615 <published>2024-05-02T00:00:00+00:00</published> 616 <updated>2024-05-02T00:00:00+00:00</updated> 617 <id>https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html</id> 618 <content type="html" xml:base="https://blog.rust-lang.org/2024/05/02/Rust-1.78.0.html"><p>The Rust team is happy to announce a new version of Rust, 1.78.0. Rust is a programming language empowering everyone to build reliable and efficient software.</p> 619 <p>If you have a previous version of Rust installed via <code>rustup</code>, you can get 1.78.0 with:</p> 620 <pre><code class="language-console">$ rustup update stable 621 </code></pre> 622 <p>If you don't have it already, you can <a href="https://www.rust-lang.org/install.html">get <code>rustup</code></a> from the appropriate page on our website, and check out the <a href="https://doc.rust-lang.org/nightly/releases.html#version-1780-2024-05-02">detailed release notes for 1.78.0</a>.</p> 623 <p>If you'd like to help us out by testing future releases, you might consider updating locally to use the beta channel (<code>rustup default beta</code>) or the nightly channel (<code>rustup default nightly</code>). Please <a href="https://github.com/rust-lang/rust/issues/new/choose">report</a> any bugs you might come across!</p> 624 <h2><a href="#whats-in-1780-stable" aria-hidden="true" class="anchor" id="whats-in-1780-stable"></a>What's in 1.78.0 stable</h2> 625 <h3><a href="#diagnostic-attributes" aria-hidden="true" class="anchor" id="diagnostic-attributes"></a>Diagnostic attributes</h3> 626 <p>Rust now supports a <code>#[diagnostic]</code> attribute namespace to influence compiler error messages. These are treated as hints which the compiler is not <em>required</em> to use, and it is also not an error to provide a diagnostic that the compiler doesn't recognize. This flexibility allows source code to provide diagnostics even when they're not supported by all compilers, whether those are different versions or entirely different implementations.</p> 627 <p>With this namespace comes the first supported attribute, <code>#[diagnostic::on_unimplemented]</code>, which can be placed on a trait to customize the message when that trait is required but hasn't been implemented on a type. Consider the example given in the <a href="https://github.com/rust-lang/rust/pull/119888/">stabilization pull request</a>:</p> 628 <pre><code class="language-rust">#[diagnostic::on_unimplemented( 629 message = &quot;My Message for `ImportantTrait&lt;{A}&gt;` is not implemented for `{Self}`&quot;, 630 label = &quot;My Label&quot;, 631 note = &quot;Note 1&quot;, 632 note = &quot;Note 2&quot; 633 )] 634 trait ImportantTrait&lt;A&gt; {} 635 636 fn use_my_trait(_: impl ImportantTrait&lt;i32&gt;) {} 637 638 fn main() { 639 use_my_trait(String::new()); 640 } 641 </code></pre> 642 <p>Previously, the compiler would give a builtin error like this:</p> 643 <pre><code>error[E0277]: the trait bound `String: ImportantTrait&lt;i32&gt;` is not satisfied 644 --&gt; src/main.rs:12:18 645 | 646 12 | use_my_trait(String::new()); 647 | ------------ ^^^^^^^^^^^^^ the trait `ImportantTrait&lt;i32&gt;` is not implemented for `String` 648 | | 649 | required by a bound introduced by this call 650 | 651 </code></pre> 652 <p>With <code>#[diagnostic::on_unimplemented]</code>, its custom message fills the primary error line, and its custom label is placed on the source output. The original label is still written as help output, and any custom notes are written as well. (These exact details are subject to change.)</p> 653 <pre><code>error[E0277]: My Message for `ImportantTrait&lt;i32&gt;` is not implemented for `String` 654 --&gt; src/main.rs:12:18 655 | 656 12 | use_my_trait(String::new()); 657 | ------------ ^^^^^^^^^^^^^ My Label 658 | | 659 | required by a bound introduced by this call 660 | 661 = help: the trait `ImportantTrait&lt;i32&gt;` is not implemented for `String` 662 = note: Note 1 663 = note: Note 2 664 </code></pre> 665 <p>For trait authors, this kind of diagnostic is more useful if you can provide a better hint than just talking about the missing implementation itself. For example, this is an abridged sample from the standard library:</p> 666 <pre><code class="language-rust">#[diagnostic::on_unimplemented( 667 message = &quot;the size for values of type `{Self}` cannot be known at compilation time&quot;, 668 label = &quot;doesn't have a size known at compile-time&quot; 669 )] 670 pub trait Sized {} 671 </code></pre> 672 <p>For more information, see the reference section on <a href="https://doc.rust-lang.org/nightly/reference/attributes/diagnostics.html#the-diagnostic-tool-attribute-namespace">the <code>diagnostic</code> tool attribute namespace</a>.</p> 673 <h3><a href="#asserting-unsafe-preconditions" aria-hidden="true" class="anchor" id="asserting-unsafe-preconditions"></a>Asserting <code>unsafe</code> preconditions</h3> 674 <p>The Rust standard library has a number of assertions for the preconditions of <code>unsafe</code> functions, but historically they have only been enabled in <code>#[cfg(debug_assertions)]</code> builds of the standard library to avoid affecting release performance. However, since the standard library is usually compiled and distributed in release mode, most Rust developers weren't ever executing these checks at all.</p> 675 <p>Now, the condition for these assertions is delayed until code generation, so they will be checked depending on the user's own setting for debug assertions -- enabled by default in debug and test builds. This change helps users catch undefined behavior in their code, though the details of how much is checked are generally not stable.</p> 676 <p>For example, <a href="https://doc.rust-lang.org/std/slice/fn.from_raw_parts.html"><code>slice::from_raw_parts</code></a> requires an aligned non-null pointer. The following use of a purposely-misaligned pointer has undefined behavior, and while if you were unlucky it may have <em>appeared</em> to &quot;work&quot; in the past, the debug assertion can now catch it:</p> 677 <pre><code class="language-rust">fn main() { 678 let slice: &amp;[u8] = &amp;[1, 2, 3, 4, 5]; 679 let ptr = slice.as_ptr(); 680 681 // Create an offset from `ptr` that will always be one off from `u16`'s correct alignment 682 let i = usize::from(ptr as usize &amp; 1 == 0); 683 684 let slice16: &amp;[u16] = unsafe { std::slice::from_raw_parts(ptr.add(i).cast::&lt;u16&gt;(), 2) }; 685 dbg!(slice16); 686 } 687 </code></pre> 688 <pre><code>thread 'main' panicked at library/core/src/panicking.rs:220:5: 689 unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null, and the total size of the slice not to exceed `isize::MAX` 690 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace 691 thread caused non-unwinding panic. aborting. 692 </code></pre> 693 <h3><a href="#deterministic-realignment" aria-hidden="true" class="anchor" id="deterministic-realignment"></a>Deterministic realignment</h3> 694 <p>The standard library has a few functions that change the alignment of pointers and slices, but they previously had caveats that made them difficult to rely on in practice, if you followed their documentation precisely. Those caveats primarily existed as a hedge against <code>const</code> evaluation, but they're only stable for non-<code>const</code> use anyway. They are now promised to have consistent runtime behavior according to their actual inputs.</p> 695 <ul> 696 <li> 697 <p><a href="https://doc.rust-lang.org/std/primitive.pointer.html#method.align_offset"><code>pointer::align_offset</code></a> computes the offset needed to change a pointer to the given alignment. It returns <code>usize::MAX</code> if that is not possible, but it was previously permitted to <em>always</em> return <code>usize::MAX</code>, and now that behavior is removed.</p> 698 </li> 699 <li> 700 <p><a href="https://doc.rust-lang.org/std/primitive.slice.html#method.align_to"><code>slice::align_to</code></a> and <a href="https://doc.rust-lang.org/std/primitive.slice.html#method.align_to_mut"><code>slice::align_to_mut</code></a> both transmute slices to an aligned middle slice and the remaining unaligned head and tail slices. These methods now promise to return the largest possible middle part, rather than allowing the implementation to return something less optimal like returning everything as the head slice.</p> 701 </li> 702 </ul> 703 <h3><a href="#stabilized-apis" aria-hidden="true" class="anchor" id="stabilized-apis"></a>Stabilized APIs</h3> 704 <ul> 705 <li><a href="https://doc.rust-lang.org/stable/std/io/struct.Stdin.html#impl-Read-for-%26Stdin"><code>impl Read for &amp;Stdin</code></a></li> 706 <li><a href="https://github.com/rust-lang/rust/pull/113833/">Accept non <code>'static</code> lifetimes for several <code>std::error::Error</code> related implementations</a></li> 707 <li><a href="https://github.com/rust-lang/rust/pull/114655/">Make <code>impl&lt;Fd: AsFd&gt;</code> impl take <code>?Sized</code></a></li> 708 <li><a href="https://doc.rust-lang.org/stable/std/io/struct.Error.html#impl-From%3CTryReserveError%3E-for-Error"><code>impl From&lt;TryReserveError&gt; for io::Error</code></a></li> 709 </ul> 710 <p>These APIs are now stable in const contexts:</p> 711 <ul> 712 <li><a href="https://doc.rust-lang.org/stable/std/sync/struct.Barrier.html#method.new"><code>Barrier::new()</code></a></li> 713 </ul> 714 <h3><a href="#compatibility-notes" aria-hidden="true" class="anchor" id="compatibility-notes"></a>Compatibility notes</h3> 715 <ul> 716 <li>As <a href="https://blog.rust-lang.org/2024/02/26/Windows-7.html">previously announced</a>, Rust 1.78 has increased its minimum requirement to Windows 10 for the following targets: 717 <ul> 718 <li><code>x86_64-pc-windows-msvc</code></li> 719 <li><code>i686-pc-windows-msvc</code></li> 720 <li><code>x86_64-pc-windows-gnu</code></li> 721 <li><code>i686-pc-windows-gnu</code></li> 722 <li><code>x86_64-pc-windows-gnullvm</code></li> 723 <li><code>i686-pc-windows-gnullvm</code></li> 724 </ul> 725 </li> 726 <li>Rust 1.78 has upgraded its bundled LLVM to version 18, completing the announced <a href="https://blog.rust-lang.org/2024/03/30/i128-layout-update.html"><code>u128</code>/<code>i128</code> ABI change</a> for x86-32 and x86-64 targets. Distributors that use their own LLVM older than 18 may still face the calling convention bugs mentioned in that post.</li> 727 </ul> 728 <h3><a href="#other-changes" aria-hidden="true" class="anchor" id="other-changes"></a>Other changes</h3> 729 <p>Check out everything that changed in <a href="https://github.com/rust-lang/rust/releases/tag/1.78.0">Rust</a>, <a href="https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-178-2024-05-02">Cargo</a>, and <a href="https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-178">Clippy</a>.</p> 730 <h2><a href="#contributors-to-1780" aria-hidden="true" class="anchor" id="contributors-to-1780"></a>Contributors to 1.78.0</h2> 731 <p>Many people came together to create Rust 1.78.0. We couldn't have done it without all of you. <a href="https://thanks.rust-lang.org/rust/1.78.0/">Thanks!</a></p> 732 </content> 733 734 <author> 735 <name>The Rust Release Team</name> 736 </author> 737 </entry> 738 <entry> 739 <title>Announcing Google Summer of Code 2024 selected projects</title> 740 <link rel="alternate" href="https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html" type="text/html" title="Announcing Google Summer of Code 2024 selected projects" /> 741 <published>2024-05-01T00:00:00+00:00</published> 742 <updated>2024-05-01T00:00:00+00:00</updated> 743 <id>https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html</id> 744 <content type="html" xml:base="https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html"><p>The Rust Project is <a href="https://blog.rust-lang.org/2024/02/21/Rust-participates-in-GSoC-2024.html">participating</a> in <a href="https://summerofcode.withgoogle.com">Google Summer of Code (GSoC) 2024</a>, a global program organized by Google which is designed to bring new contributors to the world of open-source.</p> 745 <p>In February, we published a list of <a href="https://github.com/rust-lang/google-summer-of-code">GSoC project ideas</a>, and started discussing these projects with potential GSoC applicants on our <a href="https://rust-lang.zulipchat.com/#narrow/stream/421156-gsoc">Zulip</a>. We were pleasantly surprised by the amount of people that wanted to participate in these projects and that led to many fruitful discussions with members of various Rust teams. Some of them even immediately began contributing to various repositories of the Rust Project, even before GSoC officially started!</p> 746 <p>After the initial discussions, GSoC applicants prepared and submitted their project proposals. We received 65 (!) proposals in total. We are happy to see that there was so much interest, given that this is the first time the Rust Project is participating in GSoC.</p> 747 <p>A team of mentors primarily composed of Rust Project contributors then thoroughly examined the submitted proposals. GSoC required us to produce a ranked list of the best proposals, which was a challenging task in itself since Rust is a big project with many priorities! We went through many rounds of discussions and had to consider many factors, such as prior conversations with the given applicant, the quality and scope of their proposal, the importance of the proposed project for the Rust Project and its wider community, but also the availability of mentors, who are often volunteers and thus have limited time available for mentoring.</p> 748 <p>In many cases, we had multiple proposals that aimed to accomplish the same goal. Therefore, we had to pick only one per project topic despite receiving several high-quality proposals from people we'd love to work with. We also often had to choose between great proposals targeting different work within the same Rust component to avoid overloading a single mentor with multiple projects.</p> 749 <p>In the end, we narrowed the list down to twelve best proposals, which we felt was the maximum amount that we could realistically support with our available mentor pool. We submitted this list and eagerly awaited how many of these twelve proposals would be accepted into GSoC.</p> 750 <h2><a href="#selected-projects" aria-hidden="true" class="anchor" id="selected-projects"></a>Selected projects</h2> 751 <p>On the 1st of May, Google has announced the accepted projects. We are happy to announce that <code>9</code> proposals out of the twelve that we have submitted were accepted by Google, and will thus participate in Google Summer of Code 2024! Below you can find the list of accepted proposals (in alphabetical order), along with the names of their authors and the assigned mentor(s):</p> 752 <ul> 753 <li><strong><a href="https://summerofcode.withgoogle.com/programs/2024/projects/hADSyIDV">Adding lint-level configuration to cargo-semver-checks</a></strong> by Max Carr, mentored by Predrag Gruevski</li> 754 <li><strong><a href="https://summerofcode.withgoogle.com/programs/2024/projects/zxxeGZMt">Implementation of a Faster Register Allocator For Cranelift</a></strong> by d-sonuga, mentored by Chris Fallin and Amanieu d'Antras</li> 755 <li><strong><a href="https://summerofcode.withgoogle.com/programs/2024/projects/MeyNanKI">Improve Rust benchmark suite</a></strong> by s7tya, mentored by Jakub Beránek</li> 756 <li><strong><a href="https://summerofcode.withgoogle.com/programs/2024/projects/jjnidpgn">Move cargo shell completions to Rust</a></strong> by shanmu, mentored by Ed Page</li> 757 <li><strong><a href="https://summerofcode.withgoogle.com/programs/2024/projects/P5BC91Hr">Rewriting Esoteric, Error-Prone Makefile Tests Using Robust Rust Features</a></strong> by Julien Robert, mentored by Jieyou Xu</li> 758 <li><strong><a href="https://summerofcode.withgoogle.com/programs/2024/projects/gHEu3vxc">Rewriting the Rewrite trait</a></strong> by SeoYoung Lee, mentored by Yacin Tmimi</li> 759 <li><strong><a href="https://summerofcode.withgoogle.com/programs/2024/projects/IIHP5ozV">Rust to .NET compiler - add support for compiling &amp; running cargo tests</a></strong> by Fractal Fir, mentored by Jack Huey</li> 760 <li><strong><a href="https://summerofcode.withgoogle.com/programs/2024/projects/kXG0mZoj">Sandboxed and Deterministic Proc Macro using Wasm</a></strong> by Apurva Mishra, mentored by David Lattimore</li> 761 <li><strong><a href="https://summerofcode.withgoogle.com/programs/2024/projects/rk1Ey4hN">Tokio async support in Miri</a></strong> by Tiffany Pek Yuan, mentored by Oli Scherer</li> 762 </ul> 763 <p><strong>Congratulations to all applicants whose project was selected!</strong> The mentors are looking forward to working with you on these exciting projects to improve the Rust ecosystem. You can expect to hear from us soon, so that we can start coordinating the work on your GSoC projects.</p> 764 <p>We would also like to thank all the applicants whose proposal was sadly not accepted, for their interactions with the Rust community and contributions to various Rust projects. There were some great proposals that did not make the cut, in large part because of limited review capacity. However, even if your proposal was not accepted, we would be happy if you would consider contributing to the projects that got you interested, even outside GSoC! Our <a href="https://github.com/rust-lang/google-summer-of-code">project idea list</a> is still actual, and could serve as a general entry point for contributors that would like to work on projects that would help the Rust Project maintainers and the Rust ecosystem.</p> 765 <p>Assuming our involvement in GSoC 2024 is successful, there's a good chance we'll participate next year as well (though we can't promise anything yet) and we hope to receive your proposals again in the future! We also are planning to participate in similar programs in the very near future. Those announcements will come in separate blog posts, so make sure to subscribe to this blog so that you don't miss anything.</p> 766 <p>The accepted GSoC projects will run for several months. After GSoC 2024 finishes (in autumn of 2024), we plan to publish a blog post in which we will summarize the outcome of the accepted projects.</p> 767 </content> 768 769 <author> 770 <name>Jakub Beránek, Jack Huey and Paul Lenz</name> 771 </author> 772 </entry> 773 <entry> 774 <title>Security advisory for the standard library (CVE-2024-24576)</title> 775 <link rel="alternate" href="https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html" type="text/html" title="Security advisory for the standard library (CVE-2024-24576)" /> 776 <published>2024-04-09T00:00:00+00:00</published> 777 <updated>2024-04-09T00:00:00+00:00</updated> 778 <id>https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html</id> 779 <content type="html" xml:base="https://blog.rust-lang.org/2024/04/09/cve-2024-24576.html"><p>The Rust Security Response WG was notified that the Rust standard library did 780 not properly escape arguments when invoking batch files (with the <code>bat</code> and 781 <code>cmd</code> extensions) on Windows using the <a href="https://doc.rust-lang.org/std/process/struct.Command.html"><code>Command</code></a> API. An attacker able to 782 control the arguments passed to the spawned process could execute arbitrary 783 shell commands by bypassing the escaping.</p> 784 <p>The severity of this vulnerability is <strong>critical</strong> if you are invoking batch 785 files on Windows with untrusted arguments. No other platform or use is 786 affected.</p> 787 <p>This vulnerability is identified by CVE-2024-24576.</p> 788 <h2><a href="#overview" aria-hidden="true" class="anchor" id="overview"></a>Overview</h2> 789 <p>The <a href="https://doc.rust-lang.org/std/process/struct.Command.html#method.arg"><code>Command::arg</code></a> and <a href="https://doc.rust-lang.org/std/process/struct.Command.html#method.args"><code>Command::args</code></a> APIs state in their 790 documentation that the arguments will be passed to the spawned process as-is, 791 regardless of the content of the arguments, and will not be evaluated by a 792 shell. This means it should be safe to pass untrusted input as an argument.</p> 793 <p>On Windows, the implementation of this is more complex than other platforms, 794 because the Windows API only provides a single string containing all the 795 arguments to the spawned process, and it's up to the spawned process to split 796 them. Most programs use the standard C run-time argv, which in practice results 797 in a mostly consistent way arguments are splitted.</p> 798 <p>One exception though is <code>cmd.exe</code> (used among other things to execute batch 799 files), which has its own argument splitting logic. That forces the standard 800 library to implement custom escaping for arguments passed to batch files. 801 Unfortunately it was reported that our escaping logic was not thorough enough, 802 and it was possible to pass malicious arguments that would result in arbitrary 803 shell execution.</p> 804 <h2><a href="#mitigations" aria-hidden="true" class="anchor" id="mitigations"></a>Mitigations</h2> 805 <p>Due to the complexity of <code>cmd.exe</code>, we didn't identify a solution that would 806 correctly escape arguments in all cases. To maintain our API guarantees, we 807 improved the robustness of the escaping code, and changed the <code>Command</code> API to 808 return an <a href="https://doc.rust-lang.org/std/io/enum.ErrorKind.html#variant.InvalidInput"><code>InvalidInput</code></a> error when it cannot safely escape an argument. 809 This error will be emitted when spawning the process.</p> 810 <p>The fix will be included in Rust 1.77.2, to be released later today.</p> 811 <p>If you implement the escaping yourself or only handle trusted inputs, on 812 Windows you can also use the <a href="https://doc.rust-lang.org/std/os/windows/process/trait.CommandExt.html#tymethod.raw_arg"><code>CommandExt::raw_arg</code></a> method to bypass the 813 standard library's escaping logic.</p> 814 <h2><a href="#affected-versions" aria-hidden="true" class="anchor" id="affected-versions"></a>Affected Versions</h2> 815 <p>All Rust versions before 1.77.2 on Windows are affected, if your code or one of 816 your dependencies executes batch files with untrusted arguments. Other 817 platforms or other uses on Windows are not affected.</p> 818 <h2><a href="#acknowledgments" aria-hidden="true" class="anchor" id="acknowledgments"></a>Acknowledgments</h2> 819 <p>We want to thank RyotaK for responsibly disclosing this to us according to the 820 <a href="https://www.rust-lang.org/policies/security">Rust security policy</a>, and Simon Sawicki (Grub4K) for identifying some of 821 the escaping rules we adopted in our fix.</p> 822 <p>We also want to thank the members of the Rust project who helped us disclose 823 the vulnerability: Chris Denton for developing the fix; Mara Bos for reviewing 824 the fix; Pietro Albini for writing this advisory; Pietro Albini, Manish 825 Goregaokar and Josh Stone for coordinating this disclosure; Amanieu d'Antras 826 for advising during the disclosure.</p> 827 </content> 828 829 <author> 830 <name>The Rust Security Response WG</name> 831 </author> 832 </entry> 833 <entry> 834 <title>Changes to Rust's WASI targets</title> 835 <link rel="alternate" href="https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html" type="text/html" title="Changes to Rust's WASI targets" /> 836 <published>2024-04-09T00:00:00+00:00</published> 837 <updated>2024-04-09T00:00:01+00:00</updated> 838 <id>https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html</id> 839 <content type="html" xml:base="https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html"><p><a href="https://bytecodealliance.org/articles/WASI-0.2">WASI 0.2 was recently 840 stabilized</a>, and Rust has begun 841 implementing first-class support for it in the form of a dedicated new target. 842 Rust 1.78 will introduce new <code>wasm32-wasip1</code> (tier 2) and <code>wasm32-wasip2</code> (tier 843 3) targets. <code>wasm32-wasip1</code> is an effective rename of the existing <code>wasm32-wasi</code> 844 target, freeing the target name up for an eventual WASI 1.0 release. <strong>Starting 845 Rust 1.78 (May 2nd, 2024), users of WASI 0.1 are encouraged to begin migrating 846 to the new <code>wasm32-wasip1</code> target before the existing <code>wasm32-wasi</code> target is 847 removed in Rust 1.84 (January 5th, 2025).</strong></p> 848 <p>In this post we'll discuss the introduction of the new targets, the motivation 849 behind it, what that means for the existing WASI targets, and a detailed 850 schedule for these changes. This post is about the WASI targets only; the 851 existing <code>wasm32-unknown-unknown</code> and <code>wasm32-unknown-emscripten</code> targets are 852 unaffected by any changes in this post.</p> 853 <h2><a href="#introducing-wasm32-wasip2" aria-hidden="true" class="anchor" id="introducing-wasm32-wasip2"></a>Introducing <code>wasm32-wasip2</code></h2> 854 <p>After nearly five years of work the <a href="https://wasi.dev">WASI 0.2 specification</a> 855 was recently stabilized. This work builds on <a href="https://component-model.bytecodealliance.org">WebAssembly 856 Components</a> (think: strongly-typed 857 ABI for Wasm), providing standard interfaces for things like asynchronous IO, 858 networking, and HTTP. This will finally make it possible to write asynchronous 859 networked services on top of WASI, something which wasn't possible using WASI 860 0.1.</p> 861 <p>People interested in compiling Rust code to WASI 0.2 today are able to do so 862 using the <a href="https://github.com/bytecodealliance/cargo-component">cargo-component</a> 863 tool. This tool is able to take WASI 0.1 binaries, and transform them to WASI 0.2 864 Components using a shim. It also provides native support for common cargo 865 commands such as <code>cargo build</code>, <code>cargo test</code>, and <code>cargo run</code>. While it 866 introduces some inefficiencies because of the additional translation layer, in 867 practice this already works really well and people should be able to get 868 started with WASI 0.2 development.</p> 869 <p>We're however keen to begin making that translation layer obsolete. And for 870 that reason we're happy to share that Rust has made its first steps towards 871 that with the introduction of the <a href="https://doc.rust-lang.org/rustc/platform-support.html#tier-3">tier 872 3</a> <code>wasm32-wasip2</code> 873 target landing in Rust 1.78. <strong>This will initially miss a lot of expected</strong> 874 <strong>features such as stdlib support, and we don't recommend people use this target</strong> 875 <strong>quite yet.</strong> But as we fill in those missing features over the coming months, we 876 aim to eventually meet the criteria to become a tier 2 target, at which 877 point the <code>wasm32-wasip2</code> target would be considered ready for general use. This 878 work will happen through 2024, and we expect for this to land before the end of 879 the calendar year.</p> 880 <h2><a href="#renaming-wasm32-wasi-to-wasm32-wasip1" aria-hidden="true" class="anchor" id="renaming-wasm32-wasi-to-wasm32-wasip1"></a>Renaming <code>wasm32-wasi</code> to <code>wasm32-wasip1</code></h2> 881 <p>The original name for what we now call WASI 0.1 was &quot;WebAssembly System 882 Interface, snapshot 1&quot;. Rust shipped support for this in 2019, and we did so 883 knowing the target would likely undergo significant changes in the future. With 884 the knowledge we have today though, we would not have chosen to introduce the 885 &quot;WASI, snapshot 1&quot; target as <code>wasm32-wasi</code>. We should have instead chosen to add 886 some suffix to the initial target triple so that the eventual stable WASI 1.0 887 target can just be called <code>wasm32-wasi</code>.</p> 888 <p>In anticipation of both an eventual WASI 1.0 target, and to preserve consistency 889 between target names, we'll begin rolling out a name change to the existing WASI 890 0.1 target. Starting in Rust 1.78 (May 2nd, 2024) a new <code>wasm32-wasip1</code> target 891 will become available. Starting Rust 1.81 (September 5th, 2024) we will begin 892 warning existing users of <code>wasm32-wasi</code> to migrate to <code>wasm32-wasip1</code>. And 893 finally in Rust 1.84 (January 9th, 2025) the <code>wasm32-wasi</code> target will no longer 894 be shipped on the stable release channel. This will provide an 8 month 895 transition period for projects to switch to the new target name when they update 896 their Rust toolchains.</p> 897 <p>The name <code>wasip1</code> can be read as either &quot;WASI (zero) point one&quot; or &quot;WASI preview 898 one&quot;. The official specification uses the &quot;preview&quot; moniker, however in most 899 communication the form &quot;WASI 0.1&quot; is now preferred. This target triple was 900 chosen because it not only maps to both terms, but also more closely resembles 901 the target terminology used in <a href="https://go.dev/blog/wasi">other programming 902 languages</a>. This is something the WASI Preview 2 903 specification <a href="https://github.com/WebAssembly/WASI/tree/f45e72e5294e990c23d548eea32fd35c80525fd6/preview2#introduction">also makes note 904 of</a>.</p> 905 <h2><a href="#timeline" aria-hidden="true" class="anchor" id="timeline"></a>Timeline</h2> 906 <p>This table provides the dates and cut-offs for the target rename from 907 <code>wasm32-wasi</code> to <code>wasm32-wasip1</code>. The dates in this table do not apply to the 908 newly-introduced <code>wasm32-wasi-preview1-threads</code> target; this will be renamed to 909 <code>wasm32-wasip1-threads</code> in Rust 1.78 without going through a transition period. 910 The tier 3 <code>wasm32-wasip2</code> target will also be made available in Rust 1.78.</p> 911 <table> 912 <thead> 913 <tr> 914 <th>date</th> 915 <th>Rust Stable</th> 916 <th>Rust Beta</th> 917 <th>Rust Nightly</th> 918 <th>Notes</th> 919 </tr> 920 </thead> 921 <tbody> 922 <tr> 923 <td>2024-02-08</td> 924 <td>1.76</td> 925 <td>1.77</td> 926 <td>1.78</td> 927 <td><code>wasm32-wasip1</code> available on nightly</td> 928 </tr> 929 <tr> 930 <td>2024-03-21</td> 931 <td>1.77</td> 932 <td>1.78</td> 933 <td>1.79</td> 934 <td><code>wasm32-wasip1</code> available on beta</td> 935 </tr> 936 <tr> 937 <td>2024-05-02</td> 938 <td>1.78</td> 939 <td>1.79</td> 940 <td>1.80</td> 941 <td><code>wasm32-wasip1</code> available on stable</td> 942 </tr> 943 <tr> 944 <td>2024-06-13</td> 945 <td>1.79</td> 946 <td>1.80</td> 947 <td>1.81</td> 948 <td>warn if <code>wasm32-wasi</code> is used on nightly</td> 949 </tr> 950 <tr> 951 <td>2024-07-25</td> 952 <td>1.80</td> 953 <td>1.81</td> 954 <td>1.82</td> 955 <td>warn if <code>wasm32-wasi</code> is used on beta</td> 956 </tr> 957 <tr> 958 <td>2024-09-05</td> 959 <td>1.81</td> 960 <td>1.82</td> 961 <td>1.83</td> 962 <td>warn if <code>wasm32-wasi</code> is used on stable</td> 963 </tr> 964 <tr> 965 <td>2024-10-17</td> 966 <td>1.82</td> 967 <td>1.83</td> 968 <td>1.84</td> 969 <td><code>wasm32-wasi</code> unavailable on nightly</td> 970 </tr> 971 <tr> 972 <td>2024-11-28</td> 973 <td>1.83</td> 974 <td>1.84</td> 975 <td>1.85</td> 976 <td><code>wasm32-wasi</code> unavailable on beta</td> 977 </tr> 978 <tr> 979 <td>2025-01-09</td> 980 <td>1.84</td> 981 <td>1.85</td> 982 <td>1.86</td> 983 <td><code>wasm32-wasi</code> unavailable on stable</td> 984 </tr> 985 </tbody> 986 </table> 987 <h2><a href="#conclusion" aria-hidden="true" class="anchor" id="conclusion"></a>Conclusion</h2> 988 <p>In this post we've discussed the upcoming updates to Rust's WASI targets. Come 989 Rust 1.78 the <code>wasm32-wasip1</code> (tier 2) and <code>wasm32-wasip2</code> (tier 3) targets will 990 be added. In Rust 1.81 we will begin warning if <code>wasm32-wasi</code> is being used. And 991 in Rust 1.84, the existing <code>wasm32-wasi</code> target will be removed. This will free 992 up <code>wasm32-wasi</code> to eventually be used for a WASI 1.0 target. Users will have 8 993 months to switch to the new target name when they update their Rust toolchains.</p> 994 <p>The <code>wasm32-wasip2</code> target marks the start of native support for WASI 0.2. In 995 order to target it today from Rust, people are encouraged to use 996 <a href="https://github.com/bytecodealliance/cargo-component">cargo-component</a> tool 997 instead. The plan is to eventually graduate <code>wasm32-wasip2</code> to a tier-2 target, 998 at which point <code>cargo-component</code> will be upgraded to support it natively instead.</p> 999 <p>With WASI 0.2 finally stable, it's an exciting time for WebAssembly development. 1000 We're happy for Rust to begin implementing native support for WASI 0.2, and 1001 we're excited about what this will enable people to build.</p> 1002 </content> 1003 1004 <author> 1005 <name>Yosh Wuyts</name> 1006 </author> 1007 </entry> 1008 </feed>