Fix dangling-else bugs in FAIL_FAST_IF and EMIT_USER_WARNING macros

[Eamon (Eamon2009)]

Summary of the Pull Request

FAIL_FAST_IF and EMIT_USER_WARNING were missing the standard do { } while(0) macro guard. When used as the single statement branch of an enclosing if/else, the else would incorrectly bind to the macro's internal if instead of the outer if, silently inverting control flow.

Windows counterpart: #41513

PR Checklist

• Closes: Fixes dangling-else ambiguity in FAIL_FAST_IF and EMIT_USER_WARNING
• Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
• Tests: Added/updated if needed and all pass
• Localization: All end user facing strings can be localized
• Dev docs: Added/updated if needed
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

Changes

• Wrapped FAIL_FAST_IF in do { } while ((void)0, 0)
• Wrapped EMIT_USER_WARNING in do { } while ((void)0, 0)

Both macros were previously defined as bare if statements, which left callers vulnerable to dangling-else misassociation when used without braces:

if (condition)
    EMIT_USER_WARNING("msg");
else

The do { ... } while ((void)0, 0) wrapper ensures each macro always expands to a single statement, preventing the outer else from binding to the internal if.

Validation Steps Performed

• Verified that FAIL_FAST_IF and EMIT_USER_WARNING expand to single statements when used in if/else contexts without braces.
• Windows part PR Harden Windows macros against dangling-else ambiguity #41513 for consistency.

another PR #41342

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

🟢 Approval recommended

The macro-guard changes correctly address the dangling-else control-flow bug, and remaining feedback is limited to non-blocking formatting consistency.

Pull request overview

This PR fixes a classic “dangling else” macro hazard in the Linux-side WIL shim by ensuring multi-statement macros expand as a single statement, preventing else from binding to an internal if.

Changes:

• Wrapped FAIL_FAST_IF in a do { } while (0)-style guard.
• Wrapped EMIT_USER_WARNING in a do { } while (0)-style guard.

File summaries

File	Description
src/linux/inc/lxwil.h	Makes FAIL_FAST_IF and EMIT_USER_WARNING safe in if/else single-statement contexts by adding a statement-guard wrapper.

Review details

Suppressed comments (1)

src/linux/inc/lxwil.h:658

• For consistency with other guarded multi-statement macros in this file (e.g., WI_SetFlagIf), prefer placing the opening brace for the do/while guard on its own line.

#define EMIT_USER_WARNING(Warning) \
   do { \
       if (::wil::ScopedWarningsCollector::CanCollectWarning()) \
       { \
           ::wil::ScopedWarningsCollector::CollectWarning(Warning); \

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟢 Approval recommended

The functional fix matches the PR description and addresses the dangling-else hazard; remaining feedback is limited to minor formatting consistency within macro bodies.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

🟡 Changes recommended

The Windows EMIT_USER_WARNING definition still has the same dangling-else vulnerability.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

🔵 Needs a closer look

Formatting violations remain, and the Windows macro still has the dangling-else bug.

Review details

Suppressed comments (3)

Previously missed (1) — in code that hasn't changed since the last review.

src/linux/inc/lxwil.h:655

• This second do statement also violates the repository's Allman brace convention; WI_SetFlagIf at src/linux/inc/lxwil.h:639-646 shows the established macro formatting. Put the opening brace on its own continued line.

src/linux/inc/lxwil.h:654

• The Windows definition at src/windows/common/ExecutionContext.h:37-41 is still an unguarded if, so EMIT_USER_WARNING retains the same dangling-else bug for Windows callers. Apply the equivalent single-statement guard to that definition as part of this fix.

#define EMIT_USER_WARNING(Warning) \

src/linux/inc/lxwil.h:19

• This control statement does not follow the repository's Allman brace convention; the nearby WI_SetFlagIf macro at src/linux/inc/lxwil.h:639-646 puts the opening brace on the next continued line. Split do and { to keep this macro consistent with the file's established formatting.

    do { \

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Copilot]

🟢 Approval recommended

The reviewed change safely resolves the ambiguity with no unresolved issues.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Ben Hillis (benhillis)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Ben Hillis (benhillis)]

Looks good, thank you for the contribution.