Compile-time errors for Q# programs not supported by QPRGen1 runtime capabilities

[bamarsha]

Quantum execution targets with QPRGen1 runtime capabilities can only inspect measurement results (via equality comparison) within the conditional expression of an if-statement. The body of any if-statement that depends on a measurement result (or any subsequent bodies in an if...elif...else chain) cannot contain return statements or set statements for any variable declared outside the body.

The compiler should verify this and give errors if the program is not compatible with a QPRGen1 target.

• Add diagnostics for equality comparisons between values of type Result (Compile-time errors for Q# programs not supported by QPRGen1 runtime capabilities #488)
• Improve diagnostics when comparing derived types that contain Result (see discussion here)

[bamarsha]

Continuing this conversion with @bettinaheim:

Hm, as far as error messages go, it is good to spawn less errors rather than more; the errors should be actionable, and having a clear set of errors to fix rather than a list of 500 subsequent ones generally helps that I think.
However, since these are kind of two distinct things, my inclination here would be to indeed implement it and even give two errors (since the error is really about two different issues).

I thought about this some more and I'd like to wait to do this until Q# actually supports structural equality on tuples and arrays. The simple way to do this, using ResolvedType.Exists to recursively check if a type contains Result, is incorrect:

• It will incorrectly say equality of callables that have Result in their argument or return type is a result equality. Regardless of whether Q# supports equality on callables, comparing two callables that have Result in their signature does not imply equality of Results.
• It stops recursing when it encounters a UDT, but equality of UDTs could imply equality of Results.

We would need something to search a type that stops at callables but continues recursing on UDTs after looking up the underlying type. The UDT-looking-up part sounds non-trivial. Also, I think the benefit is very small right now - the new situations where the error message would be shown are already invalid right now and need to be changed before the program compiles anyway.

[bettinaheim]

@SamarSha I see your point about it being a non-trivial amount of code that currently wouldn't serve any functionality, and agree that we should write it when it is used. I sent you a note on tracking this.