Inconsistency between tuples and struct-tuples with `min-exhaustive-patterns`
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
I tried this code:
#![feature(min_exhaustive_patterns)]
#![feature(never_type)]
use std::marker::PhantomData;
pub fn foo<B>(x: (!, PhantomData<B>)) -> ! {
match x {}
}
pub struct Bar<B>(!, PhantomData<B>);
impl<B> Bar<B> {
pub fn bar(&self) -> ! {
match *self {}
}
}
I expected to see this happen: No errors (because Bar<B> is empty the same way foo's parameter is).
Instead, this happened: non-exhaustive patterns: type Bar<B> is non-empty.
Note that the tracking issue #119612 mentions "a struct with a visible field of empty type", so I also tried to make the first field pub ! to see, but it's the same behavior. Note that I consider the field visible in the scope it is used, which matches with the fact that adding pub did not fix the issue. The issue seems thus to be a difference between struct-tuple and tuple.
Meta
rustc --version --verbose:
rustc 1.82.0-nightly (f8060d282 2024-07-30)
binary: rustc
commit-hash: f8060d282d42770fadd73905e3eefb85660d3278
commit-date: 2024-07-30
host: x86_64-unknown-linux-gnu
release: 1.82.0-nightly
LLVM version: 18.1.7
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the example from the issue with the min_exhaustive_patterns and never_type features, comparing the tuple function with the struct-tuple method. Read tracking issue #119612 for the intended empty-type behavior. Done means the struct-tuple match is accepted consistently with the tuple match, with regression coverage for the reported case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100