-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Test structural matching for all range types #76339
Conversation
de0023b
to
973f53c
Compare
@matklad any updates on this? thanks |
Hm, looks like there are some conflicts here. But presumably they won't really affect this PR, just need to be resolved. I think we should probably keep the const generics test around, because it is testing that they can't be used in that context. I don't know that we don't have other tests already testing that, but I see no particular reason to delete it, and I do think that there is some potential for concern given that matching on these values is allowed. |
829ffd9
to
bb540e1
Compare
I rebased onto master and excluded the changes to the const-generic tests |
Adds structural match tests for all range types. Note: also adds the otherwise unrelated test `test_range_to_inclusive` for completeness
bb540e1
to
6728240
Compare
@rustbot modify labels: -S-waiting-on-author +S-waiting-on-review |
@bors r+ rollup |
📌 Commit 6728240 has been approved by |
…rk-Simulacrum Test structural matching for all range types As of rust-lang#70166 all range types (`core::ops::Range` etc.) can be structurally matched upon, and by extension used in const generics. In reference to the fact that this is a publicly observable property of these types, and thus falls under the Rust stability guarantees of the standard library, a regression test was added in rust-lang#70283. This regression test was implemented by me by testing for the ability to use the range types within const generics, but that is not the actual property the std guarantees now (const generics is still unstable). This PR addresses that situation by adding extra tests for the range types that directly test whether they can be structurally matched upon. Note: also adds the otherwise unrelated test `test_range_to_inclusive` for completeness with the other range unit tests
Rollup of 11 pull requests Successful merges: - rust-lang#74989 (Implement `Index` and `IndexMut` for arrays) - rust-lang#76339 (Test structural matching for all range types) - rust-lang#77691 (Rename/Deprecate LayoutErr in favor of LayoutError) - rust-lang#78364 (Update RELEASES.md for 1.48.0) - rust-lang#78678 (Add tests and improve rendering of cfgs on traits) - rust-lang#78714 (Simplify output capturing) - rust-lang#78769 (Remove unneeded lifetimes in array/mod.rs) - rust-lang#78903 (BTreeMap: test chaotic ordering & other bits & bobs) - rust-lang#79032 (improve type const mismatch errors) - rust-lang#79061 (Make all rustdoc functions and structs crate-private) - rust-lang#79087 (Update E0744 about control flow in `const` contexts to accurately describe when the error is triggered and why) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
As of #70166 all range types (
core::ops::Range
etc.) can be structurally matched upon, and by extension used in const generics. In reference to the fact that this is a publicly observable property of these types, and thus falls under the Rust stability guarantees of the standard library, a regression test was added in #70283.This regression test was implemented by me by testing for the ability to use the range types within const generics, but that is not the actual property the std guarantees now (const generics is still unstable). This PR addresses that situation by adding extra tests for the range types that directly test whether they can be structurally matched upon.
Note: also adds the otherwise unrelated test
test_range_to_inclusive
for completeness with the other range unit tests