aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | Update `DefMap` and `block_def_map` docsJonas Schievink2021-02-032-1/+25
| | |
* | | Merge #7543bors[bot]2021-02-031-23/+23
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | 7543: Grammar fixes r=Kushagra-0801 a=Kushagra-0801 I think line 235 is still wrong, but I am not sure. Is the `crated/tt` in line 252 supposed to be `crates/tt`? Co-authored-by: Kushagra Gupta <[email protected]>
| * | typo fixesKushagra Gupta2021-02-031-4/+4
| | |
| * | Grammar fixesKushagra Gupta2021-02-031-20/+20
|/ / | | | | | | | | I think line 235 is still wrong, but I am not sure. Is the `crated/tt` in line 252 supposed to be `crates/tt`?
* | Merge #7541bors[bot]2021-02-0312-100/+211
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7541: Use block_def_map in body lowering (third time's the charm) r=jonas-schievink a=jonas-schievink After https://github.com/rust-analyzer/rust-analyzer/pull/7380 and https://github.com/rust-analyzer/rust-analyzer/pull/7506 both had to be reverted, this should have finally resolved all remaining bugs. Most importantly, the optimization to skip `block_def_map` computation when the block contains no inner items was fixed (which fortunately was simpler than expected). I've ran `analysis-stats` on libstd locally, which works fine, and also ran this PR locally for a short while without issues. Note that this *still* has no (or almost no) user-facing impact, because the rest of r-a still relies on some local item support hacks. bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * | Test for name resolution with DefMap shortcutJonas Schievink2021-02-031-0/+33
| | |
| * | Shortcut `block_def_map` if there's no inner itemsJonas Schievink2021-02-035-11/+26
| | | | | | | | | | | | | | | This previously didn't work, but apparently only because of the wonky test setup
| * | Use body lowering for block_def_map testsJonas Schievink2021-02-033-68/+117
| | | | | | | | | | | | Removes the hacky and buggy custom lowering code
| * | Use block_def_map in body loweringJonas Schievink2021-02-036-26/+40
| | |
* | | Merge #7539bors[bot]2021-02-033-14/+50
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | 7539: Add cargo file tidy test r=edwin0cheng a=edwin0cheng bors r+ cc @pksunkara Co-authored-by: Edwin Cheng <[email protected]>
| * | Add cargo file tidy testEdwin Cheng2021-02-033-14/+50
|/ /
* | Merge #7538bors[bot]2021-02-031-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | 7538: Make sure normal dependencies always have version r=edwin0cheng a=pksunkara How do I prevent this happening in the future by doing something in the CI? IIRC this is the second time. Co-authored-by: Pavan Kumar Sunkara <[email protected]>
| * | Make sure normal dependencies always have versionPavan Kumar Sunkara2021-02-031-1/+1
| | |
* | | Merge #7537bors[bot]2021-02-034-27/+31
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | 7537: Fix spelling mistakes in docs/dev r=Veykril a=Veykril Also adds a line for `crates/cfg` and `crates/stdx` to the architecture. bors r+ Co-authored-by: Lukas Wirth <[email protected]>
| * | Fix spelling mistakes in docs/devLukas Wirth2021-02-034-27/+31
|/ /
* | Merge #7536bors[bot]2021-02-032-201/+317
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | 7536: Make architecture more informative r=matklad a=matklad bors r+ 🤖 Co-authored-by: Aleksey Kladov <[email protected]>
| * | Make architecture more informativeAleksey Kladov2021-02-032-201/+317
| |/ | | | | | | Call out boundaries and invariants
* | Merge #7528bors[bot]2021-02-021-4/+4
|\ \ | |/ |/| | | | | | | | | | | 7528: Update mimalloc r=kjeremy a=kjeremy Co-authored-by: kjeremy <[email protected]>
| * Update mimallockjeremy2021-02-021-4/+4
|/
* Merge #7525bors[bot]2021-02-022-2/+7
|\ | | | | | | | | | | | | | | | | | | | | 7525: Fix resolution of `crate` paths from within blocks r=jonas-schievink a=jonas-schievink They resolve to the crate root, not the DefMap's root module (which can be a block) bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * Fix resolution of `crate` paths from within blocksJonas Schievink2021-02-022-2/+7
|/ | | | | They resolve to the crate root, not the DefMap's root module (which can be a block)
* Merge #7523bors[bot]2021-02-024-16/+16
|\ | | | | | | | | | | | | | | 7523: Bump chalk and rustc_lexer r=lnicola a=lnicola bors r+ Co-authored-by: LaurenČ›iu Nicola <[email protected]>
| * Bump rustc_lexerLaurențiu Nicola2021-02-022-3/+3
| |
| * Bump chalkLaurențiu Nicola2021-02-023-13/+13
|/
* Merge #7522bors[bot]2021-02-023-7/+6
|\ | | | | | | | | | | | | | | | | | | | | 7522: Use non-deprecated memmap2 crate r=kjeremy a=kjeremy `cargo audit` complains that `memmap` is unmaintained so switch to RazrFalcon's maintained version. Removes yet another edge on winapi Co-authored-by: kjeremy <[email protected]>
| * Use non-deprecated memmap2 cratekjeremy2021-02-023-7/+6
|/ | | | | | | `cargo audit` complains that `memmap` is unmaintained so switch to RazrFalcon's maintained version. Removes yet another edge on winapi
* Merge #7521bors[bot]2021-02-021-4/+4
|\ | | | | | | | | | | | | | | 7521: cargo update r=kjeremy a=kjeremy Pulls in soundness fix from rowan. Co-authored-by: kjeremy <[email protected]>
| * cargo updatekjeremy2021-02-021-4/+4
| |
* | Merge #7520bors[bot]2021-02-021-1/+5
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 7520: Show alias underlying type r=lnicola a=lumenian Closes #7511 Display underlying type in the tooltip: ```rust pub type SomeAlias = f64 ``` instead of: ```rust pub type SomeAlias ``` Co-authored-by: lumenian <[email protected]>
| * Show alias underlying typelumenian2021-02-021-1/+5
|/
* Merge #7519bors[bot]2021-02-021-0/+14
|\ | | | | | | | | | | | | | | 7519: add useless types to the styleguide r=matklad a=matklad bors r+ Co-authored-by: Aleksey Kladov <[email protected]>
| * add useless types to the styleguideAleksey Kladov2021-02-021-0/+14
|/
* Merge #7518bors[bot]2021-02-023-2/+20
|\ | | | | | | | | | | | | | | | | | | 7518: Use the right `DefMap` when looking up modules r=jonas-schievink a=jonas-schievink Fixes the bugs encountered in https://github.com/rust-analyzer/rust-analyzer/pull/7506#issuecomment-771417467 bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * Use the right `DefMap` when looking up modulesJonas Schievink2021-02-023-2/+20
|/
* Merge #7516bors[bot]2021-02-0210-161/+96
|\ | | | | | | | | | | | | | | | | | | 7516: Revert "Use block_def_map in body lowering" r=jonas-schievink a=jonas-schievink Reverts rust-analyzer/rust-analyzer#7506 bors r+ Co-authored-by: Jonas Schievink <[email protected]>
| * Revert "Use block_def_map in body lowering"Jonas Schievink2021-02-0210-161/+96
|/
* 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-08 00:20:20 +0000