3913: Remove allocations from LCA r=matklad a=matklad
I haven't actually profiled this, but not allocating a hash map (or
anything, really) seems like a good idea
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3912: Parse correctly fn f<T>() where T: Fn() -> u8 + Send {} r=matklad a=matklad
We used to parse it as T: Fn() -> (u8 + Send), which is different from
the rustc behavior of T: (Fn() -> u8) + Send
bors r+
🤖
Co-authored-by: Luca Barbieri <luca@luca-barbieri.com>
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>
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>
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>
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>
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
3884: Match check fix missing pattern panic r=flodiebold a=JoshMcguigan
As reported by @cynecx, match arm exhaustiveness checking could panic when tuple enums were missing their pattern. This was reported in the comments of #3706.
This fixes the panic, and adds a similar test to ensure tuples don't have this problem.
It turns out malformed tuple patterns are caught in the "type check" outside the `is_useful` function, while malformed enum tuple patterns are not. This makes sense to me in hindsight, since the type checker can tell that an enum is the right type even if it is missing its internal pattern, but a tuple (non-enum) just becomes a different type if it is "missing" its pattern. This discrepency is why we report a diagnostic in the tuple case (because all arms are filtered out, so there are missing arms), but not in the enum tuple case (because we return an `Err(MalformedMatchArm)` from `is_useful`). I don't think this is that big of a deal, because in both cases this is malformed code and there should eventually be a `MalformedMatchArm` diagnostic or similar. But perhaps we should change things so that if any arm fails the type check we skip the entire diagnostic? That would at least make these two cases behave in the same way.
@flodiebold
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
- 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
3826: Flatten nested highlight ranges during DFS traversal r=matklad a=ltentrup
Implements the flattening of nested highlights from #3447.
There is a caveat: I needed to add `Clone` to `HighlightedRange` to split highlight ranges ~and the nesting does not appear in the syntax highlighting test (it does appear in the accidental-quadratic test but there it is not checked against a ground-truth)~.
I have added a test case for the example mentioned in #3447.
Co-authored-by: Leander Tentrup <leander.tentrup@gmail.com>
3892: Add L_DOLLAR for TYPE_RECOVERY_SET r=matklad a=edwin0cheng
This PR is a hot fix for issue #3861 that just prevent it make the parser being stuck.
The actual problem described in https://github.com/rust-analyzer/rust-analyzer/pull/3873#issuecomment-610208693 is a very deep rabbit hole I don't want to dig right now :(
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3882: Move computation of missing fields into hir r=matklad a=matklad
cc @SomeoneToIgnore, this is that refactoring that moves computation of missing fields to hir.
it actually removes meaningful duplication between diagnostics code and the completion code. Nontheless, it's a net addition of code :(
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
3706: missing match arms diagnostic r=flodiebold a=JoshMcguigan
Following up on https://github.com/rust-analyzer/rust-analyzer/pull/3689#issuecomment-602718222, this PR creates a missing match arms diagnostic.
At the moment this is a very early draft, but I wanted to open it just to get some initial feedback.
Initial questions:
* Have I roughly created the correct boilerplate?
* Inside the new `validate_match` function:
* Am I correct in thinking I want to do validation by comparing the match arms against `match_expr`? And when analyzing `match_expr` I should be looking at it as a `hir_def::expr::Expr`?
* I mostly copied the chained if-let statements from the struct validation. Shouldn't there be a non-failable way to get an AstPtr from the hir data structures?
Thanks for all the guidance.
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
