can call send/recv from helper fn

[proppy]

it seems that send and recv operation fails when being called from helper fns invoked from a proc (even if being passed the appropriate token and chan):

  output: chan<u8> out;

  init {
    u8:0
  }

  config(output: chan<u8> out) {
    (output,)
  }

  next(tok: token, state: u8) {
    let tok = send(tok, output, state);
    state + u8:1
  }
}

fn assert_recv_eq(tok: token, output_r: chan<u8> in, expected: u8) -> token {
  let (tok, value) = recv(tok, output_r);
  let _ = assert_eq(value, expected);
  tok
}

#[test_proc]
proc counter_test {
  terminator: chan<bool> out;
  output_s: chan<u8> out;
  output_r: chan<u8> in;

  init {
    ()
  }

  config(t: chan<bool> out) {
    let (output_s, output_r) = chan<u8>;
    spawn counter(output_s);
    (t, output_s, output_r)
  }

  next(tok: token, state: ()) {
    let tok = assert_recv_eq(tok, output_r, u8:0);
    let tok = send(tok, terminator, true);
    ()
  }
}

would produce the following error:

[ RUN UNITTEST  ] counter_test
E0502 10:10:52.469354   31692 bytecode_emitter.cc:1088] INTERNAL: XLS_RET_CHECK failure (xls/dslx/bytecode/bytecode_emitter.cc:1088) proc_node != nullptr 
0x5588a02eb970: xabsl::StatusBuilder::CreateStatusAndConditionallyLog()
0x55889ea06909: absl::lts_20220623::StatusOr<>::StatusOr<>()
0x55889e9f7ae6: xls::dslx::(anonymous namespace)::CreateChannelData()
0x55889e9f6c23: xls::dslx::BytecodeEmitter::HandleRecv()
0x55889ea62c2b: xls::dslx::Recv::AcceptExpr()
0x55889e9f4757: xls::dslx::BytecodeEmitter::HandleLet()
0x55889ea6364b: xls::dslx::Let::AcceptExpr()
0x55889e9e7c3a: xls::dslx::BytecodeEmitter::HandleBlock()
0x55889ea5fd38: xls::dslx::Block::AcceptExpr()
0x55889e9e4b21: xls::dslx::BytecodeEmitter::EmitProcNext()
0x55889e9e4954: xls::dslx::BytecodeEmitter::Emit()
0x55889e8b30f4: xls::dslx::BytecodeCache::GetOrCreateBytecodeFunction()
0x55889e9ca5db: xls::dslx::BytecodeInterpreter::GetBytecodeFn()
0x55889e9bab62: xls::dslx::BytecodeInterpreter::EvalCall()
0x55889e9b9d04: xls::dslx::BytecodeInterpreter::EvalNextInstruction()
0x55889e9b8975: xls::dslx::BytecodeInterpreter::Run()
0x55889e9dca2f: xls::dslx::ProcInstance::Run()
0x55889e84835f: xls::dslx::ParseAndTest()
0x55889e7fc068: main
0x7f03e4869083: __libc_start_main

E0502 10:10:52.469560   31692 run_routines.cc:379] Internal error: INTERNAL: XLS_RET_CHECK failure (xls/dslx/bytecode/bytecode_emitter.cc:1088) proc_node != nullptr 
[        FAILED ] counter_test: internal error: INTERNAL: XLS_RET_CHECK failure (xls/dslx/bytecode/bytecode_emitter.cc:1088) proc_node != nullptr 
[===============] 1 test(s) ran; 1 failed; 0 skipped.

[grebe]

Channel operations are not currently supported in functions. This error message really doesn't convey that, it should be better.

It's a separate question if functions should be able to do channel operations. My understanding is that there are simulator/JIT reasons why it's nice that functions can't do channel operations. However, it is totally natural to want to factor a proc's functionality out into functions and would help solve a lot of proc's clunkiness.

729 related.