Rollup merge of #99384 - compiler-errors:issue-99375, r=oli-obk
use body's param-env when checking if type needs drop
The type comes from the body, so we should be using the body's param-env, as opposed to the ADT's param env, because we know less in the latter compared to the former.
I think this should be good to go, there are only two things where I am somewhat unsure:
- Is there a better way to get the fully-qualified path for the suggestion? I tried `self.tcx.def_path_str`, but that didn't seem to always give a correct path for the context.
- Should all this be extracted into it's own method or is it fine where it is?
Rollup merge of #99434 - timvermeulen:skip_next_non_fused, r=scottmcm
Fix `Skip::next` for non-fused inner iterators
`iter.skip(n).next()` will currently call `nth` and `next` in succession on `iter`, without checking whether `nth` exhausts the iterator. Using `?` to propagate a `None` value returned by `nth` avoids this.
Rollup merge of #99335 - Dav1dde:fromstr-docs, r=JohnTitor
Use split_once in FromStr docs
Current implementation:
```rust
fn from_str(s: &str) -> Result<Self, Self::Err> {
let coords: Vec<&str> = s.trim_matches(|p| p == '(' || p == ')' )
.split(',')
.collect();
let x_fromstr = coords[0].parse::<i32>()?;
let y_fromstr = coords[1].parse::<i32>()?;
Ok(Point { x: x_fromstr, y: y_fromstr })
}
```
Creating the vector is not necessary, `split_once` does the job better.
Alternatively we could also remove `trim_matches` with `strip_prefix` and `strip_suffix`:
```rust
let (x, y) = s
.strip_prefix('(')
.and_then(|s| s.strip_suffix(')'))
.and_then(|s| s.split_once(','))
.unwrap();
```
The question is how much 'correctness' is too much and distracts from the example. In a real implementation you would also not unwrap (or originally access the vector without bounds checks), but implementing a custom Error and adding a `From<ParseIntError>` and implementing the `Error` trait adds a lot of code to the example which is not relevant to the `FromStr` trait.
Rollup merge of #97183 - oli-obk:tait_ice_async, r=jackh726
wf-check generators
fixes #90409
We should not rely on generators being well formed by construction now that they can get used via type alias impl trait (and thus users can choose generic arguments that are invalid). This can cause surprising behaviour if (definitely unsound) transmutes are used, and it's generally saner to just check for well formedness.
Auto merge of #98189 - mystor:fast_ident_literal, r=eddyb
proc_macro/bridge: stop using a remote object handle for proc_macro Ident and Literal
This is the fourth part of https://github.com/rust-lang/rust/pull/86822, split off as requested in https://github.com/rust-lang/rust/pull/86822#pullrequestreview-1008655452. This patch transforms the `Ident` and `Group` types into structs serialized over IPC rather than handles.
Symbol values are interned on both the client and server when deserializing, to avoid unnecessary string copies and keep the size of `TokenTree` down. To do the interning efficiently on the client, the proc-macro crate is given a vendored version of the fxhash hasher, as `SipHash` appeared to cause performance issues. This was done rather than depending on `rustc_hash` as it is unfortunately difficult to depend on crates from within `proc_macro` due to it being built at the same time as `std`.
In addition, a custom arena allocator and symbol store was also added, inspired by those in `rustc_arena` and `rustc_span`. To prevent symbol re-use across multiple invocations of a macro on the same thread, a new range of `Symbol` names are used for each invocation of the macro, and symbols from previous invocations are cleaned-up.
In order to keep `Ident` creation efficient, a special ASCII-only case was added to perform ident validation without using RPC for simple identifiers. Full identifier validation couldn't be easily added, as it would require depending on the `rustc_lexer` and `unicode-normalization` crates from within `proc_macro`. Unicode identifiers are validated and normalized using RPC.
See the individual commit messages for more details on trade-offs and design decisions behind these patches.
Auto merge of #99422 - Dylan-DPC:rollup-htjofm6, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #98839 (Add assertion that `transmute_copy`'s U is not larger than T)
- #98998 (Remove branch target prologues from `#[naked] fn`)
- #99198 (add missing null ptr check in alloc example)
- #99344 (rustdoc: avoid inlining items with duplicate `(type, name)`)
- #99351 (Use `typeck_results` to get accurate qpath res for arg mismatch error)
- #99378 (interpret/visitor: add missing early return)
- #99394 (Add regression test for #95230)
proc_macro: Move subspan to be a method on Span in the bridge
This method is still only used for Literal::subspan, however the
implementation only depends on the Span component, so it is simpler and
more efficient for now to pass down only the information that is needed.
In the future, if more information about the Literal is required in the
implementation (e.g. to validate that spans line up as expected with
source text), that extra information can be added back with extra
arguments.
proc_macro: stop using a remote object handle for Literal
This builds on the symbol infrastructure built for `Ident` to replicate
the `LitKind` and `Lit` structures in rustc within the `proc_macro`
client, allowing literals to be fully created and interacted with from
the client thread. Only parsing and subspan operations still require
sync RPC.
proc_macro: stop using a remote object handle for Ident
Doing this for all unicode identifiers would require a dependency on
`unicode-normalization` and `rustc_lexer`, which is currently not
possible for `proc_macro` due to it being built concurrently with `std`
and `core`. Instead, ASCII identifiers are validated locally, and an RPC
message is used to validate unicode identifiers when needed.
String values are interned on the both the server and client when
deserializing, to avoid unnecessary copies and keep Ident cheap to copy and
move. This appears to be important for performance.
The client-side interner is based roughly on the one from rustc_span, and uses
an arena inspired by rustc_arena.
RPC messages passing symbols always include the full value. This could
potentially be optimized in the future if it is revealed to be a
performance bottleneck.
Despite now having a relevant implementaion of Display for Ident, ToString is
still specialized, as it is a hot-path for this object.
The symbol infrastructure will also be used for literals in the next
part.
proc_macro: use fxhash within the proc_macro crate
Unfortunately, as it is difficult to depend on crates from within proc_macro,
this is done by vendoring a copy of the hasher as a module rather than
depending on the rustc_hash crate.
This probably doesn't have a substantial impact up-front, however will be more
relevant once symbols are interned within the proc_macro client.
Rollup merge of #98998 - workingjubilee:naked-means-no-clothes-enforcement-technology, r=Amanieu
Remove branch target prologues from `#[naked] fn`
This patch hacks around rust-lang/rust#98768 for now via injecting appropriate attributes into the LLVMIR we emit for naked functions. I intend to pursue this upstream so that these attributes can be removed in general, but it's slow going wading through C++ for me.
Rollup merge of #98839 - 5225225:assert_transmute_copy_size, r=thomcc
Add assertion that `transmute_copy`'s U is not larger than T
This is called out as a safety requirement in the docs, but because knowing this can be done at compile time and constant folded (just like the `align_of` branch is removed), we can just panic here.
I've looked at the asm (using `cargo-asm`) of a function that both is correct and incorrect, and the panic is completely removed, or is unconditional, without needing build-std.
I don't expect this to cause much breakage in the wild. I scanned through https://miri.saethlin.dev/ub for issues that would look like this (error: Undefined Behavior: memory access failed: alloc1768 has size 1, so pointer to 8 bytes starting at offset 0 is out-of-bounds), but couldn't find any.
That doesn't rule out it happening in crates tested that fail earlier for some other reason, though, but it indicates that doing this is rare, if it happens at all. A crater run for this would need to be build and test, since this is a runtime thing.
Auto merge of #99232 - lcnr:no-bound-vars-check, r=jackh726
`replace_bound_vars` fast path: check predicates, don't check consts
split out from #98900
`ty::Const` doesn't have precomputed type flags, so
computing `has_vars_bound_at_or_above` for constants
requires us to visit the const and its contained types
and constants. A noop fold should be pretty much equally as
fast so removing it prevents us from walking the constant twice
in case it contains bound vars.
Turns out that all we need to do here is reorder the bounds checks to convince LLVM that all the bounds checks can be removed. It seems like LLVM just fails to propagate the original length information past the first bounds check and into the second one. With this implementation it doesn't need to, each check can be proven inbounds based on the one immediately previous.
I've gradually convinced myself that this implementation is unambiguously better based on the above logic, but maybe this is still deserving of a codegen test?
Also the mentioned borrowck limitation no longer seems to exist.
Auto merge of #99181 - lcnr:arenaGTrc, r=wesleywiser
`arena > Rc` for query results
The `Rc`s have to live for the whole duration as their count cannot go below 1 while stored as part of the query results.
By storing them in an arena we should save a bit of memory because we don't have as many independent allocations and also don't have to clone the `Rc` anymore.
Auto merge of #99391 - JohnTitor:rollup-tdigzzo, r=JohnTitor
Rollup of 6 pull requests
Successful merges:
- #98383 (Remove restrictions on compare-exchange memory ordering.)
- #99350 (Be more precise when suggesting removal of parens on unit ctor)
- #99356 (Do not constraint TAITs when checking impl/trait item compatibility)
- #99360 (Do not ICE when we have `-Zunpretty=expanded` with invalid ABI)
- #99373 (Fix source code sidebar tree auto-expand)
- #99374 (Fix doc for `rchunks_exact`)
Rollup merge of #99356 - compiler-errors:tait-in-assoc-ty-supertraits, r=oli-obk
Do not constraint TAITs when checking impl/trait item compatibility
Check out the UI test for the example.
Open to other approaches to fix this issue -- ideally we _would_ be able to collect this opaque type constraint in a way to use it in `find_opaque_ty_constraints`, so we can report a better mismatch error in the incompatible case, and just allow it in the compatible case. But that seems like a bigger refactor, so I wouldn't want to start it unless someone else thought it was a good idea.
Rollup merge of #99350 - compiler-errors:issue-99240, r=fee1-dead
Be more precise when suggesting removal of parens on unit ctor
* Fixes #99240 by only suggesting to remove parens on path exprs, not arbitrary expressions with enum type
* Generalizes by suggesting removal of parens on unit struct, too, because why not?
Rollup merge of #98383 - m-ou-se:remove-memory-order-restrictions, r=joshtriplett
Remove restrictions on compare-exchange memory ordering.
We currently don't allow the failure memory ordering of compare-exchange operations to be stronger than the success ordering, as was the case in C++11 when its memory model was copied to Rust. However, this restriction was lifted in C++17 as part of [p0418r2](https://wg21.link/p0418r2). It's time we lift the restriction too.
Use ICF (identical code folding) for building rustc
It seems that ICF (identical code folding) is able to remove duplicated functions created by monomorphization from binaries, resulting in smaller binary size and better i-cache utilization. Let's see if it helps for `rustc`.
I'm not sure if `lld` is even used for linking `rustc` on the Linux `dist` builder, let's see.
Auto merge of #99033 - 5225225:interpreter-validity-checks, r=oli-obk
Use constant eval to do strict mem::uninit/zeroed validity checks
I'm not sure about the code organisation here, I just dumped the check in rustc_const_eval at the root. Not hard to move it elsewhere, in any case.
Also, this means cranelift codegen intrinsics lose the strict checks, since they don't seem to depend on rustc_const_eval, and I didn't see a point in keeping around two copies.
I also left comments in the is_zero_valid methods about "uhhh help how do i do this", those apply to both methods equally.
Also rustc_codegen_ssa now depends on rustc_const_eval... is this okay?
Pinging `@RalfJung` since you were the one who mentioned this to me, so I'm assuming you're interested.
Haven't had a chance to run full tests on this since it's really warm, and it's 1AM, I'll check out any failures/comments in the morning :)
Auto merge of #99362 - JohnTitor:rollup-4d5zo9d, r=JohnTitor
Rollup of 7 pull requests
Successful merges:
- #94927 (Stabilize `let_chains` in Rust 1.64)
- #97915 (Implement `fmt::Write` for `OsString`)
- #99036 (Add `#[test]` to functions in test modules)
- #99088 (Document and stabilize process_set_process_group)
- #99302 (add tracking issue to generic member access APIs)
- #99306 (Stabilize `future_poll_fn`)
- #99354 (Add regression test for #95829)
Rollup merge of #94927 - c410-f3r:stabilize-let-chains, r=joshtriplett
Stabilize `let_chains` in Rust 1.64
# Stabilization proposal
This PR proposes the stabilization of `#![feature(let_chains)]` in a future-compatibility way that will allow the **possible** addition of the `EXPR is PAT` syntax.
The ability to chain let expressions along side local variable declarations or ordinary conditional expressions. For example:
```rust
pub enum Color {
Blue,
Red,
Violet,
}
pub enum Flower {
Rose,
Tulip,
Violet,
}
pub fn roses_are_red_violets_are_blue_printer(
(first_flower, first_flower_color): (Flower, Color),
(second_flower, second_flower_color): (Flower, Color),
pick_up_lines: &[&str],
) {
if let Flower::Rose = first_flower
&& let Color::Red = first_flower_color
&& let Flower::Violet = second_flower
&& let Color::Blue = second_flower_color
&& let &[first_pick_up_line, ..] = pick_up_lines
{
println!("Roses are red, violets are blue, {}", first_pick_up_line);
}
}
fn main() {
roses_are_red_violets_are_blue_printer(
(Flower::Rose, Color::Red),
(Flower::Violet, Color::Blue),
&["sugar is sweet and so are you"],
);
}
```
## Motivation
The main motivation for this feature is improving readability, ergonomics and reducing paper cuts.
For more examples, see the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/2497-if-let-chains.md).
## What isn't stabilized
* Let chains in match guards (`if_let_guard`)
* Resolution of divergent non-terminal matchers
* The `EXPR is PAT` syntax
## History
* On 2017-12-24, [RFC: if- and while-let-chains](https://github.com/rust-lang/rfcs/pull/2260)
* On 2018-07-12, [eRFC: if- and while-let-chains, take 2](https://github.com/rust-lang/rfcs/pull/2497)
* On 2018-08-24, [Tracking issue for eRFC 2497, "if- and while-let-chains, take 2](https://github.com/rust-lang/rust/issues/53667)
* On 2019-03-19, [Run branch cleanup after copy prop](https://github.com/rust-lang/rust/pull/59290)
* On 2019-03-26, [Generalize diagnostic for x = y where bool is the expected type](https://github.com/rust-lang/rust/pull/59439)
* On 2019-04-24, [Introduce hir::ExprKind::Use and employ in for loop desugaring](https://github.com/rust-lang/rust/pull/60225)
* On 2019-03-19, [[let_chains, 1/6] Remove hir::ExprKind::If](https://github.com/rust-lang/rust/pull/59288)
* On 2019-05-15, [[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains](https://github.com/rust-lang/rust/pull/60861)
* On 2019-06-20, [[let_chains, 3/6] And then there was only Loop](https://github.com/rust-lang/rust/pull/61988)
* On 2020-11-22, [Reintroduce hir::ExprKind::If](https://github.com/rust-lang/rust/pull/79328)
* On 2020-12-24, [Introduce hir::ExprKind::Let - Take 2](https://github.com/rust-lang/rust/pull/80357)
* On 2021-02-19, [Lower condition of if expression before it's "then" block](https://github.com/rust-lang/rust/pull/82308)
* On 2021-09-01, [Fix drop handling for `if let` expressions](https://github.com/rust-lang/rust/pull/88572)
* On 2021-09-04, [Formally implement let chains](https://github.com/rust-lang/rust/pull/88642)
* On 2022-01-19, [Add tests to ensure that let_chains works with if_let_guard](https://github.com/rust-lang/rust/pull/93086)
* On 2022-01-18, [Introduce `enhanced_binary_op` feature](https://github.com/rust-lang/rust/pull/93049)
* On 2022-01-22, [Fix `let_chains` and `if_let_guard` feature flags](https://github.com/rust-lang/rust/pull/93213)
* On 2022-02-25, [Initiate the inner usage of `let_chains`](https://github.com/rust-lang/rust/pull/94376)
* On 2022-01-28, [[WIP] Introduce ast::StmtKind::LetElse to allow the usage of `let_else` with `let_chains`](https://github.com/rust-lang/rust/pull/93437)
* On 2022-02-26, [1 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94396)
* On 2022-02-26, [2 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94400)
* On 2022-02-27, [3 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94420)
* On 2022-02-28, [4 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94445)
* On 2022-02-28, [5 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94448)
* On 2022-02-28, [6 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94465)
* On 2022-03-01, [7 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94476)
* On 2022-03-01, [8 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94484)
* On 2022-03-01, [9 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94498)
* On 2022-03-08, [Warn users about `||` in let chain expressions](https://github.com/rust-lang/rust/pull/94754)
From the first RFC (2017-12-24) to the theoretical future stabilization day (2022-10-22), it can be said that this feature took 4 years, 9 months and 28 days of research, development, discussions, agreements and headaches to be settled.
## Divergent non-terminal matchers
More specifically, https://github.com/rust-lang/rust/issues/86730.
```rust
macro_rules! mac {
($e:expr) => {
if $e {
true
} else {
false
}
};
}
// ERROR! Anything starting with `let` is not considered an expression
assert_eq!(mac!(let 1 = 1 && true), true);
}
```
To the best of my knowledge, such error or divergence is orthogonal, does not prevent stabilization and can be tackled independently in the near future or effectively in the next Rust 2024 edition. If not, then https://github.com/c410-f3r/rust/tree/let-macro-blah contains a set of changes that will consider `let` an expression.
It is possible that none of the solutions above satisfies all applicable constraints but I personally don't know of any other plausible answers.
## Alternative syntax
Taking into account the usefulness of this feature and the overwhelming desire to use both now and in the past, `let PAT = EXPR` will be utilized for stabilization but it doesn't or shall create any obstacle for a **possible** future addition of `EXPR is PAT`.
The introductory snippet would then be written as the following.
```rust
if first_flower is Flower::Rose
&& first_flower_color is Color::Red
&& second_flower is Flower::Violet
&& second_flower_color is Color::Blue
&& pick_up_lines is &[first_pick_up_line, ..]
{
println!("Roses are red, violets are blue, {}", first_pick_up_line);
}
```
Just to reinforce, this PR only unblocks a **possible** future road for `EXPR is PAT` and does emphasize what is better or what is worse.
## Tests
* [Verifies the drop order of let chains and ensures it won't change in the future in an unpredictable way](https://github.com/rust-lang/rust/blob/master/src/test/ui/mir/mir_let_chains_drop_order.rs)
* [AST lowering does not wrap let chains in an `DropTemps` expression](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs)
* [Verifies uninitialized variables due to MIR modifications](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/chains-without-let.rs)
* [A collection of statements where `let` expressions are forbidden](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/disallowed-positions.rs)
* [All or at least most of the places where let chains are allowed](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/feature-gate.rs)
* [Ensures that irrefutable lets are allowed in let chains](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/irrefutable-lets.rs)
* [issue-88498.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-88498.rs), [issue-90722.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-90722.rs), [issue-92145.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-92145.rs) and [issue-93150.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-93150.rs) were bugs found by third parties and fixed overtime.
* [Indexing was triggering a ICE due to a wrongly constructed MIR graph](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/no-double-assigments.rs)
* [Protects the precedence of `&&` in relation to other things](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/protect-precedences.rs)
* [`let_chains`, as well as `if_let_guard`, has a valid MIR graph that evaluates conditional expressions correctly](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/then-else-blocks.rs)
Most of the infra-structure used by let chains is also used by `if` expressions in stable compiler versions since https://github.com/rust-lang/rust/pull/80357 and https://github.com/rust-lang/rust/pull/88572. As a result, no bugs were found since the integration of https://github.com/rust-lang/rust/pull/88642.
## Possible future work
* Let chains in match guards is implemented and working but stabilization is blocked by `if_let_guard`.
* The usage of `let_chains` with `let_else` is possible but not implemented. Regardless, one attempt was introduced and closed in https://github.com/rust-lang/rust/pull/93437.
Thanks `@Centril` for creating the RFC and huge thanks (again) to `@matthewjasper` for all the reviews, mentoring and MIR implementations.
Auto merge of #98866 - nagisa:nagisa/align-offset-wroom, r=Mark-Simulacrum
Add a special case for align_offset /w stride != 1
This generalizes the previous `stride == 1` special case to apply to any
situation where the requested alignment is divisible by the stride. This
in turn allows the test case from #98809 produce ideal assembly, along
the lines of:
leaq 15(%rdi), %rax
andq $-16, %rax
This also produces pretty high quality code for situations where the
alignment of the input pointer isn’t known:
Here LLVM is smart enough to replace the `usize::MAX` special case with
a branch-less bitwise-OR approach, where the mask is constructed using
the neg and sbb instructions. This appears to work across various
architectures I’ve tried.
This change ends up introducing more branches and code in situations
where there is less knowledge of the arguments. For example when the
requested alignment is entirely unknown. This use-case was never really
a focus of this function, so I’m not particularly worried, especially
since llvm-mca is saying that the new code is still appreciably faster,
despite all the new branching.
Fixes #98809.
Sadly, this does not help with #72356.
Add a special case for align_offset /w stride != 1
This generalizes the previous `stride == 1` special case to apply to any
situation where the requested alignment is divisible by the stride. This
in turn allows the test case from #98809 produce ideal assembly, along
the lines of:
leaq 15(%rdi), %rax
andq $-16, %rax
This also produces pretty high quality code for situations where the
alignment of the input pointer isn’t known:
Here LLVM is smart enough to replace the `usize::MAX` special case with
a branch-less bitwise-OR approach, where the mask is constructed using
the neg and sbb instructions. This appears to work across various
architectures I’ve tried.
This change ends up introducing more branches and code in situations
where there is less knowledge of the arguments. For example when the
requested alignment is entirely unknown. This use-case was never really
a focus of this function, so I’m not particularly worried, especially
since llvm-mca is saying that the new code is still appreciably faster,
despite all the new branching.
Fixes #98809.
Sadly, this does not help with #72356.
Rollup merge of #99323 - GuillaumeGomez:fix-gui-flaky, r=Dylan-DPC
Fix flakyness of GUI tests
Fixes #98163.
All flaky tests seemed to be linked to the search. Since the search JS is loaded when we focus the search input, I think it's possible that we enter faster than the JS is actually loaded. The solution for that would be to do it in two steps: first we write into the search input (`browser-ui-test` adds a small sleep time after such commands) and then we press enter to be sure that it wasn't missed.
Rollup merge of #99317 - yanchith:borrow-vec-ta-as-slice-t, r=Mark-Simulacrum
Borrow Vec<T, A> as [T]
Hello all,
When `Vec` was parametrized with `A`, the `Borrow` impls were omitted and currently `Vec<T, A>` can't be borrowed as `[T]`. This PR fixes that.
This was probably missed, because the `Borrow` impls are in a different file - `src/alloc/slice.rs`.
We briefly discussed this here: https://github.com/rust-lang/wg-allocators/issues/96 and I was told to go ahead and make a PR :)
I tested this by building the toolchain and building my code that needed the `Borrow` impl against it, but let me know if I should add any tests to this PR.
Seems to have caused an incremental compilation bug. The root cause of the incr comp bug is somewhat unrelated but is triggered by this PR, so I don't feel comfortable with having this PR in the codebase until it can be investigated further. Fixes #99233.
projects / rust.git / log