Bug 8665 – auto function and implicit conversion in return statement corrupt returned value
Status
RESOLVED
Resolution
FIXED
Severity
critical
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-09-15T20:31:00Z
Last change time
2012-10-28T05:55:02Z
Keywords
pull, wrong-code
Assigned to
k.hara.pg
Creator
k.hara.pg
Comments
Comment #0 by k.hara.pg — 2012-09-15T20:31:19Z
From digitalmars.d.leran forum:
http://forum.dlang.org/thread/[email protected]
Reduced test case:
auto foo(bool val)
{
if (val)
return 42;
else
return 1.5;
}
void main()
{
assert(foo(true) == 42); // assertion failure
assert(foo(false) == 1.5);
}
The return type of foo is double, but returning 42 is broken in runtime.
Comment #1 by issues.dlang — 2012-09-15T20:50:14Z
According to the spec, this code shouldn't compile in the first place, since there are multiple types being returned. To quote the spec:
> If there are multiple ReturnStatements, the types of them must match exactly. If there are no ReturnStatements, the return type is inferred to be void.
So, depending on what's causing the corruption, it doesn't need to be fixed but rather the compiler needs to be fixed so that it this example outright fails to compile.
Comment #2 by k.hara.pg — 2012-09-15T21:11:12Z
(In reply to comment #1)
> According to the spec, this code shouldn't compile in the first place, since
> there are multiple types being returned. To quote the spec:
>
> > If there are multiple ReturnStatements, the types of them must match exactly. If there are no ReturnStatements, the return type is inferred to be void.
>
> So, depending on what's causing the corruption, it doesn't need to be fixed but
> rather the compiler needs to be fixed so that it this example outright fails to
> compile.
But, I have already *fixed* bug 5899. It is getting common type of null and other reference types. Therefore, now, multiple return statements in auto function calculates the most derived common type as the actual return type.
So, I think the spec should be improved.
(I think I have to do it...)
If the decision is that we want different behavior than the spec dictates, then the spec needs to be changed, but as it stands, according to the spec, this code is supposed to be illegal, and I was just pointing that out.