aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | better `&mut ` and `&` matchingIceSentry2020-04-091-6/+6
| | | |
| * | | ignore `&mut ` and `&` when checking paramsIceSentry2020-04-091-3/+13
| | | |
| * | | remove TODOIceSentry2020-04-081-1/+0
| | | |
| * | | Add more heuristics for hiding obvious param hintsIceSentry2020-04-081-4/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | Merge #3919bors[bot]2020-04-0923-341/+247
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3919: Refactor tokena accessors r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | Be consistent about token accesorsAleksey Kladov2020-04-0914-114/+36
| | | | |
| * | | | Add _token suffix to token accessorsAleksey Kladov2020-04-0912-213/+210
| | | | | | | | | | | | | | | | | | | | | | | | | I think this makes is more clear which things are : AstNode and which are : AstToken
| * | | | SimplifyAleksey Kladov2020-04-091-26/+13
| | | | |
* | | | | Merge #3917bors[bot]2020-04-093-2/+136
|\ \ \ \ \ | |_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3917: Improve tt::Subtree debug print r=matklad a=edwin0cheng Co-authored-by: Edwin Cheng <[email protected]>
| * | | | Improve tt::Subtree debug printEdwin Cheng2020-04-093-2/+136
| | | | |
* | | | | Merge #3915bors[bot]2020-04-098-9746/+7154
|\ \ \ \ \ | |/ / / / |/| / / / | |/ / / | | | | | | | | | | | | | | | | | | | | 3915: Prettify generated code r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | Put displays at the endAleksey Kladov2020-04-092-702/+706
| | | |
| * | | More compactAleksey Kladov2020-04-093-1438/+240
| | | |
| * | | More compact generated codeAleksey Kladov2020-04-094-2184/+731
| | | |
| * | | Move the rest of the tokens to generated/tokensAleksey Kladov2020-04-094-738/+751
| | | |
| * | | Move generated tokens to a separate fileAleksey Kladov2020-04-094-3092/+3121
| | | |
| * | | Start ast/generated/tokensAleksey Kladov2020-04-094-3/+10
| | | |
| * | | Prepare for spliting generated into tokens and nodesAleksey Kladov2020-04-095-9627/+9630
| | | |
| * | | Reduce visibilityAleksey Kladov2020-04-091-2/+2
| | | |
| * | | Cleanup importAleksey Kladov2020-04-091-2/+5
|/ / /
* | | Merge #3913bors[bot]2020-04-091-3/+13
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | Remove allocations from LCAAleksey Kladov2020-04-091-3/+13
|/ / / | | | | | | | | | | | | I haven't actually profiled this, but not allocating a hash map (or anything, really) seems like a good idea
* | | Merge #3912bors[bot]2020-04-093-1/+63
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | Parse correctly fn f<T>() where T: Fn() -> u8 + Send {}Luca Barbieri2020-04-093-1/+63
| | | | | | | | | | | | | | | | | | | | We used to parse it as T: Fn() -> (u8 + Send), which is different from the rustc behavior of T: (Fn() -> u8) + Send
* | | | Merge #3911bors[bot]2020-04-0920-398/+2412
|\| | | | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | 3911: Genrate token accessors r=matklad a=matklad bors r+ 🤖 Co-authored-by: Luca Barbieri <[email protected]> Co-authored-by: Aleksey Kladov <[email protected]>
| * | Scale back to only two traitsAleksey Kladov2020-04-098-227/+2019
| | |
| * | Provide more complete AST accessors to support usage in rustcLuca Barbieri2020-04-0918-214/+436
|/ /
* | Merge #3909bors[bot]2020-04-094-74/+3176
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 3909: Generate tokense r=matklad a=matklad bors r+ 🤖 Co-authored-by: Luca Barbieri <[email protected]> Co-authored-by: Aleksey Kladov <[email protected]>
| * | Scale back the traitsAleksey Kladov2020-04-093-245/+3061
| | |
| * | Add AstElement trait, generate tokens, support tokens in enumsLuca Barbieri2020-04-083-94/+380
| | | | | | | | | | | | | | | | | | | | | | | | | | | - 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
* | | Merge #3880bors[bot]2020-04-094-7/+58
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * \ \ feat: add attributes support on struct fields and method #3870Benjamin Coenen2020-04-0928-336/+522
| |\ \ \ | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | | | feat: add attributes support on struct fields and method #3870Benjamin Coenen2020-04-084-43/+30
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
| * | | | Merge branch 'master' of github.com:rust-analyzer/rust-analyzerBenjamin Coenen2020-04-07322-160/+1823
| |\ \ \ \
| * | | | | feat: add attributes support on struct fields #3870Benjamin Coenen2020-04-074-7/+71
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Benjamin Coenen <[email protected]>
* | | | | | Merge #3908bors[bot]2020-04-091-2/+4
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3908: Fix add missing items assist order r=matklad a=matklad closes #3904 bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | | | | | Fix add missing items assist orderAleksey Kladov2020-04-091-2/+4
|/ / / / / / | | | | | | | | | | | | | | | | | | closes #3904
* | | | | | Merge #3906bors[bot]2020-04-094-1/+689
|\ \ \ \ \ \ | |_|_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | | | Remove unused funcEdwin Cheng2020-04-091-3/+1
| | | | | |
| * | | | | Add rustc_server (ra_tt rustc bridge)Edwin Cheng2020-04-094-1/+691
|/ / / / /
* | | | | Merge #3902bors[bot]2020-04-081-24/+1
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | | | Better Sublime documentationElinvynia2020-04-081-24/+1
|/ / / / /
* | | | | Merge #3899bors[bot]2020-04-084-18/+8
|\ \ \ \ \ | |_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | | Enable the SemanticTokensFeature by defaultkjeremy2020-04-084-18/+8
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | Merge #3884bors[bot]2020-04-081-15/+59
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>
| * | | match checking add additional test for match checking tuple with missing patternJosh Mcguigan2020-04-081-0/+14
| | | |
| * | | fix panic in match checking when tuple enum missing patternJosh Mcguigan2020-04-081-15/+45
|/ / /
* | | Merge #3895bors[bot]2020-04-081-1/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3895: Fix warnings emitted when compiling as part of rustc r=matklad a=matklad bors r+ 🤖 Co-authored-by: Luca Barbieri <[email protected]>
| * | | Fix warnings emitted when compiling as part of rustcLuca Barbieri2020-04-081-1/+1
|/ / /
* | | Merge #3826bors[bot]2020-04-085-51/+148
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <[email protected]>