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

newlines in impl definition break syntax highlighting #493

Open
fpdotmonkey opened this issue Aug 2, 2022 · 2 comments
Open

newlines in impl definition break syntax highlighting #493

fpdotmonkey opened this issue Aug 2, 2022 · 2 comments
Labels
A-syntax Area: Syntax highlighting

Comments

@fpdotmonkey
Copy link

Sublime Text Version

Build 4126

Rust Enhanced Version

v2.25.0

Operating system

OS Name Microsoft Windows 10 Home
Version 21H2 build 19044.1826

Expected behavior

For the following snippet, the trait name should be colored like normal text and the for keyword should colored like a keyword

impl ThisTraitHasAVeryLongNameWhichCausesTheEndOfTheStatementToGoToTheNextLineWithWrongHighlight
    for MyType
{
}

This may occur in cases where you implement e.g. TryFrom<U> where U is very templated or deep in some module structure.

Actual behavior

The trait name is highlighted like it's the type name and for is not highlighted like a keyword.

image

Steps to reproduce

  1. Copy the snippet into Sublime
  2. Observe errant highlighting
@ehuss ehuss changed the title Very long trait names lead to incorrect syntax highlighting newlines in impl definition break syntax highlighting Aug 3, 2022
@ehuss ehuss added the A-syntax Area: Syntax highlighting label Aug 3, 2022
@ehuss
Copy link

ehuss commented Aug 3, 2022

Thanks for the report. The issue isn't necessarily the very long identifier, but the fact that newlines aren't supported, as in:

impl Foo
for Bar
{}

The cause is that the syntax highlighting rules in Sublime can't cross newlines. The lookahead rule here can't see to the next line.

I'm not sure what the best way is to fix it, but I think it will be rather involved (perhaps by creating additional states?). In general, the use of lookaheads is a bit fragile, particularly around newlines.

@fpdotmonkey
Copy link
Author

A really dumb way would be to change how for lines are highlighted, e.g. if the word after for looks like a type and there's no in on that line, then it must be the second line of a impl ... for ... statement

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-syntax Area: Syntax highlighting
Projects
None yet
Development

No branches or pull requests

2 participants