Skip to content
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

Tracking Issue for RFC 3535: Constants in Patterns #120362

Closed
7 of 8 tasks
traviscross opened this issue Jan 26, 2024 · 2 comments
Closed
7 of 8 tasks

Tracking Issue for RFC 3535: Constants in Patterns #120362

traviscross opened this issue Jan 26, 2024 · 2 comments
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@traviscross
Copy link
Contributor

traviscross commented Jan 26, 2024

This is a tracking issue for the RFC 3535: Constants in Patterns (rust-lang/rfcs#3535).

Summary

When a constant appears as a pattern, this is syntactic sugar for writing a pattern that corresponds to the constant's value by hand. This operation is only allowed when (a) the type of the constant implements PartialEq, and (b) the value of the constant being matched on has "structural equality", which means that PartialEq behaves the same way as that desugared pattern.

This RFC does not allow any new code, compared to what already builds on stable today. Its purpose is to explain the rules for constants in patterns in one coherent document, and to justify why we will start rejecting some code that currently works (see the breaking changes).

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Status of the relevant lints

Unresolved questions

Related issues

@traviscross traviscross added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Jan 26, 2024
@RustyYato

This comment was marked as resolved.

bors added a commit to rust-lang-ci/rust that referenced this issue Feb 8, 2024
make non-PartialEq-typed consts as patterns a hard error

This lint was introduced in rust-lang#115893, for Rust 1.74, so we just had the third stable release where this is shown as a future-compat lint (which is shown for dependencies). Not a single comment or backreference showed up in the tracking issue, rust-lang#116122. So this seems fairly safe to turn into a hard error.

Of course we should do a crater run first.

This is part of rust-lang#120362.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 25, 2024
…li-obk

make non-PartialEq-typed consts as patterns a hard error

This lint was introduced in rust-lang#115893, for Rust 1.74, so we just had the third stable release where this is shown as a future-compat lint (which is shown for dependencies). Not a single comment or backreference showed up in the tracking issue, rust-lang#116122. So this seems fairly safe to turn into a hard error.

Of course we should do a crater run first.

This is part of rust-lang#120362.
Closes rust-lang#116122.
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Feb 25, 2024
Rollup merge of rust-lang#120805 - RalfJung:const-pat-partial-eq, r=oli-obk

make non-PartialEq-typed consts as patterns a hard error

This lint was introduced in rust-lang#115893, for Rust 1.74, so we just had the third stable release where this is shown as a future-compat lint (which is shown for dependencies). Not a single comment or backreference showed up in the tracking issue, rust-lang#116122. So this seems fairly safe to turn into a hard error.

Of course we should do a crater run first.

This is part of rust-lang#120362.
Closes rust-lang#116122.
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Feb 26, 2024
make non-PartialEq-typed consts as patterns a hard error

This lint was introduced in rust-lang/rust#115893, for Rust 1.74, so we just had the third stable release where this is shown as a future-compat lint (which is shown for dependencies). Not a single comment or backreference showed up in the tracking issue, rust-lang/rust#116122. So this seems fairly safe to turn into a hard error.

Of course we should do a crater run first.

This is part of rust-lang/rust#120362.
Closes rust-lang/rust#116122.
bors added a commit to rust-lang-ci/rust that referenced this issue May 3, 2024
…atterns, r=<try>

Turn remaining non-structural-const-in-pattern lints into hard errors

This completes the implementation of rust-lang#120362 by turning out remaining future-compat lints into hard errors: indirect_structural_match and pointer_structural_match.

They have been future-compat lints for a while (indirect_structural_match for many years, pointer_structural_match since Rust 1.75), and have shown up in dependency breakage reports since Rust 1.78 (released yesterday). I don't expect any code will still depend on them, but we will of course do a crater run.

A lot of cleanup is now possible in const_to_pat, but that is deferred to a later PR.

Fixes rust-lang#70861
bors added a commit to rust-lang-ci/rust that referenced this issue May 26, 2024
…atterns, r=pnkfelix

Turn remaining non-structural-const-in-pattern lints into hard errors

This completes the implementation of rust-lang#120362 by turning our remaining future-compat lints into hard errors: indirect_structural_match and pointer_structural_match.

They have been future-compat lints for a while (indirect_structural_match for many years, pointer_structural_match since Rust 1.75 (released Dec 28, 2023)), and have shown up in dependency breakage reports since Rust 1.78 (just released on May 2, 2024). I don't expect a lot of code will still depend on them, but we will of course do a crater run.

A lot of cleanup is now possible in const_to_pat, but that is deferred to a later PR.

Fixes rust-lang#70861
RalfJung pushed a commit to RalfJung/miri that referenced this issue May 27, 2024
…r=pnkfelix

Turn remaining non-structural-const-in-pattern lints into hard errors

This completes the implementation of rust-lang/rust#120362 by turning our remaining future-compat lints into hard errors: indirect_structural_match and pointer_structural_match.

They have been future-compat lints for a while (indirect_structural_match for many years, pointer_structural_match since Rust 1.75 (released Dec 28, 2023)), and have shown up in dependency breakage reports since Rust 1.78 (just released on May 2, 2024). I don't expect a lot of code will still depend on them, but we will of course do a crater run.

A lot of cleanup is now possible in const_to_pat, but that is deferred to a later PR.

Fixes rust-lang/rust#70861
bors added a commit to rust-lang/rust-analyzer that referenced this issue Jun 20, 2024
…r=pnkfelix

Turn remaining non-structural-const-in-pattern lints into hard errors

This completes the implementation of rust-lang/rust#120362 by turning our remaining future-compat lints into hard errors: indirect_structural_match and pointer_structural_match.

They have been future-compat lints for a while (indirect_structural_match for many years, pointer_structural_match since Rust 1.75 (released Dec 28, 2023)), and have shown up in dependency breakage reports since Rust 1.78 (just released on May 2, 2024). I don't expect a lot of code will still depend on them, but we will of course do a crater run.

A lot of cleanup is now possible in const_to_pat, but that is deferred to a later PR.

Fixes rust-lang/rust#70861
flip1995 pushed a commit to flip1995/rust-clippy that referenced this issue Jun 28, 2024
…r=pnkfelix

Turn remaining non-structural-const-in-pattern lints into hard errors

This completes the implementation of rust-lang/rust#120362 by turning our remaining future-compat lints into hard errors: indirect_structural_match and pointer_structural_match.

They have been future-compat lints for a while (indirect_structural_match for many years, pointer_structural_match since Rust 1.75 (released Dec 28, 2023)), and have shown up in dependency breakage reports since Rust 1.78 (just released on May 2, 2024). I don't expect a lot of code will still depend on them, but we will of course do a crater run.

A lot of cleanup is now possible in const_to_pat, but that is deferred to a later PR.

Fixes rust-lang/rust#70861
@RalfJung
Copy link
Member

RalfJung commented Jul 4, 2024

All the PRs have landed, the lints turned into hard errors, the issue closed... I would say this is done. :)
#119398 remains open, but it doesn't need to keep this tracking issue open.

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants