Fixing size parameter handling in len-mechanism to handle function parameters with different size parameters

[batzuu]

• This contribution adheres to CONTRIBUTING.md.
• I've updated CHANGELOG.md if applicable.
• I've added tests applicable for this pull request

What does this Pull Request accomplish?

Fixes the codegen to properly handle functions with multiple array parameters that reference different size parameters:

• Updates metadata_filters.py: Refactors the filter_parameters function to collect all size parameter names referenced by len-sized parameters into a len_size_parameter_names, replacing the previous single len_size_parameter approach. Removed assert to check if all size parameters are same from filter_len_parameters. Following this updated var names in default_method.py.mako and initialization_method.py.mako to reflect multiple possible size params.

• Updates to nifake to enable testing: Details covered in testing section

Previously, it was assumed all len-mechanism arrays in a function shared the same size parameter. This change enables functions like CreateDeembeddingSparameterTableArray in NI-RFSG where frequencies uses frequenciesSize and sparameterTable uses sparameterTableSize.

List issues fixed by this Pull Request

Issue 2137: Fix size parameter handling for functions with parameters referencing multiple size parameters.
Additional PR needs to be raised to update NI-RFSG function metadata (CreateDeembeddingSparameterTableArray) to consume
these changes.

What testing has been done?

• Added MultipleArraysDifferentSize function to nifake metadata with two arrays (valuesArray using valuesArraySize, and dataArray using dataArraySize) to test the change in filter param logic
• Added unit test test_multiple_arrays_different_size in test_library_interpreter.py that verifies correct handling of multiple arrays with independent size parameters
• Test validates that each array's length is properly calculated and passed with its corresponding size parameter (3 elements for valuesArray with valuesArraySize, and 5 elements for dataArray with dataArraySize)
• All existing tests continue to pass.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 90.47619% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.12%. Comparing base (be77b68) to head (ce0a252).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
generated/nifake/nifake/_grpc_stub_interpreter.py	50.00%	1 Missing ⚠️
generated/nifake/nifake/session.py	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2138      +/-   ##
==========================================
+ Coverage   90.09%   90.12%   +0.03%     
==========================================
  Files          71       71              
  Lines       18662    18675      +13     
==========================================
+ Hits        16813    16831      +18     
+ Misses       1849     1844       -5     

Flag	Coverage Δ
codegenunittests	84.87% <100.00%> (+0.43%)	⬆️
nidcpowersystemtests	94.65% <ø> (+0.04%)	⬆️
nidcpowerunittests	89.53% <ø> (ø)
nidigitalsystemtests	92.26% <ø> (ø)
nidigitalunittests	68.44% <ø> (ø)
nidmmsystemtests	92.72% <ø> (ø)
nifakeunittests	85.60% <60.00%> (-0.11%)	⬇️
nifgensystemtests	94.61% <ø> (ø)
nimodinstsystemtests	73.85% <ø> (ø)
nimodinstunittests	94.20% <ø> (ø)
nirfsgsystemtests	82.40% <ø> (ø)
niscopesystemtests	92.94% <ø> (ø)
niscopeunittests	43.20% <ø> (ø)
nisesystemtests	91.50% <ø> (ø)
niswitchsystemtests	82.03% <ø> (ø)
nitclksystemtests	94.87% <ø> (ø)
nitclkunittests	98.26% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
build/helper/metadata_filters.py	76.69% <100.00%> (+3.88%)	⬆️
build/helper/metadata_find.py	80.55% <100.00%> (+12.69%)	⬆️
generated/nifake/nifake/_grpc_stub_interpreter.py	82.80% <50.00%> (-0.27%)	⬇️
generated/nifake/nifake/session.py	77.62% <66.66%> (-0.07%)	⬇️

... and 1 file with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update be77b68...ce0a252. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ni-jfitzger]

generated/nidcpower/nidcpower/_library_singleton.py:43:5: F824 global _instance_lock is unused: name is never assigned in scope
global _instance_lock

It seems we've gone from using flake8 7.1.2 to using flake8 7.3.0 and the new one has this new error code.
It doesn't like that we're using global here but never assigning a value to _instance_lock in that scope.
Though, according to the documentation, you need to declare with global before you can even use the variable.

https://docs.python.org/3/reference/simple_stmts.html#the-global-statement

This seems like something we should address in a separate PR.

[bkeryan]

Though, according to the documentation, you need to declare with global before you can even use the variable.

https://docs.python.org/3/reference/simple_stmts.html#the-global-statement

This seems like something we should address in a separate PR.

You only need the global keyword to assign global variables from an inner scope, not to read them.

https://stackoverflow.com/questions/291978/short-description-of-the-scoping-rules
https://docs.python.org/3/reference/executionmodel.html#resolution-of-names

[batzuu]

It seems we've gone from using flake8 7.1.2 to using flake8 7.3.0 and the new one has this new error code. It doesn't like that we're using global here but never assigning a value to _instance_lock in that scope. Though, according to the documentation, you need to declare with global before you can even use the variable.

https://docs.python.org/3/reference/simple_stmts.html#the-global-statement

This seems like something we should address in a separate PR.

I have added a noqa to suppress the flake8 warning so that this PR can merge. The actual issue we will address in a separate PR.

[ni-jfitzger]

From looking at nifake/functions.py, the mechanism isn't typically set for and ivi-dance size parameter or a length size parameter. In fact, not even size is set. So, what seems to end up happening is that size gets added for each by metadata_add_all._add_buffer_info with a "mechanism" of "fixed" and a "value" of 1. test_metadata_add_all shows further evidence of this.

I don't think it's important to set mechanism for 'ivi_size' or 'len_size' in this test, but if you're going to explicitly set them, you should probably set them correctly.

[ni-jfitzger]

As to why it's fixed when calculate it in the library interpreter?
I think it's just an usused default value, but I haven't traced the usage, myself.

[ni-jfitzger]

If you're going to set mechanism to 'fixed' for a parameter, you set size_value to a number and direction to 'out'. If you want it to be a parameter that gets passed in, the mechanism should be 'passed-in'.