stan parser: disallow transpose operator on primitive type variables

[mitzimorris]

Summary:

parser allows transpose of primitives in program - it would be better to flag this and fail.

Description:

noticed during code review as part of #2498

transpose is allowed to apply to a primitive, doing nothing. I'd rather it fail at this point and print a warning message, but that would be a change in current language behavior and we can do that in a different PR.

Reproducible Steps:

Please report steps to reproduce the issue. If it's not possible to reproduce, please include a description of how you discovered the issue.

If you have a reproducible example, please include it.

Current Output:

The current output. Knowing what is the current behavior is useful.

Expected Output:

Describe what you expect the output to be. Knowing the correct behavior is also very useful.

Additional Information:

Provide any additional information here.

Current Version:

v2.18.0

[VMatthijs]

If I try to compile

model {
  print(1.0');
}

with stanc3, it tells me

Semantic error at file "test.stan", line 2, characters 8-12:
   -------------------------------------------------
     1:  model {
     2:    print(1.0');
                 ^
     3:  }
   -------------------------------------------------

Ill-typed arguments supplied to postfix operator '. Available signatures:
(matrix) => matrix
(row_vector) => vector
(vector) => row_vector
Instead supplied argument of incompatible type: real.

[bob-carpenter]

I think this is OK as an error message here. Is there a way to get the caret to point at "'" rather than "1"?

…

On Dec 13, 2018, at 7:44 AM, Matthijs Vákár ***@***.***> wrote: If I try to compile model { print(1.0'); } with stanc3, it tells me Semantic error at file "test.stan", line 2, characters 8-12: ------------------------------------------------- 1: model { 2: print(1.0'); ^ 3: } ------------------------------------------------- Ill-typed arguments supplied to postfix operator '. Available signatures: (matrix) => matrix (row_vector) => vector (vector) => row_vector Instead supplied argument of incompatible type: real. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[VMatthijs]

Not an easy way, I think. Currently, start and end locations are only carried around for expressions, statements and identifiers. Operators do not fall into those categories. The error location currently being used is that of the expression 1.0' (specifically its start location).
I could consistently move the caret to the end rather than start of an expression in a semantic error, but I think that would make things worse, rather than better, overall.
Of course, these things can be fixed, but it's a matter of priorities.

[bob-carpenter]

I think it's more conventional to point at the end of a problematic expression. Compare the C++ behavior:

int main() {
  double x = (x + x)++;
}

The error message is:

cpperr.cpp:2:21: error: expression is not assignable
  double x = (x + x)++;
             ~~~~~~~^
1 error generated.

And for this,

struct foo { };
int main() {
  foo y;
  double x = y++;
}

we get

cpperr.cpp:4:15: error: cannot increment value of type 'foo'
  double x = y++;
             ~^
1 error generated.