For the purposes of this project, custom preprocessor directives are defined as preprocessor directives not part of the GLSL specification. Whilst such directives are, obviously, technically illegal, it is not unthinkable that some people may have their own (pre-)preprocess step that uses custom directives to control something, (and said step also strips out these directives to produce a valid GLSL file).
Since this is a non-standard feature, we control the design. To keep things simple and avoid unexpected behaviour, custom preprocessor directives must start with a name that conforms to an identifier: must contain only a..z | A..Z | _. If a custom preprocessor directive is found and allowed, any tokens, even invalid ones, are allowed to follow the name of the directive; no error checking of any kind will happen, and the library/server will effectively completely ignore it (other than modelling it in the AST).
Since this is a non-standard feature, it must be opt-in. We could just have an on/off toggle, but it would be better to allow the user to define a list of custom directive names that should be accepted. From the perspective of the library, this would probably just be a [&str] given to the parser/lexer. From the perspective of the server, this would have to be some sort of "project" configuration; maybe something like glsl-lsp.project.customDirectives = ["foo", "bar"].
Tasks
[x] Add a new variant to the preprocessor tokenstream type for custom directives, and modify the lexer to produce it.
[ ] Modify the parser to produce syntax highlighting tokens. Do we want a new token modifier?
[ ] Decide on a schema for defining custom directives.
[ ] Actually implement support in both the server and client.
For the purposes of this project, custom preprocessor directives are defined as preprocessor directives not part of the GLSL specification. Whilst such directives are, obviously, technically illegal, it is not unthinkable that some people may have their own (pre-)preprocess step that uses custom directives to control something, (and said step also strips out these directives to produce a valid GLSL file).
Since this is a non-standard feature, we control the design. To keep things simple and avoid unexpected behaviour, custom preprocessor directives must start with a name that conforms to an identifier: must contain only
a..z|A..Z|_. If a custom preprocessor directive is found and allowed, any tokens, even invalid ones, are allowed to follow the name of the directive; no error checking of any kind will happen, and the library/server will effectively completely ignore it (other than modelling it in the AST).Since this is a non-standard feature, it must be opt-in. We could just have an on/off toggle, but it would be better to allow the user to define a list of custom directive names that should be accepted. From the perspective of the library, this would probably just be a
[&str]given to the parser/lexer. From the perspective of the server, this would have to be some sort of "project" configuration; maybe something likeglsl-lsp.project.customDirectives = ["foo", "bar"].Tasks