Mismatch in generic class argument list causes CHECK failure

[josh11b]

#1195 has a test that fails with a CHECK-failure and a stack trace instead of a compiler error. The relevant lines are:

class Point(T:! Type) {
  // Point(T, T) does not match class declaration
  fn Origin(zero: T) -> Point(T, T) {
...

The mismatch between the Point declaration, which takes a single parameter, and the return type, which passes two arguments to Point, should be caught and reported instead of triggering a CHECK failure and stack trace:

CHECK failure at executable_semantics/interpreter/interpreter.cpp:216: p_tup.elements().size() == v_tup.elements().size()
...

This is something introduced with generic class support in #1124 .

[josh11b]

In addition, this test passes, even though it should fail if type checking was happening correctly:

https://github.com/carbon-language/carbon-lang/pull/1194/files#diff-0ffd162ea3936ac862435a58e53a61620f80e607da0bf38649526018ee65d56e

Relevant code:

class Point(T:! Type) {

  // Should error, wrote `Point` instead of `Point(T)`.
  fn Origin(zero: T) -> Point {
...

[jonmeow]

fn Origin(zero: T) -> Point(T, T) {

This is probably missing a check in the type checker that Point(T, T) is an argument mismatch.

fn Origin(zero: T) -> Point {

Is this line of code an error? Is it okay to return the unparameterized type, or does the type always need to be parameterized?

Note, if the answer to the above is "no not an error", the return statement is still an error due to the type mismatch.

[josh11b]

Currently, types that are declared with a parameter list should always be called with an argument list, so that line is in fact an error.

[josh11b]

Even if we were to make Point by itself legal, it wouldn't be a type but a function returning a type, and so would not be legal in the return type position.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. This issue is labeled inactive because the last activity was over 90 days ago.

[jonmeow]

Looks fixed, probably by #1200 and #1204.