Add some debug info to diplomacy.

[sequencer]

Type of change: other enhancement

Impact: no functional change

Development Phase: implementation

Release Notes:
BundleBridgeNexusNode is using MixedNexusNode, debug without nearby nodes is hard.
This PR gives better debug infomation by printing nearby nodes require is false.

[hcook]

Can you add similar information to

    require (po.size == oKnown || oStars == 1, s"$context has only ${oKnown} outputs connected out of ${po.size}")
    require (po.size >= oKnown, s"$context has ${oKnown} outputs out of ${po.size}; cannot assign ${po.size - oKnown} edges to resolve :=*")

in SourceNode
and

require (pi.size == iKnown || iStars == 1, s"$context has only ${iKnown} inputs connected out of ${pi.size}")
    require (pi.size >= iKnown, s"$context has ${iKnown} inputs out of ${pi.size}; cannot assign ${pi.size - iKnown} edges to resolve :*=")

in SinkNode?

I think those errors also cause confusion. Especially the phrasing "X inputs connected out of Y" because it sounds like Y should be bigger than X, but lots of times Y is smaller because you did not put enough params in your pi: Seq[U] 😅

Maybe "X inputs were connected ($names) but Y sinks were specified to the node constructor."?

[hcook]

Maybe let's preface more (or all) of these types of errors with either "Diplomacy error:" or maybe something longer like val errorMessage = "Diplomacy detected a problem with your graph:\n"

These aren't bugs in diplomacy, and they aren't a protocol-specific requirethat failed, they are a problem with the structure of the graph that means negotiation will not be able to proceed... The answer is usually to go fix the shape of the graph to make it match the number of parameters put in or calculated...

[hcook]

@terpstra How do you feeling about preferring the terms "inward connections" and "outward connections" to "inputs" and "outputs", at least in terms of reporting these node error messages? I feel like "input" and "output" are kind of overloaded due to being used as wire IO directions...

[terpstra]

Yes, inward and outward are better.

[hcook]

One more general comment, is there some way we can get the SourceInfo information associated with a particular node's instantiation to show up in context or a particular binding to show up in oPorts/iPorts along with the name?

[sequencer]

@hcook added more infos to resolveStar, I think this might be more easy for debugging?

[hcook]

Thank you for all the edits! This is great!