Chapel: Compile error about missing error handling despite main marked as throws

[BryantLam]

Summary of Problem

array1 and array2 emit compile-time errors complaining about error-handling despite proc main marked as throws. On 1.17.1, array3 also had the same error, but has since been fixed on master (shown for completeness).

Steps to Reproduce

Source Code:

module CannotThrow {
  proc willthrow(x: int) throws {
    throw new Error();
    return x;
  }
  proc main() throws {
    var array1 = for i in 0..3 do willthrow(i);
    var array2 = forall i in 0..3 do willthrow(i);
    var array3 = if true then [1, willthrow(2), 3] else [0];
  }
}

emits compile-time error:

CannotThrow.chpl:7: In iterator 'chpl__loopexpr_iter2':
CannotThrow.chpl:7: error: call to throwing function willthrow without throws, try, or try! (relaxed mode)
CannotThrow.chpl:2: note: throwing function willthrow defined here
CannotThrow.chpl:8: In iterator 'chpl__loopexpr_iter3':
CannotThrow.chpl:8: error: call to throwing function willthrow without throws, try, or try! (relaxed mode)
CannotThrow.chpl:2: note: throwing function willthrow defined here

Configuration Information

chpl version 1.18.0 pre-release (f56e58c3)

[bradcray]

As a quick diagnosis: It appears to me that the problem relates to the routines that the compiler introduces to represent for and forall expressions. Specifically, compiling with --devel shows the following:

testit.chpl:7: In iterator 'chpl__loopexpr_iter2':
testit.chpl:7: error: call to throwing function willthrow without throws, try, or try! (relaxed mode)
testit.chpl:2: note: throwing function willthrow defined here
testit.chpl:8: In iterator 'chpl__loopexpr_iter3':
testit.chpl:8: error: call to throwing function willthrow without throws, try, or try! (relaxed mode)
testit.chpl:2: note: throwing function willthrow defined here

where the chpl__loopexpr_iter* routines are compiler-introduced to represent the loops. I suspect that the fix here is to propagate throws information to these routines? Pinging @mppf who knows the most about error-handling and @benharsh who's messed with representation of these expressions recently.

[mppf]

PR #10642 should fix this issue.