-
Notifications
You must be signed in to change notification settings - Fork 3
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
Support captured parameters being used after the iteration completes #10
Comments
BenWoodworth
added a commit
that referenced
this issue
Nov 17, 2023
Previously the same delegate instance was shared between all iterations, and its argument points to the value in the current iteration. This was fine if the parameter is only used in the current iteration, but if a parameter is captured in a lambda and used later, the argument will change for a future iteration's argument combination, and the value will not be the same as when it was captured. To fix this, the delegate is now unique to its iteration instead of being shared, and maintains an unchanging argument so that it can be captured and accessed later. See issue #10 for context.
BenWoodworth
added a commit
that referenced
this issue
Nov 17, 2023
Previously the same delegate instance was shared between all iterations, and its argument points to the value in the current iteration. This was fine if the parameter is only used in the current iteration, but if a parameter is captured in a lambda and used later, the argument will change for a future iteration's argument combination, and the value will not be the same as when it was captured. To fix this, the delegate is now unique to its iteration instead of being shared, and maintains an unchanging argument so that it can be captured and accessed later. See issue #10 for context.
BenWoodworth
added a commit
that referenced
this issue
Nov 20, 2023
Previously the same delegate instance was shared between all iterations, and its argument points to the value in the current iteration. This was fine if the parameter is only used in the current iteration, but if a parameter is captured in a lambda and used later, the argument will change for a future iteration's argument combination, and the value will not be the same as when it was captured. To fix this, the delegate is now unique to its iteration instead of being shared, and maintains an unchanging argument so that it can be captured and accessed later. See issue #10 for context.
BenWoodworth
added a commit
that referenced
this issue
Nov 20, 2023
Previously the same delegate instance was shared between all iterations, and its argument points to the value in the current iteration. This was fine if the parameter is only used in the current iteration, but if a parameter is captured in a lambda and used later, the argument will change for a future iteration's argument combination, and the value will not be the same as when it was captured. To fix this, the delegate is now unique to its iteration instead of being shared, and maintains an unchanging argument so that it can be captured and accessed later. See issue #10 for context.
BenWoodworth
changed the title
Allow parameters to be used after its iteration completes.
Support captured parameters being used after the iteration completes
Nov 20, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In v0.1, this use case isn't supported:
That is, testing frameworks that declare their tests with DSLs. In this case, declaring separate test cases for each parameter argument. The
test
function registers a lambda that will execute later. And, since theletter
parameter is captured by the test lambda, the parameter will be accessed after that parameterize iteration completed.There are two issues with the current implementation that prevent this:
1. The parameter delegate is shared between iterations
When
letter
is finally accessed, the delegate's state will be pointing to an argument for a later iteration. That, or the parameter will be reset to an uninitialized state as if it weren't declared yet, and throw when accessed. Either way,letter
won't give the expected value when the test lambda is executed.The solution here is simple enough. Instead of the delegate representing "the current iteration's parameter", have it be a fixed value. Roughly equivalent to this in v0.1:
Though not this straightforward, since the parameter delegate should still be able to communicate whether the parameter's been used or not (for failure reporting, only reporting the parameters that were used, which could have contributed to the failure)
2. Unused parameters do not contribute to argument combinations
This is an additional optimization to help the programmer in case a parameter is determined to be redundant, based on if it's used in the iteration it's declared. There's an issue specific to this here: #11
But how that affects this issue, take this code for example (assuming the issue above is resolved):
Here,
b
is never used in the iteration, since it's only accessed afterwards from the registered test. So,b
is assumed to be redundant so is never iterated over. The solution here is to drop the assumption that parameters will never be used (since they may have been captured and relied on later), and evaluate and iterate over them unconditionally.The text was updated successfully, but these errors were encountered: