[PR #1426] [MERGED] add non_exhaustive to public enums #2312

New issue

Closed

opened 2026-03-16 08:47:02 +03:00 by kerem · 0 comments

kerem commented

2026-03-16 08:47:02 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hickory-dns/hickory-dns/pull/1426
Author: @bluejekyll
Created: 3/28/2021
Status: ✅ Merged
Merged: 4/6/2021
Merged by: @djc

Base: main ← Head: non_exhaustive_patterns

📝 Commits (4)

5e3ab3b add non_exhaustive to public enums
284320a warn on not fully matched enums in some cases
4dd41f2 mark ResolverOpts and DnsRequestOptions as non_exhaustive
2642183 updated CHANGELOG for resolver non_exhaustive

📊 Changes

32 files changed (+100 additions, -64 deletions)

View changed files

📝 CHANGELOG.md (+7 -0)
📝 Cargo.lock (+0 -2)
📝 bin/src/named.rs (+4 -0)
📝 crates/client/src/error/client_error.rs (+1 -0)
📝 crates/client/src/error/dnssec_error.rs (+1 -0)
📝 crates/client/src/error/lexer_error.rs (+1 -0)
📝 crates/client/src/error/parse_error.rs (+6 -0)
📝 crates/client/src/rr/dnssec/key_format.rs (+0 -2)
📝 crates/client/src/rr/dnssec/keypair.rs (+0 -2)
📝 crates/client/src/serialize/txt/parse_rdata.rs (+32 -23)
📝 crates/https/src/error.rs (+1 -0)
📝 crates/proto/src/error.rs (+1 -0)
📝 crates/proto/src/rr/dnssec/algorithm.rs (+1 -0)
📝 crates/proto/src/rr/dnssec/digest_type.rs (+1 -0)
📝 crates/proto/src/rr/dnssec/public_key.rs (+1 -0)
📝 crates/proto/src/rr/dnssec/rdata/mod.rs (+2 -0)
📝 crates/proto/src/rr/rdata/opt.rs (+2 -0)
📝 crates/proto/src/rr/record_data.rs (+1 -0)
📝 crates/proto/src/rr/record_type.rs (+1 -0)
📝 crates/proto/src/serialize/binary/decoder.rs (+1 -0)

...and 12 more files

📄 Description

I don't know if we want to make this guarantee. But It's worth putting it up for discussion.

We know that record types will be coming in the future, but adding non_exhaustive to RecordType is also a bit annoying because the RecordTypes are mostly fixed. So The question here is, where do we want to add non_exhaustive such that minor and patch releases are forward compatible. Do we want to make forward compatibility a guarantee on perhaps on patch releases, but not minor releases? See #1425, which happened on a pre 1.0 patch release as an example.

How extreme do we want to be on this at the detriment of losing one of Rusts greatest checks (all enum variants are covered in a match statement).

Fixes: #1425

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/hickory-dns/hickory-dns/pull/1426 **Author:** [@bluejekyll](https://github.com/bluejekyll) **Created:** 3/28/2021 **Status:** ✅ Merged **Merged:** 4/6/2021 **Merged by:** [@djc](https://github.com/djc) **Base:** `main` ← **Head:** `non_exhaustive_patterns` --- ### 📝 Commits (4) - [`5e3ab3b`](https://github.com/hickory-dns/hickory-dns/commit/5e3ab3bbc2ec3c51d20df67e289f88a5ccef3e16) add non_exhaustive to public enums - [`284320a`](https://github.com/hickory-dns/hickory-dns/commit/284320a1245a0fb66b7857e878beea57c44b5387) warn on not fully matched enums in some cases - [`4dd41f2`](https://github.com/hickory-dns/hickory-dns/commit/4dd41f2d082cd4b7d9a964757a85fd31d881dee9) mark ResolverOpts and DnsRequestOptions as non_exhaustive - [`2642183`](https://github.com/hickory-dns/hickory-dns/commit/26421839bb7a82e0c29ec69975771ce9b944cb19) updated CHANGELOG for resolver non_exhaustive ### 📊 Changes **32 files changed** (+100 additions, -64 deletions) <details> <summary>View changed files</summary> 📝 `CHANGELOG.md` (+7 -0) 📝 `Cargo.lock` (+0 -2) 📝 `bin/src/named.rs` (+4 -0) 📝 `crates/client/src/error/client_error.rs` (+1 -0) 📝 `crates/client/src/error/dnssec_error.rs` (+1 -0) 📝 `crates/client/src/error/lexer_error.rs` (+1 -0) 📝 `crates/client/src/error/parse_error.rs` (+6 -0) 📝 `crates/client/src/rr/dnssec/key_format.rs` (+0 -2) 📝 `crates/client/src/rr/dnssec/keypair.rs` (+0 -2) 📝 `crates/client/src/serialize/txt/parse_rdata.rs` (+32 -23) 📝 `crates/https/src/error.rs` (+1 -0) 📝 `crates/proto/src/error.rs` (+1 -0) 📝 `crates/proto/src/rr/dnssec/algorithm.rs` (+1 -0) 📝 `crates/proto/src/rr/dnssec/digest_type.rs` (+1 -0) 📝 `crates/proto/src/rr/dnssec/public_key.rs` (+1 -0) 📝 `crates/proto/src/rr/dnssec/rdata/mod.rs` (+2 -0) 📝 `crates/proto/src/rr/rdata/opt.rs` (+2 -0) 📝 `crates/proto/src/rr/record_data.rs` (+1 -0) 📝 `crates/proto/src/rr/record_type.rs` (+1 -0) 📝 `crates/proto/src/serialize/binary/decoder.rs` (+1 -0) _...and 12 more files_ </details> ### 📄 Description I don't know if we want to make this guarantee. But It's worth putting it up for discussion. We know that record types will be coming in the future, but adding non_exhaustive to RecordType is also a bit annoying because the RecordTypes are mostly fixed. So The question here is, where do we want to add non_exhaustive such that minor and patch releases are forward compatible. Do we want to make forward compatibility a guarantee on perhaps on patch releases, but not minor releases? See #1425, which happened on a pre 1.0 patch release as an example. How extreme do we want to be on this at the detriment of losing one of Rusts greatest checks (all enum variants are covered in a match statement). Fixes: #1425 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>