-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Erroneous right paren when annotating closure with tuple return type #16084
Comments
I've noticed the same issue even in a much simpler case. Given the following: I want to surround the first two operands in parentheses like this: but when adding a '(' to the left of 1, a ')' is automatically added to the right of 3: Is there a way to somehow disable it until it's fixed? In cases such as this one, there's a risk to introduce some sneaky bugs due to operators' precedence rules. rust-analyzer version: |
@rdxdkr True, and that has been messing me up as well. That said, in an expression context, the insertion of a closing
If you prevent your editor from sending the |
Having the same issue using vscode. I did not find any settings to disable these automatic parenthesis being inserted - I can see some people liking this as a feature, but it should definitively be configurable. |
tl;dr: Disable automatic insertion of closing parentheses and braces with the configuration This behaviour is quite surprising to me. It was difficult to troubleshoot and figure out what which feature of Rust Analyzer is responsible for it and how to disable it. The incorrect automatically inserted parenthesis or brace can be so far away in the code that it's not visible on the screen. I found the VSCode feature
This feature is documented at https://rust-analyzer.github.io/manual.html#assists-code-actions under Related issue Related PRs |
Yes, we should probably disable it fully by default (and flip the setting around to enable the chars instead). Making this work correctly is super tricky and the current implementation just lacks too many decent heuristics. |
#18939 flips the setting to be opt-in and reduces the enabled default to |
Reproduction Steps
cargo new temp
.bin.rs
, define the following function:|a: i64|
, just before the opening{
.-> (i64, i64)
Expected behavior
After adding the return type annotation to the closure, the editor should have the following text:
Observed behavior
After adding the return type annotation to the closure, the editor has the following text.
The extra closing
)
occurs at the end of the closure definition, causing a compilation error due to unmatched parentheses. Because the insertion of the extra)
may be several lines away from the point where the user is typing, this is difficult to spot as it occurs.Suspected Mechanism
(
in(i64, i64)
triggers theon_char_typed
, which then delegates toon_opening_bracket_typed
on_opening_bracket_typed
callsbracket_expr
, to determine if the(
occurred just prior to an expression that should be parenthesized.bracket_expr
recognizes the body of the lambda as a block expression, and inserts a closing)
between the closing}
of the lambda and the;
rust-analyzer version:
rust-analyzer 1.74.1 (a28077b 2023-12-04)
rust-analyzer 1.74.0-nightly (203c57d 2023-09-17)
rust-analyzer 1.74.0-nightly (65ea825 2023-09-18)
The list of rustc commits, starting at the first known bad commit is here. The subtree updates for
rust-analyzer
in this window are from this PR. This PR included commit0f1cde70
, which was an upstreaming of therust-analyzer
PR #15532, and seems the most likely commit to have introduced this error.rustc version:
rustc 1.74.1 (a28077b28 2023-12-04)
relevant settings: (eg. client settings, or environment variables like
CARGO
,RUSTC
,RUSTUP_HOME
orCARGO_HOME
)rust-mode
version 20230805.1558 (latest version on melpa)lsp-mode
version 20231124.833 (~1 week away from latest version on melpa)The text was updated successfully, but these errors were encountered: