create_work_if causes a frontend assertion breakage due to AH aliasing by the frontend

[lifflander]

See minimal example for reproduction: c2472f0b943708da5c52fde390d090ed566d93ed

Code snippet:

void darma_main_task(std::vector<std::string> args) {
  auto val = initial_access<int>();

  create_work([=]{
    val.set_value(sentinal_value);
  });

  create_work_if([=]{
    return val.get_value() == sentinal_value;
  }).then_([=]{
    val.set_value(other_sentinal_value);
  });

  create_work(reads(val), [=]{
    assert(val.get_value() == other_sentinal_value);
  });

  create_work_if([=]{
    return val.get_value() != other_sentinal_value;
  }).then_([=]{
    assert(0 && "If condition evaluated incorrectly");

    // *frontend bug if you comment out this line*
    val.get_value();
  });

  create_work(reads(val), [=]{
    assert(val.get_value() == other_sentinal_value);
  });
}

[dhollman]

I haven't worked out all of the interactions with aliasing and the new control structures, but this looks like it's unrelated to that; it's just a problem with handling a continuation that doesn't capture anything. I'll look into it when I have a chance.

[lifflander]

OK: this was the error:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! DARMA assertion failed: Expression should be true: false Assertion details: File: /Users/jliffla/codes2/darma-threads-development/darma-build/repos/frontend/src/include/darma/impl/task_do_capture.impl.h Line: 106 Captured the same handle via different variables without explicitly allowing aliasing in create_work call (using the keyword_arguments_for_task_creation::allow_aliasing keyword argument). !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[lifflander]

Also, I should note that it does not break if the task after that create_work_if is removed.

[dhollman]

Yeah, I'm not unsetting the already_captured flag somewhere that I should be. Should be an easy fix once I get the time to track it down

[dhollman]

Fixed in the if/then/else interface. There is an analogous bug (sort of) in the while interface, but I'm not checking for aliasing there (in other words, it'll just hang because it'll register two consecutive uses if you give it two handles that are aliased). This is a known bug called out in TODOs in the create_work_while implementation, so that should be fixed before the interface is marked complete.