Aleksey Kladov [Sun, 15 Aug 2021 10:24:37 +0000 (13:24 +0300)]
internal: optimize compile time
cargo llvm-lines shows that path_to_error bloats the code. I don't think
I've needed this functionality recently, seems that we've fixed most of
the serialization problems. So let's just remove it. Should be easy to
add back if we ever need it, and it does make sense to keep the
`from_json` function around.
bors[bot] [Sat, 14 Aug 2021 15:52:48 +0000 (15:52 +0000)]
Merge #9893
9893: fix: Don't use uncached syntax nodes in `generate_function` for sema lookups r=Veykril a=Veykril
Fixes the crash in the comment here https://github.com/rust-analyzer/rust-analyzer/issues/9382#issuecomment-896101298
Couldn't make out a repro test for this unfortunately
still not idea about the original issue
Aleksey Kladov [Sat, 14 Aug 2021 13:40:00 +0000 (16:40 +0300)]
internal: make invert binary op more robust
Previously, we only inverted comparison operators (< and the like) if
the type implemented Ord. This doesn't make sense: if `<` works, then
`>=` will work as well!
Extra semantic checks greatly reduce robustness and predictability of
the assist, it's better to keep things simple.
It looks like `compile` expects to be called like `RegExp.compile("foo", "m")`, so calling `.compile()` on an existing regex replaces it with an empty one.
bors[bot] [Fri, 13 Aug 2021 11:19:16 +0000 (11:19 +0000)]
Merge #9871
9871: Jump to generated func r=mahdi-frms a=rylev
Worked on this with `@yoshuawuyts.`
We thought we ran into an issue with the `generate_function` assist where the code was not being generated in a certain situations. However, it wasn't actually a bug just a very confusing implementation where the cursor is not moved to the newly generated function. This happened when the return type was successfully inferred (and not unit). The function would be generated, but selection would not be changed.
This can be very confusing: If the function is generated somewhat far from where the assist is being invoked, the user never sees that the code was generated (nor are they given the chance to actually implement the function body).
This PR makes it so that the cursor is _always_ moved to somewhere in the newly generated function. In addition, if we can infer unit as the type, then we do not still generate `-> ()` as the return type. Instead, we simply omit the return type.
This means the selection will move to either one of two places:
* A generated `-> ()` return type when we cannot successfully infer the return type.
* The `todo!()` body when we can successfully infer the return type.
bors[bot] [Thu, 12 Aug 2021 22:28:04 +0000 (22:28 +0000)]
Merge #9879
9879: feat: Support `if let` match guards r=jonas-schievink a=jonas-schievink
Adds support for parsing and computing bindings for `if let` match guards (https://github.com/rust-lang/rust/issues/51114). Type inference support is still missing, but shouldn't be hard to add in a follow-up PR.
bors[bot] [Thu, 12 Aug 2021 17:55:29 +0000 (17:55 +0000)]
Merge #9807
9807: Implicit `Sized` bounds r=iDawer a=iDawer
This should close #8984
`hir_ty`:
- Type parameters, associated types and `impl Trait` are `Sized` by deafault except `Self` in a trait.
- Implicit `Sized` bound is added to end of predicate list. It does not check if such bound is present already. Also it does not track the bound is implicit.
- Allowed ambiguous unsize coercion if Chalk returns definite guidance.
- Allowed ambiguous autoderef if Chalk returns definite guidance.
bors[bot] [Thu, 12 Aug 2021 12:11:09 +0000 (12:11 +0000)]
Merge #9869
9869: Use term "method" on label for generating method impl r=Veykril a=rylev
When showing the user the `generate_function` assist, use the term "method" when generating a method instead of the term "function" (which is correct but maybe not the most appropriate in that context).
bors[bot] [Wed, 11 Aug 2021 09:54:09 +0000 (09:54 +0000)]
Merge #9836
9836: Refactor: quick clean-up of iteration idioms in the `vfs` crate r=matklad a=Some-Dood
This PR cleans up some of the iteration idioms used in the `vfs` crate. Most of the changes simply converted `for` loops into their `std::iter::Iterator`-method counterpart. Other changes required some inversion of logic to accommodate for better short-circuiting. Overall, there should be no behavioral changes. If there are any stylistic issues, I will gladly adhere to them and adjust the PR accordingly. Thanks!
bors[bot] [Wed, 11 Aug 2021 08:30:53 +0000 (08:30 +0000)]
Merge #9828
9828: Remove dependency on the system graphviz when rendering crate graph r=lnicola a=p32blo
This PR removes the need for having `graphviz` installed on the user system by using the `d3-graphviz` npm package.
The responsibility of rendering the svg output is moved to the extension while the rust side only handles the generation of the dot file.
This change also brings the following additional features:
- Allow zooming the view
- Ctrl+click to reset the zoom
- Adjust the color scheme to dark themes
- Works on any platform without installing graphviz locally
---
I’m not sure if this fits what you had in mind for the crates graph feature but I decided to submit it anyway to see if this is useful to anyone else.
A potential downside might be that it increases the extension size ( haven’t checked) but this feature already required the installation of graphviz on the user side, so the cost is just moved explicitly to the extension.
projects / rust.git / log