syntax/c: highlight the header name in #include as a string, not a type

[Londopy]

#include <float.h> highlighted float as a type (and <, ., > as operators) because the #include line was only matched by a pattern rule, so the other top-level patterns still ran over the header name.

This makes #include lines a preproc region (like scad.yaml does), which stops the type/identifier patterns from matching inside it. The region's inner rules highlight <...> and "..." as constant.string — matching how #include "float.h" was already rendered — and keep trailing // and /* */ comments as comments. Inner rules are patterns rather than nested regions, since nested regions get top-level patterns leaked into them by highlightRegion.

Checked with pkg/highlight directly:

input	result
#include <float.h>	#include:preproc, <float.h>:constant.string
#include "float.h"	unchanged from before
# include <stdint.h> // TODO: drop	<stdint.h>:constant.string, // TODO: drop:comment
#include <bool.h> /* int */	/* int */:comment (int no longer a type)
#include MY_HEADER	all preproc
float x = 1.0f; / int y = a < b > c;	unchanged
#include <float.h> followed by float z;	second line still highlights float as type (region closes at EOL)

Closes #3930

[Andriamanitra]

This is a nice little improvement, works as expected.

You could remove "include" from the preproc rule on line 17 since it's now handled by the region.

[Londopy]

Done! Dropped include from the pattern. While retesting I noticed that left #include_next unhighlighted (the old pattern was partially matching it), so the region start now also accepts _next.

[JoeKar]

The same is valid for the cpp.yaml (maybe even more like objc.yaml), right?

[Andriamanitra]

The same is valid for the cpp.yaml (maybe even more like objc.yaml), right?

Good point! We have syntaxes for 6 different variants of C:

• arduino
• c
• cpp
• cuda
• hc
• objc

It would probably make sense to use include: "c" in at least some of these to inherit from the C syntax, but I'm not sure which ones are true supersets of C. But for this PR simply copying the rule to all of them would be fine too.

Grepping for #.*include also found three others that are not C but I guess can use a similar preprocessor (I don't think we need to touch these):

• ats
• fortran
• zscript