about summary refs log tree commit diff
path: root/tests/ui/pattern
AgeCommit message (Collapse)AuthorLines
2023-12-20Reveal opaque types in exhaustiveness checkingNadrieril-9/+39
2023-12-20Add testsNadrieril-0/+217
2023-12-09Don't warn an empty pattern unreachable if we're not sure the data is validNadrieril-597/+87
2023-12-09Test empty types betterNadrieril-489/+2595
2023-12-08Auto merge of #118527 - Nadrieril:never_patterns_parse, r=compiler-errorsbors-15/+15
never_patterns: Parse match arms with no body Never patterns are meant to signal unreachable cases, and thus don't take bodies: ```rust let ptr: *const Option<!> = ...; match *ptr { None => { foo(); } Some(!), } ``` This PR makes rustc accept the above, and enforces that an arm has a body xor is a never pattern. This affects parsing of match arms even with the feature off, so this is delicate. (Plus this is my first non-trivial change to the parser). ~~The last commit is optional; it introduces a bit of churn to allow the new suggestions to be machine-applicable. There may be a better solution? I'm not sure.~~ EDIT: I removed that commit r? `@compiler-errors`
2023-12-04Remove the `precise_pointer_size_matching` feature gateNadrieril-63/+24
2023-12-03Disallow arm bodies on never patternsNadrieril-14/+14
2023-12-02Add testsNadrieril-1/+1
2023-11-29Rollup merge of #118157 - Nadrieril:never_pat-feature-gate, r=compiler-errorsMatthias Krüger-0/+150
Add `never_patterns` feature gate This PR adds the feature gate and most basic parsing for the experimental `never_patterns` feature. See the tracking issue (https://github.com/rust-lang/rust/issues/118155) for details on the experiment. `@scottmcm` has agreed to be my lang-team liaison for this experiment.
2023-11-29Add `never_patterns` feature gateNadrieril-0/+150
2023-11-27Suggest swapping the order of `ref` and `box`Hirochika Matsumoto-0/+36
2023-11-26Auto merge of #117611 - Nadrieril:linear-pass-take-4, r=cjgillotbors-91/+120
Rewrite exhaustiveness in one pass This is at least my 4th attempt at this in as many years x) Previous attempts were all too complicated or too slow. But we're finally here! The previous version of the exhaustiveness algorithm computed reachability for each arm then exhaustiveness of the whole match. Since each of these steps does roughly the same things, this rewrites the algorithm to do them all in one go. I also think this makes things much simpler. I also rewrote the documentation of the algorithm in depth. Hopefully it's up-to-date and easier to follow now. Plz comment if anything's unclear. r? `@oli-obk` I think you're one of the rare other people to understand the exhaustiveness algorithm? cc `@varkor` I know you're not active anymore, but if you feel like having a look you might enjoy this :D Fixes https://github.com/rust-lang/rust/issues/79307
2023-11-24Show number in error message even for one errorNilstrieb-52/+52
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
2023-11-22Fully rework the algorithm and its explanationNadrieril-27/+34
2023-11-22Keep rows with guards in the matrixNadrieril-14/+14
2023-11-22Add some testsNadrieril-55/+77
2023-11-17On resolve error of `[rest..]`, suggest `[rest @ ..]`Esteban Küber-0/+39
When writing a pattern to collect multiple entries of a slice in a single binding, it is easy to misremember or typo the appropriate syntax to do so, instead writing the experimental `X..` pattern syntax. When we encounter a resolve error because `X` isn't available, we suggest `X @ ..` as an alternative. ``` error[E0425]: cannot find value `rest` in this scope --> $DIR/range-pattern-meant-to-be-slice-rest-pattern.rs:3:13 | LL | [1, rest..] => println!("{rest:?}"), | ^^^^ not found in this scope | help: if you meant to collect the rest of the slice in `rest`, use the at operator | LL | [1, rest @ ..] => println!("{rest:?}"), | + ``` Fix #88404.
2023-11-08Auto merge of #116930 - RalfJung:raw-ptr-match, r=davidtwcobors-14/+94
patterns: reject raw pointers that are not just integers Matching against `0 as *const i32` is fine, matching against `&42 as *const i32` is not. This extends the existing check against function pointers and wide pointers: we now uniformly reject all these pointer types during valtree construction, and then later lint because of that. See [here](https://github.com/rust-lang/rust/pull/116930#issuecomment-1784654073) for some more explanation and context. Also fixes https://github.com/rust-lang/rust/issues/116929. Cc `@oli-obk` `@lcnr`
2023-11-03Tweak spans for "adt defined here" noteNadrieril-136/+150
2023-11-02Always do all the pattern checksNadrieril-4/+22
2023-11-02Add regression test for pattern checksNadrieril-0/+72
2023-11-02Tweak diagnostic for consistencyNadrieril-57/+109
2023-11-01Auto merge of #117289 - estebank:issue-72298, r=cjgillotbors-0/+94
Account for `ref` and `mut` in the wrong place for pattern ident renaming If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest the correct code. Fix #72298.
2023-10-30Account for `ref` and `mut` in the wrong place for pattern ident renamingEsteban Küber-0/+94
If the user writes `S { ref field: name }` instead of `S { field: ref name }`, we suggest the correct code. Fix #72298.
2023-10-28make pointer_structural_match warn-by-defaultRalf Jung-14/+94
2023-10-27Match usize/isize exhaustivelyNadrieril-243/+194
2023-10-27Add testsNadrieril-14/+80
2023-10-27Lint overlapping ranges as a separate passNadrieril-15/+58
2023-10-16Fix inline const pattern unsafety checking in THIRMatthew Jasper-14/+31
THIR unsafety checking was getting a cycle of function unsafety checking -> building THIR for the function -> evaluating pattern inline constants in the function -> building MIR for the inline constant -> checking unsafety of functions (so that THIR can be stolen) This is fixed by not stealing THIR when generating MIR but instead when unsafety checking. This leaves an issue with pattern inline constants not being unsafety checked because they are evaluated away when generating THIR. To fix that we now represent inline constants in THIR patterns and visit them in THIR unsafety checking.
2023-10-15use `PatKind::error` when an ADT const value has violationbohan-0/+18
2023-10-14Skip most of check_match checks in the presence of `PatKind::Error`Nadrieril-34/+9
2023-10-12Auto merge of #116391 - Nadrieril:constructorset, r=cjgillotbors-0/+61
exhaustiveness: Rework constructor splitting `SplitWildcard` was pretty opaque. I replaced it with a more legible abstraction: `ConstructorSet` represents the set of constructors for patterns of a given type. This clarifies responsibilities: `ConstructorSet` handles one clear task, and diagnostic-related shenanigans can be done separately. I'm quite excited, I had has this in mind for years but could never quite introduce it. This opens up possibilities, including type-specific optimisations (like using a `FxHashSet` to collect enum variants, which had been [hackily attempted some years ago](https://github.com/rust-lang/rust/pull/76918)), my one-pass rewrite (https://github.com/rust-lang/rust/pull/116042), and future librarification.
2023-10-11Avoid emitting the non_exhaustive error if other errors already occurredOli Scherer-47/+9
2023-10-11Prevent spurious `unreachable pattern` lintsOli Scherer-143/+71
Means you'll get more `non-exhaustive` patterns
2023-10-06Auto merge of #114811 - estebank:impl-ambiguity, r=wesleywiserbors-0/+3
Show more information when multiple `impl`s apply - When there are `impl`s without type params, show only those (to avoid showing overly generic `impl`s). ``` error[E0283]: type annotations needed --> $DIR/multiple-impl-apply.rs:34:9 | LL | let y = x.into(); | ^ ---- type must be known at this point | note: multiple `impl`s satisfying `_: From<Baz>` found --> $DIR/multiple-impl-apply.rs:14:1 | LL | impl From<Baz> for Bar { | ^^^^^^^^^^^^^^^^^^^^^^ ... LL | impl From<Baz> for Foo { | ^^^^^^^^^^^^^^^^^^^^^^ = note: required for `Baz` to implement `Into<_>` help: consider giving `y` an explicit type | LL | let y: /* Type */ = x.into(); | ++++++++++++ ``` - Lower the importance of `T: Sized`, `T: WellFormed` and coercion errors, to prioritize more relevant errors. The pre-existing deduplication logic deals with hiding redundant errors better that way, and we show errors with more metadata that is useful to the user. - Show `<SelfTy as Trait>::assoc_fn` suggestion in more cases. ``` error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type --> $DIR/cross-return-site-inference.rs:38:16 | LL | return Err(From::from("foo")); | ^^^^^^^^^^ cannot call associated function of trait | help: use a fully-qualified path to a specific available implementation | LL | return Err(</* self type */ as From>::from("foo")); | +++++++++++++++++++ + ``` Fix #88284.
2023-10-05Add a note to duplicate diagnosticsAlex Macleod-0/+4
2023-10-05Fix handling slices of empty typesNadrieril-0/+61
2023-10-04Reorder fullfillment errors to keep more interesting ones firstEsteban Küber-0/+3
In `report_fullfillment_errors` push back `T: Sized`, `T: WellFormed` and coercion errors to the end of the list. The pre-existing deduplication logic eliminates redundant errors better that way, keeping the resulting output with fewer errors than before, while also having more detail.
2023-10-01Evaluate float consts eagerlyNadrieril-15/+77
2023-09-21adjust how closure/generator types and rvalues are printedRalf Jung-2/+2
2023-09-07fixes #114896surechen-0/+18
2023-09-03Improve clarity of diagnostic message on non-exhaustive matchesSebastian Toh-5/+5
2023-08-28Add note when matching on nested non-exhaustive enumsSebastian Toh-0/+42
2023-08-28Add note that str cannot be matched exhaustivelySebastian Toh-0/+31
2023-08-21Add note when matching on tuples/ADTs containing non-exhaustive typesSebastian Toh-0/+245
2023-07-28address reviewb-naber-1/+13
2023-07-17add more testsb-naber-25/+103
2023-07-17address reviewb-naber-3/+8
2023-07-17add test for nested patternb-naber-0/+15
2023-07-17add tests for refutable patternsb-naber-5/+172