-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add path expanded flag #12820
Merged
andy31415
merged 3 commits into
project-chip:master
from
mlepage-google:add-path-expanded-flag
Dec 10, 2021
Merged
Add path expanded flag #12820
andy31415
merged 3 commits into
project-chip:master
from
mlepage-google:add-path-expanded-flag
Dec 10, 2021
Conversation
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
bzbarsky-apple
approved these changes
Dec 9, 2021
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me if codesize is fine with this!
PR #12820: Size comparison from b6297f3 to fd0a81c Increases (19 builds for efr32, esp32, k32w, linux, mbed, p6, qpg, telink)
Decreases (1 build for linux)
Full report (22 builds for efr32, esp32, k32w, linux, mbed, p6, qpg, telink)
|
mrjerryjohns
approved these changes
Dec 9, 2021
PR #12820: Size comparison from b6297f3 to 550d24d Increases above 0.2%:
Increases (14 builds for efr32, k32w, linux, p6, qpg, telink)
Decreases (3 builds for p6, qpg)
Full report (15 builds for efr32, k32w, linux, p6, qpg, telink)
|
PR #12820: Size comparison from 0089995 to f9b8638 Increases (26 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
Decreases (2 builds for linux)
Full report (32 builds for efr32, esp32, k32w, linux, mbed, nrfconnect, p6, qpg, telink)
|
/rebase |
And set it from the AttributePathExpandIterator.
Derived "copy" constructors that take the base can slice it. Fix that.
It's more of a metadata thing anyways.
f9b8638
to
3057b4e
Compare
PR #12820: Size comparison from 2400884 to 3057b4e Increases (16 builds for efr32, k32w, linux, mbed, p6, qpg, telink)
Decreases (2 builds for linux)
Full report (20 builds for efr32, k32w, linux, mbed, p6, qpg, telink)
|
Damian-Nordic
approved these changes
Dec 10, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
When processing concrete attribute paths, it's not known if they were originally
concrete, or if they were expanded (from a wildcard or group path). This is necessary
because handling may need to differ based on whether the concrete path was
expanded or not (e.g. if access is denied).
Change overview
Add an expanded flag to ConcreteAttributePath. It can be a boolean fit in between
other larger member variables, so alignment means it shouldn't typically use more
space.
The expanded flag defaults to false. It's effectively "optional". (Only some code will
care what it's set to.)
It's set to true by the AttributeExpandPathIterator based on the ClusterInfo it's currently
iterating.
It's logged in the log statement in ReadSingleClusterData.
Testing
How was this tested? (at least one bullet point required)