bug#63957: 29.0.91; c-ts-mode: incorrect fontification in alloc.c

[Yuan Fu <casouri@gmail.com>]

>> 
>>>>> emacs -Q
>>>>> C-x C-f src/alloc.c RET
>>>>> M-x c-ts-mode RET
>>>>> C-u 3184 M-g g
>>>>> 
>>>>> Observe that several "else if" clauses in the following fragment are not
>>>>> fontified correctly:
>>>> 
>>>> Adding the relevant folks.
>>>> 
>>>> Could you guys please look into this issue?
>> 
>> Ok, so this is one of such cases where the preproc directives severs the code and the parser can’t recover very well. We can cover it over by just fontifying “else if” with keyword face, but there are a million ways for the preproc directive to mess up the parser, I don’t think we can cover every case.
> 
> Can you explain what is special in this particular case that is
> different from other preprocessor directives?  I'd like to think if
> this case is important enough to try harder.

I wouldn’t say that this case is special, actually the cases we were able to more or less fix are special. The problem with preproc directives is that they can appear anywhere and break whatever construct they appear in. (Because tree-sitter-c parses preproc constructs as top-level constructs, higher than anything else.)

Say there’s a struct:

struct A
{
  int a;
  int b;
}

If we add preproc directives:

struct A
{
#if A
  int a;
#else  
  int b;
}
#endif

Now the parser will parse the "struct A {“ individually; parse “int a;” individually; and parse “int b; }” individually.

So in general, if a preproc directives butchers some construct, the first part is usually fine (eg, the “struct A {“ part), but the rest often have problems. Like a dangling “else if {}” in if-else-if, or a dangling “xxx }” in a function definition, or maybe a “default: xxx }” in a switch-case.

The Emacs-specific macros we were able to “fix” all have a specific pattern, so we can find them and expect them to have a certain shape, but the breakage caused by preproc directives don’t really have a pattern. I can’t think of a good way to handle them.

I’m not against fixing these case-by-case, if the cases becomes too many and not scalable, we can give up.

Yuan