Internal compiler error in memory management generic iterator method

[DanilaFe]

Summary of Problem

I get an internal compiler error when compiling the following code:

class Expr {
  iter nodes(): Expr {}
}

var node: owned Expr = new Expr();

for childNode in node.nodes() {}

I believe that the code technically is not valid (childNode is generic, and I don't think that's allowed?), but a compiler error is not the right way to go. In developer mode, the error is reported as follows:

minimal-explosion.chpl:2: internal error: every return type must also have a ref type. [AST/checkAST.cpp:331]

The regular error message points to line 2 as the source of the issue.

Steps to Reproduce

Compile command: chpl minimal-explosion.chpl

• Output of chpl --version:

  chpl version 1.28.0 pre-release (dc228b96ba)
    built with LLVM version 14.0.6
  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: darwin
  CHPL_TARGET_COMPILER: llvm
  CHPL_TARGET_ARCH: arm64
  CHPL_TARGET_CPU: native
  CHPL_LOCALE_MODEL: flat
  CHPL_COMM: none
  CHPL_TASKS: fifo
  CHPL_LAUNCHER: none
  CHPL_TIMERS: generic
  CHPL_UNWIND: none
  CHPL_MEM: cstdlib
  CHPL_ATOMICS: cstdlib
  CHPL_GMP: bundled
  CHPL_HWLOC: none
  CHPL_RE2: bundled
  CHPL_LLVM: system
  CHPL_AUX_FILESYS: none

[bradcray]

Just to make sure I'm understanding the salient features here, I'm guessing that this works if:

• the declared return type (really, yield type) is removed?
• the iterator were to actually yield something? (compatible with Expr obviously :) )

Anyway, I agree that an internal error is always a bug, so am not trying to brush this aside... just trying to understand how likely it is to come up in practice. Thanks!

[DanilaFe]

At the time of writing (bc583a2afd059782bd0f8cae55f06dec08ca3f7a) this no longer causes an internal error. Closing.