# Out intent error on \[\] real versus real confusion

**URL:** <https://chapel.discourse.group/t/out-intent-error-on-real-versus-real-confusion/49006>\
**Category:** Users\
**Created:** [April 16, 2026, 6:41pm UTC](https://chapel.discourse.group/t/out-intent-error-on-real-versus-real-confusion/49006 "2026-04-16T18:41:51Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![nelsonluisdias](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/nelsonluisdias/32/691_2.png) [@nelsonluisdias](https://chapel.discourse.group/u/nelsonluisdias)\
**Post date:** [April 16, 2026, 6:41pm UTC](https://chapel.discourse.group/t/out-intent-error-on-real-versus-real-confusion/49006/1 "2026-04-16T18:41:51Z")

</div>

The code below,

```chapel
const nC = 5;
var xbar,ybar: [1..nC] real;
for C in 1..nC do {
   // -----------------------------------------------------------------
   // The eigenvalues.
   // -----------------------------------------------------------------
   var lambda1 = 10.0;
   // -----------------------------------------------------------------
   // Find the ellipse for each cluster.
   // -----------------------------------------------------------------
   ErrorTest(lambda1,xbar,ybar);
}
proc ErrorTest(
   const in lambda1: real,
   out xbar: real,
   out ybar: real) {
   xbar = lambda1;
   ybar = lambda1 + 1.0;
}

```

Produces an error message that is somewhat cryptic:

```Chapel
trials$ chpl outerror.chpl
outerror.chpl:11: internal error: AST-FOR-LLS-01346 chpl version 2.8.0
Note: This source location is a guess.

Internal errors indicate a bug in the Chapel compiler,
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.

```

The error itself is not hard to spot: the procedure call should have been

```chapel
ErrorTest(lambda1,xbar[C],ybar[C]);

```

However, I expected the compiler to identify the error in the type passed (`[] real` instead of `real`) and to issue an error message about the wrong type being used. Could this be a compiler bug?

Regards

Nelson

---

<div class="post-metadata">

**Author:** ![bradcray](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/bradcray/32/72_2.png) [@bradcray](https://chapel.discourse.group/u/bradcray)\
**Post date:** [April 16, 2026, 6:50pm UTC](https://chapel.discourse.group/t/out-intent-error-on-real-versus-real-confusion/49006/2 "2026-04-16T18:50:30Z")

</div>

Hi Nelson —

We consider any internal error to be a bug, yes. Please feel encouraged to open a GitHub issue for this.

-Brad

---

<div class="post-metadata">

**Author:** ![nelsonluisdias](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/nelsonluisdias/32/691_2.png) [@nelsonluisdias](https://chapel.discourse.group/u/nelsonluisdias)\
**Post date:** [April 16, 2026, 7:01pm UTC](https://chapel.discourse.group/t/out-intent-error-on-real-versus-real-confusion/49006/3 "2026-04-16T19:01:52Z")

</div>

Github issue posted.

---

<div class="post-metadata">

**Author:** ![bradcray](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/bradcray/32/72_2.png) [@bradcray](https://chapel.discourse.group/u/bradcray)\
**Post date:** [April 17, 2026, 9:59pm UTC](https://chapel.discourse.group/t/out-intent-error-on-real-versus-real-confusion/49006/4 "2026-04-17T21:59:19Z")

</div>

Thanks Nelson!

Here's the issue for future readers who might find their way here:

> <https://github.com/chapel-lang/chapel/issues/28696>
>
> \### Summary of Problem
> 
> \*\*Description:\*\*
> 
> What behavior did you observe when enc…ountering this issue?
> 
> The compiler reports an internal error
> 
> What behavior did you expect to observe?
> 
> The compiler should have catched the type mismatch.
> 
> Describe the workarounds you've tried, if any.
> 
> It is easy to identify the mismatch manually. The error message refers to the
> correct line (11; see code below)
> 
> 
> \*\*Is this issue currently blocking your progress?\*\*
> 
> No, because it is easy to spot the problem manually.
> 
> \### Steps to Reproduce
> 
> \*\*Source Code:\*\*
> 
> \`\`\`chapel
> const nC = 5;
> var xbar,ybar: \[1..nC\] real;
> for C in 1..nC do {
> // -----------------------------------------------------------------
> // The eigenvalues.
> // -----------------------------------------------------------------
> var lambda1 = 10.0;
> // -----------------------------------------------------------------
> // Find the ellipse for each cluster.
> // -----------------------------------------------------------------
> ErrorTest(lambda1,xbar,ybar);
> }
> proc ErrorTest(
> const in lambda1: real,
> out xbar: real,
> out ybar: real) {
> xbar = lambda1;
> ybar = lambda1 + 1.0;
> }
> \`\`\`
> 
> \*\*Compile command:\*\*
> 
> chpl outerror.chpl
> 
> Gives the error
> \`\`\`
> outerror.chpl:11: internal error: AST-FOR-LLS-01346 chpl version 2.8.0
> Note: This source location is a guess.
> 
> Internal errors indicate a bug in the Chapel compiler,
> 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.
> \`\`\`
> 
> 
> 
> \*\*Associated Future Test(s):\*\*
> 
> 
> \### Configuration Information
> 
> \- Output of \`chpl --version\`:
> 
> chpl version 2.8.0
> built with LLVM version 18.1.3
> available LLVM targets: xtensa, m68k, xcore, x86-64, x86, wasm64, wasm32, ve, systemz, sparcel, sparcv9, sparc, riscv64, riscv32, ppc64le, ppc64, ppc32le, ppc32, nvptx64, nvptx, msp430, mips64el, mips64, mipsel, mips, loongarch64, loongarch32, lanai, hexagon, bpfeb, bpfel, bpf, avr, thumbeb, thumb, armeb, arm, amdgcn, r600, aarch64\_32, aarch64\_be, aarch64, arm64\_32, arm64
> Copyright 2020-2026 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: bundled
> CHPL\_TARGET\_MEM: jemalloc
> CHPL\_ATOMICS: cstdlib
> CHPL\_GMP: bundled
> CHPL\_HWLOC: bundled
> CHPL\_RE2: bundled
> CHPL\_LLVM: system \*
> CHPL\_AUX\_FILESYS: none

-Brad

---

<div class="post-metadata">

**Author:** ![nelsonluisdias](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/nelsonluisdias/32/691_2.png) [@nelsonluisdias](https://chapel.discourse.group/u/nelsonluisdias)\
**Post date:** [April 28, 2026, 9:18pm UTC](https://chapel.discourse.group/t/out-intent-error-on-real-versus-real-confusion/49006/5 "2026-04-28T21:18:36Z")

</div>

I have been thinking about this post that I initiated for some time. It is not the first time that I made a mistake regarding promotion; see [https://chapel.discourse.group/t/intent-in-real-but-compiler-accepts-a-whole-array/28211](https://chapel.discourse.group/t/intent-in-real-but-compiler-accepts-a-whole-array/28211)

It is of course the programmer's (myself) responsibility to know the language features and understand what happens when inserting an array in lieu of a scalar triggers promotion. On the other hand, because promotion is much less frequently needed than standard scalar arguments, I wonder if it would make sense to make promotion an explicit request (instead of an automatic decision by the compiler), as in

```chapel
proc haversine( const in x: || real) : || real { 
   return sin(x/2)**2 ;
}

```

Then the compiler would know that haversine is a candidate for promotion. Just a thought: neither a priority nor an actual feature request ...

Cheers

Nelson