Skip to content

Automatically add semicolon #3830

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

Open
mikhail-m1 opened this issue Apr 2, 2020 · 17 comments
Open

Automatically add semicolon #3830

mikhail-m1 opened this issue Apr 2, 2020 · 17 comments
Labels
C-enhancement Category: enhancement S-unactionable Issue requires feedback, design decisions or is blocked on other work

Comments

@mikhail-m1
Copy link
Contributor

Can we add a semicolon at the end if something is added in not to the end of function?
for example

fn x() {
bar();
// <- I am starting typing here and want to have a semicolon at the end of the line
foo()
}
@bjorn3
Copy link
Member

bjorn3 commented Apr 2, 2020

You may have wanted to type x.. Rust analyzer wouldn't now if you wanted that or not.

@mikhail-m1
Copy link
Contributor Author

I don't get it about x. because I cannot find a case when ; is not needed, but in next cases it shouldn't be added (or should be removed):

  • if
  • loop
  • for
  • while

@bjorn3
Copy link
Member

bjorn3 commented Apr 2, 2020

You may have wanted to end up with x.foo().

@mikhail-m1
Copy link
Contributor Author

@bjorn3 if x. on a new line semicolon should be added and rust-analyzer already has join line command.

@bjorn3
Copy link
Member

bjorn3 commented Apr 3, 2020

I think it is more annoying if something gets added when you didn't want it, than having to add it manually when you want. Maybe make adding the semicolon an off by default thing?

@matklad
Copy link
Member

matklad commented Apr 3, 2020

Yeah, I also with that rust-analyzer handled semicolons in more cases. I am afraid though that just "type something" would be a too impercise heuristic here. Like, if the user types let v = , we want to add the semi after foo(), and not at the end of the line (and we already do that). Moreover, if the user types loop {}, we shouldn't be adding a semicolon, as block expressions do not require one.

I definitely will be fine with merging this as off-by-default though, for the sake of experimentation. IntelliJ has complete statement feature for similar cases, but I personally have never figured out how to use it effectively.

@mikhail-m1
Copy link
Contributor Author

looks like it will affect performance :(
in Analysis::on_char_typed parse only runs for .=> and it would require run it for all characters.

@matklad
Copy link
Member

matklad commented Apr 12, 2020

One specific thing we can try is extending this:

https://github.com/rust-analyzer/rust-analyzer/blob/268b7987290143550461090c2c0e23371813dbec/crates/ra_ide/src/typing.rs#L63

to add a semicolon after = in the following cases:

  • ^let foo =$
  • ^foo =$

Be warned though, that I have a vague recollection that I've actually tried doing that, (or something similar) and was unable to add new characters immediately after the cursor, due to how vscode works.

@mikhail-m1
Copy link
Contributor Author

mikhail-m1 commented Apr 13, 2020

I checked how it can be done, and found:

  1. on_eq_typed is called on textDocument/onTypeFormatting and in mine vscode format for each line was off, so it was never executed. And in general I don't think this is the right callback for changes like this.
  2. on_enter looks a an option, ; can be added after { and ; and unnecessary ; can be removed by rustfmt later but:
  • I cannot find simple rule for not adding it to last return statement
  • in my vscode Shif +Enter is bound to Insert line below and I don't want to create another command to support it.
  1. Maybe there is a way to automatically apply a fix for missing ;, but I haven't checked is any way to do it.

@acilcenter
Copy link

Automatic semicolon insertion is never a good idea. It may not totally apply but we know automatic semicolon insertion was one of Eich's regret about the language.

https://brendaneich.com/2012/04/the-infernal-semicolon/

You may argue this is nothing to do with Rust, this is just a tool but few years later there will be more and more people asking or depending of this feature. Things will get more complicated.

@matklad
Copy link
Member

matklad commented Apr 24, 2020

The feature described here has nothing to do with JavaScript style ASI.

@acilcenter
Copy link

acilcenter commented Apr 25, 2020

I was trying to bring your attention to a well known example of adding unnecessary complexiy early in the project to solve a very trivial problem, based on the earlier comments. Never mind.

@lnicola lnicola added the S-unactionable Issue requires feedback, design decisions or is blocked on other work label Jan 25, 2021
@iMonZ
Copy link

iMonZ commented Jun 5, 2022

anything new here?

@futurist
Copy link

futurist commented Oct 2, 2022

Rust need semicolon, seems that cannot changed: rust-lang/rfcs#2583
But we need this feature to reduce the unnecessary mechanical work when there should clearly need a semicolon.
Leave any uncertain case untouched is always the part of the solution.
There're always exceptions, when people don't want this ASI feature, they can turn off using an option, but I believe this feature can improve the efficiency when people from Python/JS/Scala, Or Go, or sometimes we have a need to work with many languages mixed in a big project. Oh, even the Old Bash-Script don't need semicolon when newline there.
Maybe Rust can have this feature as an Explicit Semicolon Insertion vs ASI? The Explicit also matches rust's philosophy?

@indiejames
Copy link

Maybe an option to insert missing semis on save?

@Veykril Veykril added the C-enhancement Category: enhancement label Feb 9, 2023
@t101804
Copy link

t101804 commented Jan 2, 2024

any info?

@Veykril
Copy link
Member

Veykril commented Aug 10, 2024

Maybe an option to insert missing semis on save?

Right now formatting is handled via rustfmt and we are quite a bit a way from having our own formatter so this isn't really something we can tackle right now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: enhancement S-unactionable Issue requires feedback, design decisions or is blocked on other work
Projects
None yet
Development

No branches or pull requests

10 participants