forked from rust-lang/blog.rust-lang.org
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathfeed.xml
783 lines (753 loc) · 79.5 KB
/
feed.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
<generator uri="https://blog.rust-lang.org/" version="0.1.0">Rust Blog</generator>
<link href="https://blog.rust-lang.org/feed.xml" rel="self" type="application/atom+xml" />
<link href="https://blog.rust-lang.org/" rel="alternate" type="text/html" />
<id>https://blog.rust-lang.org/</id>
<title>Rust Blog</title>
<subtitle>Empowering everyone to build reliable and efficient software.</subtitle>
<author>
<name>Maintained by the Rust Teams.</name>
<uri>https://github.com/rust-lang/blog.rust-lang.org/</uri>
</author>
<updated>2023-02-10T15:38:56+00:00</updated>
<entry>
<title>Announcing Rust 1.67.1</title>
<link rel="alternate" href="https://blog.rust-lang.org/2023/02/09/Rust-1.67.1.html" type="text/html" title="Announcing Rust 1.67.1" />
<published>2023-02-09T00:00:00+00:00</published>
<updated>2023-02-09T00:00:00+00:00</updated>
<id>https://blog.rust-lang.org/2023/02/09/Rust-1.67.1.html</id>
<content type="html" xml:base="https://blog.rust-lang.org/2023/02/09/Rust-1.67.1.html"><p>The Rust team has published a new point release of Rust, 1.67.1. Rust is a
programming language that is empowering everyone to build reliable and
efficient software.</p>
<p>If you have a previous version of Rust installed via rustup, you can get 1.67.1 with:</p>
<pre><code>rustup update stable
</code></pre>
<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://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1671-2023-02-09">detailed release notes for 1.67.1</a> on GitHub.</p>
<h2><a href="#whats-in-1671-stable" aria-hidden="true" class="anchor" id="whats-in-1671-stable"></a>What's in 1.67.1 stable</h2>
<p>Rust 1.67.1 fixes a regression for projects that link to thin archives
(<code>.a</code> files that reference external <code>.o</code> objects). The new
archive writer in 1.67.0 could not read thin archives as inputs, leading to the
error &quot;Unsupported archive identifier.&quot; The compiler now uses LLVM's archive
writer again, until that format is supported in the new code.</p>
<p>Additionally, the clippy style lint <code>uninlined_format_args</code> is temporarily
downgraded to pedantic -- allowed by default. While the compiler has supported
this format since Rust 1.58, <code>rust-analyzer</code> does not support it yet, so it's
not necessarily good to use that style everywhere possible.</p>
<p>The final change is a soundness fix in Rust's own bootstrap code. This had no
known problematic uses, but it did raise an error when bootstrap was compiled
with 1.67 itself, rather than the prior 1.66 release as usual.</p>
<h3><a href="#contributors-to-1671" aria-hidden="true" class="anchor" id="contributors-to-1671"></a>Contributors to 1.67.1</h3>
<p>Many people came together to create Rust 1.67.1. We couldn't have done it
without all of you. <a href="https://thanks.rust-lang.org/rust/1.67.1/">Thanks!</a></p>
</content>
<author>
<name>The Rust Release Team</name>
</author>
</entry>
<entry>
<title>Announcing Rustup 1.25.2</title>
<link rel="alternate" href="https://blog.rust-lang.org/2023/02/01/Rustup-1.25.2.html" type="text/html" title="Announcing Rustup 1.25.2" />
<published>2023-02-01T00:00:00+00:00</published>
<updated>2023-02-01T00:00:00+00:00</updated>
<id>https://blog.rust-lang.org/2023/02/01/Rustup-1.25.2.html</id>
<content type="html" xml:base="https://blog.rust-lang.org/2023/02/01/Rustup-1.25.2.html"><p>The rustup working group is announcing the release of rustup version 1.25.2.
Rustup is the recommended tool to install Rust, a programming language that is
empowering everyone to build reliable and efficient software.</p>
<p>If you have a previous version of rustup installed, getting rustup 1.25.2 is as
easy as stopping any programs which may be using Rustup (e.g. closing your IDE)
and running:</p>
<pre><code>rustup self update
</code></pre>
<p>Rustup will also automatically update itself at the end of a normal toolchain
update:</p>
<pre><code>rustup update
</code></pre>
<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>
<h2><a href="#whats-new-in-rustup-1252" aria-hidden="true" class="anchor" id="whats-new-in-rustup-1252"></a>What's new in rustup 1.25.2</h2>
<p>This version of rustup fixes a warning incorrectly saying that signature
verification failed for Rust releases. The warning was due to a dependency of
Rustup including a time-based check preventing the use of SHA-1 from February
1st, 2023 onwards.</p>
<p>Unfortunately Rust's release signing key uses SHA-1 to sign its subkeys, which
resulted in all signatures being marked as invalid. Rustup 1.25.2 temporarily
fixes the problem by allowing again the use of SHA-1.</p>
<h2><a href="#why-is-signature-verification-failure-only-a-warning" aria-hidden="true" class="anchor" id="why-is-signature-verification-failure-only-a-warning"></a>Why is signature verification failure only a warning?</h2>
<p>Signature verification is currently an experimental and incomplete feature
included in rustup, as it's still missing crucial features like key rotation.
Until the feature is complete and ready for use, its outcomes are only
displayed as warnings without a way to turn them into errors.</p>
<p>This is done to avoid potentially breaking installations of rustup. Signature
verification will error out on failure only after the design and implementation
of the feature will be finished.</p>
<h2><a href="#thanks" aria-hidden="true" class="anchor" id="thanks"></a>Thanks</h2>
<p>Thanks again to all the contributors who made rustup 1.25.2 possible!</p>
<ul>
<li>Daniel Silverstone (kinnison)</li>
<li>Pietro Albini (pietroalbini)</li>
</ul>
</content>
<author>
<name>The rustup working group</name>
</author>
</entry>
<entry>
<title>Announcing Rust 1.67.0</title>
<link rel="alternate" href="https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html" type="text/html" title="Announcing Rust 1.67.0" />
<published>2023-01-26T00:00:00+00:00</published>
<updated>2023-01-26T00:00:00+00:00</updated>
<id>https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html</id>
<content type="html" xml:base="https://blog.rust-lang.org/2023/01/26/Rust-1.67.0.html"><p>The Rust team is happy to announce a new version of Rust, 1.67.0. Rust is a
programming language empowering everyone to build reliable and efficient
software.</p>
<p>If you have a previous version of Rust installed via rustup, you can get 1.67.0
with:</p>
<pre><code class="language-console">rustup update stable
</code></pre>
<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://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1670-2023-01-26">detailed release notes for
1.67.0</a>
on GitHub.</p>
<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>
<h2><a href="#whats-in-1670-stable" aria-hidden="true" class="anchor" id="whats-in-1670-stable"></a>What's in 1.67.0 stable</h2>
<h3><a href="#must_use-effective-on-async-fn" aria-hidden="true" class="anchor" id="must_use-effective-on-async-fn"></a><code>#[must_use]</code> effective on <code>async fn</code></h3>
<p><code>async</code> functions annotated with <code>#[must_use]</code> now apply that attribute to the
output of the returned <code>impl Future</code>. The <code>Future</code> trait itself is already
annotated with <code>#[must_use]</code>, so all types implementing <code>Future</code> are
automatically <code>#[must_use]</code>, which meant that previously there was no way to
indicate that the output of the <code>Future</code> is itself significant and should be used in some way.</p>
<p>With 1.67, the compiler will now warn if the output isn't used in some way.</p>
<pre><code class="language-rust">#[must_use]
async fn bar() -&gt; u32 { 0 }
async fn caller() {
bar().await;
}
</code></pre>
<pre><code>warning: unused output of future returned by `bar` that must be used
--&gt; src/lib.rs:5:5
|
5 | bar().await;
| ^^^^^^^^^^^
|
= note: `#[warn(unused_must_use)]` on by default
</code></pre>
<h3><a href="#stdsyncmpsc-implementation-updated" aria-hidden="true" class="anchor" id="stdsyncmpsc-implementation-updated"></a><code>std::sync::mpsc</code> implementation updated</h3>
<p>Rust's standard library has had a multi-producer, single-consumer channel since
before 1.0, but in this release the implementation is switched out to be based
on <a href="https://crates.io/crates/crossbeam-channel"><code>crossbeam-channel</code></a>. This
release contains no API changes, but the new implementation fixes a number of
bugs and improves the performance and maintainability of the implementation.</p>
<p>Users should not notice any significant changes in behavior as of this release.</p>
<h3><a href="#stabilized-apis" aria-hidden="true" class="anchor" id="stabilized-apis"></a>Stabilized APIs</h3>
<ul>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.i32.html#method.checked_ilog"><code>{integer}::checked_ilog</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.i32.html#method.checked_ilog2"><code>{integer}::checked_ilog2</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.i32.html#method.checked_ilog10"><code>{integer}::checked_ilog10</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.i32.html#method.ilog"><code>{integer}::ilog</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.i32.html#method.ilog2"><code>{integer}::ilog2</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.i32.html#method.ilog10"><code>{integer}::ilog10</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/num/struct.NonZeroU32.html#method.ilog2"><code>NonZeroU*::ilog2</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/num/struct.NonZeroU32.html#method.ilog10"><code>NonZeroU*::ilog10</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/num/struct.NonZeroU32.html#associatedconstant.BITS"><code>NonZero*::BITS</code></a></li>
</ul>
<p>These APIs are now stable in const contexts:</p>
<ul>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.char.html#method.from_u32"><code>char::from_u32</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.char.html#method.from_digit"><code>char::from_digit</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.char.html#method.to_digit"><code>char::to_digit</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/core/char/fn.from_u32.html"><code>core::char::from_u32</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/core/char/fn.from_digit.html"><code>core::char::from_digit</code></a></li>
</ul>
<p>Check out everything that changed in
<a href="https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1670-2023-01-26">Rust</a>,
<a href="https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-167-2023-01-26">Cargo</a>,
and <a href="https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-167">Clippy</a>.</p>
<h3><a href="#contributors-to-1670" aria-hidden="true" class="anchor" id="contributors-to-1670"></a>Contributors to 1.67.0</h3>
<p>Many people came together to create Rust 1.67.0.
We couldn't have done it without all of you.
<a href="https://thanks.rust-lang.org/rust/1.67.0/">Thanks!</a></p>
</content>
<author>
<name>The Rust Release Team</name>
</author>
</entry>
<entry>
<title>Officially announcing the types team</title>
<link rel="alternate" href="https://blog.rust-lang.org/2023/01/20/types-announcement.html" type="text/html" title="Officially announcing the types team" />
<published>2023-01-20T00:00:00+00:00</published>
<updated>2023-01-20T00:00:00+00:00</updated>
<id>https://blog.rust-lang.org/2023/01/20/types-announcement.html</id>
<content type="html" xml:base="https://blog.rust-lang.org/2023/01/20/types-announcement.html"><p>Oh hey, it's <a href="https://blog.rust-lang.org/inside-rust/2022/09/29/announcing-the-rust-style-team.html">another</a> new team announcement. But I will admit: if you follow the <a href="https://github.com/rust-lang/rfcs/pull/3254">RFCs repository</a>, the <a href="https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types">Rust zulip</a>, or were particularly observant on the <a href="https://blog.rust-lang.org/2022/10/28/gats-stabilization.html">GATs stabilization announcement post</a>, then this <em>might</em> not be a surprise for you. In fact, this &quot;new&quot; team was officially established at the end of May last year.</p>
<p>There are a few reasons why we're sharing this post now (as opposed to months before or...never). First, the team finished a three day in-person/hybrid meetup at the beginning of December and we'd like to share the purpose and outcomes of that meeting. Second, posting this announcement now is just around 7 months of activity and we'd love to share what we've accomplished within this time. Lastly, as we enter into the new year of 2023, it's a great time to share a bit of where we expect to head in this year and beyond.</p>
<h2><a href="#background---how-did-we-get-here" aria-hidden="true" class="anchor" id="background---how-did-we-get-here"></a>Background - How did we get here?</h2>
<p>Rust has grown significantly in the last several years, in many metrics: users, contributors, features, tooling, documentation, and more. As it has grown, the list of <em>things</em> people want to do with it has grown just as quickly. On top of powerful and ergonomic features, the demand for powerful tools such as IDEs or learning tools for the language has become more and more apparent. New compilers (frontend and backend) are being written. And, to top it off, we want Rust to continue to maintain one of its core design principles: safety.</p>
<p>All of these points highlights some key needs: to be able to <em>know</em> how the Rust language should work, to be able to <em>extend</em> the language and compiler with new features in a relatively painless way, to be able to <em>hook into</em> the compiler and be able to query important information about programs, and finally to be able to <em>maintain</em> the language and compiler in an amenable and robust way. Over the years, considerable effort has been put into these needs, but we haven't <em>quite</em> achieved these key requirements.</p>
<p>To extend a little, and put some numbers to paper, there are currently around 220 open tracking issues for <a href="https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AC-tracking-issue+label%3AT-lang">language</a>, <a href="https://github.com/rust-lang/rust/issues?page=1&amp;q=is%3Aopen+is%3Aissue+label%3AC-tracking-issue+label%3AT-compiler">compiler</a>, or <a href="https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AC-tracking-issue+label%3AT-types">types</a> features that have been accepted but are not completely implemented, of which about half are at least 3 years old and many are several years older than that. Many of these tracking issues have been open for so long not solely because of bandwidth, but because working on these features is hard, in large part because putting the relevant semantics in context of the larger language properly is hard; it's not easy for anyone to take a look at them and know what needs to be done to finish them. It's clear that we still need better foundations for making changes to the language and compiler.</p>
<p>Another number that might shock you: there are currently 62 open <a href="https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3AI-unsound">unsoundness issues</a>. This sounds <em>much</em> scarier than it really is: nearly all of these are edges of the compiler and language that have been found by people who specifically poke and prod to find them; in practice these will not pop up in the programs you write. Nevertheless, these are edges we want to iron out.</p>
<h2><a href="#the-types-team" aria-hidden="true" class="anchor" id="the-types-team"></a>The Types Team</h2>
<p>Moving forward, let's talk about a smaller subset of Rust rather than the entire language and compiler. Specifically, the parts relevant here include the type checker - loosely, defining the semantics and implementation of how variables are assigned their type, trait solving - deciding what traits are defined for which types, and borrow checking - proving that Rust's ownership model always holds. All of these can be thought of cohesively as the &quot;type system&quot;.</p>
<p>As of <a href="https://rust-lang.github.io/rfcs/3254-types-team.html">RFC 3254</a>, the above subset of the Rust language and compiler are under the purview of the types team. So, what exactly does this entail?</p>
<p>First, since around 2018, there existed the &quot;traits working group&quot;, which had the primary goal of creating a performant and extensible definition and implementation of Rust's trait system (including the <a href="https://github.com/rust-lang/chalk">Chalk</a> trait-solving library). As time progressed, and particularly in the latter half of 2021 into 2022, the working group's influence and responsibility naturally expanded to the type checker and borrow checker too - they are actually strongly linked and its often hard to disentangle the trait solver from the other two. So, in some ways, the types team essentially subsumes the former traits working group.</p>
<p>Another relevant working group is the <a href="https://rust-lang.github.io/compiler-team/working-groups/polonius/">polonius working group</a>, which primarily works on the design and implementation of the <a href="https://github.com/rust-lang/polonius">Polonius</a> borrow-checking library. While the working group itself will remain, it is now also under the purview of the types team.</p>
<p>Now, although the traits working group was essentially folded into the types team, the creation of a <em>team</em> has some benefits. First, like the <a href="https://blog.rust-lang.org/inside-rust/2022/09/29/announcing-the-rust-style-team.html">style team</a> (and many other teams), the types team is not a <em>top level</em> team. It actually, currently uniquely, has <em>two</em> parent teams: the lang and compiler teams. Both teams have decided to delegate decision-making authority covering the type system.</p>
<p>The language team has delegated the part of the <em>design</em> of type system. However, importantly, this design covers less of the &quot;feel&quot; of the features of type system and more of how it &quot;works&quot;, with the expectation that the types team will advise and bring concerns about new language extensions where required. (This division is not strongly defined, but the expectation is generally to err on the side of more caution). The compiler team, on the other hand, has delegated the responsibility of defining and maintaining the implementation of the trait system.</p>
<p>One particular responsibility that has traditionally been shared between the language and compiler teams is the assessment and fixing of soundness bugs in the language related to the type system. These often arise from implementation-defined language semantics and have in the past required synchronization and input from both lang and compiler teams. In the majority of cases, the types team now has the authority to assess and implement fixes without the direct input from either parent team. This applies, importantly, for fixes that are <em>technically</em> backwards-incompatible. While fixing safety holes is <a href="https://blog.rust-lang.org/2014/10/30/Stability.html#what-are-the-stability-caveats">not covered under Rust's backwards compatibility guarantees</a>, these decisions are not taken lightly and generally require team signoff and are assessed for potential ecosystem breakage with <a href="https://github.com/rust-lang/crater">crater</a>. However, this can now be done under one team rather than requiring the coordination of two separate teams, which makes closing these soundness holes easier (I will discuss this more later.)</p>
<h2><a href="#formalizing-the-rust-type-system" aria-hidden="true" class="anchor" id="formalizing-the-rust-type-system"></a>Formalizing the Rust type system</h2>
<p>As mentioned above, a nearly essential element of the growing Rust language is to know how it <em>should</em> work (and to have this well documented). There are relatively recent efforts pushing for a Rust specification (like <a href="https://github.com/ferrocene/specification">Ferrocene</a> or <a href="https://github.com/rust-lang/rfcs/pull/3355">this open RFC</a>), but it would be hugely beneficial to have a formalized definition of the type system, regardless of its potential integration into a more general specification. In fact the existence of a formalization would allow a better assessment of potential new features or soundness holes, without the subtle intricacies of the rest of the compiler.</p>
<p>As far back as 2015, not long after the release of Rust 1.0, an experimental Rust trait solver called Chalk began to be written. The core idea of Chalk is to translate the surface syntax and ideas of the Rust trait system (e.g. traits, impls, where clauses) into a set of logic rules that can be solved using a Prolog-like solver. Then, once this set of logic and solving reaches parity with the trait solver within the compiler itself, the plan was to simply replace the existing solver. In the meantime (and continuing forward), this new solver could be used by other tools, such as rust-analyzer, where it is used today.</p>
<p>Now, given Chalk's age and the promises it had been hoped to be able to deliver on, you might be tempted to ask the question &quot;Chalk, when?&quot; - and plenty have. However, we've learned over the years that Chalk is likely not the correct long-term solution for Rust, for a few reasons. First, as mentioned a few times in this post, the trait solver is only but a part of a larger type system; and modeling how the entire type system fits together gives a more complete picture of its details than trying to model the parts separately. Second, the needs of the <em>compiler</em> are quite different than the needs of a <em>formalization</em>: the compiler needs performant code with the ability to track information required for powerful diagnostics; a good formalization is one that is not only complete, but also easy to maintain, read, and understand. Over the years, Chalk has tried to have both and it has so far ended up with neither.</p>
<p>So, what are the plans going forward? Well, first the types team has begun working on a formalization of the Rust typesystem, currently coined <a href="https://github.com/nikomatsakis/a-mir-formality/">a-mir-formality</a>. An initial experimental phase was written using <a href="https://redex.racket-lang.org/">PLT redex</a>, but a Rust port is in-progress. There's lot to do still (including modeling more of the trait system, writing an RFC, and moving it into the rust-lang org), but it's already showing great promise.</p>
<p>Second, we've begun an <a href="https://github.com/rust-lang/types-team/issues/58">initiative</a> for writing a new trait solver in-tree. This new trait solver is more limited in scope than a-mir-formality (i.e. not intending to encompass the entire type system). In many ways, it's expected to be quite similar to Chalk, but leverage bits and pieces of the existing compiler and trait solver in order to make the transition as painless as possible. We do expect it to be pulled out-of-tree at some point, so it's being written to be as modular as possible. During our types team meetup earlier this month, we were able to hash out what we expect the structure of the solver to look like, and we've already gotten that <a href="https://github.com/rust-lang/rust/pull/105661">merged into the source tree</a>.</p>
<p>Finally, Chalk is no longer going to be a focus of the team. In the short term, it still may remain a useful tool for experimentation. As said before, rust-analyzer uses Chalk as its trait solver. It's also able to be used in rustc under an unstable feature flag. Thus, new ideas currently could be implemented in Chalk and battle-tested in practice. However, this benefit will likely not last long as a-mir-formality and the new in-tree trait solver get more usable and their interfaces become more accessible. All this is not to say that Chalk has been a failure. In fact, Chalk has taught us a lot about how to think about the Rust trait solver in a logical way and the current Rust trait solver has evolved over time to more closely model Chalk, even if incompletely. We expect to still support Chalk in some capacity for the time being, for rust-analyzer and potentially for those interested in experimenting with it.</p>
<h2><a href="#closing-soundness-holes" aria-hidden="true" class="anchor" id="closing-soundness-holes"></a>Closing soundness holes</h2>
<p>As brought up previously, a big benefit of creating a new types team with delegated authority from both the lang and compiler teams is the authority to assess and fix unsoundness issues mostly independently. However, a secondary benefit has actually just been better procedures and knowledge-sharing that allows the members of the team to get on the same page for what soundness issues there are, why they exist, and what it takes to fix them. For example, during our meetup earlier this month, we were able to go through the full list of soundness issues (focusing on those relevant to the type system), identify their causes, and discuss expected fixes (though most require prerequisite work discussed in the previous section).</p>
<p>Additionally, the team has already made a number of soundness fixes and has a few more in-progress. I won't go into details, but instead am just opting to putting them in list form:</p>
<ul>
<li><a href="https://github.com/rust-lang/rust/pull/99217">Consider unnormalized types for implied bounds</a>: landed in 1.65, no regressions found</li>
<li><a href="https://github.com/rust-lang/rust/pull/95474">Neither require nor imply lifetime bounds on opaque type for well formedness</a>: landed in 1.66, no regressions found</li>
<li><a href="https://github.com/rust-lang/rust/pull/105575">Add <code>IMPLIED_BOUNDS_ENTAILMENT</code> lint</a>: landing in 1.68, future-compat lint because many regressions found (of unsoundness)</li>
<li><a href="https://github.com/rust-lang/rust/pull/105102">Check ADT fields for copy implementations considering regions</a>: currently open, ready to land</li>
<li><a href="https://github.com/rust-lang/rust/pull/100046">Register wf obligation before normalizing in wfcheck</a>: currently open, regressions found, needs additional work</li>
<li><a href="https://github.com/rust-lang/rust/pull/100555">Handle projections as uncovered types during coherence check</a>: currently open, some regressions found, future-compat lint suggested</li>
<li><a href="https://github.com/rust-lang/rust/pull/101947">Don't normalize in AstConv</a>: landing in 1.68, 1 small regression found</li>
</ul>
<p>As you can see, we're making progress on closing soundness holes. These sometimes break code, as assessed by crater. However, we do what we can to mitigate this, even when the code being broken is technically unsound.</p>
<h2><a href="#new-features" aria-hidden="true" class="anchor" id="new-features"></a>New features</h2>
<p>While it's not technically under the types team purview to <em>propose and design</em> new features (these fall more under lang team proper), there are a few instances where the team is heavily involved (if not driving) feature design.</p>
<p>These can be small additions, which are close to bug fixes. For example, <a href="https://github.com/rust-lang/rust/pull/104765">this PR</a> allows more permutations of lifetime outlives bounds than what compiled previously. Or, these PRs can be larger, more impactful changes, that don't fit under a &quot;feature&quot;, but instead are tied heavily to the type system. For example, <a href="https://github.com/rust-lang/rust/pull/100386">this PR</a> makes the <code>Sized</code> trait coinductive, which effectively makes more cyclic bounds compile (see <a href="https://github.com/rust-lang/rust/pull/100386/files#diff-7efe7060b98871be57269858d3abd0c9a6f877a6c65fd0fba54ef122cd2d5281">this test</a> for an example).</p>
<p>There are also a few larger features and feature sets that have been driven by the types team, largely due to the heavy intersection with the type system. Here are a few examples:</p>
<ul>
<li>Generic associated types (GATs) - The feature long predates the types team and is the only one in this list that has actually been stabilized so far. But due to heavy type system interaction, the team was able to navigate the issues that came on its final path to stabilization. See <a href="https://blog.rust-lang.org/2022/10/28/gats-stabilization.html">this blog post</a> for much more details.</li>
<li>Type alias impl trait (TAITs) - Implementing this feature <em>properly</em> requires a thorough understanding of the type checker. This is close to stabilization. For more information, see <a href="https://github.com/rust-lang/rust/issues/63063">the tracking issue</a>.</li>
<li>Trait upcasting - This one is relatively small, but has some type system interaction. Again, see <a href="https://github.com/rust-lang/rust/issues/65991">the tracking issue</a> for an explanation of the feature.</li>
<li>Negative impls - This too predates the types team, but has recently been worked on by the team. There are still open bugs and soundness issues, so this is a bit away from stabilization, but you can follow <a href="https://github.com/rust-lang/rust/issues/68318">here</a>.</li>
<li>Return position impl traits in traits (RPITITs) and async functions in traits (AFITs) - These have only recently been possible with advances made with GATs and TAITs. They are currently tracked under a single <a href="https://github.com/rust-lang/rust/issues/91611">tracking issue</a>.</li>
</ul>
<h2><a href="#roadmap" aria-hidden="true" class="anchor" id="roadmap"></a>Roadmap</h2>
<p>To conclude, let's put all of this onto a roadmap. As always, goals are best when they are specific, measurable, and time-bound. For this, we've decided to split our goals into roughly 4 stages: summer of 2023, end-of-year 2023, end-of-year 2024, and end-of-year 2027 (6 months, 1 year, 2 years, and 5 years). Overall, our goals are to build a platform to maintain a sound, testable, and documented type system that can scale to new features need by the Rust language. Furthermore, we want to cultivate a sustainable and open-source team (the types team) to maintain that platform and type system.</p>
<p>A quick note: some of the things here have not quite been explained in this post, but they've been included in the spirit of completeness. So, without further ado:</p>
<p><strong>6 months</strong></p>
<ul>
<li>The work-in-progress new trait solver should be testable</li>
<li>a-mir-formality should be testable against the Rust test suite</li>
<li>Both TAITs and RPITITs/AFITs should be stabilized or on the path to stabilization.</li>
</ul>
<p><strong>EOY 2023</strong></p>
<ul>
<li>New trait solver replaces part of existing trait solver, but not used everywhere</li>
<li>We have an onboarding plan (for the team) and documentation for the new trait solver</li>
<li>a-mir-formality is integrated into the language design process</li>
</ul>
<p><strong>EOY 2024</strong></p>
<ul>
<li>New trait solver shared by rustc and rust-analyzer
<ul>
<li>Milestone: Type IR shared</li>
</ul>
</li>
<li>We have a clean API for extensible trait errors that is available at least internally</li>
<li>&quot;Shiny features&quot;
<ul>
<li>Polonius in a usable state</li>
<li>Implied bounds in higher-ranked trait bounds (see <a href="https://github.com/rust-lang/rust/issues/90696">this issue</a> for an example of an issue this would fix)</li>
<li>Being able to use <code>impl Trait</code> basically anywhere</li>
</ul>
</li>
<li>Potential edition boundary changes</li>
</ul>
<p><strong>EOY 2027</strong></p>
<ul>
<li>(Types) unsound issues resolved</li>
<li>Most language extensions are easy to do; large extensions are feasible</li>
<li>a-mir-formality passes 99.9% of the Rust test suite</li>
</ul>
<h2><a href="#conclusion" aria-hidden="true" class="anchor" id="conclusion"></a>Conclusion</h2>
<p>It's an exciting time for Rust. As its userbase and popularity grows, the language does as well. And as the language grows, the need for a sustainable type system to support the language becomes ever more apparent. The project has formed this new types team to address this need and hopefully, in this post, you can see that the team has so far accomplished a lot. And we expect that trend to only continue over the next many years.</p>
<p>As always, if you'd like to get involved or have questions, please drop by the <a href="https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types">Rust zulip</a>.</p>
</content>
<author>
<name>Jack Huey</name>
</author>
</entry>
<entry>
<title>Security advisory for Cargo (CVE-2022-46176)</title>
<link rel="alternate" href="https://blog.rust-lang.org/2023/01/10/cve-2022-46176.html" type="text/html" title="Security advisory for Cargo (CVE-2022-46176)" />
<published>2023-01-10T00:00:00+00:00</published>
<updated>2023-01-10T00:00:00+00:00</updated>
<id>https://blog.rust-lang.org/2023/01/10/cve-2022-46176.html</id>
<content type="html" xml:base="https://blog.rust-lang.org/2023/01/10/cve-2022-46176.html"><blockquote>
<p>This is a cross-post of <a href="https://groups.google.com/g/rustlang-security-announcements/c/v5cFFJ7T0RY">the official security advisory</a>. The
official advisory contains a signed version with our PGP key, as well.</p>
</blockquote>
<p>The Rust Security Response WG was notified that Cargo did not perform SSH host
key verification when cloning indexes and dependencies via SSH. An attacker
could exploit this to perform man-in-the-middle (MITM) attacks.</p>
<p>This vulnerability has been assigned CVE-2022-46176.</p>
<h2><a href="#overview" aria-hidden="true" class="anchor" id="overview"></a>Overview</h2>
<p>When an SSH client establishes communication with a server, to prevent MITM
attacks the client should check whether it already communicated with that
server in the past and what the server's public key was back then. If the key
changed since the last connection, the connection must be aborted as a MITM
attack is likely taking place.</p>
<p>It was discovered that Cargo never implemented such checks, and performed no
validation on the server's public key, leaving Cargo users vulnerable to MITM
attacks.</p>
<h2><a href="#affected-versions" aria-hidden="true" class="anchor" id="affected-versions"></a>Affected Versions</h2>
<p>All Rust versions containing Cargo before 1.66.1 are vulnerable.</p>
<p>Note that even if you don't explicitly use SSH for alternate registry indexes
or crate dependencies, you might be affected by this vulnerability if you have
configured git to replace HTTPS connections to GitHub with SSH (through git's
<a href="https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtinsteadOf"><code>url.&lt;base&gt;.insteadOf</code></a> setting), as that'd cause you to clone the
crates.io index through SSH.</p>
<h2><a href="#mitigations" aria-hidden="true" class="anchor" id="mitigations"></a>Mitigations</h2>
<p>We will be releasing Rust 1.66.1 today, 2023-01-10, changing Cargo to check the
SSH host key and abort the connection if the server's public key is not already
trusted. We recommend everyone to upgrade as soon as possible.</p>
<p>Patch files for Rust 1.66.0 are also available <a href="https://github.com/rust-lang/wg-security-response/tree/main/patches/CVE-2022-46176">here</a> for custom-built
toolchains.</p>
<p>For the time being Cargo will not ask the user whether to trust a server's
public key during the first connection. Instead, Cargo will show an error
message detailing how to add that public key to the list of trusted keys. Note
that this might break your automated builds if the hosts you clone dependencies
or indexes from are not already trusted.</p>
<p>If you can't upgrade to Rust 1.66.1 yet, we recommend configuring Cargo to use
the <code>git</code> CLI instead of its built-in git support. That way, all git network
operations will be performed by the <code>git</code> CLI, which is not affected by this
vulnerability. You can do so by adding this snippet to your <a href="https://doc.rust-lang.org/cargo/reference/config.html">Cargo
configuration file</a>:</p>
<pre><code class="language-toml">[net]
git-fetch-with-cli = true
</code></pre>
<h2><a href="#acknowledgments" aria-hidden="true" class="anchor" id="acknowledgments"></a>Acknowledgments</h2>
<p>Thanks to the Julia Security Team for disclosing this to us according to our
<a href="https://www.rust-lang.org/policies/security">security policy</a>!</p>
<p>We also want to thank the members of the Rust project who contributed to fixing
this issue. Thanks to Eric Huss and Weihang Lo for writing and reviewing the
patch, Pietro Albini for coordinating the disclosure and writing this advisory,
and Josh Stone, Josh Triplett and Jacob Finkelman for advising during the
disclosure.</p>
<p><em>Updated on 2023-01-10 at 21:30 UTC to include additional mitigations.</em></p>
</content>
<author>
<name>The Rust Security Response WG</name>
</author>
</entry>
<entry>
<title>Announcing Rust 1.66.1</title>
<link rel="alternate" href="https://blog.rust-lang.org/2023/01/10/Rust-1.66.1.html" type="text/html" title="Announcing Rust 1.66.1" />
<published>2023-01-10T00:00:00+00:00</published>
<updated>2023-01-10T00:00:01+00:00</updated>
<id>https://blog.rust-lang.org/2023/01/10/Rust-1.66.1.html</id>
<content type="html" xml:base="https://blog.rust-lang.org/2023/01/10/Rust-1.66.1.html"><p>The Rust team has published a new point release of Rust, 1.66.1. Rust is a
programming language that is empowering everyone to build reliable and
efficient software.</p>
<p>If you have a previous version of Rust installed via rustup, you can get 1.66.1 with:</p>
<pre><code>rustup update stable
</code></pre>
<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://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1661-2023-01-10">detailed release notes for 1.66.1</a> on GitHub.</p>
<h2><a href="#whats-in-1661-stable" aria-hidden="true" class="anchor" id="whats-in-1661-stable"></a>What's in 1.66.1 stable</h2>
<p>Rust 1.66.1 fixes Cargo not verifying SSH host keys when cloning dependencies
or registry indexes with SSH. This security vulnerability is tracked as
<a href="https://www.cve.org/CVERecord?id=CVE-2022-46176">CVE-2022-46176</a>, and you <a href="https://blog.rust-lang.org/2023/01/10/cve-2022-46176.html">can find more details in the advisory</a>.</p>
<h3><a href="#contributors-to-1661" aria-hidden="true" class="anchor" id="contributors-to-1661"></a>Contributors to 1.66.1</h3>
<p>Many people came together to create Rust 1.66.1. We couldn't have done it
without all of you. <a href="https://thanks.rust-lang.org/rust/1.66.1/">Thanks!</a></p>
</content>
<author>
<name>The Rust Release Team</name>
</author>
</entry>
<entry>
<title>Updating the Android NDK in Rust 1.68</title>
<link rel="alternate" href="https://blog.rust-lang.org/2023/01/09/android-ndk-update-r25.html" type="text/html" title="Updating the Android NDK in Rust 1.68" />
<published>2023-01-09T00:00:00+00:00</published>
<updated>2023-01-09T00:00:00+00:00</updated>
<id>https://blog.rust-lang.org/2023/01/09/android-ndk-update-r25.html</id>
<content type="html" xml:base="https://blog.rust-lang.org/2023/01/09/android-ndk-update-r25.html"><p>We are pleased to announce that Android platform support in Rust will be
modernized in Rust 1.68 as we update the target NDK from r17 to r25. As a
consequence the minimum supported API level will increase from 15 (Ice Cream
Sandwich) to 19 (KitKat).</p>
<p>In NDK r23 Android switched to using LLVM's <code>libunwind</code> for all architectures.
This meant that</p>
<ol>
<li>If a project were to target NDK r23 or newer with previous versions of Rust
<a href="https://github.com/rust-lang/rust/pull/85806#issuecomment-1096266946">a workaround</a>
would be required to redirect attempts to link against <code>libgcc</code> to instead
link against <code>libunwind</code>. Following this update this workaround will no
longer be necessary.</li>
<li>If a project uses NDK r22 or older it will need to be updated to use <a href="https://developer.android.com/ndk/downloads">r23 or
newer</a>. Information about the
layout of the NDK's toolchain can be found
<a href="https://developer.android.com/ndk/guides/other_build_systems">here</a>.</li>
</ol>
<p>Going forward the Android platform will target the most recent LTS NDK, allowing
Rust developers to access platform features sooner. These updates should occur
yearly and will be announced in release notes.</p>
</content>
<author>
<name>Android Platform Team</name>
</author>
</entry>
<entry>
<title>Announcing Rust 1.66.0</title>
<link rel="alternate" href="https://blog.rust-lang.org/2022/12/15/Rust-1.66.0.html" type="text/html" title="Announcing Rust 1.66.0" />
<published>2022-12-15T00:00:00+00:00</published>
<updated>2022-12-15T00:00:00+00:00</updated>
<id>https://blog.rust-lang.org/2022/12/15/Rust-1.66.0.html</id>
<content type="html" xml:base="https://blog.rust-lang.org/2022/12/15/Rust-1.66.0.html"><p>The Rust team is happy to announce a new version of Rust, 1.66.0. Rust is a
programming language empowering everyone to build reliable and efficient
software.</p>
<p>If you have a previous version of Rust installed via rustup, you can get 1.66.0
with:</p>
<pre><code class="language-console">rustup update stable
</code></pre>
<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://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1660-2022-12-15">detailed release notes for
1.66.0</a>
on GitHub.</p>
<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>
<h2><a href="#whats-in-1660-stable" aria-hidden="true" class="anchor" id="whats-in-1660-stable"></a>What's in 1.66.0 stable</h2>
<h3><a href="#explicit-discriminants-on-enums-with-fields" aria-hidden="true" class="anchor" id="explicit-discriminants-on-enums-with-fields"></a>Explicit discriminants on enums with fields</h3>
<p>Enums with integer representations can now use explicit discriminants, even when they have fields.</p>
<pre><code class="language-rust">#[repr(u8)]
enum Foo {
A(u8),
B(i8),
C(bool) = 42,
}
</code></pre>
<p>Previously, you could use explicit discriminants on enums with representations, but only if none of their variants had fields. Explicit discriminants are useful when passing values across language boundaries where the representation of the enum needs to match in both languages. For example,</p>
<pre><code class="language-rust">#[repr(u8)]
enum Bar {
A,
B,
C = 42,
D,
}
</code></pre>
<p>Here the <code>Bar</code> enum is guaranteed to have the same layout as <code>u8</code>. In addition, the <code>Bar::C</code> variant is guaranteed to have a discriminant of 42. Variants without explicitly-specified values will have discriminants that are automatically assigned according to their order in the source code, so <code>Bar::A</code> will have a discriminant of 0, <code>Bar::B</code> will have a discriminant of 1, and <code>Bar::D</code> will have a discriminant of 43. Without this feature, the only way to set the explicit value of <code>Bar::C</code> would be to add 41 unnecessary variants before it!</p>
<p>Note: whereas for field-less enums it is possible to inspect a discriminant via <code>as</code> casting (e.g. <code>Bar::C as u8</code>), Rust provides no language-level way to access the raw discriminant of an enum with fields. Instead, currently unsafe code must be used to inspect the discriminant of an enum with fields. Since this feature is intended for use with cross-language FFI where unsafe code is already necessary, this should hopefully not be too much of an extra burden. In the meantime, if all you need is an opaque handle to the discriminant, please see the <code>std::mem::discriminant</code> function.</p>
<h3><a href="#corehintblack_box" aria-hidden="true" class="anchor" id="corehintblack_box"></a><code>core::hint::black_box</code></h3>
<p>When benchmarking or examining the machine code produced by a compiler, it's often useful to prevent optimizations from occurring in certain places. In the following example, the function <code>push_cap</code> executes <code>Vec::push</code> 4 times in a loop:</p>
<pre><code class="language-rust">fn push_cap(v: &amp;mut Vec&lt;i32&gt;) {
for i in 0..4 {
v.push(i);
}
}
pub fn bench_push() -&gt; Duration {
let mut v = Vec::with_capacity(4);
let now = Instant::now();
push_cap(&amp;mut v);
now.elapsed()
}
</code></pre>
<p>If you inspect the optimized output of the compiler on x86_64, you'll notice that it looks rather short:</p>
<pre><code class="language-asm">example::bench_push:
sub rsp, 24
call qword ptr [rip + std::time::Instant::now@GOTPCREL]
lea rdi, [rsp + 8]
mov qword ptr [rsp + 8], rax
mov dword ptr [rsp + 16], edx
call qword ptr [rip + std::time::Instant::elapsed@GOTPCREL]
add rsp, 24
ret
</code></pre>
<p>In fact, the entire function <code>push_cap</code> we wanted to benchmark has been optimized away!</p>
<p>We can work around this using the newly stabilized <code>black_box</code> function. Functionally, <code>black_box</code> is not very interesting: it takes the value you pass it and passes it right back. Internally, however, the compiler treats <code>black_box</code> as a function that could do anything with its input and return any value (as its name implies).</p>
<p>This is very useful for disabling optimizations like the one we see above. For example, we can hint to the compiler that the vector will actually be used for something after every iteration of the for loop.</p>
<pre><code class="language-rust">use std::hint::black_box;
fn push_cap(v: &amp;mut Vec&lt;i32&gt;) {
for i in 0..4 {
v.push(i);
black_box(v.as_ptr());
}
}
</code></pre>
<p>Now we can find the unrolled for loop in our <a href="https://rust.godbolt.org/z/Ws1GGbY6Y">optimized assembly output</a>:</p>
<pre><code class="language-asm"> mov dword ptr [rbx], 0
mov qword ptr [rsp + 8], rbx
mov dword ptr [rbx + 4], 1
mov qword ptr [rsp + 8], rbx
mov dword ptr [rbx + 8], 2
mov qword ptr [rsp + 8], rbx
mov dword ptr [rbx + 12], 3
mov qword ptr [rsp + 8], rbx
</code></pre>
<p>You can also see a side effect of calling <code>black_box</code> in this assembly output. The instruction <code>mov qword ptr [rsp + 8], rbx</code> is uselessly repeated after every iteration. This instruction writes the address <code>v.as_ptr()</code> as the first argument of the function, which is never actually called.</p>
<p>Notice that the generated code is not at all concerned with the possibility of allocations introduced by the <code>push</code> call. This is because the compiler is still using the fact that we called <code>Vec::with_capacity(4)</code> in the <code>bench_push</code> function. You can play around with the placement of <code>black_box</code>, or try using it in multiple places, to see its effects on compiler optimizations.</p>
<h3><a href="#cargo-remove" aria-hidden="true" class="anchor" id="cargo-remove"></a>cargo remove</h3>
<p>In Rust 1.62.0 we introduced <code>cargo add</code>, a command line utility to add dependencies to your project. Now you can use <code>cargo remove</code> to remove dependencies.</p>
<h3><a href="#stabilized-apis" aria-hidden="true" class="anchor" id="stabilized-apis"></a>Stabilized APIs</h3>
<ul>
<li><a href="https://doc.rust-lang.org/stable/proc_macro/struct.Span.html#method.source_text"><code>proc_macro::Span::source_text</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.u8.html#method.checked_add_signed"><code>u*::{checked_add_signed, overflowing_add_signed, saturating_add_signed, wrapping_add_signed}</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.i8.html#method.checked_add_unsigned"><code>i*::{checked_add_unsigned, overflowing_add_unsigned, saturating_add_unsigned, wrapping_add_unsigned}</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.i8.html#method.checked_sub_unsigned"><code>i*::{checked_sub_unsigned, overflowing_sub_unsigned, saturating_sub_unsigned, wrapping_sub_unsigned}</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/collections/struct.BTreeSet.html#method.first"><code>BTreeSet::{first, last, pop_first, pop_last}</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/collections/struct.BTreeMap.html#method.first_key_value"><code>BTreeMap::{first_key_value, last_key_value, first_entry, last_entry, pop_first, pop_last}</code></a></li>
<li><a href="https://github.com/rust-lang/rust/pull/101768/">Add <code>AsFd</code> implementations for stdio lock types on WASI.</a></li>
<li><a href="https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#impl-TryFrom%3CVec%3CT%2C%20Global%3E%3E-for-Box%3C%5BT%3B%20N%5D%2C%20Global%3E"><code>impl TryFrom&lt;Vec&lt;T&gt;&gt; for Box&lt;[T; N]&gt;</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/hint/fn.black_box.html"><code>core::hint::black_box</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/time/struct.Duration.html#method.try_from_secs_f32"><code>Duration::try_from_secs_{f32,f64}</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/option/enum.Option.html#method.unzip"><code>Option::unzip</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/os/fd/index.html"><code>std::os::fd</code></a></li>
</ul>
<h3><a href="#other-changes" aria-hidden="true" class="anchor" id="other-changes"></a>Other changes</h3>
<p>There are other changes in the Rust 1.66 release, including:</p>
<ul>
<li>You can now use <code>..=X</code> ranges in patterns.</li>
<li>Linux builds now optimize the rustc frontend and LLVM backend with LTO and BOLT, respectively, improving both runtime performance and memory usage.</li>
</ul>
<p>Check out everything that changed in
<a href="https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1660-2022-12-15">Rust</a>,
<a href="https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-166-2022-12-15">Cargo</a>,
and <a href="https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-166">Clippy</a>.</p>
<h3><a href="#contributors-to-1660" aria-hidden="true" class="anchor" id="contributors-to-1660"></a>Contributors to 1.66.0</h3>
<p>Many people came together to create Rust 1.66.0.
We couldn't have done it without all of you.
<a href="https://thanks.rust-lang.org/rust/1.66.0/">Thanks!</a></p>
</content>
<author>
<name>The Rust Release Team</name>
</author>
</entry>
<entry>
<title>Launching the 2022 State of Rust Survey</title>
<link rel="alternate" href="https://blog.rust-lang.org/2022/12/05/survey-launch.html" type="text/html" title="Launching the 2022 State of Rust Survey" />
<published>2022-12-05T00:00:00+00:00</published>
<updated>2022-12-05T00:00:00+00:00</updated>
<id>https://blog.rust-lang.org/2022/12/05/survey-launch.html</id>
<content type="html" xml:base="https://blog.rust-lang.org/2022/12/05/survey-launch.html"><p>The <a href="https://surveyhero.com/c/sfhmgxgd">2022 State of Rust Survey</a> is here!</p>
<p>It's that time again! Time for us to take a look at who the Rust community is composed of, how the Rust project is doing, and how we can improve the Rust programming experience. The Rust Survey working group is pleased to announce our <a href="https://surveyhero.com/c/sfhmgxgd">2022 State of Rust Survey</a>! Whether or not you use Rust today, we want to know your opinions. Your responses will help the project understand its strengths and weaknesses, and establish development priorities for the future.</p>
<p>Completing this survey should take about 5–20 minutes and is anonymous. We will be accepting submissions for the next two weeks (until the 19th of December), and we will share our findings on <a href="https://blog.rust-lang.org">blog.rust-lang.org</a> sometime in early 2023. You can also check out <a href="https://blog.rust-lang.org/2022/02/15/Rust-Survey-2021.html">last year’s results</a>.</p>
<p>We're happy to be offering the survey in the following languages. If you speak multiple languages, please pick one.</p>
<ul>
<li><a href="https://surveyhero.com/c/sfhmgxgd?lang=en">English</a></li>
<li><a href="https://surveyhero.com/c/sfhmgxgd?lang=zh-cn">Simplified Chinese</a></li>
<li><a href="https://surveyhero.com/c/sfhmgxgd?lang=zh-tw">Traditional Chinese</a></li>
<li><a href="https://surveyhero.com/c/sfhmgxgd?lang=fr">French</a></li>
<li><a href="https://surveyhero.com/c/sfhmgxgd?lang=de">German</a></li>
<li><a href="https://surveyhero.com/c/sfhmgxgd?lang=ja">Japanese</a></li>
<li><a href="https://surveyhero.com/c/sfhmgxgd?lang=ko">Korean</a></li>
<li><a href="https://surveyhero.com/c/sfhmgxgd?lang=pt">Portuguese</a></li>
<li><a href="https://surveyhero.com/c/sfhmgxgd?lang=ru">Russian</a></li>
<li><a href="https://surveyhero.com/c/sfhmgxgd?lang=es">Spanish</a></li>
<li><a href="https://surveyhero.com/c/sfhmgxgd?lang=uk">Ukrainian</a></li>
</ul>
<p>Please help us spread the word by sharing the survey link on your social network feeds, at meetups, around your office, and in other communities.</p>
<p>If you have any questions, please see our <a href="https://github.com/rust-lang/surveys/blob/main/documents/Community-Survey-FAQ.md">frequently asked questions</a>.</p>
<p>Finally, we wanted to thank everyone who helped develop, polish, and test the survey.</p>
</content>
<author>
<name>The Rust Survey Working Group</name>
</author>
</entry>
<entry>
<title>Announcing Rust 1.65.0</title>
<link rel="alternate" href="https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html" type="text/html" title="Announcing Rust 1.65.0" />
<published>2022-11-03T00:00:00+00:00</published>
<updated>2022-11-03T00:00:00+00:00</updated>
<id>https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html</id>
<content type="html" xml:base="https://blog.rust-lang.org/2022/11/03/Rust-1.65.0.html"><p>The Rust team is happy to announce a new version of Rust, 1.65.0. Rust is a
programming language empowering everyone to build reliable and efficient
software.</p>
<hr />
<p>Before going into the details of the new Rust release, we'd like to draw
attention to the tragic <a href="https://en.wikipedia.org/wiki/Death_of_Mahsa_Amini">death of Mahsa
Amini</a> and the death and
violent suppression of many others, by the religious morality police of Iran.
See <a href="https://en.wikipedia.org/wiki/Mahsa_Amini_protests">https://en.wikipedia.org/wiki/Mahsa_Amini_protests</a> for more details. We
stand in solidarity with the people in Iran struggling for human rights.</p>
<hr />
<p>If you have a previous version of Rust installed via rustup, you can get 1.65.0
with:</p>
<pre><code class="language-console">rustup update stable
</code></pre>
<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://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1650-2022-11-03">detailed release notes for
1.65.0</a>
on GitHub.</p>
<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>
<h2><a href="#whats-in-1650-stable" aria-hidden="true" class="anchor" id="whats-in-1650-stable"></a>What's in 1.65.0 stable</h2>
<h3><a href="#generic-associated-types-gats" aria-hidden="true" class="anchor" id="generic-associated-types-gats"></a>Generic associated types (GATs)</h3>
<p>Lifetime, type, and const generics can now be defined on associated types, like so:</p>
<pre><code class="language-rust">trait Foo {
type Bar&lt;'x&gt;;
}
</code></pre>
<p>It's hard to put into few words just how useful these can be, so here are a
few example traits, to get a sense of their power:</p>
<pre><code class="language-rust">/// An `Iterator`-like trait that can borrow from `Self`
trait LendingIterator {
type Item&lt;'a&gt; where Self: 'a;
fn next&lt;'a&gt;(&amp;'a mut self) -&gt; Option&lt;Self::Item&lt;'a&gt;&gt;;
}
/// Can be implemented over smart pointers, like `Rc` or `Arc`,
/// in order to allow being generic over the pointer type
trait PointerFamily {
type Pointer&lt;T&gt;: Deref&lt;Target = T&gt;;
fn new&lt;T&gt;(value: T) -&gt; Self::Pointer&lt;T&gt;;
}
/// Allows borrowing an array of items. Useful for
/// `NdArray`-like types that don't necessarily store
/// data contiguously.
trait BorrowArray&lt;T&gt; {
type Array&lt;'x, const N: usize&gt; where Self: 'x;
fn borrow_array&lt;'a, const N: usize&gt;(&amp;'a self) -&gt; Self::Array&lt;'a, N&gt;;
}
</code></pre>
<p>As you can see, GATs are quite versatile and enable a number
of patterns that are not currently able to be written. For more
information, check out the post announcing the
<a href="https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html">push for stabilization</a>
published last year or the
<a href="https://blog.rust-lang.org/2022/10/28/gats-stabilization.html">stabilization announcement post</a>
published last week. The former goes into a bit more depth
of a couple of the examples above, while the latter talks
about some of the known limitations of this stabilization.</p>
<p>More in depth reading can be found in the associated types
section of the <a href="https://doc.rust-lang.org/nightly/reference/items/associated-items.html#associated-types">nightly reference</a>
or the <a href="https://rust-lang.github.io/rfcs/1598-generic_associated_types.html">original RFC</a> (which was initially opened over 6.5 years ago!).</p>
<h3><a href="#let-else-statements" aria-hidden="true" class="anchor" id="let-else-statements"></a><code>let</code>-<code>else</code> statements</h3>
<p>This introduces a new type of <code>let</code> statement with a refutable pattern and a
diverging <code>else</code> block that executes when that pattern doesn't match.</p>
<pre><code>let PATTERN: TYPE = EXPRESSION else {
DIVERGING_CODE;
};
</code></pre>
<p>Normal <code>let</code> statements can only use <em>irrefutable</em> patterns, statically known
to always match. That pattern is often just a single variable binding, but may
also unpack compound types like structs, tuples, and arrays. However, that was
not usable for conditional matches, like pulling out a variant of an enum --
until now! With <code>let</code>-<code>else</code>, a refutable pattern can match and bind variables
in the surrounding scope like a normal <code>let</code>, or else diverge (e.g. <code>break</code>,
<code>return</code>, <code>panic!</code>) when the pattern doesn't match.</p>
<pre><code class="language-rust">fn get_count_item(s: &amp;str) -&gt; (u64, &amp;str) {
let mut it = s.split(' ');
let (Some(count_str), Some(item)) = (it.next(), it.next()) else {
panic!(&quot;Can't segment count item pair: '{s}'&quot;);
};
let Ok(count) = u64::from_str(count_str) else {
panic!(&quot;Can't parse integer: '{count_str}'&quot;);
};
(count, item)
}
assert_eq!(get_count_item(&quot;3 chairs&quot;), (3, &quot;chairs&quot;));
</code></pre>
<p>The scope of name bindings is the main thing that makes this different from
<code>match</code> or <code>if let</code>-<code>else</code> expressions. You could previously approximate these
patterns with an unfortunate bit of repetition and an outer <code>let</code>:</p>
<pre><code class="language-rust"> let (count_str, item) = match (it.next(), it.next()) {
(Some(count_str), Some(item)) =&gt; (count_str, item),
_ =&gt; panic!(&quot;Can't segment count item pair: '{s}'&quot;),
};
let count = if let Ok(count) = u64::from_str(count_str) {
count
} else {
panic!(&quot;Can't parse integer: '{count_str}'&quot;);
};
</code></pre>
<h3><a href="#break-from-labeled-blocks" aria-hidden="true" class="anchor" id="break-from-labeled-blocks"></a><code>break</code> from labeled blocks</h3>
<p>Plain block expressions can now be labeled as a <code>break</code> target, terminating
that block early. This may sound a little like a <code>goto</code> statement, but it's not
an arbitrary jump, only from within a block to its end. This was already
possible with <code>loop</code> blocks, and you may have seen people write loops that
always execute only once, just to get a labeled <code>break</code>.</p>
<p>Now there's a language feature specifically for that! Labeled <code>break</code> may also
include an expression value, just as with loops, letting a multi-statement
block have an early &quot;return&quot; value.</p>
<pre><code class="language-rust">let result = 'block: {
do_thing();
if condition_not_met() {
break 'block 1;
}
do_next_thing();
if condition_not_met() {
break 'block 2;
}
do_last_thing();
3
};
</code></pre>
<h3><a href="#splitting-linux-debuginfo" aria-hidden="true" class="anchor" id="splitting-linux-debuginfo"></a>Splitting Linux debuginfo</h3>
<p>Back in Rust 1.51, the compiler team added support for <a href="https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#splitting-debug-information">split debug
information</a>
on macOS, and now this option is stable for use on Linux as well.</p>
<ul>
<li><code>-Csplit-debuginfo=unpacked</code> will split debuginfo out into multiple <code>.dwo</code>
DWARF object files.</li>
<li><code>-Csplit-debuginfo=packed</code> will produce a single <code>.dwp</code> DWARF package
alongside your output binary with all the debuginfo packaged together.</li>
<li><code>-Csplit-debuginfo=off</code> is still the default behavior, which includes DWARF
data in <code>.debug_*</code> ELF sections of the objects and final binary.</li>
</ul>
<p>Split DWARF lets the linker avoid processing the debuginfo (because it isn't in
the object files being linked anymore), which can speed up link times!</p>
<p>Other targets now also accept <code>-Csplit-debuginfo</code> as a stable option with their
platform-specific default value, but specifying other values is still unstable.</p>
<h3><a href="#stabilized-apis" aria-hidden="true" class="anchor" id="stabilized-apis"></a>Stabilized APIs</h3>
<p>The following methods and trait implementations are now stabilized:</p>
<ul>
<li><a href="https://doc.rust-lang.org/stable/std/backtrace/struct.Backtrace.html"><code>std::backtrace::Backtrace</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/ops/enum.Bound.html#method.as_ref"><code>Bound::as_ref</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/io/fn.read_to_string.html"><code>std::io::read_to_string</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.cast_mut"><code>&lt;*const T&gt;::cast_mut</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.cast_const"><code>&lt;*mut T&gt;::cast_const</code></a></li>
</ul>
<p>Of particular note, the <code>Backtrace</code> API allows capturing a stack backtrace at
any time, using the same platform-specific implementation that usually serves
panic backtraces. This may be useful for adding runtime context to error types,
for example.</p>
<p>These APIs are now usable in const contexts:</p>
<ul>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.offset_from"><code>&lt;*const T&gt;::offset_from</code></a></li>
<li><a href="https://doc.rust-lang.org/stable/std/primitive.pointer.html#method.offset_from"><code>&lt;*mut T&gt;::offset_from</code></a></li>
</ul>
<h3><a href="#compatibility-notes" aria-hidden="true" class="anchor" id="compatibility-notes"></a>Compatibility notes</h3>
<ul>
<li>As the final step of the <a href="https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html">RLS
deprecation</a>,
this release has replaced RLS with a small LSP server showing a deprecation
warning, advising users to migrate to <code>rust-analyzer</code>.</li>
</ul>
<h3><a href="#other-changes" aria-hidden="true" class="anchor" id="other-changes"></a>Other changes</h3>
<p>There are other changes in the Rust 1.65 release, including:</p>
<ul>
<li>MIR inlining is now enabled for optimized compilations. This provides a 3-10%
improvement in compiletimes for real world crates.</li>
<li>When scheduling builds, Cargo now sorts the queue of pending jobs to improve performance.</li>
</ul>
<p>Check out everything that changed in
<a href="https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1650-2022-11-03">Rust</a>,
<a href="https://github.com/rust-lang/cargo/blob/master/CHANGELOG.md#cargo-165-2022-11-03">Cargo</a>,
and <a href="https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-165">Clippy</a>.</p>
<h3><a href="#contributors-to-1650" aria-hidden="true" class="anchor" id="contributors-to-1650"></a>Contributors to 1.65.0</h3>
<p>Many people came together to create Rust 1.65.0.
We couldn't have done it without all of you.
<a href="https://thanks.rust-lang.org/rust/1.65.0/">Thanks!</a></p>
</content>
<author>
<name>The Rust Release Team</name>
</author>
</entry>
</feed>