aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* Merge #7514bors[bot]2021-02-011-14/+16
|\ | | | | | | | | | | | | | | | | | | 7514: Only allow one proc-macro process r=edwin0cheng a=edwin0cheng cc @lnicola bors r+ Co-authored-by: Edwin Cheng <[email protected]>
| * Only allow one proc-macro processEdwin Cheng2021-02-011-14/+16
|/
* Merge #7512bors[bot]2021-02-013-8/+5
|\ | | | | | | | | | | | | | | 7512: Reap proc macro server instances r=lnicola a=lnicola Fixes #7510, but not the root cause. Co-authored-by: Laurențiu Nicola <[email protected]>
| * Reap proc macro server instancesLaurențiu Nicola2021-02-013-8/+5
|/
* Merge #7509bors[bot]2021-02-011-1/+34
|\ | | | | | | | | | | | | | | 7509: Improve nvim-lsp setup instructions r=lnicola a=lnicola bors r+ Co-authored-by: Laurențiu Nicola <[email protected]>
| * Improve nvim-lsp setup instructionsLaurențiu Nicola2021-02-011-1/+34
|/
* Merge #7508bors[bot]2021-02-012-5/+48
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7508: Don't filter code suggestions on Applicability r=lnicola a=CryZe I've noticed that there are various suggestions that rust-analyzer seems to filter out, even if they make sense. Here's an example of where it seems like there should be a suggestion, but there isn't: ![https://i.imgur.com/wsjM6iz.png](https://i.imgur.com/wsjM6iz.png) It turns out that this specific suggestion is not considered `MachineApplicable`, which are the only suggestions that rust-analyzer accepts. However if you read the documentation for `MachineApplicable`, [Source](https://github.com/rust-lang/rust/blob/b3897e3d1302391ed02efbac1dce8073646b8173/compiler/rustc_lint_defs/src/lib.rs#L27-L29) ```rust /// The suggestion is definitely what the user intended. This suggestion should be /// automatically applied. MachineApplicable, ``` then you realize that these are specifically only those suggestions that rust-analyzer could even automatically apply (in some distant future, behind some setting or command or so). Other suggestions that may have some semantic impact do not use `MachineApplicable`. So all other suggestions are still intended to be suggested to the user, just not automatically applied without the user being consulted. [Source](https://github.com/rust-lang/rust/blob/b3897e3d1302391ed02efbac1dce8073646b8173/compiler/rustc_lint_defs/src/lib.rs#L22-L24) ```rust /// All suggestions are marked with an `Applicability`. Tools use the applicability of a suggestion /// to determine whether it should be automatically applied or if the user should be consulted /// before applying the suggestion. ``` So with that in mind, rust-analyzer should almost definitely not filter out `MaybeIncorrect` (which honestly is named horribly, it just means that it's a semantic change, not just a syntactical one). Then there's `HasPlaceholders` which basically is just another semantic one, but with placeholders. The user will have to make some adjustments, but the suggestion still is perfectly valid. rust-analyzer could probably detect those placeholders and put proper "tab through" markers there for the IDE, but that's not necessary for now. Then the last one is `Unspecified` which is so unknown that I don't even know how to judge it, meaning that the suggestion should probably also just be suggested to the user and then they can decide. So with all that in mind, I'm proposing to get rid of the check for Applicability entirely. Co-authored-by: Christopher Serr <[email protected]>
| * Update Test DataChristopher Serr2021-02-011-1/+46
| |
| * Don't filter code suggestions on ApplicabilityChristopher Serr2021-02-011-4/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've noticed that there are various suggestions that rust-analyzer seems to filter out, even if they make sense. Here's an example of where it seems like there should be a suggestion, but there isn't: ![https://i.imgur.com/wsjM6iz.png](https://i.imgur.com/wsjM6iz.png) It turns out that this specific suggestion is not considered `MachineApplicable`, which are the only suggestions that rust-analyzer accepts. However if you read the documentation for `MachineApplicable`, https://github.com/rust-lang/rust/blob/b3897e3d1302391ed02efbac1dce8073646b8173/compiler/rustc_lint_defs/src/lib.rs#L27-L29 then you realize that these are specifically only those suggestions that rust-analyzer could even automatically apply (in some distant future, behind some setting or so). Other suggestions that may have some semantic impact do not use `MachineApplicable`. So all other suggestions are still intended to be suggested to the user, just not automatically applied without the user being consulted. https://github.com/rust-lang/rust/blob/b3897e3d1302391ed02efbac1dce8073646b8173/compiler/rustc_lint_defs/src/lib.rs#L22-L24 So with that in mind, rust-analyzer should almost definitely not filter out `MaybeIncorrect` (which honestly is named horribly, it just means that it's a semantic change, not just a syntactical one). Then there's `HasPlaceholders` which basically is just another semantic one, but with placeholders. The user will have to make some adjustments, but the suggestion still is perfectly valid. rust-analyzer could probably detect those placeholders and put proper "tab through" markers there for the IDE, but that's not necessary for now. Then the last one is `Unspecified` which is so unknown that I don't even know how to judge it, meaning that the suggestion should probably also just be suggested to the user and then they can decide. So with all that in mind, I'm proposing to get rid of the check for Applicability entirely.
* Merge #7507bors[bot]2021-02-011-0/+4
|\ | | | | | | | | | | | | | | 7507: Explain what to do if a release fails r=lnicola a=lnicola bors r+ Co-authored-by: Laurențiu Nicola <[email protected]>
| * Explain what to do if a release failsLaurențiu Nicola2021-02-011-0/+4
| |
* | Merge #7506bors[bot]2021-02-0110-96/+161
|\ \ | |/ |/| | | | | | | | | | | | | | | 7506: Use block_def_map in body lowering r=jonas-schievink a=jonas-schievink This makes `lower_block` update the `DefMap` and `ModuleId` used by the expander to the corresponding `block_def_map`. This cleans up a bit of code, but doesn't expose any new features. bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * Shortcut `block_def_map` if there's no inner itemsJonas Schievink2021-02-011-2/+4
| | | | | | | | | | This previously didn't work, but apparently only because of the wonky test setup
| * Use body lowering for block_def_map testsJonas Schievink2021-02-013-68/+117
| | | | | | | | Removes the hacky and buggy custom lowering code
| * Use block_def_map in body loweringJonas Schievink2021-02-016-26/+40
|/
* Merge #7503bors[bot]2021-01-312-1/+25
|\ | | | | | | | | | | | | | | 7503: Return inner attributes of outline mod declarations in `attrs_query` r=jonas-schievink a=Veykril Co-authored-by: Lukas Wirth <[email protected]>
| * Return inner attributes of outline mod declarations in `attrs_query`Lukas Wirth2021-01-312-1/+25
| |
* | Merge #7502bors[bot]2021-01-312-8/+23
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | 7502: Honor #![macro_use] in mod source files r=jonas-schievink a=Veykril Fixes #7501 Since `ItemTree` builds the `RawAttrs` directly we need the special check here as I don't think we can fix this in `RawAttrs` constructor as its solely AST based and we need to touch two different ASTs here. This just made me realize that `attrs_query` suffers from a similar problem, for example hovering an outline `mod` decl won't show inner docs, only outer ones, #7503. Co-authored-by: Lukas Wirth <[email protected]>
| * Honor #![macro_use] in mod source filesLukas Wirth2021-01-312-8/+23
|/
* Merge #7500bors[bot]2021-01-301-2/+19
|\ | | | | | | | | | | | | | | | | | | 7500: Fix ast::String::value not properly escaping in some cases r=Veykril a=Veykril Fixes #7496 bors r+ Co-authored-by: Lukas Wirth <[email protected]>
| * Fix ast::String::value not properly escaping in some casesLukas Wirth2021-01-301-2/+19
| |
* | Merge #7483bors[bot]2021-01-305-27/+59
|\ \ | |/ |/| | | | | | | | | | | 7483: Classify function calls as functions when shadowed by types r=matklad a=Veykril Fixes #7479 Co-authored-by: Lukas Wirth <[email protected]>
| * Prefer ValueNS when resolving hir path for PathExpressionsLukas Wirth2021-01-291-14/+31
| |
| * Classify function calls as functions when shadowed by typesLukas Wirth2021-01-285-16/+31
| |
* | Merge #7494bors[bot]2021-01-304-74/+71
|\ \ | | | | | | | | | | | | | | | | | | | | | 7494: Simpilfy mbe parsing r=edwin0cheng a=edwin0cheng bors r+ Co-authored-by: Edwin Cheng <[email protected]>
| * | Simpilfy mbe parsingEdwin Cheng2021-01-304-74/+71
| | |
* | | Merge #7493bors[bot]2021-01-291-0/+2
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 7493: Add --print-config-schema to help r=lnicola a=lnicola bors r+ Co-authored-by: Laurențiu Nicola <[email protected]>
| * | Add --print-config-schema to helpLaurențiu Nicola2021-01-291-0/+2
|/ /
* | Merge #7491bors[bot]2021-01-296-210/+180
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 7491: Simplify mbe match error. r=edwin0cheng a=edwin0cheng Handle parse error in rule parsing instead of matching in mbe. bors r+ Co-authored-by: Edwin Cheng <[email protected]>
| * | Simplify mbe match error.Edwin Cheng2021-01-296-210/+180
| | | | | | | | | | | | Handle parse error in rule parsing instead of match in mbe
* | | Merge #7490bors[bot]2021-01-291-4/+4
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7490: cargo update r=kjeremy a=kjeremy Co-authored-by: kjeremy <[email protected]>
| * | | cargo updatekjeremy2021-01-291-4/+4
|/ / /
* | | Merge #7489bors[bot]2021-01-291-2/+2
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | 7489: :arrow_up: rowan r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | :arrow_up: rowanAleksey Kladov2021-01-291-2/+2
|/ /
* | Merge #7488bors[bot]2021-01-294-5/+5
|\ \ | | | | | | | | | | | | | | | | | | | | | 7488: Rename mbe_expander for consistency r=edwin0cheng a=edwin0cheng bors r+ Co-authored-by: Edwin Cheng <[email protected]>
| * | Rename mbe_expander for consistencyEdwin Cheng2021-01-294-5/+5
|/ /
* | Merge #7487bors[bot]2021-01-281-1/+22
|\ \ | | | | | | | | | | | | | | | | | | | | | 7487: Forbid flyimport completions in use statements r=SomeoneToIgnore a=SomeoneToIgnore Closes #7469 Co-authored-by: Kirill Bulatov <[email protected]>
| * | Forbid flyimport completions in use statementsKirill Bulatov2021-01-281-1/+22
|/ /
* | Merge #7486bors[bot]2021-01-281-2/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | 7486: :arrow_up: rowan r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | :arrow_up: rowanAleksey Kladov2021-01-281-2/+2
| | |
* | | Merge #7485bors[bot]2021-01-282-16/+9
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7485: Fix incorrect `FileId` and remove broken shortcut r=jonas-schievink a=jonas-schievink Apparently we were using the crate's root file instead of the file containing the block. bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * | | Fix incorrect `FileId` and remove broken shortcutJonas Schievink2021-01-282-16/+9
|/ / / | | | | | | | | | | | | Apparently we were using the crate's root file instead of the file containing the block.
* | | Merge #7482bors[bot]2021-01-281-0/+63
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | 7482: block_def_map: add a few macro tests r=jonas-schievink a=jonas-schievink bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * | block_def_map: add a few macro testsJonas Schievink2021-01-281-0/+63
| | |
* | | Merge #7412bors[bot]2021-01-2814-202/+406
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7412: Async loading for outdir and proc-macro r=maklad a=edwin0cheng cc #7328 ![Peek 2021-01-24 02-04](https://user-images.githubusercontent.com/11014119/105610083-8f208100-5de8-11eb-8e96-c2d4e349b352.gif) [Edit] ~~Finding a way to know when the workspace and build data are loaded...~~ [Edit 2] Not perfect solution, but seem to work now. Co-authored-by: Edwin Cheng <[email protected]>
| * | Update lsp-extension.md hashEdwin Cheng2021-01-281-1/+1
| | |
| * | bug fixEdwin Cheng2021-01-281-1/+1
| | |
| * | Update docEdwin Cheng2021-01-281-1/+1
| | |
| * | Update vscode for new statusEdwin Cheng2021-01-282-1/+7
| | |
| * | Async Loading outdir and proc-macroEdwin Cheng2021-01-2811-199/+397
| |/