diff options
| author | Michael Kubacki <michael.kubacki@microsoft.com> | 2026-02-03 16:11:53 +0300 |
|---|---|---|
| committer | mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> | 2026-02-24 00:01:28 +0300 |
| commit | 3f81a4902a985f09050289669233fca3ffa44572 (patch) | |
| tree | 4e424be6d23b28aeb720e0af59212b6699359b4d /BaseTools/Source/Python | |
| parent | b963cb6244674bf92047226521f5f8e7b02d41ed (diff) | |
| download | edk2-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
