summaryrefslogtreecommitdiff
path: root/BaseTools/Source/Python
diff options
context:
space:
mode:
authorMichael Kubacki <michael.kubacki@microsoft.com>2026-02-03 16:11:53 +0300
committermergify[bot] <37929162+mergify[bot]@users.noreply.github.com>2026-02-24 00:01:28 +0300
commit3f81a4902a985f09050289669233fca3ffa44572 (patch)
tree4e424be6d23b28aeb720e0af59212b6699359b4d /BaseTools/Source/Python
parentb963cb6244674bf92047226521f5f8e7b02d41ed (diff)
downloadedk2-3f81a4902a985f09050289669233fca3ffa44572.tar.xz
BaseTools/VfrCompile: Add #pragma once support
The C preprocessor turns each .vfr file into a pre-processed .i file. At this step, the C preprocessor processes `#pragma once`. Then, VfrCompile is called (with `-n` to prevent preprocessing) to parse the pre-processed .i files. The .i files may still contain `#pragma once` lines. Currently, VfrCompile treats `once` as an unknown token, causing parse failures. Originally, this change was going to add a `PragmaOnce` token rule to the VFR lexer grammar (in VfrSyntax.g) that matched `#pragma once` lines and silently skipped them using `skip()` and `newline()`. The `newline()` call would keep line numbers stable for error reporting. This was consistent with how other preprocessor artifacts were already handled like `#line` directives (`LineDefinition` and `GccLineDefinition` tokens) and `extern` declarations (skipped with `mode(CPP_COMMENT)`). Writing a regular expression to match `#pragma once` was simple enough, but it makes overall pragma token recognition more fragile at the lexer level. When the lexer is walking the DFA state table, it could begin to match a `#pragma ` line but then not be able to match remaining characters to recognize tokens other than `once`. Instead, this change handles `#pragma once` lines in the VFR parser grammar in `vfrPragmaDefinition` alongside where `pack` is already handled. Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Diffstat (limited to 'BaseTools/Source/Python')
0 files changed, 0 insertions, 0 deletions