Allow IndexSlice to be indexed by ranges.
#136610
Merged
+144
−42
Conversation
This file contains 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
|
r? @Noratrieb rustbot has assigned @Noratrieb. Use |
rustbot
added
S-waiting-on-review
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in coverage instrumentation. cc @Zalathar |
oli-obk
added
the
T-libs-api
This comment was marked as resolved.
This comment was marked as resolved.
Jarcho
changed the title
SliceIndex to be indexed by ranges.IndexSlice to be indexed by ranges.
|
I just realized I had a typo in the title; should have been |
oli-obk
reviewed
Feb 21, 2025
oli-obk
reviewed
Feb 21, 2025
oli-obk
reviewed
Feb 21, 2025
oli-obk
reviewed
Feb 21, 2025
|
I think there are various improvements that could be landed on master first before this PR (or just as commits before the currently only commit of this PR) |
Jarcho
force-pushed
the
range_idx
branch
2 times, most recently
from
bb61f03 to
8705084
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@rustbot label -T-libs-api :) |
rustbot
removed
the
T-libs-api
|
@bors r+ |
bors
added
S-waiting-on-bors
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Feb 24, 2025
Allow `IndexSlice` to be indexed by ranges. This comes with some annoyances as the index type can no longer inferred from indexing expressions. The biggest offender for this is `IndexVec::from_fn_n(|idx| ..., n)` where the index type won't be inferred from the call site or any index expressions inside the closure. My main use case for this is mapping a `Place` to `Range<Idx>` for value tracking where the range represents all the values the place contains.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 24, 2025
Rollup of 9 pull requests Successful merges: - rust-lang#131282 (std: detect stack overflows in TLS destructors on UNIX) - rust-lang#136610 (Allow `IndexSlice` to be indexed by ranges.) - rust-lang#136991 ([rustdoc] Add new setting to wrap source code lines when too long) - rust-lang#137393 (Stabilize `unbounded_shifts`) - rust-lang#137482 (Windows: use existing wrappers in `File::open_native`) - rust-lang#137484 (Fix documentation for unstable sort on slice) - rust-lang#137491 (Tighten `str-to-string-128690.rs``CHECK{,-NOT}`s to make it less likely to incorrectly fail with symbol name mangling) - rust-lang#137495 (Added into_value function to ControlFlow<T, T>) - rust-lang#137501 (Move `impl` blocks out of `rustc_middle/src/mir/syntax.rs`) Failed merges: - rust-lang#137489 (remove `#[rustc_intrinsic_must_be_overridde]`) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 24, 2025
Rollup of 10 pull requests Successful merges: - rust-lang#136610 (Allow `IndexSlice` to be indexed by ranges.) - rust-lang#136991 ([rustdoc] Add new setting to wrap source code lines when too long) - rust-lang#137061 (Unstable `gen_future` Feature Tracking ) - rust-lang#137393 (Stabilize `unbounded_shifts`) - rust-lang#137482 (Windows: use existing wrappers in `File::open_native`) - rust-lang#137484 (Fix documentation for unstable sort on slice) - rust-lang#137491 (Tighten `str-to-string-128690.rs``CHECK{,-NOT}`s to make it less likely to incorrectly fail with symbol name mangling) - rust-lang#137495 (Added into_value function to ControlFlow<T, T>) - rust-lang#137501 (Move `impl` blocks out of `rustc_middle/src/mir/syntax.rs`) - rust-lang#137505 (Add a span to `CompilerBuiltinsCannotCall`) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 24, 2025
Rollup merge of rust-lang#136610 - Jarcho:range_idx, r=Noratrieb Allow `IndexSlice` to be indexed by ranges. This comes with some annoyances as the index type can no longer inferred from indexing expressions. The biggest offender for this is `IndexVec::from_fn_n(|idx| ..., n)` where the index type won't be inferred from the call site or any index expressions inside the closure. My main use case for this is mapping a `Place` to `Range<Idx>` for value tracking where the range represents all the values the place contains.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This comes with some annoyances as the index type can no longer inferred from indexing expressions. The biggest offender for this is
IndexVec::from_fn_n(|idx| ..., n)where the index type won't be inferred from the call site or any index expressions inside the closure.My main use case for this is mapping a
PlacetoRange<Idx>for value tracking where the range represents all the values the place contains.