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

[Yuan Fu]

>> 
>>>>> 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