[enhancement] Proc tests should indicate where test proc is blocked in "deadline exceeded" condition

[meheff]

What's hard to do? (limit 100 words)

Often when testing a proc, you will get a DEADLINE_EXCEEDED error when the test proc is deadlocked. This can easily occur if, for example, you try to receive from a channel one too many times. There is no hint as to what where the test proc is blocked.

Current best alternative workaround (limit 100 words)

No great work around besides diving in and finding where the proc is blocked.

Your view of the "best case XLS enhancement" (limit 100 words)

The error message should include a pointer to the line where the test proc is blocked. A better error message than DEADLINE_EXCEEDED would also be helpful. Maybe, test unable to make progress, blocked at <reference to line including line snippet>

[dplassgit]

Currently, actual deadlocks are detected, e.g.:

E0903 10:51:05.224160    8686 run_routines.cc:107] Internal error: DEADLINE_EXCEEDED: Procs are deadlocked. Blocked channels: incrementer::in_ch, tester_proc::data_in

If it's a deadline exceeded due to an infinite loop, e.g.,

#[test_proc]
proc test_main {
    config(terminator_s: chan<bool> out) {  }

    init { u32:0 }

    next(iter: u32) {
        // Just spin.
        iter + u32:1
    }
}

How could this be handled?

[mikex-oss]

That example is a bit extraordinary, since the blocked receive is hidden (i.e. there is something in XLS internals waiting for the terminator send from the test proc), so you don't have a source location to point to.

In other cases, it'd be good to point to something like proc my_proc in path/to/foo.x is waiting on recv from incrementer::in_ch at line ## or something.

[dplassgit]

In the above error message Blocked channels: incrementer::in_ch, tester_proc::data_in - it gives the name of the proc and the channel. If it drilled down to the span (file+line/column), do you feel that would be better?

[mikex-oss]

@meheff may have different thoughts, but what I meant was that we want to see which recv is blocked. For example, in a test proc, you might do 1) send stimulus, 2) recv some output, 3) assert_eq, 4) send stimulus, 5) recv some output, 6) assert, ...

I'd like to know if it's blocked at the line for 2 or 5.