Auto merge of #140106 - dianne:deref-pat-usefulness, r=Nadrieril

allow deref patterns to participate in exhaustiveness analysis

Per [this proposal](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Exhaustiveness), this PR allows deref patterns to participate in exhaustiveness analysis. Currently all deref patterns enforce `DerefPure` bounds on their scrutinees, so this assumes all patterns it's analyzing are well-behaved. This also doesn't support [mixed exhaustiveness](https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Mixed-exhaustiveness), and instead emits an error if deref patterns are used together with normal constructors. I think mixed exhaustiveness would be nice to have (especially if we eventually want to support arbitrary `Deref` impls[^1]), but it'd require more work to get reasonable diagnostics[^2].

Tracking issue for deref patterns: #87121

r? `@Nadrieril`

[^1]: Regardless of whether we support limited exhaustiveness checking for untrusted `Deref` or always require other arms to be exhaustive, I think it'd be useful to allow mixed matching for user-defined smart pointers. And it'd be strange if it worked there but not for `Cow`.

[^2]: I think listing out witnesses of non-exhaustiveness can be confusing when they're not necessarily disjoint, and when you only need to cover some of them, so we'd probably want special formatting and/or explanatory subdiagnostics. And if it's implemented similarly to unions, we'd probably also want some way of merging witnesses; the way witnesses for unions can appear duplicated is pretty unfortunate. I'm not sure yet how the diagnostics should look, especially for deeply nested patterns.
tree: f8aec230f54c32fdc51d778a9856fc753a6ceb1a
  1. .github/
  2. compiler/
  3. library/
  4. LICENSES/
  5. src/
  6. tests/
  7. .clang-format
  8. .editorconfig
  9. .git-blame-ignore-revs
  10. .gitattributes
  11. .gitignore
  12. .gitmodules
  13. .ignore
  14. .mailmap
  15. bootstrap.example.toml
  16. Cargo.lock
  17. Cargo.toml
  18. CODE_OF_CONDUCT.md
  19. configure
  20. CONTRIBUTING.md
  21. COPYRIGHT
  22. INSTALL.md
  23. LICENSE-APACHE
  24. license-metadata.json
  25. LICENSE-MIT
  26. README.md
  27. RELEASES.md
  28. REUSE.toml
  29. rust-bors.toml
  30. rustfmt.toml
  31. triagebot.toml
  32. x
  33. x.ps1
  34. x.py
README.md

Website | Getting started | Learn | Documentation | Contributing

This is the main source code repository for Rust. It contains the compiler, standard library, and documentation.

Why Rust?

  • Performance: Fast and memory-efficient, suitable for critical services, embedded devices, and easily integrated with other languages.

  • Reliability: Our rich type system and ownership model ensure memory and thread safety, reducing bugs at compile-time.

  • Productivity: Comprehensive documentation, a compiler committed to providing great diagnostics, and advanced tooling including package manager and build tool (Cargo), auto-formatter (rustfmt), linter (Clippy) and editor support (rust-analyzer).

Quick Start

Read “Installation” from The Book.

Installing from Source

If you really want to install from source (though this is not recommended), see INSTALL.md.

Getting Help

See https://www.rust-lang.org/community for a list of chat platforms and forums.

Contributing

See CONTRIBUTING.md.

License

Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with portions covered by various BSD-like licenses.

See LICENSE-APACHE, LICENSE-MIT, and COPYRIGHT for details.

Trademark

The Rust Foundation owns and protects the Rust and Cargo trademarks and logos (the “Rust Trademarks”).

If you want to use these names or brands, please read the Rust language trademark policy.

Third-party logos may be subject to third-party copyrights and trademarks. See Licenses for details.