internal compiler error UTI-MIS-093 [due to instantiating a type field with an array type]

[lucaferranti]

Summary of Problem

Steps to Reproduce

Source Code:

    record MultiDual {
        type t;
        type d;
        var prim : t;
        var dual : d;
    }

    proc gradient(x : [?D] ?t) {
        type d = MultiDual(t, [D] t);
        var x0 : [D] d;
        forall i in D {
            var eps : [D] t = 0.0;
            eps[i] = 1.0;
            x0[i] = new d(x[i], eps); // this is line 15
        }
        return x0;
    }

    var x = [1.0, 2.0, 3.0];
    var a = gradient(x);
    writeln(a);

produces

src/multidual.chpl:15: internal error: UTI-MIS-0935 chpl version 1.26.0
Note: This source location is a guess.

Internal errors indicate a bug in the Chapel compiler ("It's us, not you"),
and we're sorry for the hassle.  We would appreciate your reporting this bug --
please see https://chapel-lang.org/bugs.html for instructions.  In the meantime,
the filename + line number above may be useful in working around the issue.

Compile command:

chpl multidual.chpl

Associated Future Test(s):

Configuration Information

• Output of chpl --version:

chpl version 1.26.0
  built with LLVM version 12.0.0
Copyright 2020-2022 Hewlett Packard Enterprise Development LP
Copyright 2004-2019 Cray Inc.
(See LICENSE file for more details)

• Output of $CHPL_HOME/util/printchplenv --anonymize:

CHPL_TARGET_PLATFORM: linux64
CHPL_TARGET_COMPILER: llvm
CHPL_TARGET_ARCH: x86_64
CHPL_TARGET_CPU: native
CHPL_LOCALE_MODEL: flat
CHPL_COMM: none
CHPL_TASKS: qthreads
CHPL_LAUNCHER: none
CHPL_TIMERS: generic
CHPL_UNWIND: none
CHPL_MEM: jemalloc
CHPL_ATOMICS: cstdlib
CHPL_GMP: bundled
CHPL_HWLOC: bundled
CHPL_RE2: bundled
CHPL_LLVM: system
CHPL_AUX_FILESYS: none`

• Back-end compiler and version, e.g. gcc --version or clang --version:

gcc (Ubuntu 10.3.0-1ubuntu1) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[bradcray]

[reflecting a response from gitter]

I haven't had the chance to see what is causing this internal error, though my guess is that it's running afoul of some aspect of static vs. dynamic types for the array argument in Chapel. If it helps someone get unblocked, I massaged the code into a format that I was fairly confident would work by essentially factoring the runtime types out of the generic fields in MultiDual by adding an explicit domain field:

record MultiDual {
  type t;
  var Dom: domain(1);;
  var prim: t;
  var dual: [Dom] t;

  proc init(type t) {
    this.t = t;
  }

  proc init(val, arr) {
    this.t = val.type;
    this.Dom = arr.domain;
    this.prim = val;
    this.dual = arr;
  }
}

proc gradient(x : [?D] ?t) {
  type d = MultiDual(t);
  var x0 : [D] d;
  forall i in D {
    var eps : [D] t = 0.0;
    eps[i] = 1.0;
    x0[i] = new MultiDual(x[i], eps); // this is line 15                        
  }
  return x0;
}

var x = [1.0, 2.0, 3.0];
var a = gradient(x);
writeln(a);

[bradcray]

@lucaferranti — I got back to this today and verified that the internal error does relate to the type field taking on a runtime type. Though the behavior seems different, I suspect that this is related to #15929 and #11549.

I also put together #20084 to convert it from an internal error to a user error in a very simple way, which is not particularly satisfying, but at least makes the user experience epsilon better. To see whether they have additional thoughts on this, I'm tagging @mppf because it's his code I've modified, @vasslitvinov because of his role in #11549, and @benharsh as (I believe) the author of the default initializer that's leading to this behavior (not that I'm trying to assign blame in any of those tags... just curious for thoughts about whether to proceed with the PR for now, or try something different).

Luca, from subsequent questions you've asked, I've gotten the sense that you've proceeded with workarounds, and that this isn't holding you up (even if it is unsatisfying), but would you let me know if I'm wrong about that?

[lucaferranti]

Luca, from subsequent questions you've asked, I've gotten the sense that you've proceeded with workarounds, and that this isn't holding you up (even if it is unsatisfying), but would you let me know if I'm wrong about that?

yes this is correct, in the end I managed to avoid having to tweak with inner constructors and managed to get past this (and the other internal compiler errors I met across the way). If you are curious, the relevant code of what I was trying to do and how I ended up doing it is here and here

[vasslitvinov]

When compiled with --verify, the code in the OP fails verification after resolution, on the same line:

internal error: MAI-CHE-CKS-0905