Python support ListElement in MaD
#21134
Conversation
There was a problem hiding this comment.
Pull request overview
This PR adds support for the ListElement token in Models as Data (MaD) for Python, enabling users to specify list element access in data flow models. The implementation maps ListElement to the existing subscript functionality, reusing infrastructure already in place for list element content.
Key changes:
- Enabled
ListElementtoken in MaD access paths by treating it the same asDictionaryElementAny - Updated test case to verify list element source detection works correctly
- Added
ListElementto the list of valid tokens for identifying access paths
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
python/ql/test/library-tests/frameworks/data/test.ext.yml |
Uncommented test case for ListElement to validate the new functionality |
python/ql/test/library-tests/frameworks/data/test.expected |
Added expected test output showing that list element sources are now detected |
python/ql/lib/semmle/python/frameworks/data/internal/ApiGraphModelsSpecific.qll |
Added ListElement support to token handling predicates, mapping it to subscript access |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # test steps through content | ||
| - ["testlib", "Member[source_dict].DictionaryElement[key].Member[func].ReturnValue", "test-source"] | ||
| - ["testlib", "Member[source_dict_any].DictionaryElementAny.Member[func].ReturnValue", "test-source"] | ||
| # TODO: Add support for list/tuples |
There was a problem hiding this comment.
The TODO comment should be updated to reflect that list support has now been added. Consider changing it to "TODO: Add support for tuples" since only tuple support remains unimplemented.
| # TODO: Add support for list/tuples | |
| # TODO: Add support for tuples |
tausbn
left a comment
tausbn
left a comment
There was a problem hiding this comment.
I think this looks very reasonable, modulo a small issue of naming that I just want to make sure we've thought about. 🙂
| */ | ||
| predicate isExtraValidNoArgumentTokenInIdentifyingAccessPath(string name) { | ||
| name = ["Instance", "Awaited", "Call", "Subclass", "DictionaryElementAny"] | ||
| name = ["Instance", "Awaited", "Call", "Subclass", "DictionaryElementAny", "ListElement"] |
There was a problem hiding this comment.
I feel like we may have had this discussion before, but should this instead be ListElementAny? Or is it safe to overload ListElement if we want to have more fine-grained control over the index later on?
There was a problem hiding this comment.
I did consider this and initially paused. I then noticed that no other language is using ListElement, so there is no conflicting semantics, at least.
We have several choices for how to take this, including adding ListElementAny or supporting ListElement[any] to be the same as just ListElement.
There was a problem hiding this comment.
Alright, let's just go with the current implementation, then. No need to complicate things.
2 participants
It should be easy enough to ad tuple element (although these should take an index) and set element. List element was added in response to a user question. The change is trivial as it simply maps to the already supported subscript.