We've never before had a C++ class with members in the following pattern:
some basic type (int, float, bool...)
some not basic type (string, collection, class...)
more than one basic types
but it came up in #1221. It revealed a bug in which AwkwardForth statements are supposed to be generated from the last fields/formats list to be filled (these variables are both lists of lists), but the old code was looking at the first.
This was in the "AwkwardForth testing E" block, for the case in which there's more than just one fields/formats.
If part 3 (above) has no more than one basic type, then we'd be in "AwkwardForth testing D", which was correct (fields[-1][0] and formats[-1][0], with the -1 in the first index).
If there was no part 1 (above), then fields[0] is fields[-1] and formats[0] is formats[-1], and it worked by accident.
All of the tests/test_0637_setup_tests_for_AwkwardForth.py tests are insensitive to the code change, so this case doesn't exist in our test suite. It would be great to get example files from #1221 and add them to our test suite.
We've never before had a C++ class with members in the following pattern:
but it came up in #1221. It revealed a bug in which AwkwardForth statements are supposed to be generated from the last
fields/formatslist to be filled (these variables are both lists of lists), but the old code was looking at the first.This was in the "AwkwardForth testing E" block, for the case in which there's more than just one
fields/formats.fields[-1][0]andformats[-1][0], with the-1in the first index).fields[0] is fields[-1]andformats[0] is formats[-1], and it worked by accident.All of the tests/test_0637_setup_tests_for_AwkwardForth.py tests are insensitive to the code change, so this case doesn't exist in our test suite. It would be great to get example files from #1221 and add them to our test suite.