Skip to content
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

Feature request: handle merge conflicts #7127

Open
Nadrieril opened this issue Jan 1, 2021 · 8 comments
Open

Feature request: handle merge conflicts #7127

Nadrieril opened this issue Jan 1, 2021 · 8 comments
Labels
A-parser parser issues C-Architecture Big architectural things which we need to figure up-front (or suggestions for rewrites :0) ) S-actionable Someone could pick this issue up and work on it right now

Comments

@Nadrieril
Copy link
Member

Nadrieril commented Jan 1, 2021

A regular source of annoyance for me is the flurry of error messages when I am resolving a merge conflict. There are syntax errors everywhere which make the code hard to read. Could rust-analyzer notice merge conflicts and refrain from emitting too many syntax errors? Maybe just a single error "syntax error: this is a merge conflict".
More far-fetched would be if ra could actually process both versions in parallel (or all 3 of them in 3-way merges), but I won't hold my breath x)

@GopherJ
Copy link

GopherJ commented Jan 2, 2021

I think it's not on rust-analyzer side, this is a common issue for all languages, vscode can have a resolve confolicts mode which disables temporarily diagnostics.

@JohnCSimon
Copy link
Member

What do other IDEs do?

@lnicola lnicola added A-parser parser issues C-Architecture Big architectural things which we need to figure up-front (or suggestions for rewrites :0) ) S-actionable Someone could pick this issue up and work on it right now labels Jan 18, 2021
@gilescope
Copy link
Contributor

Would be kinda cool though.

@gilescope
Copy link
Contributor

The cheapest thing to do would be to use the first block and skip the second block.
That way the rest of the file would parse nicely and you would avoid the ugly sea of red.

That's probably a lot cheaper to implement and would make all the difference. (maybe have a setting to say always take the first or the second conflict chunk?)

@Nadrieril
Copy link
Member Author

Nadrieril commented Jan 16, 2024

Note that rustc detects merge conflicts nicely now. Looks like this:

error: encountered diff marker
  --> compiler/rustc_pattern_analysis/src/lib.rs:49:1
   |
49 | <<<<<<< HEAD
   | ^^^^^^^ after this is the code before the merge
...
53 | ||||||| parent of 0bb9d9e0111 (Remove Ty: Copy bound)
   | -------
54 |     type Ty: Copy + Clone + fmt::Debug; // FIXME: remove Copy
55 | =======
   | -------
56 |     type Ty: Clone + fmt::Debug;
57 | >>>>>>> 0bb9d9e0111 (Remove Ty: Copy bound)
   | ^^^^^^^ above this are the incoming code changes
   |
   = help: if you're having merge conflicts after pulling new code, the top section is the code you already had and the bottom section is the remote code
   = help: if you're in the middle of a rebase, the top section is the code being rebased onto and the bottom section is the code coming from the current commit being rebased

@Veykril
Copy link
Member

Veykril commented Jan 16, 2024

I agree we should detect this to some degree at least, rustc PR that introduced this for inspiration: rust-lang/rust#106242

@Jesse-Bakker
Copy link
Contributor

One feature related to handling merge conflicts that would save me a lot of headaches would be to resolve a merge conflict in imports by merging the respective imports. For example, this is a very common conflict, where one commit added B to the imports and the other commit added C:

<<<<<< HEAD
use crate::{A, B};
======
use crate::{A, C};
>>>>>>

In this case, an assist to merge these would be awesome.

@ChayimFriedman2
Copy link
Contributor

@Jesse-Bakker Technically, this can be achieved by accepting both and configuring rustfmt import granularity. Though I agree an assist would be nice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parser parser issues C-Architecture Big architectural things which we need to figure up-front (or suggestions for rewrites :0) ) S-actionable Someone could pick this issue up and work on it right now
Projects
None yet
Development

No branches or pull requests

8 participants