-
Notifications
You must be signed in to change notification settings - Fork 28
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Use local variable to work around LLVM/Clang bug
- Loading branch information
Showing
1 changed file
with
47 additions
and
0 deletions.
There are no files selected for viewing
47 changes: 47 additions & 0 deletions
47
0001-Use-local-variable-to-work-around-macOS-compiler-bug.patch
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,47 @@ | ||
From 0e225199339461c5c821afc34fa2798d4a5026f7 Mon Sep 17 00:00:00 2001 | ||
Message-ID: <0e225199339461c5c821afc34fa2798d4a5026f7.1713960078.git.stefan@agner.ch> | ||
From: Stefan Agner <[email protected]> | ||
Date: Wed, 24 Apr 2024 13:25:42 +0200 | ||
Subject: [PATCH] Use local variable to work around macOS compiler bug | ||
|
||
It seems that when directly passing the status, via inline condition | ||
etc. it triggers a compiler bug on the latest macOS ARM64 GitHub Action | ||
runner or Pigweed, I am not sure. | ||
|
||
Use a local variable to work around the problem. | ||
--- | ||
src/controller/python/chip/clusters/attribute.cpp | 7 ++++++- | ||
1 file changed, 6 insertions(+), 1 deletion(-) | ||
|
||
diff --git a/src/controller/python/chip/clusters/attribute.cpp b/src/controller/python/chip/clusters/attribute.cpp | ||
index e31f3431b8..4ba77ff58a 100644 | ||
--- a/src/controller/python/chip/clusters/attribute.cpp | ||
+++ b/src/controller/python/chip/clusters/attribute.cpp | ||
@@ -168,6 +168,8 @@ public: | ||
uint8_t buffer[CHIP_CONFIG_DEFAULT_UDP_MTU_SIZE]; | ||
uint32_t size = 0; | ||
CHIP_ERROR err = CHIP_NO_ERROR; | ||
+ Protocols::InteractionModel::Status status = Protocols::InteractionModel::Status::Success; | ||
+ | ||
// When the apData is nullptr, means we did not receive a valid event data from server, status will be some error | ||
// status. | ||
if (apData != nullptr) | ||
@@ -195,11 +197,14 @@ public: | ||
this->OnError(err); | ||
} | ||
|
||
+ if (apStatus != nullptr) | ||
+ status = apStatus->mStatus; | ||
+ | ||
gOnReadEventDataCallback( | ||
mAppContext, aEventHeader.mPath.mEndpointId, aEventHeader.mPath.mClusterId, aEventHeader.mPath.mEventId, | ||
aEventHeader.mEventNumber, to_underlying(aEventHeader.mPriorityLevel), aEventHeader.mTimestamp.mValue, | ||
to_underlying(aEventHeader.mTimestamp.mType), buffer, size, | ||
- to_underlying(apStatus == nullptr ? Protocols::InteractionModel::Status::Success : apStatus->mStatus)); | ||
+ to_underlying(status)); | ||
} | ||
|
||
void OnError(CHIP_ERROR aError) override { gOnReadErrorCallback(mAppContext, ToPyChipError(aError)); } | ||
-- | ||
2.44.0 | ||
|