Fix a bug causing generic variables used in a coforall to crash com…

…pilation (chapel-lang#24301)

Resolves chapel-lang#21272.

Fix a bug that caused a generic class variable mentioned in a `coforall`
to crash the program with an internal assertion.

Remove the internal assertion. It asserts that actuals passed to a task
function are not generic, but it is possible for this to be the case if
we are already in an error state. In that case, we should continue to
the end of the pass rather than crash.

While here, adjust the class section of the spec to indicate that for a
class type `C`, the expression `C` is taken to mean generic management
except in the `new` expression, where it implies `owned C`.

TESTING

- [x] `linux64`, `standard`

Reviewed by @vasslitvinov. Thanks!

compiler/resolution/functionResolution.cpp

@@ -7201,7 +7201,11 @@ static void handleTaskIntentArgs(CallInfo& info, FnSymbol* taskFn) {
 
       // If 'call' is in a generic function, it will have been instantiated by
       // now. Otherwise our task function has to remain generic.
-      INT_ASSERT(varActual->type->symbol->hasFlag(FLAG_GENERIC) == false);
+      //
+      // ---> It's possible for this assert to fire if the caller is generic
+      // and we are already in an error state. Remove it for now so that we
+      // can make progress.
+      // INT_ASSERT(varActual->type->symbol->hasFlag(FLAG_GENERIC) == false);
 
       if (formal->id == breakOnResolveID)
         gdbShouldBreakHere();

doc/rst/language/spec/classes.rst

@@ -192,9 +192,10 @@ specified, may appear in the inheritance lists of other class
 declarations.
 
 If a class type's memory management strategy is unspecified, it will be
-generic. (This is not the case for instances of classes. When a new class
-instance is created with an unspecified memory management strategy it
-will default to ``owned``.)
+generic. (This is not the case for class instances created using the
+``new`` expression (see :ref:`Class_New`). When a ``new`` expression
+does not specify a memory management strategy, then the management will
+default to ``owned``.)
 
 Variables of class type cannot store ``nil`` unless the class type is
 nilable (:ref:`Nilable_Classes`).

test/statements/loops/CoforallDefaultInitBug.chpl

@@ -0,0 +1,15 @@
+class MyClass {
+  proc func() {
+    return 2 + 2;
+  }
+}
+
+// Split-init error should fire at this point. It would be nice if the error
+// would mention a note about the use within the `coforall`, but that isn't
+// necessary - and would require modification to map `m` to temporaries
+// introduced for the `coforall` block function.
+var m: MyClass;
+
+coforall idx in 0..3 {
+  m.func();
+}

test/statements/loops/CoforallDefaultInitBug.good

@@ -0,0 +1,3 @@
+CoforallDefaultInitBug.chpl:13: error: cannot default-initialize a variable with generic type
+CoforallDefaultInitBug.chpl:13: note: 'm' has generic type 'MyClass'
+CoforallDefaultInitBug.chpl:13: note: cannot find initialization point to split-init this variable