8717: Update match checking algorithm r=iDawer a=iDawer
I've recently got interest in the match checking to extend the current algo to support reporting witnesses of non-exhaustiveness.
It appears the algo is outdated from rustc's implementation. I decided to rewrite it based on the latest rustc's version. It is a diff-based port to ra codebase. That means you can diff-compare these files to rustc.
I'm striving to keep minimal ra-related changes in the algo to make it easier to backport future changes from the upstream.
Based on upstream algorithm of version rust-lang/rust 1.52.0-nightly (25c15cdbe 2021-04-22)
https://github.com/rust-lang/rust/blob/25c15cdbe/compiler/rustc_mir_build/src/thir/pattern/usefulness.rs
The goal of this PR is to cover the current `missing-match-arm` diagnostic.
What is remaining to do:
- [x] Error handling. The errors that are unrelated to match checking will be handled before the check. Just like how it made in rustc.
- [x] Lowering `hir_def::expr::Pat` to `hir_ty::diagnostics::match_check::Pat`. rustc's match checking works on top of `rustc_mir_build::thir::Pat`, which is lowered from `hir::Pat` and carries some extra semantics used by the check. All unrelated checks are done there. RA could use this to rule out running the check on unimplemented cases (`Pat::ConstBlock`, etc).
- [x] ~~Proper~~Loose typecheck of match arm patterns (https://github.com/rust-analyzer/rust-analyzer/pull/8840, https://github.com/rust-analyzer/rust-analyzer/pull/8875).
- [x] Tests from `hir_ty::diagnostics::match_check::tests`.
- [x] Clean up `todo`s
- [x] Test run on real repos https://github.com/rust-analyzer/rust-analyzer/pull/8717#issuecomment-847120265.
Co-authored-by: Dawer <7803845+iDawer@users.noreply.github.com>
fn is_useful , more skeletons
Specify a lifetime on pattern references
impl PatStack
fill impl Matrix
PatStack::pop_head_constructor
Index-based approach
struct PatCtxt
fields construction fn Fields::wildcards
split wildcard
fn Constructor::is_covered_by_any(..)
fn Matrix::specialize_constructor(..)
impl Usefulness
Initial work on witness construction
Reorganize files
Replace match checking diagnostic
Handle types of expanded patterns
unit match checking go brrr
8952: add support of impl block for doctest into runnables r=matklad a=bnjjj
close#6356
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
8866: Update salsa r=matklad a=jonas-schievink
This updates salsa to include https://github.com/salsa-rs/salsa/pull/265, and removes all cancellation-related code from rust-analyzer
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9060: feat: Diagnose unimplemented built-in macros r=matklad a=jonas-schievink
A number of built-in attribute macros are unsupported, I thought it might be useful to put a diagnostic on their definition in libcore. Not sure.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9051: Fix incorrect setting descriptions r=lnicola a=sclu1034
Descriptions for diagnostic warning hint and info display were swapped.
Fixes#8485.
Co-authored-by: Lucas Schwiderski <lucas@lschwiderski.de>
9027: feat: Attribute completion is context aware r=Veykril a=Veykril
This splits off the `lint` and `derive` completions into their own submodules of `attribute`.
The idea is to create a lazy global hashmap that maps `SyntaxKind` to attribute names(`&[&str]`) in which we index with the syntax kind of the "thing" we are attributing giving us the attributes back that are valid for this kind. Then we use this name to do a binary search on the attribute list to fetch and build the corresponding completion item.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9040: Don't label derive macros with their banged_name r=Veykril a=Veykril
cc https://github.com/rust-analyzer/rust-analyzer/issues/7072#issuecomment-850396203
This doesn't fix it non builtin derives yet I think cause of a FIXME somewhere that doesn't categorize proc-macro derives as derives yet
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9029: minor: test that `ItemTree` makes `hir_def` queries syntax-independent r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8997: internal: stop expanding UseTrees during ItemTree lowering r=jonas-schievink a=jonas-schievink
Closes https://github.com/rust-analyzer/rust-analyzer/issues/8908
Messy diff, but `ItemTree` lowering got simpler, since we now have a strict 1-to-1 mapping between `ast::Item` and `ModItem`.
The most messy part is mapping a single `UseTree` back to its `ast::UseTree` counterpart for diagnostics, but I think the ad-hoc source map built during lowering does the job.
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9017: internal: Reduce the number of traits passed through chalk during applicable trait lookup r=SomeoneToIgnore a=SomeoneToIgnore
Inherent traits can be omitted before trait solving, presumably slightly helping https://github.com/rust-analyzer/rust-analyzer/issues/7542 and slightly simplifying the code.
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
9015: Merge pattern completion related bools into an enum r=Veykril a=Veykril
The two bools can never both be set so this is basically just a tri-state enum.
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9012: feat: add tab stops for keyword completions r=matklad a=eduardocanellas
Add tab stops for all the keywords that I judged fit. I also introduced some line breaks and spaces, following the pattern I saw in the `postfix` module.
Co-authored-by: Eduardo Canellas <eduardocanellas98@gmail.com>
9002: Move annotations below item attributes r=Veykril a=Veykril
This moves annotations/code lenses below attributes in items, bringing them inline with functions where this is already the case. This is done by changing the annotations covering range to just the name node's range which is also more inline with what the lsp expects which is that the range should ideally only cover a single line.
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/9000
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
8996: Fix bug where library functions were not highlighted as such r=arzg a=arzg
Sorry about forgetting to test this in my last PR.
Co-authored-by: Aramis Razzaghipour <aramisnoah@gmail.com>
8993: fix: don't show pd/ppd completions where it shouldn't be r=flodiebold a=eduardocanellas
Closes #8992
Co-authored-by: Eduardo Canellas <eduardocanellas98@gmail.com>
8994: Check for subdirs in vfs loader exclusions. r=matklad a=ammkrn
The current logic used to transfer global_excludes into vfs exclusions
only transfers global_excludes that are the parent of an item in
dirs.include.
This commit additionally adds an item from global_exclude to the vfs
exclusions if the global_exclude is a child of an included item.
Co-authored-by: ammkrn <ammkrn@tuta.io>
The current logic used to transfer global_excludes into vfs exclusions
only transfers global_excludes that are the parent of an item in
dirs.include.
This commit additionally adds an item from global_exclude to the vfs
exclusions if the global_exclude is a child of an included item.
The idea here is to eventually get rid of `dyn Diagnostic` and
`DiagnosticSink` infrastructure altogether, and just have a `enum
hir::Diagnostic` instead.
The problem with `dyn Diagnostic` is that it is defined in the lowest
level of the stack (hir_expand), but is used by the highest level (ide).
As a first step, we free hir_expand and hir_def from `dyn Diagnostic`
and kick the can up to `hir_ty`, as an intermediate state. The plan is
then to move DiagnosticSink similarly to the hir crate, and, as final
third step, remove its usage from the ide.
One currently unsolved problem is testing. You can notice that the test
which checks precise diagnostic ranges, unresolved_import_in_use_tree,
was moved to the ide layer. Logically, only IDE should have the infra to
render a specific range.
At the same time, the range is determined with the data produced in
hir_def and hir crates, so this layering is rather unfortunate. Working
on hir_def shouldn't require compiling `ide` for testing.
8990: feat: Also do goto implementation on assoc consts r=lnicola a=lf-
I forgot to put this into #8988, sorry.
Goto implementation on a const on the trait will go to the
implementations with their respective definitions of the const, if
present.
Co-authored-by: Jade <software@lfcode.ca>
I forgot to put this into #8988, sorry.
Goto implementation on a const on the trait will go to the
implementations with their respective definitions of the const, if
present.
