# \[Chapel Merge\] Fix a postinit case for unions; customize union errors for management types

**URL:** https://chapel.discourse.group/t/chapel-merge-fix-a-postinit-case-for-unions-customize-union-errors-for-management-types/51459
**Category:** Commits
**Created:** [August 19, 2026, 6:23pm UTC](https://chapel.discourse.group/t/chapel-merge-fix-a-postinit-case-for-unions-customize-union-errors-for-management-types/51459 "2026-08-19T18:23:37Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![chapelhpcBot](https://avatars.discourse-cdn.com/v4/letter/c/7feea3/32.png) [@chapelhpcBot](https://chapel.discourse.group/u/chapelhpcBot)
#### Post date: [August 19, 2026, 6:23pm UTC](https://chapel.discourse.group/t/chapel-merge-fix-a-postinit-case-for-unions-customize-union-errors-for-management-types/51459/1 "2026-08-19T18:23:37Z")

</div>

Branch: refs/heads/main  
Revision: 29fa80d7f4ecfabcd13a330b2d0a734de79fe351  
Author: bradcray  
Link: [Fix a postinit case for unions; customize union errors for management types by bradcray · Pull Request #29281 · chapel-lang/chapel · GitHub](https://github.com/chapel-lang/chapel/pull/29281)  
Log Message:  
Fix a postinit case for unions; customize union errors for management types (#29281)

While prepping my demo for this morning's Chapel meeting, I ran across a  
case where we weren't calling postinit() as we should've been. In fact,  
one of the tests I added in #29253 had this bug, but it slipped past  
both me and my reviewer. It seems that when declaring a union field like  
`var myU: u;` we did not call postinit(). The fix for this was simple,  
and reflected another `isRecord()` test that should've been expanded to  
include `isUnion()`.

This PR fixes that issue and also extends a few other 'isRecord()' tests  
in functionResolution.cpp to include unions as well. The most visible of  
these is that we now generate a customized error for (illegal) 'new  
owned u()' and friends, and I've added a test to lock that in. Here, the  
case was not as bad for non-unions, as we had a catch-all for "other  
non-record, non-class types."

Of the changes here, the one to line 13276/9 is pretty speculative. I  
spent a few minutes trying to write a test showing that it improved  
things, but wasn't able to do so quickly. My sense is that if this case  
should include unions (as I'm hypothesizing), it's easier to fix it now  
than to hunt it down later; and that if it shouldn't, it'll either bite  
us in an obvious way or be innocuous.

[reviewed by @benharsh]

Compare: [Comparing fbdb6afcc89063b084441654686d34b0661ccf7a...2494c6327c661dfe8aaa15c0be3b902e48883bca · chapel-lang/chapel · GitHub](https://github.com/chapel-lang/chapel/compare/fbdb6afcc89063b084441654686d34b0661ccf7a...2494c6327c661dfe8aaa15c0be3b902e48883bca)

Diff:  
M compiler/resolution/functionResolution.cpp  
A test/types/unions/union-new-managed.chpl  
A test/types/unions/union-new-managed.good  
M test/types/unions/union-postinit.good  
[https://github.com/chapel-lang/chapel/pull/29281.diff](https://github.com/chapel-lang/chapel/pull/29281.diff)