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

Check for version control conflict markers #32059

Closed
Manishearth opened this issue Mar 5, 2016 · 10 comments
Closed

Check for version control conflict markers #32059

Manishearth opened this issue Mar 5, 2016 · 10 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The parsing of Rust source code to an AST C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Manishearth
Copy link
Member

See https://twitter.com/whitequark/status/706091651979083776

If a C file has a version control conflict marker (e.g. <<<<<<<<< HEAD or >>>>>>>>>>>>> branch), clang will helpfully detect it and spit out a more specific parse error. Sounds like something we could be doing too.

@Manishearth Manishearth added A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The parsing of Rust source code to an AST labels Mar 5, 2016
@msjyoo

This comment has been minimized.

@tiehuis
Copy link
Contributor

tiehuis commented Mar 22, 2016

I'm actually quite interested in implementing this. It looks reasonable enough on a cursory glance.

My initial approach would likely be modifying the lexer itself and identifying conflict markers there. Seems like the most straight-forward approach given the line-based nature of conflict markers. There are probably a few different behaviours that could be explored (do we continue lexing? attempt to parse using one-conflict etc?) but more discussion is probably required before choosing anything complex.

Any suggestions are appreciated.

@Manishearth
Copy link
Member Author

That sounds ok to me. Let me know if you have further questions!

@gchp
Copy link
Contributor

gchp commented May 30, 2016

@tiehuis did you make any progress on this? If not, I'd be interesting if giving it a shot myself...

@tiehuis
Copy link
Contributor

tiehuis commented May 30, 2016

I have made some progress, but a few things were still left to do. Been a bit inactive, so feel free to take a go. The rough approach I have which may be of some use) is:

  • Modify the lexer at the < token scan to perform a scan through the source for a consecutive series of < tokens. If we find a match, then assume this is a version control marker and scan for a closing sequence of >>>>>>>.
  • If a closing sequence is found, then report an error that a warning control marker is found and set a flag indicating that we are currently in a version control statement.
  • Continue lexing tokens as normal. We assume that the new-diff contents (before =======) are the valid for the sake of better error messages.
  • Once we find a =, then check if we are in a version-control scan state and scan for the diff marker. If this is the marker, then skip the old-diff and jump to the end of the trailing >>>>>>>. We know this exists.

@Centril
Copy link
Contributor

Centril commented Mar 26, 2020

cc @matklad re. lexer impl.

@PoignardAzur
Copy link
Contributor

PoignardAzur commented Aug 25, 2021

Any progress on this? If not, is there a specific blocker, or just a lack of manpower?

@Manishearth
Copy link
Member Author

Lack of people working on this

estebank added a commit to estebank/rust that referenced this issue Dec 29, 2022
@estebank
Copy link
Contributor

estebank commented Dec 29, 2022

#106242 will address some specific cases, but because it happens in the parser and not the lexer, it doesn't have full coverage for all cases people might encounter, but it does cover a few I thought of. At the very least, a check for where bounds, for ADT bodies and type parsing should be added. The PR also makes no attempt to recover the parser state (even though it potentially could because we're in the parser) because I don't want to deal with the emission of weird errors that might confuse people more than they would help.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 29, 2022
Detect diff markers in the parser

Partly address rust-lang#32059.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 29, 2022
Detect diff markers in the parser

Partly address rust-lang#32059.
Aaron1011 pushed a commit to Aaron1011/rust that referenced this issue Jan 6, 2023
Detect diff markers in the parser

Partly address rust-lang#32059.
@estebank
Copy link
Contributor

Closing, we can open new tickets if specific cases are found where the current approach doesn't trigger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-parser Area: The parsing of Rust source code to an AST C-feature-request Category: A feature request, i.e: not implemented / a PR. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

9 participants