Closed Drewniok closed 3 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 83.47%. Comparing base (
93a37e8
) to head (056df91
).:exclamation: Current head 056df91 differs from pull request most recent head 2684518. Consider uploading reports for the commit 2684518 to get more accurate results
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Thanks! As I try to understand the problem and the solution, I notice a few things:
test_copy_names_view
) are not testing the assignment operator (operator=
overload), but the copy constructor instead. This is the same for the test you added (names_view<Ntk> new_named_ntk_empty = ntk_empty;
). To have the assignment operator called, we need to separate the declaration of the new named network and the assignment into two lines.Ntk::operator=( named_ntk );
) happens in the end, so for the code before, this
either has no PIs (if it is empty), or has the same number of PIs and with the same indices (if assignment happens between different versions of the same network), or has a completely unrelated set of PIs (if assignment happens between unrelated networks --- should be a rare situation). In none of the cases, it doesn't make sense to me to map the old PI signals to names in the network to be assigned. Please allow me some more time to think about it more thoroughly. If you have any thoughts (e.g. from your usage scenario), please do let me know!
Thanks @lee30sonia for your helpful feedback! The situation is as follows: For a few months now, we have been getting an error in the PR (https://github.com/cda-tum/fiction/actions/runs/8452568703/job/23153203895?pr=317) in debug on Windows only. So I built everything on a Windows machine and investigated why the problem occurs in the CI. It turned out that windows in debug fails because of current_pis[i]
in case of an empty current_pis
vector.
@Drewniok That's weird. It would be interesting to know how the test case that triggers the bug looks like. e.g., having a print-out in the assignment operator printing how many PIs *this
and named_ntk
has, respectively.
@Drewniok That's weird. It would be interesting to know how the test case that triggers the bug looks like. e.g., having a print-out in the assignment operator printing how many PIs
*this
andnamed_ntk
has, respectively.
@lee30sonia The bug seems to manifest itself when updating a *this
instance without primary inputs (pis
) with another instance named_ntk
that includes primary inputs. This mismatch causes incorrect behavior. I made adjustments to handle this specific scenario to ensure proper functionality. Additionally, I have implemented a test to validate the fix under these conditions.
Hi @lee30sonia,
Have you found time to take a look at the changes yet? No problem if not! I only ask because after this is fixed, I will continue working on the mentioned PR in fiction
. Thank you!
Hi @Drewniok, sorry, I am on in-between-jobs vacation these weeks and don't have much time. This PR is on my TODO list and I promise to get back as soon as possible.
Sorry for the delay and thanks again for the contribution! It looks good to me. I pushed just some minor changes and will merge once the tests are complete.
This PR addresses a bug related to signal name assignment within the
names_view<Ntk>::operator=
method. The code has been refactored to include a check for the emptiness of thecurrent_pis
vector before attempting to access its elements. This change ensures that the loop is only executed when thecurrent_pis
vector is not empty, preventing potential out-of-range accesses and improving code safety.