Fuzz: Panic: 'path should be resolved'. about qsharp HOT 5 CLOSED

I can reproduce with d6de278, but not latest main. I think #163 accidentally fixed this, because it changed the type checker to no longer try to resolve paths in types. Let me know if updating helps.

from qsharp.

Confirmed, the panic is resolved. I'm unblocked.

But the Q# code comment still changes the behavior between the commands qsc.exe t3.qs and qsc.exe - < t3.qs. I'm not sure if this is something that requires fixing or not, if yes then whether the current GitHub item needs to be reopened or a new one created. Up to you.
It is at least interesting to know why the comment affects the behavior, may be there is some hidden bug...

qsc.exe t3.qs

  × `i` not found in this scope
   ╭─[t3.qs:1:1]
 1 │ //
 2 │ namespace N{operation P(a:i):D{}}
   ·                           ┬
   ·                           ╰── not found
   ╰────


  × `D` not found in this scope
   ╭─[t3.qs:1:1]
 1 │ //
 2 │ namespace N{operation P(a:i):D{}}
   ·                              ┬
   ·                              ╰── not found
   ╰────


  × mismatched types
   ╭─[t3.qs:1:1]
 1 │ //
 2 │ namespace N{operation P(a:i):D{}}
   ·                               ─┬
   ·                                ╰── expected ?, found ()
   ╰────

qsc.exe - < t3.qs

  × entry point not found
  help: a single callable with the `@EntryPoint()` attribute must be present if no entry expression is provided

Also the following bug reporting seems misleading to me:

 2 │ namespace N{operation P(a:i):D{}}
   ·                               ─┬
   ·                                ╰── expected ?, found ()

Complains that found () whereas there is {} in the input stream.

Also the following fragment seems misleading to me in all the cases [t3.qs:1:1]. Refers to a wrong line and column.

from qsharp.

But the Q# code comment still changes the behavior between the commands qsc.exe t3.qs and qsc.exe - < t3.qs. I'm not sure if this is something that requires fixing or not, if yes then whether the current GitHub item needs to be reopened or a new one created. Up to you.
It is at least interesting to know why the comment affects the behavior, may be there is some hidden bug...

I think this is a separate bug with how qsc is reading stdin. It looks like the newline after the comment is getting eaten, because that error happens with an empty input file. Can you file another issue?

Also the following bug reporting seems misleading to me:

 2 │ namespace N{operation P(a:i):D{}}
   ·                               ─┬
   ·                                ╰── expected ?, found ()

Complains that found () whereas there is {} in the input stream.

The error is correct, although possibly confusing. The type of {} (empty block) is () (empty tuple).

Also the following fragment seems misleading to me in all the cases [t3.qs:1:1]. Refers to a wrong line and column.

This is how Miette renders errors. It shows the position of the start of the excerpt. Since the excerpt shows the entire file, it starts at line 1, column 1.

from qsharp.

Can you file another issue?

#188

The error is correct, although possibly confusing. The type of {} (empty block) is () (empty tuple).

FYI: This is really confusing that the function/operation body (or a block starting with { and ending with } and containing that body) has a data type (separate from the function/operation signature type). It makes an impression that one can declare/define a variable of that type. Is that really possible? If not then why do we need a data type for the function/operation body (or a block containing body)?

from qsharp.

I think the confusion comes from the fact that blocks are expressions. The type of the body block is equal to the return type of the function or operation. The return value of a function or operation is the value that comes from evaluating the body block as an expression. For example:

function AddOne(x : Int) : Int {
    let y = x + 1;
    y
}

When you call AddOne(2), x is bound to 2, and then the expression { let y = x + 1; y } is evaluated. So, yeah, the block has type Int. It just happens that an empty block evaluates to the unit tuple by default, so it has type () (also written as Unit).

from qsharp.