Repository navigation
Avoid pure macro collisions in LLVM attribute detection - #9074
Damyan Pepper (damyanp) merged 6 commits into
Conversation
Query __has_attribute(__pure__) so a caller's pure macro is not expanded into the builtin feature check. Keep the existing LLVM_READONLY attribute unchanged. Add a SupportTests regression for the PDB-style pure macro collision. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 08f9ee45-220b-41eb-a6ff-c21beb0fcdf9
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Remove the standalone CompilerTest.cpp regression and its SupportTests registration as requested. The net change against upstream remains only the __has_attribute(__pure__) query. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 08f9ee45-220b-41eb-a6ff-c21beb0fcdf9
There was a problem hiding this comment.
🟡 Changes recommended
The include-order fix needs an automated regression test that fails with the original spelling.
1 open issue
What changed in this PR
This PR fixes an include-order compatibility issue in LLVM’s attribute detection without changing the attribute emitted by LLVM_READONLY.
Changes:
- Uses
__has_attribute(__pure__)to avoid collisions with a caller-definedpuremacro. - Preserves the existing read-only attribute behavior.
Please add an automated regression test covering the conflicting macro before header inclusion.
| File | Description |
|---|---|
| include/llvm/Support/Compiler.h | Uses the reserved attribute spelling to avoid macro expansion. |
Review effort: Balanced
| #endif | ||
|
|
||
| #if __has_attribute(pure) || defined(__GNUC__) | ||
| #if __has_attribute(__pure__) || defined(__GNUC__) |
There was a problem hiding this comment.
This is fixed by adding a new test.
There was a problem hiding this comment.
I'm actually of the opinion that a test is unnecessary here: it's very unlikely that someone sees __pure__ in two places and goes "nah, one of them should be pure instead" and revert your change.
But, up to you.
There was a problem hiding this comment.
Make sense, removed
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 08f9ee45-220b-41eb-a6ff-c21beb0fcdf9
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 08f9ee45-220b-41eb-a6ff-c21beb0fcdf9
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 08f9ee45-220b-41eb-a6ff-c21beb0fcdf9
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 08f9ee45-220b-41eb-a6ff-c21beb0fcdf9
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
|
Can you explain some more about the motivation for making this change please? What scenario is this addressing? Has a similar change been made in upstream llvm? |
There was a problem hiding this comment.
LGTM. Assuming you will address Damyan Pepper (@damyanp) s concern
We should also make this change in LLVM. You can help justify the change there with this documentation that suggests the same: https://clang.llvm.org/docs/LanguageExtensions.html#has-attribute
Yes, there is an error in one of the OS.2020 directory, it fails during Clang PCH compilation, where that PCH include The root cause is that the pure was defined as = 0 in the PCH within another pdb.h included earlier than Compiler.h. That macro leaks into subsequent LLVM includes, turning There is a way to fix in PCH and not let the I keep this PR since LLVM does not ship into this DXC. I will create another PR in LLVM so future modern DXC can consume it. |


Avoid
puremacro collisions in LLVM attribute detectionWindows PDB headers can define
pureas= 0. If such a header is included first, Clang expands that macro inside__has_attribute(pure)and reports:Clang and GCC recognize
__pure__as an equivalent spelling of the attribute. Using that reserved spelling avoids expanding the caller'spuremacro. The existingLLVM_READONLYdefinition already emits__attribute__((__pure__)), so the emitted attribute and runtime behavior are unchanged.Validation
Local OS build with MSVC and Clang-cl.