Rustc pull update#2156
Merged
Merged
Conversation
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@68ffae4 Filtered ref: rust-lang/compiler-builtins@7602939 Upstream diff: rust-lang/rust@d0442e2...68ffae4 This merge was created using https://github.com/rust-lang/josh-sync.
…=JonathanBrouwer Move tests array slice vec r? @Kivooeo Hi, some tests that belong in the array-slice-vec folder
std: implement `clear` via `truncate` This gets rid of some `unsafe`. `truncate(0)` is even documented to be equivalent to `clear`, this makes that equivalence even more obvious.
Remove windows-sys from the library workspace Windows-sys isn't actually used as dlmalloc doesn't use it on any of the targets where std uses dlmalloc, but still ends up in the lockfile and thus gets vendored. By using a patch to replace it with an empty crate the vendor size of the standard library is reduced from 93MB to 20MB.
Add rlib digest to identify Rust object files This adds a metadata entry to `rlib` archives that lists which members are Rust object files instead of relying on the filename heuristic in `looks_like_rust_object.file`. I also added a fallback to the old behavior for `rlibs` built by older compilers. Part of rust-lang/rust#138243.
…rtdev stdarch subtree update Subtree update of `stdarch` to 6b174ad. Created using https://github.com/rust-lang/josh-sync. r? @ghost
Don't return dummy MacroData in `get_macro` I was experimenting with tool attributes and ast manipulation, and wasted some time figuring out that this was happening. AFAIK all users of `get_macro` are expecting an actual macro (and none were reading the dummy MacroData) so there should be no change in behavior.
…=wesleywiser tests/ui: allow spaces in hashbrown src normalization If one's home directory contains a space, the default location for the hashbrown source location also contains a space, and so the UI test normalization in issue-21763 fails to normalize as expected. While this new regex does not handle all valid paths, such as those beginning with `\\?\` or `\\name\`, this handles most absolute UNIX and Windows paths. Relative paths don't seem to be applicable.
…uwer Rollup of 3 pull requests Successful merges: - rust-lang/rust#156251 (stdarch subtree update) - rust-lang/rust#156151 (Don't return dummy MacroData in `get_macro`) - rust-lang/rust#156211 (tests/ui: allow spaces in hashbrown src normalization)
…ottmcm,saethlin change the type of the argument of `drop_in_place` lang item to `&mut _` We used to special case `core::ptr::drop_in_place` when computing LLVM argument attributes with this hack: https://github.com/rust-lang/rust/blob/db5e2dc248fe5bb26f70d7baec46a3bca9fa3e1d/compiler/rustc_ty_utils/src/abi.rs#L383-L392 This is because even though `drop_in_place` takes a `*mut T` it is semantically a `&mut T` (remember how `&mut Self` is passed to `Drop::drop`). This is apparently relevant for perf. This PR replaces this hack with a simpler solution -- it makes `drop_in_place` a thin wrapper around newly added `core::ptr::drop_glue`, which is the actual lang item and takes a `&mut T`: https://github.com/rust-lang/rust/blob/d2563d5003bbecff1efc40c1f5673ceec603825b/library/core/src/ptr/mod.rs#L810-L833 ------ The rest of the PR is blessing tests and cleaning up things which are not necessary after this change. One thing that is a bit awkward is that now that `drop_glue` is the actual lang item, a lot of the comments referring to `drop_in_place` are outdated. Should I try fixing that? I've also changed `async_drop_in_place` to take a `&mut T`, and it simplified the code handling it a bit. (since it's unstable we don't need to introduce a wrapper) ------- cc @RalfJung Closes rust-lang/rust#154274
…nszelmann Lint unused pub items in binary crates ~~This PR adds a new unstable flag -Ztreat-pub-as-pub-crate as [@Kobzol](https://github.com/Kobzol) suggested.~~ ~~When compiling binary crates with this flag, the seed worklist will only contain the entry fn and won't contain other reachable items. Then we can do the dead code analysis for pub items just like they are pub(crate).~~ Related zulip thread [#general > pub/pub(crate) within a binary is a footgun](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/pub.2Fpub.28crate.29.20within.20a.20binary.20is.20a.20footgun/with/558931034). --- Updated: Adds a new lint `unused_pub_items_in_binary` (crate-level, default allow for now) instead of the previous unstable flag to lint unused `pub` items for binary crates. See more details of implementation in rust-lang/rust#149509 (comment). This lint is allowed by default, but I believe this has been better than the unstable flag. Making it warn-by-default will lead to a lot of noise for this PR (like bless many tests). So I'd like to make it warn-by-default in a separate PR in the future.
Reorg tests 03 | old-name | new-sub-dir | new-name | |-|-|-| | `issue-38727.rs` [issue](rust-lang/rust#38727) | `abi/` | `return-ref-as-immediate-in-codegen.rs` | | `issue-38437.rs` [issue](rust-lang/rust#38437) | `mir/` | `reset-discriminant-drop-flag-on-partial-move.rs` | | `issue-31910.rs` [issue](rust-lang/rust#31910) | `associated-consts/` | `associated-const-in-enum-discriminant.rs` | | `issue-31910.stderr` | `associated-consts/` | `associated-const-in-enum-discriminant.stderr` | | `issue-48159.rs` [issue](rust-lang/rust#48159) | `packed/` | `packed-c-style-struct.rs` | r? Kivooeo
…imulacrum `BufWriter`: Make the soundness of `BorrowedBuf` usage clearer. The previous safety comment was outdated as it was written before `BorrowedBuf::set_init` was changed to be a boolean. It also failed to address the possibility that `flush_buf` invalidated the assumption.
Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint This is an extension to rust-lang/rust#147382. With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used. For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break. The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent. Fixes rust-lang/rust#65861
remove forever-deprecated and hidden `f64` methods The methods `f64::is_positive` and `f64::is_negative` were deprecated since 1.0 and marked as `#[doc(hidden)]` in favor of `f64::is_sign_positive` and `f64::is_sign_negative`. They also only exist on `f64`, not on `f32`. But for some unknown reason, they have been marked as stable. This PR proposes to remove both methods as they were never a part of the documented API, assuming that a crater run finds no significant breakage.
map_try_insert changes Made changes according to rust-lang/rust#82766 (comment). r? @tgross35
Clarify UTF-16 decoding errors Fix UTF-16 error messages as suggested in rust-lang/rust#116258.
stdarch subtree update Subtree update of `stdarch` to bb24cbd. Created using https://github.com/rust-lang/josh-sync. r? @ghost
…c_equal_alignment, r=Urgau stabilize `feature(cfg_target_has_atomic_equal_alignment)` See stabilization report: rust-lang/rust#93822 (comment) cc @joshtriplett
Implement `OsStr::split_at` See rust-lang/rust#156199 This allows splitting only on valid UTF-8 boundaries, regardless of the platform, which avoids cross-platform landmines.
Allow `global_asm!` in statement positions
This PR makes it possible to put `global_asm!` in statement positions. This is particularly useful for proc-macros, where you otherwise have to wrap them in `mod foo { global_asm!(...); }`.
I'm happy to open an ACP first (or a design meeting?).
I would also assume this needs sign-off from the lang-team?
Previously discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/216763-project-inline-asm/topic/Item.20position.20global_asm/with/581784943).
r? @Amanieu
Remove `UncheckedIterator`
The only remaining usage of `UncheckedIterator` was in `array::{try_,}from_trusted_iterator`. So, replace `array::repeat` and array's `Clone` impl with a manual `from_fn` call rather than going through unnecessary abstractions, and remove the `UncheckedIterator` trait.
…pl-Copy, r=clarfonthey Derives `Copy` for `ffi::FromBytesUntilNulError` [`ffi::FromBytesWithNulError` derives `Copy` since Rust 1.93](rust-lang/rust@2f5a3d4) while `ffi::FromBytesUntilNulError` doesn't. This Pr fixes that by deriving `Copy` for `ffi::FromBytesUntilNulError`. I encountered this issue while I was working in a const context. Note: I couldn't find any documentation about what kind of PR is allowed. As this one is very small, I guess it is ok to submit it directly without opening an issue first?
Fix invalid suggestion for parenthesized break Resolves rust-lang/rust#156383 The old code incorrectly assumed `e.span` started exactly at the beginning of `break`. Fixed by locating the exact start position of `break`.
Add pext/pdep as aliases for extract_bits/deposit_bits So that the methods will be found when searching for the corresponding intrinsics. Tracking issue for `extract_bits`/`deposit_bits`: rust-lang/rust#149069
Replace `println!` with `assert!` in HashMap documentation examples ## Changes - **`.keys()`** - **`.values()`** - **`.values_mut()`** - **`.iter()`** - **`.iter_mut()`**
Widen the result of `widening_mul`. Tracking issue: rust-lang/rust#152016 This PR implements <rust-lang/rust#152016 (comment)>, which mandates that `widening_mul` return a single, scalar value rather than a low/high tuple. Consequently, this method is removed from `u128` and `i128` as they are the widest integral types. It has also been removed from `usize` and `isize` due to portability concerns. Existing `widening_mul` usage has been replaced by equivalent calls to `carrying_mul` (which is logically identical to the old behaviour.) Existing – generic – non-doc tests have been removed. # Public API ```rust impl u8 { pub const fn widening_mul(self, rhs: Self) -> u16; } impl u16 { pub const fn widening_mul(self, rhs: Self) -> u32; } impl u32 { pub const fn widening_mul(self, rhs: Self) -> u64; } impl u64 { pub const fn widening_mul(self, rhs: Self) -> u128; } impl i8 { pub const fn widening_mul(self, rhs: Self) -> i16; } impl i16 { pub const fn widening_mul(self, rhs: Self) -> i32; } impl i32 { pub const fn widening_mul(self, rhs: Self) -> i64; } impl i64 { pub const fn widening_mul(self, rhs: Self) -> i128; } ```
Update `sysinfo` version to `0.39.2` Bugfixes and performance improvements.
…tems, r=mejrs Add diagnostic items for IoBufReader and StdinLock Added two new diagnostic items for IoBufReader and StdinLock.
reduce usage of `box_patterns` in tests Part of rust-lang/rust#156110.
Add infallible primitive type lookups to template arg resolver
Fixes a regression that seem to come from LLDB 22 where looking up primitive types by name on MSVC no longer works. Container types use type name lookups to resolve generics, so it causes container types (e.g. `Vec<i32>`) to fail to create their child values.
Before:
```
(lldb) v vec_v
(alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {}
(lldb) v vec_v[0]
error: <user expression 0>:1:6: array index 0 is not valid for "(Vec<i32,alloc::alloc::Global>) vec_v"
1 | vec_v[0]
| ^
```
After:
```
(lldb) v vec_v
(alloc::vec::Vec<i32,alloc::alloc::Global>) vec_v = size=5 {
[0] = 10
[1] = 20
[2] = 30
[3] = 40
[4] = 50
}
(lldb) v vec_v[0]
(long) vec_v[0] = 10
```
This patch maps the type name to its `eBasicType` equivalent (i.e. the LLDB enum for primitive types) and looks up the type based on that. AFAIK, `eBasicType` lookups are 100% infallible. Even if the primitive type somehow isn't in the debug info, `TypeSystemClang` will invent the appropriate `SBType` object for it.
This isn't a major blocker for the test suite rework, but it does prevent me from blessing tests with container types on MSVC unless I downgrade to LLDB 21.
r? @jieyouxu, @Kobzol
…up, r=GuillaumeGomez Cleanup and optimize `render_impls` - take ownership of the `Vec<&Impl>` instead of copying into another alloc - reuse `ImplString` to do natural sort ordering - lazy formatting Somewhat of a follow-up to rust-lang/rust#157233 and rust-lang/rust#157179 (cc @nnethercote - thanks!) This kinda undoes rust-lang/rust@f7c8bc2 but IMHO it makes more sense to be explicit about negative impl ordering, and also seems kinda wasteful to "render" the negativity into a string and rely on however ASCII decided to order characters. I can also undo this part, I think this PR is still a positive change even without it. r? @GuillaumeGomez LLM disclosure: I used LLM for reviewing my changes and making sure some assumptions I was making were correct (i.e. that `render_impls` will not render anything IFF the list of traits passed to it is empty)
Couple of work product cleanups Part of rust-lang/compiler-team#908
Reorganize `tests/ui/issues` [5/N] Part of [GSoC'26 project](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Reorganizing.20tests.2Fui.2Fissues) r? Kivooeo @Teapot4195
Syntactically reject equality predicates ### Background (History) Equality predicates have been *syntactically* valid since PR rust-lang/rust#39158 / nightly-2017-02-02 / 1.16 (released 2017-03-16, 9 years ago), both forms that is: `$ty = $ty` *and* `$ty == $ty`. They're not registered as an unstable feature despite having a tracking issue (rust-lang/rust#20041). Naturally, they don't have a feature gate. Of course, we reject them post-expansion, so they are still semantically invalid. Parser scaffolding for `$ident = $ty` was added in RUST-19391 (2014) which was then generalized to `$ty = $ty` in RUST-20002 (2014) and extended to additionally cover `$ty == $ty` in RUST-39158 (2017). As mentioned, the last PR also made them grammatical. RUST-87471 (2021) attempted to start impl'ing typeck'ing but it was closed due to concerns: rust-lang/rust#87471 (comment) (already back in 2017 there were concerns: https://github.com/rust-lang/rust/pull/39158/changes#r97811244). In 2022, T-lang discussed this feature during a meeting and raised concerns: rust-lang/rust#20041 (comment). However, they were inclined to accept a restricted form, namely `T::AssocTy = $ty` (`T` is a (self) ty param or a self ty alias) and `<$ty as Trait>::AssocTy = $ty` since that's trivial to support in HIR ty lowering (this is still accurate). ### Change This renders equality predicates `$ty = $ty` and `$ty == $ty` syntactically invalid again. On stable, they're merely semantically invalid. This is motivated by the fact that 1. their syntax isn't even decided upon 1. should it be `=` or `==`? 2. should the LHS be syntactically restricted to (possibly qualified) paths (i.e., *TypePath | QualifiedPathInType*), only semantically or not at all? * "syntactically" could indeed make sense since we might want to generalize types to so-called *terms* here (i.e., *Type | GenericArgsConst*) for [mGCA](rust-lang/rust#132980) but we can't generalize `$ty = $ty` to `$term = $term` due to ambiguities [^1] that would require backtracking whereas `$typepath = $term` wouldn't have that problem 2. we might (decide to) never impl this feature * after all, implementation concerns were raised as early as 9 years ago which are still relevant today even with the next-gen trait solver on the horizon 3. the compiler + tools contain a bunch of code for dealing with these predicates * like lowering, name resolution, rustfmt and Clippy * that's entirely useless since they get unconditionally rejected anyway * this code doesn't need to exist (for now) I've merely upgraded the semantic hard error to a syntactic hard error, I've intentionally not introduced an unstable feature under which equality predicates become legal. That's because a hard error is easier to push through procedurally, it's an important first step (we can always turn it into a feature gate error later on) and since this potential feature isn't backed by any official lang experiment. I don't consider T-lang's message rust-lang/rust#20041 (comment) from 2022 to be sufficient because it doesn't answer questions like (1.i), (1.ii) or whether code like `T: Trait<A>, <T as Trait<B>>::AssocTy = Ty` (`A` ≠ `B`) or `T: Trait<'r>, for<'a> <T as Trait<'a>>::AssocTy = Ty` should be legal (which would be more powerful / could lead to typechecking issues, idk) or not assuming we're going with the restricted form ofc (we would need input from T-types). ### Lang nomination rust-lang/rust#153513 (comment) [^1]: Code like `fn f() -> i32 where { 0 }` is intentionally legal today but if we had `$term = $term` the `{ 0 }` could then also be the start of an equality predicate like `{ 0 } = 0`.
LineWriter: cap write_vectored newline scan to avoid quadratic write_all_vectored This also adds some test coverage to confirm LineWriter behaves as expected under some edge cases.
…diagnostic, r=BoxyUwU macros: report unbound metavariables directly Fixes rust-lang/rust#95943. When a macro expansion contains an unbound `$ident`, report it as a missing macro parameter instead of keeping the generic fragment parser error as the primary diagnostic. This keeps the existing typo suggestions and available-metavariable notes.
…le-toggle-unstable, r=RalfJung riscv: promote d, e, and f target_features to CfgStableToggleUnstable Reference PR: - rust-lang/reference#2274 This PR is a continuation of rust-lang/rust#155962 It uses the new `CfgStableToggleUnstable` stability level for the `"d"`, `"e"`, and `"f"` `target_features` of RISC-V. This way, it will be possible to add conditional code blocks depending on whether the target architecture has FPU, for instance. The PR is related to rust-lang/rust#150257 r? @RalfJung
Clarify meaning of ranges in pointer offset docs Supersedes rust-lang/rust#154370
…rk-Simulacrum Document equivalence of `highest_one` and `ilog2` methods on integers Add notes to the primitive integer and `NonZero` types clarifying the equivalence between `highest_one` and the `ilog2`/`checked_ilog2` methods for non-negative values. Tracking issue: rust-lang/rust#145203
…acrum ci: update download-artifact action to v8 Closes rust-lang/rust#154738 (comment)
triagebot: Update messages to direct changes to appropriate repositories Follow-up rust-lang/rust#154465 Regularize messages that reference repository-specific changes, directing contributors to the appropriate repositories.
Document Repeat::last panic behavior Fixes rust-lang/rust#149707 Documents that `Repeat::last` always panics because `Repeat` is infinite. Tests: - `./x fmt --check` - `./x doc library/core` - `./x test library/core`
…Mark-Simulacrum Clarify MaybeUninit::zeroed padding docs Closes rust-lang/rust#111608. This clarifies that padding bytes in `MaybeUninit::zeroed()` are not guaranteed to remain zeroed when the `MaybeUninit<T>` value is returned, matching the existing `mem::zeroed` documentation that padding is not necessarily zeroed. Verification: - `git diff --check` - `./x fmt --check` - `./x test tidy` - `./x test library/core --doc`
…crum Silence llbc's output by default to prevent rustc's linker output warning rust-lang/rust#153968 recently made visible that the llvm-bitcode-linker (llbc) always emits messages to stdout even when linking successfully. Additionally, these messages use ANSI escape sequences for coloring, which don't get rendered correctly. This patch fixes both. - It silences llbc's output by default and adds a verbosity command line argument to it (`-v` for verbose and `-vv` for very verbose, which can be added by using rustc's `-Clink-arg=` argument). - It also removes the ANSI escape sequences and makes the output more linker-like (by removing timestamps, tracing-level, tracing-target). cc: @kjetilkjeka @rustbot label +L-linker_messages +O-NVPTX
Improve documentation of `align_of` and `Alignment`. * The documentation for `align_of_val()` and `Alignment::of_val()` did not explain its use in interacting with `dyn` types, and even contained the false statement that “Every reference to a value of the type `T` must be a multiple of this number”. This change removes that statement from everything except `align_of()`, and adds a mention of, and example code for, getting the alignment of a `dyn` value. * The documentation for `align_of_val_raw()` did not explain how it relates to other functions in the family. Now it does. * Added a caveat that the alignment of `i32` is not always 4, despite the examples asserting this. @rustbot label A-docs
Suggest using comma to separate valid attribute list items If the parser encounters a missing comma in an attribute arg list and the next item is valid, suggest adding the comma. For example: ``` error: attribute items not separated with `,` --> $DIR/expected-comma-found-token.rs:7:26 | LL | message="the message" | ^ help: try adding `,` here ```
chore: Update annotate-snippets to 0.12.16 This PR updates `annotate-snippets` to [`0.12.16`](https://github.com/rust-lang/annotate-snippets-rs/blob/main/CHANGELOG.md#01216---2026-05-06) which fixes highlighting for indented code: rust-lang/annotate-snippets-rs#405 Also fixes rust-lang/rust#155873 (the same problem)
In `copy_nonoverlapping`, use `mul nuw nsw` to compute the byte size Seems like we might as well? Adding these flags means the optimizer can tell the limited range on the count of items -- like how we use these flags (rust-lang/rust#136575) when calculating `size_of_val` for a slice. Today we use a wrapping multiplication, which mean that `copy_nonoverlapping::<u32>(src, dst, 0x40000000_00000001)` appears like 4 bytes -- a perfectly reasonable size! -- once it gets to the `memcpy` call. If I'm understanding <https://doc.rust-lang.org/std/ptr/fn.copy_nonoverlapping.html#safety> properly, this is just exploiting existing UB, since `src` and `dst` must each be inside an allocation, and those allocations can be at most `isize::MAX` bytes. (Plus, fundamentally, to be non-overlapping there's not enough space in the address space to be bigger than `isize::MAX`.) cc @RalfJung to make sure this is ok, as requested last he found out I was newly exploiting some UB in codegen 🙃 r? codegen
…olkertdev Importing suggestion reported twice when reporting privacy error cc rust-lang/rust#157454 This is a first fix proposal
Test fixup Follow up to rust-lang/rust#157438. r? @GuillaumeGomez
Rollup of 25 pull requests Successful merges: - rust-lang/rust#157447 (Move cross crate tests into the appropriate folder) - rust-lang/rust#145108 (Resolver: Batched Import Resolution) - rust-lang/rust#156119 (Further optimize `SliceIndex<str>` impl for `Range<usize>`) - rust-lang/rust#157224 (Manually unroll loop in `str::floor_char_boundary`) - rust-lang/rust#157289 (Add infallible primitive type lookups to template arg resolver) - rust-lang/rust#157540 (Cleanup and optimize `render_impls`) - rust-lang/rust#157444 (Couple of work product cleanups) - rust-lang/rust#157543 (Reorganize `tests/ui/issues` [5/N]) - rust-lang/rust#153513 (Syntactically reject equality predicates) - rust-lang/rust#155797 (LineWriter: cap write_vectored newline scan to avoid quadratic write_all_vectored) - rust-lang/rust#156155 (macros: report unbound metavariables directly) - rust-lang/rust#156188 (riscv: promote d, e, and f target_features to CfgStableToggleUnstable) - rust-lang/rust#156666 (Clarify meaning of ranges in pointer offset docs) - rust-lang/rust#157078 (Document equivalence of `highest_one` and `ilog2` methods on integers) - rust-lang/rust#157129 (ci: update download-artifact action to v8) - rust-lang/rust#157169 (triagebot: Update messages to direct changes to appropriate repositories) - rust-lang/rust#157323 (Document Repeat::last panic behavior) - rust-lang/rust#157370 (Clarify MaybeUninit::zeroed padding docs) - rust-lang/rust#157399 (Silence llbc's output by default to prevent rustc's linker output warning) - rust-lang/rust#157500 (Improve documentation of `align_of` and `Alignment`.) - rust-lang/rust#157545 (Suggest using comma to separate valid attribute list items) - rust-lang/rust#157559 (chore: Update annotate-snippets to 0.12.16) - rust-lang/rust#157560 (In `copy_nonoverlapping`, use `mul nuw nsw` to compute the byte size) - rust-lang/rust#157580 (Importing suggestion reported twice when reporting privacy error) - rust-lang/rust#157581 (Test fixup)
This updates the rust-version file to 029c9e18dd1f4668e1d42bb187c1c263dfe20093.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@029c9e1 Filtered ref: b914e70 Upstream diff: rust-lang/rust@045b177...029c9e1 This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @davidtwco (or someone else) some time within the next two weeks. Why was this reviewer chosen?The reviewer was selected based on:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Latest update from rustc.