bors [Fri, 11 Nov 2022 12:32:21 +0000 (12:32 +0000)]
Auto merge of #13602 - lowr:fix/nameres-transitive-visibility, r=Veykril
fix: check visibility of each path segment
Upon path resolution, we have not been checking if every def pointed to by each segment of the path is visible from the original module. This leads to incorrect import resolutions, in particular when one uses glob imports and names collide.
There is decent amount of changes in this PR because:
- some of our tests were not correct in terms of visibility
- I left several basic nameres tests as-is (with expect test updated) since I thought it would be nice to ensure we don't resolve defs that are not visible.
- `fix_visibility` assist relied on `Semantics::resolve_path()`, which uses the name resolution procedure I'm fixing and wouldn't be able to "see through" the items with strict visibility with this patch
bors [Fri, 11 Nov 2022 12:19:30 +0000 (12:19 +0000)]
Auto merge of #13548 - lowr:fix/tt-punct-spacing, r=Veykril
Fix `tt::Punct`'s spacing calculation
Fixes #13499
We currently set a `tt::Punct`'s spacing to `Spacing::Joint` unless its next token is a trivia (i.e. whitespaces or comment). As I understand it, rustc only [sets `Spacing::Joint` if the next token is an operator](https://github.com/rust-lang/rust/blob/5b3e9090757da9a95b22f589fe39b6a4b5455b96/compiler/rustc_parse/src/lexer/tokentrees.rs#L77-L78) and we should follow it to guarantee the consistent behavior of proc macros.
bors [Mon, 7 Nov 2022 15:04:40 +0000 (15:04 +0000)]
Auto merge of #13568 - noritada:fix/len-of-byte-string-with-escaped-newlines, r=Veykril
Fix the length displayed for byte string literals with escaped newlines
This is a fix for the problem I reported earlier: "the length of byte strings containing escaped newlines is displayed two bytes longer when the first escaped character is a newline".
I would appreciate it if you could review the fix.
Many thanks.
Previously, when triggering a method extraction from within an impl trait block, then this would always create a new impl block for
the struct, even if there already is one. Now, if there is already an existing trait-less impl block, then it'll put the extracted method in there.
**Caveats**:
- It currently requires the target impl block to be non-empty. This limitation is because the current architecture takes a `node_to_insert_after` as reference for where to insert the extracted function. An empty impl block doesn't have such a reference node, since it's empty. It seems that supporting this requires a much larger and more complex change.
- This is my first contribution in rust, so apologies for any beginner mistakes.
bors [Wed, 2 Nov 2022 11:06:54 +0000 (11:06 +0000)]
Auto merge of #13527 - unexge:use-let-else-stmt-in-convert-to-guarded-return-assist, r=jonas-schievink
Use let-else statements in `Convert to guarded return` assist
Follow up for https://github.com/rust-lang/rust-analyzer/pull/13516, addresses remaining part of https://github.com/rust-lang/rust-analyzer/issues/13254#issuecomment-1250408527
bors [Wed, 2 Nov 2022 10:50:08 +0000 (10:50 +0000)]
Auto merge of #13359 - feniljain:feat-must-use-option, r=Veykril
feat: add config for inserting must_use in `generate_enum_as_method`
Should fix #13312
Didn't add a test because I was not sure on how to add test for a specific configuration option, tried to look for the usages for other `AssistConfig` variants but couldn't find any in `tests`. If there is a way to test this, do point me towards it.
I tried to extract the formatting string as a common `template_string` and only have if-else for that, but it didn't compile :(
Also it seems these tests are failing:
```
test config::tests::generate_config_documentation ... FAILED
test config::tests::generate_package_json_config ... FAILED
```
Can you also point me to how to correct these 😅 ( I guess there is some command to automatically generate these? )
bors [Wed, 2 Nov 2022 10:15:18 +0000 (10:15 +0000)]
Auto merge of #13517 - feniljain:fix_completions, r=Veykril
fix: make custom expr prefix completions to understand refs
Possible fix of #7929
While reviewing the postfix completion code I saw that while calling `add_custom_postfix_completions` we were doing it under the part where reference was not taken into consideration, but as we are only adding postfix completions with `Expr` scope ( [source](https://github.com/rust-lang/rust-analyzer/blob/ba28e19b7838e3ad4223ae82d074dc3950ef1548/crates/ide-completion/src/completions/postfix.rs#L272) )
I shifted the `add_custom_postfix_completions` call to part where references are considered
I am not sure if this is the correct fix or I am understanding the problem exactly but this small move seemed to have fixed the issue :)
bors [Tue, 1 Nov 2022 17:01:07 +0000 (17:01 +0000)]
Auto merge of #13525 - jonas-schievink:generic-call-signature, r=jonas-schievink
feat: show signature help when calling generic types implementing `FnOnce`
This queries chalk for the `FnOnce` impl of callees and takes argument and return types from there, making generic `Callable`s available to the IDE. This makes signature help work for them, and potentially allows other features to take generic callables into account in the future.
bors [Mon, 31 Oct 2022 15:39:20 +0000 (15:39 +0000)]
Auto merge of #13523 - lowr:fix/adjust-expectation-for-if, r=lnicola
fix: disregard type variable expectation for if expressions
Fixes #13522
As [the comment](https://github.com/rust-lang/rust-analyzer/blob/8142d1f606dc2e52b1d2b8992671e2bd73379f28/crates/hir-ty/src/infer.rs#L1087-L1090) on `Expectation::adjust_for_branches` explains:
> If the expected type is just a type variable, then don't use an expected type. Otherwise, we might write parts of the type when checking the 'then' block which are incompatible with the 'else' branch.
Note that we already use it in match expressions. I've added tests for them too nevertheless.
projects / rust.git / log