Regression: Syntax highlighting breaks after #define with no definition

[sean-mcmanus]

Repros with the VS Code 0.11.0-Insiders build, which got a new atom/language-c recently (0.10.2 doesn't repro this).

#ifndef _UCRT
    #define _UCRT
#endif

This is a before and after screenshot. The 2nd image is buggy on the 3rd line. The blue on the 1st line of the 1st image might be a bug that got fixed recently (not sure). The cause is the #define line without a definition, which is valid.

[lee-dohm]

I can't reproduce this using Atom v1.15.0 on Mac OS X 10.12.3, which is using language-c v0.56.0, nor on Atom v1.17.0-dev-5b6cca41e on Mac OS X 10.12.3, which is using language-c v0.57.0, the latest released version. I tested it using both C and C++ grammars and was not able to reproduce this on either version.

This appears to be a bug in VSCode itself.

[aeschli]

Trying the example with the latest version of the grammar (676056d (2017-03-07)) results in an endless loop: 'Grammar pushed & popped a rule without advancing'.
That's with VSCode's textmate engine

[Ben3eeE]

@aeschli I don't see any problems in Atom when using v0.57.0 95d9654 or when using the latest commit 17aa804

[winstliu]

I also can't reproduce. No warnings in console either.

[aeschli]

The VSCode's textmate engine has an extra check on whether a grammar advances.
It stumbles over https://github.com/atom/language-c/blob/master/grammars/c.cson#L756

          {
            'begin': '\\G'
            'end': '(?=//)|(?=/\\*(?!.*\\\\\\s*\\n))|(?<!\\\\)(?=\\n)'
            'name': 'meta.preprocessor.c'
            'patterns': [
              {
                'include': '#preprocessor-rule-conditional-line'
              }
            ]
          }

where neither the the begin nor the end pattern consume anything, in theory entering in an endless loop. Looks like the atom-textmate implementation doesn't care and continues on the next line. Maybe you have some insights on how this scenario should be handled.
My suggestion would be to add a negative lookahead for / or \n to the begin pattern to make sure that the rule is not entered in the empty case.

[winstliu]

Looks like we handle it here.

I would be open to adding a negative lookahead.

[lee-dohm]

My suggestion would be to add a negative lookahead for / or \n to the begin pattern to make sure that the rule is not entered in the empty case.

@aeschli Since we can't test whether the solution would work for you, please feel free to submit a PR. You may want to also consider either:

1. Adding the same workaround preventing infinite loops Atom uses
2. Adding a workaround that notifies you of the problem so that you can submit PRs to improve other grammars