profile
viewpoint

JoshMcguigan/bubble-shell 49

A simple shell

JoshMcguigan/estream 46

Vim plugin to take back the quickfix window

JoshMcguigan/arr_macro 44

Initialize arrays with ease!

JoshMcguigan/belay 36

Run your CI checks locally to `git push` with confidence

JoshMcguigan/amethyst-2d-platformer-demo 33

Demo game using the Amethyst engine

JoshMcguigan/betafpv-f3 33

Board Support Crate for the BetaFPV F3 Drone Flight Controller

JoshMcguigan/dashr 15

A unix-style utility for responding programmatically to new ethernet devices joining a network

JoshMcguigan/cargo-run-script 9

Bringing `npm run-script` to Rust

JoshMcguigan/alacritty 1

A cross-platform, GPU-accelerated terminal emulator

JoshMcguigan/aoc-2018 1

Advent of Code 2018 - Solutions in Rust

PR closed mackwic/colored

WIP: fix count for gnu readline

This change adds escape sequences to mark color codes so that GNU readline counts them properly. I believe this would resolve NerdyPepper/pista#1, but I haven't tried it.

This change breaks the tests which compare against the "reference implementation" (ansi_term), but all other unit tests pass. For that reason, this PR is a work in progress. I'm not sure if I'll get back around to finishing it, but I wanted to share the progress to this point.

Thanks for your work on this crate!

+22 -3

3 comments

1 changed file

JoshMcguigan

pr closed time in 6 days

pull request commentmackwic/colored

WIP: fix count for gnu readline

Thanks for digging into this. I still use pista, but to be honest, I can't even remember if I use the version compiled with this fix or not. Feel free to close this if you'd like.

JoshMcguigan

comment created time in 6 days

PR closed rust-analyzer/rust-analyzer

Use hir in fill match arms build pat

This fixes a fixme in the fill match arms assist about using the HIR in the pattern building process.

+51 -28

2 comments

5 changed files

JoshMcguigan

pr closed time in 22 days

pull request commentrust-analyzer/rust-analyzer

Use hir in fill match arms build pat

Hey, thanks for all the mentorship on this, but I've been pretty busy and likely won't have time to get this cleaned up any time soon. I'm going to close it for now, but I hope to be back around when I get some more free time.

JoshMcguigan

comment created time in 22 days

push eventJoshMcguigan/dotvim

Josh Mcguigan

commit sha 55112280bca4b69f5103ca247c40a0e67c59a512

don't pin coc to tag

view details

push time in a month

startedkettle11/LD46

started time in a month

issue commentrust-analyzer/rust-analyzer

New weekly build crashs reproducily

or to check analysis-stats on nightlies on more projects

+1 to this

I'd really like to see the nightly CI job gate the release on a succesful run against some representative projects.

weiznich

comment created time in a month

issue commentrust-analyzer/rust-analyzer

clippy lints show instead of compile errors

I'm wondering if this is a UX issue within VS Code, or perhaps just a general UX challenge when reporting two issues with overlapping spans. In coc.nvim if I have the cursor on upper I see both the error and the clippy lint listed. If I have the cursor on fahr I see only the clippy lint listed (as expected). I also see both the error and the clippy lint in the error list.

Can you perhaps attach a screenshot of what you are seeing?

jeffsmith82

comment created time in a month

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 3bfb84f287f6a942de18e608e408d4f238ce72e9

use HIR in match arms build pat

view details

push time in a month

Pull request review commentrust-analyzer/rust-analyzer

Use hir in fill match arms build pat

 impl Completions {             .map(|field| (field.name(ctx.db), field.signature_ty(ctx.db)));         let variant_kind = variant.kind(ctx.db);         let detail = match variant_kind {-            StructKind::Tuple | StructKind::Unit => detail_types+            StructKind::Tuple(_) | StructKind::Unit => detail_types

I'm not sure what you mean here. Are you suggesting deleting detail_types above and doing the variant.fields().. in the match arms?

JoshMcguigan

comment created time in a month

Pull request review commentrust-analyzer/rust-analyzer

Use hir in fill match arms build pat

 impl Name {             _ => None,         }     }++    pub fn as_text(&self) -> Option<&SmolStr> {

Thanks for the tip. I reverted this.

JoshMcguigan

comment created time in a month

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 93541d2ada62c5eceb28868d38cdbc0b4ee7ac3a

use HIR in match arms build pat

view details

push time in a month

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 9962cbb79c47c9c8d3750723dc956a85ab523b84

use HIR in match arms build pat

view details

push time in a month

issue openedfannheyward/coc-rust-analyzer

rust-analyzer.procMacro.enabled config item

https://github.com/rust-analyzer/rust-analyzer/pull/3958 adds a rust-analyzer.procMacro.enabled config item to enable proc macro expansion. It would be great if coc-rust-analyzer was aware of this config item.

Thanks for your work on coc-rust-analyzer!

created time in a month

Pull request review commentrust-analyzer/rust-analyzer

Use hir in fill match arms build pat

 impl EnumVariant {         self.variant_data(db).kind()     } -    pub(crate) fn variant_data(self, db: &dyn HirDatabase) -> Arc<VariantData> {+    pub fn variant_data(self, db: &dyn HirDatabase) -> Arc<VariantData> {

Thanks for the detailed explanation. I created a new hir::StructKind type, and export that type now from hir rather than exporting the hir_def::StructKind (which doesn't contain the fields). Is this what you intended?

It seems one downside to this is that now the IDE completion code has to wait for the fields to be resolved, even though it doesn't use them. I'm not sure how much of a performance impact something like this has, so I don't know if this is something that is okay, or should be avoided?

JoshMcguigan

comment created time in a month

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 76b75552de6fde4f459ead1fddc58b8c73535b99

use HIR in fill match arms buid pat

view details

push time in a month

Pull request review commentrust-analyzer/rust-analyzer

Use hir in fill match arms build pat

 impl EnumVariant {         self.variant_data(db).kind()     } -    pub(crate) fn variant_data(self, db: &dyn HirDatabase) -> Arc<VariantData> {+    pub fn variant_data(self, db: &dyn HirDatabase) -> Arc<VariantData> {

Do we want to make this public? I think this PR could have been done using the existing fields and kind methods, but matching on VariantData has nicer ergonomics IMO.

JoshMcguigan

comment created time in a month

PR opened rust-analyzer/rust-analyzer

Use hir in fill match arms build pat

This fixes a fixme in the fill match arms assist about using the HIR in the pattern building process.

+24 -18

0 comment

5 changed files

pr created time in a month

create barnchJoshMcguigan/rust-analyzer

branch : fill-match-arms-build-pat-use-hir

created branch time in a month

startedMachine-Hum/realm.one

started time in a month

pull request commentrust-analyzer/rust-analyzer

Match check enum record

Any concerns about this?

As a general note about the order I am adding functionality to this missing match arms diagnostic, I am trying to convert the add match arms assist to a diagnostic fix as suggested by @matklad here. So I am adding features which build up to that.

JoshMcguigan

comment created time in a month

push eventJoshMcguigan/rust-analyzer

Edwin Cheng

commit sha ef6ee160062a8d08ab2b12b788e081f518f4c7c6

Fix path for proc-macro in nightly / stable build

view details

Laurențiu Nicola

commit sha 02b96d522cc50252b4cb7927cae04248ea6b6193

Reduce allocations when looking up proc macro decl

view details

Benjamin Coenen

commit sha 828f69ce549c9e07dec528247c97507749b1aec7

tests: add more info about what failed in tidy tests Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

view details

bors[bot]

commit sha d426462b487d9b8ec18184fb169b8fcd990a80d5

Merge #4007 4007: Reduce allocations when looking up proc macro decl r=edwin0cheng a=lnicola `libserde_derive` has about 21K symbols on Linux. It's not much, but let's ~~not be wasteful~~ avoid the allocations anyway. r? @edwin0cheng Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>

view details

bors[bot]

commit sha 69f0cb6cd77c2dc93f2eed180a6c16fd8c3fca5a

Merge #4008 4008: tests: add more info about what failed in tidy tests r=matklad a=bnjjj Separate PR from #3954 Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

view details

bors[bot]

commit sha f8016b81940f27fc4794ce75d2e7670944ef1f97

Merge #3996 3996: Fix path for proc-macro in nightly / stable release r=matklad a=edwin0cheng I messed up that I forget we use different executable names for nightly / stable release, I changed to use the current executable name instead. Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>

view details

Laurențiu Nicola

commit sha 93fcf1c133f1a473ac598e4811e88ee91d979510

Use mmap for proc macro libs

view details

bors[bot]

commit sha 46105cdaba049239d2815489f4beeedfec5be9d7

Merge #4004 4004: Use mmap for proc macro libs r=matklad a=lnicola Fixes #4002. Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>

view details

Aleksey Kladov

commit sha 3b75bc154f75cb97ff2debee9f6594d6fc4f4053

Better snippet when completing trait method

view details

bors[bot]

commit sha bd6b532224753c6e56e322158b12cd1079b03f67

Merge #4009 4009: Better snippet when completing trait method r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

view details

Aleksey Kladov

commit sha 302bf97bbf1855e3c7def9ab4f9f3d338be5e3b7

Don't expose impl details of SyntaxPtr

view details

Aleksey Kladov

commit sha a8196ffe8466aa60dec56e77c2da717793c0debe

Correctly highlight ranges of diagnostics from macros closes #2799

view details

Aleksey Kladov

commit sha 146f6f5a45a4bfd98ab0eb54bb30610d784433c9

Simplify Diagnostic structure It's not entirely clear what subnode ranges should mean in the presence of macros, so let's leave them out for now. We are not using them heavily anyway.

view details

bors[bot]

commit sha 0262c9b9c0f5091106606e959d85b1dc0cdb7e0d

Merge #4010 4010: Fix handling of ranges in diagnostics r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

view details

Aleksey Kladov

commit sha 028f1e2e3add764956911a0f2663107cb945c0ec

Don\t suggest import itself as a completion for import

view details

bors[bot]

commit sha 48a9e2061826f9154ed497c306125c1ffd5e8fb3

Merge #4011 4011: Don\t suggest import itself as a completion for import r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

view details

Josh Mcguigan

commit sha 408f914bf4d6719ae68582ae43e2de9d3cb362b0

fix panic on ellipsis in pattern

view details

bors[bot]

commit sha 179d9835351f3abab03634b50bcee94723cce148

Merge #4012 4012: fix panic on ellipsis in pattern r=flodiebold a=JoshMcguigan fixes #3999 Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>

view details

Aleksey Kladov

commit sha f178df1a5e23d584f84658a4af426b8aeb832ea4

Don't use SyntaxNodePtr::range when determining scope for offset

view details

bors[bot]

commit sha 690a0b249eee6537953350be28a0ca11fa96b12a

Merge #4016 4016: Don't use SyntaxNodePtr::range when determining scope for offset r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

view details

push time in a month

issue commentrust-analyzer/rust-analyzer

Panicked at `DotDotPat`

Got it. In that case would it not be be valid to change the definition of the slice field in hir::Pat::Slice to represent the fact that it can only be in one of the three states above (doesn't exist, exists, exists with binding)? Then any arbitrary pattern other than .. or x @ .. would be lowered as part of the prefix (most likely) or suffix.

This seems like it would make hir::Pat::Slice more type safe, since we'd enforce at compile time that the slice is the correct thing? And I think malformed source code could still be lowered since arbitrary non-ellipsis patterns would be lowered into the prefix or suffix?

This actually seems very similar to the tuple pattern to me, since if I am understanding correctly, the suffix should be empty if there is no slice? In that case, perhaps it would be even better (from a type strictness standpoint) to change hir::Pat::Slice to { pats: Vec<PatId>, slice: Option<TypeRepresentingTheThreePossibleStates, usize> }, where the usize represents the position of the .. within the pats? I guess there is an issue with this suggestion, which already plays out for tuples, which is that it doesn't really allow lowering source code containing patterns that have two .. (even though this is not valid rust).

I really appreciate you taking the time to fill me in on this. I'm not proposing these changes as something I'd necessarily go out and do right away, but talking through this really helps me understand this more fundamentally. I think this background knowledge will really help when I get around to implement match statement exhaustiveness checking for slices.

edwin0cheng

comment created time in 2 months

issue commentrust-analyzer/rust-analyzer

Panicked at `DotDotPat`

Okay, I think I am getting it, just one final question (I hope :smile:):

Is it the definition of the slice field in Pat::Slice that it represents the .. (or a x @ ..)? I want to make sure I am clear on the intention of the prefix vs slice vs suffix.

edwin0cheng

comment created time in 2 months

issue commentrust-analyzer/rust-analyzer

Panicked at `DotDotPat`

Thanks for helping me get up to speed here! Just to be sure I understand, shouldn't the first one (with the binding) be lowered to Slice { prefix: [], slice: Some(Pat::Bind { blah }), suffix: [Wild] }, whereas a .. without the binding would lower to Slice { prefix: [], slice: Some(Wild), suffix: [Wild] }?

In this case it seems there are three valid values for the slice field (within the Pat::Slice):

  • None
  • SomeWithBinding
  • SomeWithoutBinding

Am I still off track here?

edwin0cheng

comment created time in 2 months

PR opened rust-analyzer/rust-analyzer

fix panic on ellipsis in pattern

fixes #3999

+59 -3

0 comment

2 changed files

pr created time in 2 months

create barnchJoshMcguigan/rust-analyzer

branch : issue-3999

created branch time in 2 months

issue commentrust-analyzer/rust-analyzer

Panicked at `DotDotPat`

It's possible to bind to the .. in a slice pattern (as in the original example). We should instead lower it to a wildcard.

My concern about lowering .. to a Wild is it would cause the following patterns to be lowered in the same way.

fn foo(params: &[usize]) {
    match params {
        // ellipsis
        [ps @ .., _] => {}
    }
}
fn foo(params: &[usize]) {
    match params {
        // underscore
        [ps @ _, _] => {}
    }
}

I could be misunderstanding here, but I'd think lowering both _ and .. to a Wild would not provide enough information to downstream code. For example, the missing match arm diagnostic would need to know whether all slices of length > 1 are covered (as in the first example), or only slices of lenth == 2 are covered (as in the second example).

edwin0cheng

comment created time in 2 months

issue commentrust-analyzer/rust-analyzer

Panicked at `DotDotPat`

So the reason I added that panic is because before that we were mapping the ast::Pat::DotDotPat to a Pat::Wild, which wasn't valid in the tuple case, since a wild (_) takes the place of a single item while the DotDotPat can take the place of multiple items. My thinking at the time was that it was always invalid to map a DotDotPat to a Pat::Wild for this reason.

    Slice { prefix: Vec<PatId>, slice: Option<PatId>, suffix: Vec<PatId> }

I'm not too familiar with the slice pattern types. Is the slice field supposed to contain the ellipsis if there is one? If that is true, can we replace slice: Option<PatId> with slice: bool?

As I've been thinking about this I've realized we could hit this panic another way:

struct Bar {
	a: bool,
}
fn foo(b: Bar) {
	match b {
		Bar { a: .. } => {},
	}
}

Any thoughts on a more general solution to this?

edwin0cheng

comment created time in 2 months

issue commentrust-analyzer/rust-analyzer

Panicked at `DotDotPat`

Thanks for the minimal reproduction. I added that panic here so I'll take a look at this one.

edwin0cheng

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 47f7ac1a7329910cbaae38b8cba97054089d26bb

missing match arm diagnostic support enum record type

view details

push time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 47c715d05cea4d6ccff22bb1d4a57d0fc9e74fb4

missing match arm diagnostic support enum record type

view details

push time in 2 months

push eventJoshMcguigan/rust-analyzer

veetaha

commit sha 7534266156eb6e2deeac748eddc5f8c7af5f1239

fix: inlay hints config desyncronization between the frontend and the backend See the explanation in the issue comment: https://github.com/rust-analyzer/rust-analyzer/issues/3924#issuecomment-612444566

view details

Igor Żuk

commit sha f8fb009cadd6d0f837cc0236343a226850ae0974

Fix parentModule shortcut conflict The default parentModule shortcut conflicts with VSCode's built-in undo selection

view details

Florian Diebold

commit sha 7886513f89795e06eef258e0c54dbd1224c98317

Nicer display of closures in Chalk logs

view details

Florian Diebold

commit sha 2e7b88b5256bd6c51226b63b93481a77ac901e14

Nicer display of projections in Chalk logs

view details

Florian Diebold

commit sha db32a2e4211f9444ef4f10b633e400d27ed2662e

Implement inline associated type bounds Like `Iterator<Item: SomeTrait>`. This is an unstable feature, but it's used in the standard library e.g. in the definition of Flatten, so we can't get away with not implementing it :)

view details

Florian Diebold

commit sha c8b2ec8c20be44ae19d15e90ff812745f029899e

Add support for bounds on associated types in trait definitions E.g. ``` trait Trait { type Item: SomeOtherTrait; } ``` Note that these don't simply desugar to where clauses; as I understand it, where clauses have to be proved by the *user* of the trait, but these bounds are proved by the *implementor*. (Also, where clauses on associated types are unstable.)

view details

Florian Diebold

commit sha c216a93da711a4d0da97db1eb6f67389e6eb5021

Upgrade Chalk

view details

Florian Diebold

commit sha d88d67819b3f052422ad3f024e44ad73dde1630b

Handle `Self::Type` in trait definitions when referring to own associated type It was implemented for other generic parameters for the trait, but not for `Self`.

view details

Edwin Cheng

commit sha 464af68ec56b1b35151acc3b53eea3d3d67e03d3

Remove format from syntax_bridge hot path

view details

Timo Freiberg

commit sha 1231418f31c7b52cdff428fd73a11f6a9755d4b6

Change add_function assist to use todo!()

view details

Josh Mcguigan

commit sha f62c73a97286a49c228cd13c32ed37340afd2c1d

add diagnostics subcommand to rust-analyzer CLI

view details

Josh Mcguigan

commit sha f9701efbe706e8569a41847d76c4b914f479df32

cli diagnostics walk files

view details

kjeremy

commit sha d7efe545156610b777a69d9e17754ecb2c04a48f

Bump @types/vscode and vscode-languageclient

view details

kjeremy

commit sha eedab116ab9cf49860902fa051bb492653dab50c

insta 0.16

view details

Josh Mcguigan

commit sha 6be972770e75db5ec9f9ae2504786a9d7e957e4a

diagnostics cli, iterate over members

view details

bors[bot]

commit sha b495e56b0d3f7a72494d002a69440563e8394574

Merge #3971 3971: add diagnostics subcommand to rust-analyzer CLI r=JoshMcguigan a=JoshMcguigan This PR adds a `diagnostics` subcommand to the rust-analyzer CLI. The intent is to detect all diagnostics on a workspace. It returns a non-zero status code if any error diagnostics are detected. Ideally I'd like to run this in CI against the rust analyzer project as a guard against false positives. ``` $ cargo run --release --bin rust-analyzer -- diagnostics . ``` Questions for reviewers: 1. Is this the proper way to get all diagnostics for a workspace? It seems there are at least a few ways this can be done, and I'm not sure if this is the most appropriate mechanism to do this. 2. It currently prints out the relative file path as it is collecting diagnostics, but it doesn't print the crate name. Since the file name is relative to the crate there can be repeated names, so it would be nice to print some identifier for the crate as well, but it wasn't clear to me how best to accomplish this. Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>

view details

bors[bot]

commit sha d6327297e4778354bb49730e4e2e64eeedaac772

Merge #3978 3978: insta 0.16 r=matklad a=kjeremy Co-authored-by: kjeremy <kjeremy@gmail.com>

view details

bors[bot]

commit sha 61cb87e50629f510c8a1231102ba66ded524bec2

Merge #3976 3976: Bump @types/vscode and vscode-languageclient r=matklad a=kjeremy Brings us inline with proposed LSP 3.16. Co-authored-by: kjeremy <kjeremy@gmail.com>

view details

bors[bot]

commit sha 923efa72bd41456f196f1f85b5b5216c92ee9b6c

Merge #3969 3969: Change add_function assist to use todo!() instead of unimplemented!() r=matklad a=TimoFreiberg In the spirit of #3935 Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>

view details

bors[bot]

commit sha 9726401eaed82b0afc51ea26f1789f435e906b47

Merge #3963 3963: Upgrade Chalk r=matklad a=flodiebold Co-authored-by: Florian Diebold <flodiebold@gmail.com>

view details

push time in 2 months

Pull request review commentrust-analyzer/rust-analyzer

fix missing match arm false positive for enum with no variants

 pub(crate) fn is_useful(     matrix: &Matrix,     v: &PatStack, ) -> MatchCheckResult<Usefulness> {+    // Handle the special case of enums with no variants. In that case, no match+    // arm is useful.+    if let Ty::Apply(ApplicationTy { ctor: TypeCtor::Adt(AdtId::EnumId(enum_id)), .. }) =+        cx.infer[cx.match_expr].deref()+    {+        if cx.db.enum_data(*enum_id).variants.is_empty() {+            return Ok(Usefulness::NotUseful);+        }+    }

Agreed :+1:

The issue with an enum with no variants is our current method relies on the existence of at least one match arm in order to determine the constructor, which is what makes this a special case. If we always used the match expr to determine the construtor we wouldn't have that problem.

JoshMcguigan

comment created time in 2 months

Pull request review commentrust-analyzer/rust-analyzer

fix missing match arm false positive for enum with no variants

 impl Ty {         }     } +    pub fn deref(&self) -> &Ty {+        let mut t: &Ty = self;++        loop {+            match t {

while let cleaned this up a bit, thanks for the suggestion.

JoshMcguigan

comment created time in 2 months

Pull request review commentrust-analyzer/rust-analyzer

fix missing match arm false positive for enum with no variants

 impl Ty {         }     } +    pub fn deref(&self) -> &Ty {

Renamed to strip_references as suggested.

JoshMcguigan

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 360bdf653b91f5232a5584c7f4b13960caa48dda

fix false positive for enum with no variants

view details

push time in 2 months

pull request commentrust-analyzer/rust-analyzer

fix missing match arm false positive for enum with no variants

I've added a deref method on Ty, which recursively derences types until it gets a non-reference. This makes the test pass which was matching on a reference to the Never enum.

Let me know if there is a more appropriate name for this method. Or if it should go somewhere else. I thought about putting it in an impl block on ApplicationTy, but in that case I wasn't sure what the return type should be, since parameters.as_single() would still return a Ty and I wasn't sure if it was safe to assume that Ty would be an ApplicationTy in all cases.

Also, I think this method could be useful when comparing the type of the match expression to the pattern arms? But I'd like to do this in a follow up MR, because that change should come with some additional tests as well.

JoshMcguigan

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 1e65bc6002134550e84915eea7b76dc8e3ee0cd8

fix false positive for enum with no variants

view details

push time in 2 months

pull request commentrust-analyzer/rust-analyzer

fix missing match arm false positive for enum with no variants

Sorry for the noise here. Converting back to draft because I have not yet covered the reference case (i.e. &Never).

JoshMcguigan

comment created time in 2 months

Pull request review commentrust-analyzer/rust-analyzer

fix missing match arm false positive for enum with no variants

 pub(crate) fn is_useful(     matrix: &Matrix,     v: &PatStack, ) -> MatchCheckResult<Usefulness> {+    // Handle the special case of enums with no variants. In that case, no match+    // arm is useful.+    if let Some(enum_variant) = cx.infer.variant_resolution_for_expr(cx.match_expr) {+        if let VariantId::EnumVariantId(enum_variant_id) = enum_variant {+            if cx.db.enum_data(enum_variant_id.parent).variants.len() == 0 {

Ah, this makes sense. Thanks for setting me on the right track!

JoshMcguigan

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 19c3c0e943aeddc3845c947469859d1bf3823165

fix false positive for enum with no variants

view details

push time in 2 months

pull request commentrust-analyzer/rust-analyzer

add diagnostics subcommand to rust-analyzer CLI

bors r+

JoshMcguigan

comment created time in 2 months

Pull request review commentrust-analyzer/rust-analyzer

add diagnostics subcommand to rust-analyzer CLI

+//! Analyze all modules in a project for diagnostics. Exits with a non-zero status+//! code if any errors are found.++use anyhow::anyhow;+use ra_db::{SourceDatabase, SourceDatabaseExt};+use ra_ide::Severity;+use std::{collections::HashSet, path::Path};++use crate::cli::{load_cargo::load_cargo, Result};+use hir::Semantics;++pub fn diagnostics(path: &Path, load_output_dirs: bool, all: bool) -> Result<()> {+    let (host, roots) = load_cargo(path, load_output_dirs)?;+    let db = host.raw_database();+    let analysis = host.analysis();+    let semantics = Semantics::new(db);+    let members = roots+        .into_iter()+        .filter_map(|(source_root_id, project_root)| {+            // filter out dependencies+            if project_root.is_member() {+                Some(source_root_id)+            } else {+                None+            }+        })+        .collect::<HashSet<_>>();++    let mut found_error = false;+    let mut visited_files = HashSet::new();+    let crate_graph = db.crate_graph();+    for crate_id in crate_graph.iter() {+        let krate = &crate_graph[crate_id];+        if let Some(crate_name) = &krate.display_name {+            println!("processing crate: {}", crate_name);+        } else {+            println!("processing crate: unknown");+        }+        for file_id in db.source_root(db.file_source_root(krate.root_file_id)).walk() {

I've reverted to pub(crate) and added an accessor here as you suggested.

JoshMcguigan

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 6be972770e75db5ec9f9ae2504786a9d7e957e4a

diagnostics cli, iterate over members

view details

push time in 2 months

pull request commentrust-analyzer/rust-analyzer

fix missing match arm false positive for enum with no variants

I think the solution in this PR should work, but cx.infer.variant_resolution_for_expr(cx.match_expr) returns None in the following case:

enum Never {}

fn test_fn(never: Never) {
	match never {}
}

I think this is an inference issue related to the match expression coming from a function argument. Any thoughts on this @flodiebold? Places I should start looking?

Note that in the IDE I do see Never as the type when I hover over the match expression, so perhaps this is some issue which only affects variant_resolution_for_expr?

JoshMcguigan

comment created time in 2 months

issue commentrust-analyzer/rust-analyzer

Incorrectly shows an error for matching an enum without variants

Thanks for the report, I'll take a look at this.

djc

comment created time in 2 months

Pull request review commentrust-analyzer/rust-analyzer

add diagnostics subcommand to rust-analyzer CLI

+//! Analyze all modules in a project for diagnostics. Exits with a non-zero status+//! code if any errors are found.++use anyhow::anyhow;+use ra_db::{SourceDatabase, SourceDatabaseExt};+use ra_ide::Severity;+use std::{collections::HashSet, path::Path};++use crate::cli::{load_cargo::load_cargo, Result};+use hir::Semantics;++pub fn diagnostics(path: &Path, load_output_dirs: bool, all: bool) -> Result<()> {+    let (host, roots) = load_cargo(path, load_output_dirs)?;+    let db = host.raw_database();+    let analysis = host.analysis();+    let semantics = Semantics::new(db);+    let members = roots+        .into_iter()+        .filter_map(|(source_root_id, project_root)| {+            // filter out dependencies+            if project_root.is_member() {+                Some(source_root_id)+            } else {+                None+            }+        })+        .collect::<HashSet<_>>();++    let mut found_error = false;+    let mut visited_files = HashSet::new();+    let crate_graph = db.crate_graph();+    for crate_id in crate_graph.iter() {+        let krate = &crate_graph[crate_id];+        if let Some(crate_name) = &krate.display_name {+            println!("processing crate: {}", crate_name);+        } else {+            println!("processing crate: unknown");+        }+        for file_id in db.source_root(db.file_source_root(krate.root_file_id)).walk() {

you can still get the crate of the module from the module you got from to_module_def

So to_module_def gives me a Module, which I can use to get a hir::code_model::Crate. But to get the crate name I need CrateData, and the way I've been getting that is by looking up the CrateId in the crate graph. For this reason, I had to modify the visibility of the id field of hir::code_model::Crate from pub(crate) to pub.

Does this seem correct? See my latest commit for the implementation of this.

JoshMcguigan

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 78a554c24abbb0b5b6dda1953ae35f575e99545e

diagnostics cli, iterate over members

view details

push time in 2 months

pull request commentrust-analyzer/rust-analyzer

add diagnostics subcommand to rust-analyzer CLI

I'd be a bit wary about that at this stage, we don't want random PRs to break because they added new code that happens to have a false positive grimacing (Apart from the impact on build times...)

This is a good point. My thought was this would run nightly, similar to analysis-stats.

JoshMcguigan

comment created time in 2 months

pull request commentrust-analyzer/rust-analyzer

add diagnostics subcommand to rust-analyzer CLI

@flodiebold I've changed this quite a bit in my most recent commit based on your suggestions. If you don't mind I'd prefer you take another quick look before I merge.

JoshMcguigan

comment created time in 2 months

Pull request review commentrust-analyzer/rust-analyzer

add diagnostics subcommand to rust-analyzer CLI

+//! Analyze all files in project for diagnostics. Exits with a non-zero status+//! code if any errors are found.++use anyhow::anyhow;+use ra_db::{SourceDatabaseExt, SourceRootId};+use ra_ide::{Analysis, Severity};+use std::{collections::HashSet, path::Path};++use crate::cli::{load_cargo::load_cargo, Result};+use hir::{db::HirDatabase, Crate, Module};++pub fn diagnostics(path: &Path, load_output_dirs: bool) -> Result<()> {+    let (host, roots) = load_cargo(path, load_output_dirs)?;+    let db = host.raw_database();+    let analysis = host.analysis();+    let members = roots+        .into_iter()+        .filter_map(+            |(source_root_id, project_root)| {+                if project_root.is_member() {+                    Some(source_root_id)+                } else {+                    None+                }+            },+        )+        .collect::<HashSet<_>>();++    let mut found_error = false;+    let mut visited_modules = HashSet::new();+    for krate in Crate::all(db) {+        let module = krate.root_module(db).expect("crate without root module");+        check_module(module, db, &mut visited_modules, &members, &analysis, &mut found_error);+    }++    println!();+    println!("diagnostic scan complete");++    if found_error {+        println!();+        Err(anyhow!("diagnostic error detected"))+    } else {+        Ok(())+    }+}++fn check_module(+    module: Module,+    db: &(impl HirDatabase + SourceDatabaseExt),+    visited_modules: &mut HashSet<Module>,+    members: &HashSet<SourceRootId>,+    analysis: &Analysis,+    found_error: &mut bool,+) {+    let file_id = module.definition_source(db).file_id.original_file(db);+    if !visited_modules.contains(&module) {+        if members.contains(&db.file_source_root(file_id)) {+            println!("processing: {}", db.file_relative_path(file_id));+            for diagnostic in analysis.diagnostics(file_id).unwrap() {

Maybe we even shouldn't filter out the test data files by default, but provide an option to include/exclude globs -- it seems legitimate to get the diagnostics for any file in the same way we would see them in the editor thinking

I'd really like to be able to use this as at tool for avoiding false positives when developing diagnostics. For that use case, I think automatic filtering of files makes sense, although I suppose someone could potentially have a slightly different use case where they'd like to see all diagnostics. My goal here was to create something similar to cargo check. But I've created a CLI option to get the behavior you are describing.

JoshMcguigan

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha f9701efbe706e8569a41847d76c4b914f479df32

cli diagnostics walk files

view details

push time in 2 months

Pull request review commentrust-analyzer/rust-analyzer

add diagnostics subcommand to rust-analyzer CLI

+//! Analyze all files in project for diagnostics. Exits with a non-zero status+//! code if any errors are found.++use anyhow::anyhow;+use ra_db::{SourceDatabaseExt, SourceRootId};+use ra_ide::{Analysis, Severity};+use std::{collections::HashSet, path::Path};++use crate::cli::{load_cargo::load_cargo, Result};+use hir::{db::HirDatabase, Crate, Module};++pub fn diagnostics(path: &Path, load_output_dirs: bool) -> Result<()> {+    let (host, roots) = load_cargo(path, load_output_dirs)?;+    let db = host.raw_database();+    let analysis = host.analysis();+    let members = roots+        .into_iter()+        .filter_map(+            |(source_root_id, project_root)| {+                if project_root.is_member() {+                    Some(source_root_id)+                } else {+                    None+                }+            },+        )+        .collect::<HashSet<_>>();++    let mut found_error = false;+    let mut visited_modules = HashSet::new();+    for krate in Crate::all(db) {+        let module = krate.root_module(db).expect("crate without root module");+        check_module(module, db, &mut visited_modules, &members, &analysis, &mut found_error);+    }++    println!();+    println!("diagnostic scan complete");++    if found_error {+        println!();+        Err(anyhow!("diagnostic error detected"))+    } else {+        Ok(())+    }+}++fn check_module(+    module: Module,+    db: &(impl HirDatabase + SourceDatabaseExt),+    visited_modules: &mut HashSet<Module>,+    members: &HashSet<SourceRootId>,+    analysis: &Analysis,+    found_error: &mut bool,+) {+    let file_id = module.definition_source(db).file_id.original_file(db);+    if !visited_modules.contains(&module) {+        if members.contains(&db.file_source_root(file_id)) {+            println!("processing: {}", db.file_relative_path(file_id));+            for diagnostic in analysis.diagnostics(file_id).unwrap() {

Oh, and I tried one other way which was using Module::diagnostics, but this has an interface which is not quite as nice (requiring passing in a DiagnosticSink, and it doesn't provide the information about the level of the diagnostic (Error vs Warning).

As an aside, it seems the diagnostic level (Error vs Warning) would be part of the Diagnostic trait. Is there some reason it isn't?

But I'll try your suggestion of Semantics::to_module_def(file_id).is_some(), because it may help solve the "how to print the crate name" problem. Right now, since I am iterating over hir::code_model::Crate::all I don't think I have a nice way to get to the db::input::CrateData.

JoshMcguigan

comment created time in 2 months

Pull request review commentrust-analyzer/rust-analyzer

add diagnostics subcommand to rust-analyzer CLI

+//! Analyze all files in project for diagnostics. Exits with a non-zero status+//! code if any errors are found.++use anyhow::anyhow;+use ra_db::{SourceDatabaseExt, SourceRootId};+use ra_ide::{Analysis, Severity};+use std::{collections::HashSet, path::Path};++use crate::cli::{load_cargo::load_cargo, Result};+use hir::{db::HirDatabase, Crate, Module};++pub fn diagnostics(path: &Path, load_output_dirs: bool) -> Result<()> {+    let (host, roots) = load_cargo(path, load_output_dirs)?;+    let db = host.raw_database();+    let analysis = host.analysis();+    let members = roots+        .into_iter()+        .filter_map(+            |(source_root_id, project_root)| {+                if project_root.is_member() {+                    Some(source_root_id)+                } else {+                    None+                }+            },+        )+        .collect::<HashSet<_>>();++    let mut found_error = false;+    let mut visited_modules = HashSet::new();+    for krate in Crate::all(db) {+        let module = krate.root_module(db).expect("crate without root module");+        check_module(module, db, &mut visited_modules, &members, &analysis, &mut found_error);+    }++    println!();+    println!("diagnostic scan complete");++    if found_error {+        println!();+        Err(anyhow!("diagnostic error detected"))+    } else {+        Ok(())+    }+}++fn check_module(+    module: Module,+    db: &(impl HirDatabase + SourceDatabaseExt),+    visited_modules: &mut HashSet<Module>,+    members: &HashSet<SourceRootId>,+    analysis: &Analysis,+    found_error: &mut bool,+) {+    let file_id = module.definition_source(db).file_id.original_file(db);+    if !visited_modules.contains(&module) {+        if members.contains(&db.file_source_root(file_id)) {+            println!("processing: {}", db.file_relative_path(file_id));+            for diagnostic in analysis.diagnostics(file_id).unwrap() {

If I'm remembering correctly, that was my first attempt. The issue was that it included all files rather than just files in the module tree, which meant for rust analyzer itself that it included all the test-data for the parser.

Is there a different way to filter those out?

JoshMcguigan

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Benjamin Coenen

commit sha ab864ed259c10ff51f7c9c3421d098eeea7b0245

feat: add attributes support on struct fields #3870 Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

view details

Benjamin Coenen

commit sha 18a5e164838e1dc2abcc6b79d4fc2f96ffd2507c

Merge branch 'master' of github.com:rust-analyzer/rust-analyzer

view details

Luca Barbieri

commit sha 68196ccc10c60de52bb771d295879456f73ede95

Add AstElement trait, generate tokens, support tokens in enums - Adds a new AstElement trait that is implemented by all generated node, token and enum structs - Overhauls the code generators to code-generate all tokens, and also enhances enums to support including tokens, node, and nested enums

view details

Benjamin Coenen

commit sha 8f1dba6f9ae1d8d314dd9d007e4c582ed1403e8d

feat: add attributes support on struct fields and method #3870 Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

view details

kjeremy

commit sha 6f0f86d2c57749000df2d6dc2932983173f948ee

Enable the SemanticTokensFeature by default This is covered under vscode's "editor.semanticHighlighting.enabled" setting plus the user has to have a theme that has opted into highlighting. Bumps required vscode stable to 1.44

view details

bors[bot]

commit sha 937fd557b09eb3a762319200796a0114a377e9c4

Merge #3899 3899: Enable the SemanticTokensFeature by default r=matklad a=kjeremy This is covered under vscode's "editor.semanticHighlighting.enabled" setting plus the user has to have a theme that has opted into highlighting. Bumps required vscode stable to 1.44 Closes #3773 Co-authored-by: kjeremy <kjeremy@gmail.com>

view details

IceSentry

commit sha 2a582b78a5f9c1fa908fe5f4c9ff4ab2966adb2e

Add more heuristics for hiding obvious param hints This will now hide "value", "pat", "rhs" and "other" These words were selected from the std because they are used in common functions with only a single param and are obvious by their use. I think it would be good to also hide "bytes" if the type is `[u8; n]` but I'm not sure how to get the param type signature It will also hide the hint if the passed param starts or end with the param_name

view details

IceSentry

commit sha a2dc18f71acf83dd2946622603d3da00b456d42a

remove TODO

view details

Elinvynia

commit sha eb1ca5f4482bcad497652f837cd275eb9395617c

Better Sublime documentation

view details

bors[bot]

commit sha 080c983498afcac3eb54028af5c9f8bfe7f2c826

Merge #3902 3902: Better Sublime Documentation r=matklad a=Elinvynia LSP by default now has the correct rust-analyzer configuration, I feel like updating it will make it less confusing for new users. Co-authored-by: Elinvynia <59487684+Elinvynia@users.noreply.github.com>

view details

IceSentry

commit sha de6db0632228ae61f7ec1f87eaf520ccd4e46925

ignore `&mut ` and `&` when checking params

view details

IceSentry

commit sha cba694c60276f7543ee9ed1dddf3fe93209f527f

better `&mut ` and `&` matching

view details

Edwin Cheng

commit sha 6af1015f74ee8395ea7fe8339d8748089f05e3e4

Add rustc_server (ra_tt rustc bridge)

view details

Edwin Cheng

commit sha 836384393b3cb2dca003f4a2caf47e94f283f48c

Remove unused func

view details

bors[bot]

commit sha ebd1309c9a3ac0e6b0cee197f30a962d5263e727

Merge #3906 3906: Implement proc_macro rustc server r=matklad a=edwin0cheng This PR implement the `ra_tt::TokenTree` based rustc server for lib_proc_macro. Note that span information is not implemented yet. Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>

view details

Benjamin Coenen

commit sha 585bb83e2aec9c79dae8c2e031e9165f40937003

feat: add attributes support on struct fields and method #3870 Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

view details

Aleksey Kladov

commit sha dd2e8e86a9de610ca41846e0088e5e186eddf999

Fix add missing items assist order closes #3904

view details

bors[bot]

commit sha 01e5bd50f30ae22abab0733468d1e1c6dea7d506

Merge #3908 3908: Fix add missing items assist order r=matklad a=matklad closes #3904 bors r+ 🤖 Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

view details

bors[bot]

commit sha 412eda73877c7a897561a70b83f55ee346e18a2c

Merge #3880 3880: Add support for attributes for struct fields r=matklad a=bnjjj Hello I try to solve this example: ```rust struct MyStruct { my_val: usize, #[cfg(feature = "foo")] bar: bool, } impl MyStruct { #[cfg(feature = "foo")] pub(crate) fn new(my_val: usize, bar: bool) -> Self { Self { my_val, bar } } #[cfg(not(feature = "foo"))] pub(crate) fn new(my_val: usize, _bar: bool) -> Self { Self { my_val } } } ``` Here is a draft PR to try to solve this issue. In fact for now when i have this kind of example, rust-analyzer tells me that my second Self {} miss the bar field. Which is a bug. I have some difficulties to add this features. Here in my draft I share my work about adding attributes support on struct field data. But I'm stuck when I have to fetch attributes from parent expressions. I don't really know how to do that. For the first iteration I just want to solve my issue without solving on all different expressions. And then after I will try to implement that on different kind of expression. I think I have to fetch my FunctionId and then I will be able to find attributes with myFunction.attrs() But I don't know if it's the right way. @matklad (or anyone else) if you can help me it would be great :D Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

view details

Aleksey Kladov

commit sha 8f01e62bb962fbe282344125f6ace54326efcaa3

Scale back the traits

view details

push time in 2 months

PR opened rust-analyzer/rust-analyzer

add diagnostics subcommand to rust-analyzer CLI

This PR adds a diagnostics subcommand to the rust-analyzer CLI. The intent is to detect all diagnostics on a workspace. It returns a non-zero status code if any error diagnostics are detected. Ideally I'd like to run this in CI against the rust analyzer project as a guard against false positives.

$ cargo run --release --bin rust-analyzer -- diagnostics .

Questions for reviewers:

  1. Is this the proper way to get all diagnostics for a workspace? It seems there are at least a few ways this can be done, and I'm not sure if this is the most appropriate mechanism to do this.
  2. It currently prints out the relative file path as it is collecting diagnostics, but it doesn't print the crate name. Since the file name is relative to the crate there can be repeated names, so it would be nice to print some identifier for the crate as well, but it wasn't clear to me how best to accomplish this.
+117 -3

0 comment

4 changed files

pr created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha f62c73a97286a49c228cd13c32ed37340afd2c1d

add diagnostics subcommand to rust-analyzer CLI

view details

push time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha e02b3b239a62bc9846b5cc44ca8eeccec933a3b3

add diagnostics subcommand to rust-analyzer CLI

view details

push time in 2 months

pull request commentrust-analyzer/rust-analyzer

ellipsis in tuple patterns

bors r+

JoshMcguigan

comment created time in 2 months

Pull request review commentrust-analyzer/rust-analyzer

ellipsis in tuple patterns

 impl PatStack {                     Some(self.to_tail())                 }             }-            (Pat::TupleStruct { args: ref pat_ids, .. }, Constructor::Enum(enum_constructor)) => {+            (+                Pat::TupleStruct { args: ref pat_ids, ellipsis, .. },+                Constructor::Enum(enum_constructor),+            ) => {                 let pat_id = self.head().as_id().expect("we know this isn't a wild");                 if !enum_variant_matches(cx, pat_id, *enum_constructor) {                     None                 } else {-                    // If the enum variant matches, then we need to confirm-                    // that the number of patterns aligns with the expected-                    // number of patterns for that enum variant.-                    if pat_ids.len() != constructor.arity(cx)? {-                        return Err(MatchCheckErr::MalformedMatchArm);+                    let constructor_arity = constructor.arity(cx)?;+                    if let Some(ellipsis_position) = ellipsis {+                        // If there are ellipsis in the pattern, the ellipsis must take the place+                        // of at least one sub-pattern, so `pat_ids` should be smaller than the+                        // constructor arity.+                        if pat_ids.len() < constructor_arity {+                            let mut new_pattterns: Vec<PatIdOrWild> = vec![];

:+1: fixed

JoshMcguigan

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha ee822d19b7662a9055bc6693c4c40d8dcf752ea1

handle tuple patterns with ellipsis

view details

push time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha c3774aebdd3223803c9456646f5b13cbdeb8727b

add diagnostics subcommand to rust-analyzer CLI

view details

push time in 2 months

create barnchJoshMcguigan/rust-analyzer

branch : cli-diagnostics

created branch time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 9b5684a2ee5a8ae34c819626ed8e17034bc2d289

handle tuple patterns with ellipsis

view details

push time in 2 months

PR opened rust-analyzer/rust-analyzer

ellipsis in tuple patters

This PR lowers ellipsis in tuple patterns. It fixes a bug in the way ellipsis were previously lowered (by replacing the ellipsis with a single Pat::Wild no matter how many items the .. was taking the place of).

It also uses this new information to properly handle .. in tuple struct patterns when perform match statement exhaustiveness checks.

While this PR provides the building blocks for match statement exhaustiveness checks for tuples, there are some additional challenges there, so that is still unimplemented (unlike tuple structs).

+141 -58

0 comment

4 changed files

pr created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 6e29227610bafddcd56152a6c78c1f3d9d2eacc6

handle tuple patterns with ellipsis

view details

push time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 245895a6298b72a17a0d72d219206803bbe818fc

handle tuple patterns with ellipsis

view details

push time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha ab3f4ef42c225b723ea5df3982eb917bae2e78a4

WIP handle tuple patterns with ellipsis

view details

push time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha e413c0430ee8831d2947aa392fc1e60ec521b715

WIP handle tuple patterns with ellipsis

view details

push time in 2 months

create barnchJoshMcguigan/rust-analyzer

branch : tuple-ellipsis

created branch time in 2 months

issue commentrust-analyzer/rust-analyzer

missing match arm false positive

..or some issue with how I am comparing the type of the match arms to the type of the match expression..

I've confirmed the false positive you posted the screenshot of is related to this ^. The type of &self there is actually &&Literal, which is valid, but not handled correctly by the logic I wrote to check match expression types agaist match arm patterns.

The good news is #3938 does fix this false positive. The less good news is that we have the possibility for false negatives in cases where someone is matching against &&MyEnum. I suspect this would be resolved by using the type checker for comparing match arms to the match expression as suggested by @flodiebold.

@flodiebold, do you mind pointing me in the right direction on how I could get started converting this to use the type checker?

matklad

comment created time in 2 months

push eventJoshMcguigan/dotvim

Josh Mcguigan

commit sha a096b7d4d3bfb3644af8a538e8833383caf41698

remove default checkOnSave setting

view details

push time in 2 months

issue commentrust-analyzer/rust-analyzer

missing match arm false positive

Your case is related to support for .. in patterns, so I'll look into expanding hir::Pat::TupleStruct to include that information (similar to the change made in #3905).

Actually I think I mis-spoke here. In lowering, the .. is converted into a single Pat::Wild no matter how many fields it represents. I believe this is because in lowering it isn't known how many fields it will represent.

This causes challenges in downstream code, because it is hard to tell the difference between Literal::Size(_) and Literal::Size(..). But at the same time, I don't think lowering yet even knows how many patterns should be in a tuple (@matklad ?), so I'm not sure this can be solved in lowering. Perhaps we really do need a hir::Pat::DotDotPat?

I've added test cases to #3938 to demonstrate the behavior of enum tuple structs, and I don't think this is the cause of the false positive your are seeing. My guess, at this point, is that this one is related to either our ability to resolve the type of &self, or some issue with how I am comparing the type of the match arms to the type of the match expression. In either case, I do think #3938 will solve that problem (potentially by turning the false positive into the possiblity of false negatives in similar cases, but this is preferred).

@jonathandturner is this example from an open source code base that you can share?

matklad

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha bb2e5308b77e5d115df17411aaa2dd26be171b0a

missing match arm add test cases to demonstrate enum tuple struct with ellipsis behavior

view details

push time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha a59179ac2d0894dc45d614242816665b9bd6ef8a

missing match arms add test cases to demonstrate behavior of tuple with pattern

view details

push time in 2 months

issue commentrust-analyzer/rust-analyzer

missing match arm false positive

Thanks for the report @jonathandturner. Your case is related to support for .. in patterns, so I'll look into expanding hir::Pat::TupleStruct to include that information (similar to the change made in #3905).

Sorry everyone for letting all these false positives slip through!

matklad

comment created time in 2 months

push eventJoshMcguigan/monkey

Josh Mcguigan

commit sha 6615e9295df17109f3eb9e7cff436cbdcf14d6ac

remove result type from lexer return

view details

push time in 2 months

push eventJoshMcguigan/monkey

Josh Mcguigan

commit sha 6f9fc10e5b34c9e941558a3c2d1ee7eb2e06afd1

replace pom for lexing with logos

view details

push time in 2 months

startedmaciejhirsz/logos

started time in 2 months

push eventJoshMcguigan/monkey

Josh Mcguigan

commit sha 3bd5ae4cdc31ecbbff39ee8d69841855c5f5d10e

update dependencies

view details

push time in 2 months

issue commentrust-analyzer/rust-analyzer

Chalk panic on out of bound index when analyzsis-stats on rustc

We recently added a check in CI to be sure rust-analyzer doesn't panic when running analysis-stats in the rust-analyzer repository. I wonder if we should expand that check to cover the rustc repository as well.

edwin0cheng

comment created time in 2 months

issue openedneoclide/coc.nvim

Feature request: Open CocList in vertical split

Describe the solution you'd like

I'd like to be able to open CocList in a vertical split (current options are horizontal split or tab).

Additional context

Thanks for your work on coc.nvim!

created time in 2 months

push eventJoshMcguigan/dotvim

Josh Mcguigan

commit sha 5bb5e8f917ecd49ce9858eb43299b576ccecd50f

add visual mode mapping to yank selection into system clipboard

view details

push time in 2 months

pull request commentrust-analyzer/rust-analyzer

fix missing match arm false positive

I've added some additional test cases to demonstrate the behavior after this PR in cases 1-3 above.

JoshMcguigan

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha aec20e50946ea427ceb6a44451459f0cb3a84a4f

missing match arm add test for partially diverging type

view details

push time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha 26e5bb0a4efbe894d33cde3c1bc3f712fcf33cde

missing match arms add tests for match expression diverging

view details

push time in 2 months

pull request commentrust-analyzer/rust-analyzer

fix missing match arm false positive

So perhaps there are three relevant cases here.

  1. Handle the case where the match expression diverges.
enum Foo {
    A,
    B,
}

fn test() {
    match loop { } {
        Foo::A => (), 
        Foo::B => (),
    }
}

Before this PR, this would have fired the missing match arms diagnostic, because the match expression type is ! and none of the match arms fit that type, so they are all filtered out, so that leaves the ! pattern uncovered. After this PR, we would suppress the diagnostic here because the match arm types don't match the type of the match expression. Perhaps a more optimal solution would be to explicitly turn off this diagnostic of the return type of the match expression is !?

  1. Handle the case where the match expression doesn't diverge, but our current type inference infrastructure thinks it does.
enum Foo {
    A,
    B,
}

fn test() {
    match loop {
        break Foo::B
    } {
        Foo::A => (), 
        Foo::B => (),
    }
}

If I hover on the loop here, rust-analyzer tells me it is type !, but I believe it should be type Foo. From the perspective of the missing match arm diagnostic, I think this case (given the match expression type is again inferred to be !) is the same as case 1.

  1. Handle the case where the match expression type partially diverges (not sure if this is the correct wording).
fn test() -> u32 {
    match Some(1u32).map(|_| loop {}) {
        Some(val) => val,
        None => 0,
    }
}

rust-analyzer infers the type of val in Some(val) here to be u32. I think this is incorrect, but it means that with this inference the missing match arm diagnostic is not triggered. If we were to infer val as !, I suppose the missing match arm diagnostic should be updated to handle the case where the match expression type partially diverges?

Summary of the change in this PR

This PR takes the broadest approach to "solving" this, operating under the assumption that we definitely don't want any type inference issues causing false positives in this diagnostic. Given that assumption, what this PR does it suppress the missing match arms diagnostic completely if at least one match arm doesn't properly type check against the match expression. I think this solution even makes sense in the case where type inference works perfectly though, because if the users source code has a match arm that is malformed, I think we should specifically tell them that (with a MalformedMatchArm diagnostic or similar) rather than triggering a MissingMatchArms diagnostic.

JoshMcguigan

comment created time in 2 months

PR opened rust-analyzer/rust-analyzer

fix missing match arm false positive

fixes #3932

This fixes #3932 by skipping the missing match arm diagnostic in the case any of the match arms don't type check properly against the match expression.

I think this is the appropriate behavior for this diagnostic, since is_useful relies on all match arms being well formed, and the case of a malformed match arm should probably be handled by a different diagnostic.

+16 -12

0 comment

2 changed files

pr created time in 2 months

create barnchJoshMcguigan/rust-analyzer

branch : missing-match-arm-false-positive

created branch time in 2 months

issue commentrust-analyzer/rust-analyzer

missing match arm false positive

Thanks for the report @matklad. I've been looking into this, but I've not been able to come up with a minimal reproduction. I suspect this is related to a type inference issue, as I don't think in Some(child) the child is really !?

If it is a type inference issue, it can be worked around as discussed here. I did test this and it fixes this false positive in this case, but it also means the diagnostic doesn't fire when the types are actually mismatched. I still think this is probably the best option though, mismatched match arms should probably trigger a diagnostic specifically for that, rather than a missing match arm diagnostic.

I'll submit a PR to demonstrate this.

matklad

comment created time in 2 months

pull request commentrust-analyzer/rust-analyzer

add ellipsis field to hir pat record

using the .dotdot_token() accessor should work:

Thanks for pointing this out. I branched from master before that was implemented, so I wasn't seeing it.

I've marked this ready for review.

JoshMcguigan

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Benjamin Coenen

commit sha ab864ed259c10ff51f7c9c3421d098eeea7b0245

feat: add attributes support on struct fields #3870 Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

view details

Benjamin Coenen

commit sha 18a5e164838e1dc2abcc6b79d4fc2f96ffd2507c

Merge branch 'master' of github.com:rust-analyzer/rust-analyzer

view details

Luca Barbieri

commit sha 68196ccc10c60de52bb771d295879456f73ede95

Add AstElement trait, generate tokens, support tokens in enums - Adds a new AstElement trait that is implemented by all generated node, token and enum structs - Overhauls the code generators to code-generate all tokens, and also enhances enums to support including tokens, node, and nested enums

view details

Benjamin Coenen

commit sha 8f1dba6f9ae1d8d314dd9d007e4c582ed1403e8d

feat: add attributes support on struct fields and method #3870 Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

view details

IceSentry

commit sha 2a582b78a5f9c1fa908fe5f4c9ff4ab2966adb2e

Add more heuristics for hiding obvious param hints This will now hide "value", "pat", "rhs" and "other" These words were selected from the std because they are used in common functions with only a single param and are obvious by their use. I think it would be good to also hide "bytes" if the type is `[u8; n]` but I'm not sure how to get the param type signature It will also hide the hint if the passed param starts or end with the param_name

view details

IceSentry

commit sha a2dc18f71acf83dd2946622603d3da00b456d42a

remove TODO

view details

IceSentry

commit sha de6db0632228ae61f7ec1f87eaf520ccd4e46925

ignore `&mut ` and `&` when checking params

view details

IceSentry

commit sha cba694c60276f7543ee9ed1dddf3fe93209f527f

better `&mut ` and `&` matching

view details

Edwin Cheng

commit sha 6af1015f74ee8395ea7fe8339d8748089f05e3e4

Add rustc_server (ra_tt rustc bridge)

view details

Edwin Cheng

commit sha 836384393b3cb2dca003f4a2caf47e94f283f48c

Remove unused func

view details

bors[bot]

commit sha ebd1309c9a3ac0e6b0cee197f30a962d5263e727

Merge #3906 3906: Implement proc_macro rustc server r=matklad a=edwin0cheng This PR implement the `ra_tt::TokenTree` based rustc server for lib_proc_macro. Note that span information is not implemented yet. Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>

view details

Benjamin Coenen

commit sha 585bb83e2aec9c79dae8c2e031e9165f40937003

feat: add attributes support on struct fields and method #3870 Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

view details

Aleksey Kladov

commit sha dd2e8e86a9de610ca41846e0088e5e186eddf999

Fix add missing items assist order closes #3904

view details

bors[bot]

commit sha 01e5bd50f30ae22abab0733468d1e1c6dea7d506

Merge #3908 3908: Fix add missing items assist order r=matklad a=matklad closes #3904 bors r+ 🤖 Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

view details

bors[bot]

commit sha 412eda73877c7a897561a70b83f55ee346e18a2c

Merge #3880 3880: Add support for attributes for struct fields r=matklad a=bnjjj Hello I try to solve this example: ```rust struct MyStruct { my_val: usize, #[cfg(feature = "foo")] bar: bool, } impl MyStruct { #[cfg(feature = "foo")] pub(crate) fn new(my_val: usize, bar: bool) -> Self { Self { my_val, bar } } #[cfg(not(feature = "foo"))] pub(crate) fn new(my_val: usize, _bar: bool) -> Self { Self { my_val } } } ``` Here is a draft PR to try to solve this issue. In fact for now when i have this kind of example, rust-analyzer tells me that my second Self {} miss the bar field. Which is a bug. I have some difficulties to add this features. Here in my draft I share my work about adding attributes support on struct field data. But I'm stuck when I have to fetch attributes from parent expressions. I don't really know how to do that. For the first iteration I just want to solve my issue without solving on all different expressions. And then after I will try to implement that on different kind of expression. I think I have to fetch my FunctionId and then I will be able to find attributes with myFunction.attrs() But I don't know if it's the right way. @matklad (or anyone else) if you can help me it would be great :D Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>

view details

Aleksey Kladov

commit sha 8f01e62bb962fbe282344125f6ace54326efcaa3

Scale back the traits

view details

bors[bot]

commit sha 85956932872481cf4813c5e7794d981a9edb4623

Merge #3909 3909: Generate tokense r=matklad a=matklad bors r+ 🤖 Co-authored-by: Luca Barbieri <luca@luca-barbieri.com> Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

view details

Luca Barbieri

commit sha 60f4d7bd8c0ecb9f23557464e824140a2be8f41a

Provide more complete AST accessors to support usage in rustc

view details

Aleksey Kladov

commit sha 689661c95968cb438f8bd1f10ce0ee096287741b

Scale back to only two traits

view details

bors[bot]

commit sha cfc127f52988cf4f95797cb355398e3af32632aa

Merge #3911 3911: Genrate token accessors r=matklad a=matklad bors r+ 🤖 Co-authored-by: Luca Barbieri <luca@luca-barbieri.com> Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>

view details

push time in 2 months

push eventJoshMcguigan/dotvim

Josh Mcguigan

commit sha 62c98480b8f56a204e6e272afe1c26caabdec1da

remap <C-p><C-m> to show all files changed on branch

view details

push time in 2 months

pull request commentrust-analyzer/rust-analyzer

add ellipsis field to hir pat record

I created the MissingPatFields diagnostic, and I am seeing now why this wasn't actually working. A trailing .. is not treated as a DOT_DOT_PAT in a record field pat list. I believe it is parsed as the DOTDOT punctuation, and for this reason doesn't show up when we iterate over children.

Any thoughts on the best course of action here?

JoshMcguigan

comment created time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha e13e64a5be9ca735810d70ca2f9e56d9d145ffb6

add missing record field diagnostic for record patterns

view details

push time in 2 months

push eventJoshMcguigan/rust-analyzer

Josh Mcguigan

commit sha e7ed1a7a0b4629c3643c3e07939be205f98f812a

add missing record field diagnostic for record patterns

view details

push time in 2 months

Pull request review commentrust-analyzer/rust-analyzer

add ellipsis field to hir pat record

 pub fn record_pattern_missing_fields(     pat: &Pat, ) -> Option<(VariantId, Vec<LocalStructFieldId>)> {     let fields = match pat {-        Pat::Record { path: _, args } => args,+        Pat::Record { path: _, args, ellipsis: _ } => args,

So I added a bool representing the exhaustiveness to record_pattern_missing_fields, similar to record_literal_misssing fields. But record_pattern_missing_fields seems to only be called from crates/ra_hir/src/source_analyzer.rs, which also calls record_literal_missing_fields but ignores the exhaustiveness bool.

It seems this bool would be useful in creating a MissingPatField or similar diagnostic, modeled on the MissingFields diagnostic. But I'm not sure how this should be tested without implementing that diagnostic.

Can you provide some more detail on the suggestion of testing this via completion?

JoshMcguigan

comment created time in 2 months

more