rust/compiler/rustc_errors/src, branch 1.82.0https://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=1.82.02024-08-27T02:03:37+00:00Add `warn(unreachable_pub)` to `rustc_errors`.2024-08-27T02:03:37+00:00Nicholas Nethercoten.nethercote@gmail.com2024-08-27T02:03:37+00:00urn:sha1:5fd503ab445b2a70897026e495dd4df4343333ebFix `elided_named_lifetimes` in code2024-08-24T16:21:32+00:00Pavel GrigorenkoGrigorenkoPV@ya.ru2024-08-22T22:12:57+00:00urn:sha1:53ce92770d0b1005cfc07cc8f14011339e2abc26Update annotate-snippets to 0.112024-08-19T20:22:07+00:00Xiretzaxiretza@xiretza.xyz2024-08-19T20:20:48+00:00urn:sha1:c864238baf2d44e1634c754451d69e66ef56201bAdd `|` to make the html doc of `Level` rendered correctly2024-08-14T05:38:03+00:00Jaic1506933131@qq.com2024-08-14T05:38:03+00:00urn:sha1:8557b56ec7ed3b9d94d0fcbbec97547ffb45e568Rollup merge of #128978 - compiler-errors:assert-matches, r=jieyouxu2024-08-12T15:09:19+00:00Guillaume Gomezguillaume1.gomez@gmail.com2024-08-12T15:09:19+00:00urn:sha1:7c6dca90509fe94e775bfd5d2c7132fb210f57b4
Use `assert_matches` around the compiler more
It's a useful assertion, especially since it actually prints out the LHS.
Use assert_matches around the compiler2024-08-11T16:25:39+00:00Michael Gouletmichael@errs.io2024-08-11T16:10:36+00:00urn:sha1:c361c924a08c2e34c705ec3ee1ad2099315338d8Rollup merge of #128762 - fmease:use-more-slice-pats, r=compiler-errors2024-08-11T05:51:51+00:00Matthias Krügermatthias.krueger@famsik.de2024-08-11T05:51:51+00:00urn:sha1:32e0fe129d495d3d4dacdcd066d9e339534a8338
Use more slice patterns inside the compiler
Nothing super noteworthy. Just replacing the common 'fragile' pattern of "length check followed by indexing or unwrap" with slice patterns for legibility and 'robustness'.
r? ghost
Update std and compiler2024-08-10T10:07:17+00:00Nadrierilnadrieril+git@gmail.com2024-03-20T18:49:20+00:00urn:sha1:c256de2253315d4668c417291b9ea5115b49667cRollup merge of #128852 - folkertdev:multipart-suggestion-stable-sort, r=compiler-errors2024-08-09T16:24:58+00:00Matthias Krügermatthias.krueger@famsik.de2024-08-09T16:24:58+00:00urn:sha1:2066002b86062d57771f1c0f63871d825f4f201c
use stable sort to sort multipart diagnostics
I think a stable sort should be used to sort the different parts of a multipart selection. The current unstable sort uses the text of the suggestion as a tie-breaker. That just doesn't seem right, and the order of the input is a better choice I think, because it gives the diagnostic author more control.
This came up when I was building a suggestion where
```rust
fn foo() {}
```
must be turned into an unsafe function, and an attribute must be added
```rust
#[target_feature(enable = "...")]
unsafe fn foo() {}
```
In this example, the two suggestions occur at the same position, but the order is extremely important: unsafe must come after the attribute. But the situation changes if there is a pub/pub(crate), and if the unsafe is already present. It just out that because of the suggestion text, there is no way for me to order the suggestions correctly.
This change probably should be tested, but are there tests of the diagnostics code itself in the tests?
r? ```@estebank```
use stable sort to sort multipart diagnostics2024-08-09T07:45:01+00:00Folkertfolkert@folkertdev.nl2024-08-08T21:55:59+00:00urn:sha1:38874a692738f23b17d20a81bb906701303c0474