#include directive support #46
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When an include directive is recognized by the preprocessor, it executes a callback on the filepath argument to obtain the file contents. That way the compilation client can deal with the file system, include paths, etc. Currently only accepts quoted filepaths -- no angle brackets yet.
This patch introduces a new extension, GL_GOOGLE_include_directive, to enable support #include directives. It depends on the extension GL_GOOGLE_cpp_style_line_directive.
After parsing a #include directive, we push a TokenizableString
which contains the content of the included file into the input
stack. Henceforth, tokens will be read from the newly pushed
TokenizableString. However, the scanner in TParseContext still
points to the previous input stream. We need to update the scanner
to point to the new input stream inside TokenizableString. Thus,
the setCurrent{String|Line|..} method in TParseContext updates
the status of the correct input stream. After finishing the newly
pushed TokenizableString, we need to restore the scanner to the
previous input stream.
Also changed the includer interface to let it return the actual full path of the included file.
|
Cool stuff. One simple concern: It seems easy to accidentally not use the preprocessor version of requireExtensions() et. al. There is now ppError() and error(). Would it be safer if there was also ppRequireExtensions() and requireExtensions(). Seems that would be better, due to consistency and clarify, assuming it could be done without too much code duplication of the internals of requireExtensions(). Thoughts? Thanks. |
Now extensions required by preprocessor should be checked via the ppRequireExtensions method. This is more clear and coherent with the rest of the code.
|
@johnkslang: Yeah, agreed that a separate |
qingyuanzNV
pushed a commit
to qingyuanzNV/glslang
that referenced
this pull request
Oct 18, 2022
…inker Register the Khronos SPIRV-Tools Linker
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These commits add
#includedirective support in glslang. Weuse a flexible mechanism so that different contributors can
have different implementation for file searching and
#includedirective substitution. (A
ForbidIncludeis supplied though.)Please refer to individual commit messages for more details.
This fulfills the third step mentioned in Issue #37.