-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 8 pull requests #107811
Rollup of 8 pull requests #107811
Conversation
Previously, a Drop terminator was considered a move in MIR. This commit changes the behavior to only treat Drop as a mutable access to the dropped place. In order for this change to be correct, we need to guarantee that a) A dropped value won't be used again b) Places that appear in a drop won't be used again before a subsequent initialization. We can ensure this to be correct at MIR construction because Drop will only be emitted when a variable goes out of scope, thus having: (a) as there is no way of reaching the old value. drop-elaboration will also remove any uninitialized drop. (b) as the place can't be named following the end of the scope. However, the initialization status, previously tracked by moves, should also be tied to the execution of a Drop, hence the additional logic in the dataflow analyses.
This is a prerequisite for cursor support for `BTreeMap`.
Implement cursors for BTreeMap See the ACP for an overview of the API: rust-lang/libs-team#141 The implementation is split into 2 commits: - The first changes the internal insertion functions to return a handle to the newly inserted element. The lifetimes involved are a bit hairy since we need a mutable handle to both the `BTreeMap` itself (which holds the root) and the nodes allocated in memory. I have tested that this passes the standard library testsuite under miri. - The second commit implements the cursor API itself. This is more straightforward to follow but still involves some unsafe code to deal with simultaneous mutable borrows of the tree root and the node that is currently being iterated.
Treat Drop as a rmw operation Previously, a Drop terminator was considered a move in MIR. This commit changes the behavior to only treat Drop as a mutable access to the dropped place. In order for this change to be correct, we need to guarantee that 1. A dropped value won't be used again 2. Places that appear in a drop won't be used again before a subsequent initialization. We can ensure this to be correct at MIR construction because Drop will only be emitted when a variable goes out of scope, thus having: * (1) as there is no way of reaching the old value. drop-elaboration will also remove any uninitialized drop. * (2) as the place can't be named following the end of the scope. However, the initialization status, previously tracked by moves, should also be tied to the execution of a Drop, hence the additional logic in the dataflow analyses. From discussion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/.60DROP.60.20to.20.60DROP_IF.60.20compiler-team.23558), originating from rust-lang/compiler-team#558. See also rust-lang#104488 (comment)
…=Mark-Simulacrum Update strip-ansi-escapes and vte This updates strip-ansi-escapes from 0.1.0 to 0.1.1 (and consequently vte). Changes: luser/strip-ansi-escapes@0.1.0...0.1.1 The only change really is updating vte which fixes some parsing issues (and drops the vendored source size by several megabytes). Closes rust-lang#107708
Change `arena_cache` to not alter the declared query result This makes the return types a bit clearer, limiting `arena_cache`'s effect to just the computation side. It also makes it easier to potentially remove `arena_cache`. r? ```@cjgillot```
…lly-derive-const, r=fee1-dead Make `derive_const` derive properly const-if-const impls Fixes rust-lang#107774 Fixes rust-lang#107666 Also fixes rendering of const-if-const bounds in pretty printing. r? ```@oli-obk``` or ```@fee1-dead```
…, r=lcnr Rename `replace_bound_vars_with_*` to `instantiate_binder_with_*` Mentioning "binder" rather than "bound vars", imo, makes it clearer that we're doing something to the binder as a whole. Also, "instantiate" is the verb that I'm always reaching for when I'm looking for these functions, and the name that we use in the new solver anyways. r? types
…=Dylan-DPC Add missing tracking issue for `RawOsError` I forgot to add it in the original PR… See rust-lang#107792. ```@rustbot``` label +T-libs-api -T-libs
…o, r=notriddle Fix small debug typo r? ``@notriddle``
@bors r+ rollup=never p=8 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: 9433ba6394 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (ef934d9): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
|
Successful merges:
arena_cache
to not alter the declared query result #107758 (Changearena_cache
to not alter the declared query result)derive_const
derive properly const-if-const impls #107777 (Makederive_const
derive properly const-if-const impls)replace_bound_vars_with_*
toinstantiate_binder_with_*
#107780 (Renamereplace_bound_vars_with_*
toinstantiate_binder_with_*
)RawOsError
#107793 (Add missing tracking issue forRawOsError
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup