Branch: refs/heads/main
Revision: 708e6c8a621277ab9082d85f3f77a34d8563ec0b
Author: bradcray
Link: Remove this incorrect future of missing `init=` call on records by bradcray · Pull Request #29270 · chapel-lang/chapel · GitHub
Log Message:
Remove this incorrect future of missing init= call on records (#29270)
When I added this future in #29236, I thought I'd proven to myself that
this wasn't a compiler transformation like copy elision by compiling
with --baseline. But with more investigation, it is copy elision, and
it's just that --baseline doesn't disable it (presumably because it's
not an optimization, but a defined/required part of the language).
Compiling with --no-copy-elision does cause the test to work as I was
expecting.
Then, I noticed that split-init.cpp doesn't refer to whether or not a
type is POD in its analysis and wondered whether it just overlooked this
check. But refreshing my memory, reading the docs, and checking existing
tests, this is as it was intended to be so that we could optimize
assignments of arrays (which are non-POD) and the like.
So, I'm saying this is working as intended and removing (rather than
retiring) this future since other tests already cover this case well
(e.g., see test/types/records/copy-elision/copy-elision*behavior.chpl).
Note that in #29239, I claim I tried inserting a use of u4 after the
initialization and didn't see a difference in behavior, but I must have
made a mistake, as I'm seeing that disable the elision today. Best guess
is that I was looking for my init= writeln just above the last line
(as I was in the original future), but forgot that I should've looked
two lines above the last (since I'd added a new writeln).
Resolves #29239
[trivial, not reviewed]
Diff:
D test/types/unions/record-copy-init2.bad
D test/types/unions/record-copy-init2.chpl
D test/types/unions/record-copy-init2.future
D test/types/unions/record-copy-init2.good
https://github.com/chapel-lang/chapel/pull/29270.diff