Add regression test for #70155.#70283
Merged
bors merged 3 commits intorust-lang:masterfrom Mar 24, 2020
Merged
Conversation
With rust-lang#70166 merged, `RangeInclusive` now derives `PartialEq` and `Eq`, implementing structural equality and as a side effect the range is now usable with const generics, closing rust-lang#70155. A test is added to avoid a change to the private fields or the equality implementation of the range from subtly reverting rust-lang#70155.
Contributor
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
Contributor
|
Seems fine on technical grounds, but I'm going to make this r? @oli-obk since it seems to indicate an (informal-ish) commitment and I want to get another set of eye-balls on that. |
oli-obk
reviewed
Mar 23, 2020
Contributor
This is a general problem with structural equality being automatically derived together with equality if the fields support it. I think this change is fine, and it's good that all the range types behave the same now |
In addition to the regression test of `RangeInclusive` for rust-lang#70155, now all range types are checked for usability within const generics: - `RangeFrom` - `RangeFull` - `RangeToInclusive` - `RangeTo` - `Range` The test are moved from `test\ui\const-generics\issues\issue-70155` to `test\ui\const-generics\std\range` in anticipation of future similar tests for std types.
Contributor
|
Please put all the tests into the same file. They are similar enough not to need a separate test file |
Merge tests to a single test file.
Contributor
|
@bors r+ rollup Thanks! |
Collaborator
|
📌 Commit 9fdde0a has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 24, 2020
Rollup of 11 pull requests Successful merges: - rust-lang#67761 (Move the dep_graph construction to a dedicated crate.) - rust-lang#69740 (Replace some desc logic in librustc_lint with article_and_desc) - rust-lang#69981 (Evaluate repeat expression lengths as late as possible) - rust-lang#70087 (Remove const eval loop detector) - rust-lang#70242 (Improve E0308 error message wording) - rust-lang#70264 (Fix invalid suggestion on `&mut` iterators yielding `&` references) - rust-lang#70267 (get rid of ConstPropUnsupported; use ZST marker structs instead) - rust-lang#70277 (Remove `ReClosureBound`) - rust-lang#70283 (Add regression test for rust-lang#70155.) - rust-lang#70294 (Account for bad placeholder types in where clauses) - rust-lang#70309 (Clean up E0452 explanation) Failed merges: r? @ghost
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Nov 15, 2020
…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
m-ou-se
added a commit
to m-ou-se/rust
that referenced
this pull request
Nov 16, 2020
…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
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
5 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.
With #70166 merged,
RangeInclusivenow derivesPartialEqandEq, implementing structural equality and as a side effect the range is now usable with const generics, closing #70155.As per #70166 (comment) a test is added to avoid a change to the private fields or the equality implementation of the range from subtly reverting #70155.