aboutsummaryrefslogtreecommitdiff
path: root/crates/ide_ssr/src/search.rs
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2021-03-02 13:32:06 +0000
committerGitHub <[email protected]>2021-03-02 13:32:06 +0000
commit657ec3616f076c85e21d82feba0397690e836bd9 (patch)
tree16b40b68f89a5964c039b1de8220d71bbaebe5e2 /crates/ide_ssr/src/search.rs
parent91bf5fa827b2c4ef74cb68c172c79127115e394f (diff)
parent864fb063a000a38ce28c8c1d0153dc080faf1cdb (diff)
parent7066e6b3620d06dbc2143b9dfdda4d7c97d6a8ba (diff)
Merge #7335 #7691
7335: added region folding r=matklad a=LucianoBestia Regions of code that you'd like to be folded can be wrapped with `// #region` and `// #endregion` line comments. This is called "Region Folding". It is originally available for many languages in VSCode. But Rust-analyzer has its own folding function and this is missing. With this Pull Request I am suggesting a simple solution. The regions are a special kind of comments, so I added a bit of code in the comment folding function. The regex to match are: `^\s*//\s*#?region\b` and `^\s*//\s*#?endregion\b`. The number of space characters is not important. There is an optional # character. The line can end with a name of the region. Example: ```rust // 1. some normal comment // region: test // 2. some normal comment calling_function(x,y); // endregion: test ``` I added a test for this new functionality in `folding_ranges.rs`. Please, take a look and comment. I found that these exact regexes are already present in the file `language-configuration.json`, but I don't find a way to read this configuration. So my regex is hardcoded in the code. 7691: Suggest name in extract variable r=matklad a=cpud36 Generate better default name in extract variable assist as was mentioned in issue #1587 # Currently supported (in order of declining precedence) 1. Expr is argument to a function; use corresponding parameter name 2. Expr is result of a function or method call; use this function/method's name 3. Use expr type name (if possible) 4. Fallback to `var_name` otherwise # Showcase ![generate_derive_variable_name_from_method](https://user-images.githubusercontent.com/4218373/108013304-72105400-701c-11eb-9f13-eec52e74d0cc.gif) ![generate_derive_variable_name_from_param](https://user-images.githubusercontent.com/4218373/108013305-72a8ea80-701c-11eb-957e-2214f7f005de.gif) # Questions * Should we more aggressively strip known types? E.g. we already strip `&T -> T`; should we strip `Option<T> -> T`, `Result<T, E> -> T`, and others? * Integers and floats use `var_name` by default. Should we introduce a name, like `i`, `f` etc? * Can we return a list and suggest a name when renaming(like IntelliJ does)? * Should we add counters to remove duplicate variables? E.g. `type`, `type1`, type2`, etc. Co-authored-by: Luciano Bestia <[email protected]> Co-authored-by: Luciano <[email protected]> Co-authored-by: Vladyslav Katasonov <[email protected]>