You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
a-ClientRelating to the vscode clienta-LexerRelating to the lexera-ParserRelating to the parsera-ServerRelating to the LSP serverc-FeatureFeature request/suggestionl-GeneralRelating to any OpenGL/Vulkan
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
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.
The text was updated successfully, but these errors were encountered:
a-ClientRelating to the vscode clienta-LexerRelating to the lexera-ParserRelating to the parsera-ServerRelating to the LSP serverc-FeatureFeature request/suggestionl-GeneralRelating to any OpenGL/Vulkan
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
The text was updated successfully, but these errors were encountered: