Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support custom preprocessor directives #17

Open
1 of 4 tasks
KubaP opened this issue Dec 27, 2023 · 0 comments
Open
1 of 4 tasks

Support custom preprocessor directives #17

KubaP opened this issue Dec 27, 2023 · 0 comments
Labels
a-Client Relating to the vscode client a-Lexer Relating to the lexer a-Parser Relating to the parser a-Server Relating to the LSP server c-Feature Feature request/suggestion l-General Relating to any OpenGL/Vulkan

Comments

@KubaP
Copy link
Owner

KubaP commented Dec 27, 2023

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.
@KubaP KubaP added the c-Feature Feature request/suggestion label Dec 27, 2023
@KubaP KubaP added this to glsl-lsp Dec 27, 2023
@KubaP KubaP removed this from glsl-lsp Dec 27, 2023
@KubaP KubaP added this to glsl-lsp Jul 5, 2024
@KubaP KubaP added a-Lexer Relating to the lexer a-Parser Relating to the parser a-Server Relating to the LSP server a-Client Relating to the vscode client l-General Relating to any OpenGL/Vulkan labels Jul 5, 2024
@KubaP KubaP moved this to Todo in glsl-lsp Jul 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-Client Relating to the vscode client a-Lexer Relating to the lexer a-Parser Relating to the parser a-Server Relating to the LSP server c-Feature Feature request/suggestion l-General Relating to any OpenGL/Vulkan
Projects
Status: Todo
Development

No branches or pull requests

1 participant