Commit Graph

190 Commits

Author SHA1 Message Date
Michael Goulet
e1be642b41
Rollup merge of #119307 - compiler-errors:pat-lifetimes, r=Nadrieril
Clean up some lifetimes in `rustc_pattern_analysis`

This PR removes some redundant lifetimes. I figured out that we were shortening the lifetime of an arena-allocated `&'p DeconstructedPat<'p>` to `'a DeconstructedPat<'p>`, which forced us to carry both lifetimes when we could otherwise carry just one.

This PR also removes and elides some unnecessary lifetimes.

I also cherry-picked 0292eb9bb9b897f5c0926c6a8530877f67e7cc9b, and then simplified more lifetimes in `MatchVisitor`, which should make #119233 a very simple PR!

r? Nadrieril
2023-12-26 13:29:14 -05:00
Michael Goulet
48d089a800 Merge 'thir and 'p 2023-12-26 03:15:41 +00:00
bors
2271c26e4a Auto merge of #119146 - nnethercote:rm-DiagCtxt-api-duplication, r=compiler-errors
Remove `DiagCtxt` API duplication

`DiagCtxt` defines the internal API for creating and emitting diagnostics: methods like `struct_err`, `struct_span_warn`, `note`, `create_fatal`, `emit_bug`. There are over 50 methods.

Some of these methods are then duplicated across several other types: `Session`, `ParseSess`, `Parser`, `ExtCtxt`, and `MirBorrowckCtxt`. `Session` duplicates the most, though half the ones it does are unused. Each duplicated method just calls forward to the corresponding method in `DiagCtxt`. So this duplication exists to (in the best case) shorten chains like `ecx.tcx.sess.parse_sess.dcx.emit_err()` to `ecx.emit_err()`.

This API duplication is ugly and has been bugging me for a while. And it's inconsistent: there's no real logic about which methods are duplicated, and the use of `#[rustc_lint_diagnostic]` and `#[track_caller]` attributes vary across the duplicates.

This PR removes the duplicated API methods and makes all diagnostic creation and emission go through `DiagCtxt`. It also adds `dcx` getter methods to several types to shorten chains. This approach scales *much* better than API duplication; indeed, the PR adds `dcx()` to numerous types that didn't have API duplication: `TyCtxt`, `LoweringCtxt`, `ConstCx`, `FnCtxt`, `TypeErrCtxt`, `InferCtxt`, `CrateLoader`, `CheckAttrVisitor`, and `Resolver`. These result in a lot of changes from `foo.tcx.sess.emit_err()` to `foo.dcx().emit_err()`. (You could do this with more types, but it gets into diminishing returns territory for types that don't emit many diagnostics.)

After all these changes, some call sites are more verbose, some are less verbose, and many are the same. The total number of lines is reduced, mostly because of the removed API duplication. And consistency is increased, because calls to `emit_err` and friends are always preceded with `.dcx()` or `.dcx`.

r? `@compiler-errors`
2023-12-26 02:24:39 +00:00
Michael Goulet
4ae024c754 Elide more lifetimes 2023-12-26 02:12:33 +00:00
Michael Goulet
ae40f6a7ff Clean up more lifetimes 2023-12-26 02:06:39 +00:00
Michael Goulet
b91a98ba10 Even more 2023-12-26 02:02:01 +00:00
Michael Goulet
eebb2abe0b Yeet some lifetimes 2023-12-26 01:59:18 +00:00
bors
1a086e49f1 Auto merge of #118796 - Nadrieril:fix-exponential-id-match-2, r=cjgillot
Exhaustiveness: Improve complexity on some wide matches

https://github.com/rust-lang/rust/issues/118437 revealed an exponential case in exhaustiveness checking. While [exponential cases are unavoidable](https://compilercrim.es/rust-np/), this one only showed up after my https://github.com/rust-lang/rust/pull/117611 rewrite of the algorithm. I remember anticipating a case like this and dismissing it as unrealistic, but here we are :').

The tricky match is as follows:
```rust
match command {
    BaseCommand { field01: true, .. } => {}
    BaseCommand { field02: true, .. } => {}
    BaseCommand { field03: true, .. } => {}
    BaseCommand { field04: true, .. } => {}
    BaseCommand { field05: true, .. } => {}
    BaseCommand { field06: true, .. } => {}
    BaseCommand { field07: true, .. } => {}
    BaseCommand { field08: true, .. } => {}
    BaseCommand { field09: true, .. } => {}
    BaseCommand { field10: true, .. } => {}
    // ...20 more of the same

    _ => {}
}
```

To fix this, this PR formalizes a concept of "relevancy" (naming is hard) that was already used to decide what patterns to report. Now we track it for every row, which in wide matches like the above can drastically cut on the number of cases we explore. After this fix, the above match is checked with linear-many cases instead of exponentially-many.

Fixes https://github.com/rust-lang/rust/issues/118437

r? `@cjgillot`
2023-12-24 14:40:36 +00:00
Nadrieril
efb04e6572 Rework the explanation of relevancy 2023-12-23 22:43:06 +01:00
Nicholas Nethercote
99472c7049 Remove Session methods that duplicate DiagCtxt methods.
Also add some `dcx` methods to types that wrap `TyCtxt`, for easier
access.
2023-12-24 08:05:28 +11:00
Nadrieril
34307ab7c5 Reveal empty opaques in depth 2023-12-23 14:59:12 +01:00
Nadrieril
71e83347bb Improve performance on wide matches 2023-12-23 13:11:38 +01:00
Nadrieril
5fccaee59c Clarify the situation with dummy patterns and PatData
Use an explicit `Option` instead of requiring a `Default` bound
2023-12-23 00:08:38 +01:00
Nadrieril
c6aa16c469 Use derivative for better derive bounds 2023-12-23 00:04:20 +01:00
Nadrieril
2a87bae48d Reveal opaque types in exhaustiveness checking 2023-12-20 14:43:00 +01:00
bors
3a539c0889 Auto merge of #118842 - Nadrieril:librarify-further, r=compiler-errors
Make exhaustiveness usable outside of rustc

With this PR, `rustc_pattern_analysis` compiles on stable (with the `stable` feature)! `rust-analyzer` will be able to use it to provide match-related diagnostics and refactors.

Two questions:
- Should I name the feature `nightly` instead of `rustc` for consistency with other crates? `rustc` makes more sense imo.
- `typed-arena` is an optional dependency but tidy made me add it to the allow-list anyway. Can I avoid that somehow?

r? `@compiler-errors`
2023-12-19 17:15:04 +00:00
Matthias Krüger
74d81d15b4 NFC: do not clone types that are copy 2023-12-15 23:19:51 +01:00
Nadrieril
3016c29628 s/MatchCx/TypeCx/ 2023-12-15 17:26:19 +01:00
Nadrieril
4bcf66f875 Introduce MatchCtxt 2023-12-15 16:58:38 +01:00
Nadrieril
60ea14bfaa s/PatCtxt/PlaceCtxt/ 2023-12-15 16:58:38 +01:00
Nadrieril
1e89a38423 pattern_analysis doesn't need to know what spans are 2023-12-15 16:58:38 +01:00
Nadrieril
8c5e89907c Address review comments 2023-12-15 16:58:38 +01:00
Nadrieril
e10b165775 s/RustcCtxt/RustcMatchCheckCtxt/ 2023-12-15 16:58:38 +01:00
Nadrieril
63c5b008e1 Make the crate compile on stable 2023-12-15 16:58:38 +01:00
Nadrieril
e646c9f723 Make the rustc_data_structures dependency optional 2023-12-15 16:58:38 +01:00
Nadrieril
16bd6ac3ed Gate rustc-specific code under a feature 2023-12-15 16:58:37 +01:00
Nadrieril
42f4393824 Iron out last rustc-specific details 2023-12-15 16:58:37 +01:00
Nadrieril
cb622f3994 Name rustc-specific things "rustc" 2023-12-15 16:58:37 +01:00
Nadrieril
3d7c4df326 Abstract MatchCheckCtxt into a trait 2023-12-15 16:58:36 +01:00
Nadrieril
3ad76f9325 Disentangle the arena from MatchCheckCtxt 2023-12-15 16:57:36 +01:00
Nadrieril
081c3dcf43 Remove all matching on ty.kind() outside cx 2023-12-15 16:57:36 +01:00
Nadrieril
b111b2e839 Split Single ctor into more specific variants 2023-12-15 16:57:36 +01:00
Matthias Krüger
2a1acc26a0
Update compiler/rustc_pattern_analysis/src/constructor.rs
add note that `missing_empty` is cleared now

Co-authored-by: Nadrieril <Nadrieril@users.noreply.github.com>
2023-12-12 21:12:19 +01:00
Matthias Krüger
6892fcd690 simplify merging of two vecs 2023-12-12 18:42:37 +01:00
Nadrieril
43714edb6f Fix doc links 2023-12-11 12:53:01 +01:00
Nadrieril
5d6c539c2d Fix item visibilities 2023-12-11 11:20:55 +01:00
Nadrieril
de3f983bcd Make MaybeInfiniteInt rustc-independent 2023-12-11 11:20:55 +01:00
Nadrieril
24adca0a26 Move lints to their own module 2023-12-11 11:20:55 +01:00
Nadrieril
3691a0aee5 Gather rustc-specific functions around MatchCheckCtxt 2023-12-11 11:20:55 +01:00
Nadrieril
281002d42c Extract exhaustiveness into its own crate 2023-12-11 11:20:55 +01:00