Bug 9279 – [REG2.055/2.063] Static array return value implicitly converted to immutable dynamic array
Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P3
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-01-07T12:29:00Z
Last change time
2015-06-17T21:05:48Z
Keywords
accepts-invalid, pull, wrong-code
Assigned to
nobody
Creator
sludwig
Comments
Comment #0 by sludwig — 2013-01-07T12:29:25Z
The following compiles without error:
---
char[2] b()()
{
char[2] ret;
return ret;
}
string a()
{
return b();
}
---
Changing b to a normal function causes the correct error message that an implicit conversion of char[2u] to string is not possible.
Note that this affects std.digest.digest.toHexString(). Returnung toHexString(digest) from a function will result in a corrupted string.
Comment #1 by yebblies — 2013-11-19T23:42:36Z
*** Issue 11560 has been marked as a duplicate of this issue. ***
Comment #2 by dlang-bugzilla — 2013-12-23T14:35:09Z
And now it doesn't even need to be a template function. This compiles:
char[12] getArr() { return "Hello World!"; }
string getString() { return getArr(); }
Comment #3 by dlang-bugzilla — 2013-12-23T14:43:58Z
Raising priority as this bug is exhibited by typical usage of std.digest (see Issue 11560).
Comment #4 by yebblies — 2014-01-28T01:38:24Z
*** Issue 12013 has been marked as a duplicate of this issue. ***
Comment #5 by yebblies — 2014-01-28T01:39:11Z
*** Issue 11760 has been marked as a duplicate of this issue. ***
Comment #6 by dlang-bugzilla — 2015-05-29T08:49:41Z
(In reply to Vladimir Panteleev from comment #2)
> And now it doesn't even need to be a template function.
I guess that makes it a regression.
This program (based on original bug report):
/////////////////// test1.d //////////////////
static assert(!is(typeof({
char[2] b()() { char[2] ret; return ret; }
string a() { return b(); }
})));
//////////////////////////////////////////////
compiles in 2.054 but not in 2.055, regression introduced in:
https://github.com/D-Programming-Language/dmd/pull/218
This program (based on comment 2):
//////////////////// test2.d ///////////////////
static assert(!is(typeof({
char[12] getArr() { return "Hello World!"; }
string getString() { return getArr(); }
})));
////////////////////////////////////////////////
compiles in 2.062 but not in 2.063, regression introduced in:
https://github.com/D-Programming-Language/dmd/pull/1519
Comment #7 by k.hara.pg — 2015-05-29T09:50:35Z
(In reply to Vladimir Panteleev from comment #6)
> (In reply to Vladimir Panteleev from comment #2)
> I guess that makes it a regression.
I'm not sure it should be called "regression". Yes, the two enhancement PRs appended the cases of original wrong-code bug, caused by the undetection of escaping reference to local data. However the bug exists from the very old versions...
Comment #8 by dlang-bugzilla — 2015-05-29T10:07:50Z
(In reply to Kenji Hara from comment #7)
> I'm not sure it should be called "regression". Yes, the two enhancement PRs
> appended the cases of original wrong-code bug, caused by the undetection of
> escaping reference to local data. However the bug exists from the very old
> versions...
Is this about semantics?
IMO a regression is the effect of a change, not the nature of the change itself (i.e. whether it introduces a bug or merely exposes a latent bug).
You can call it whatever you like, but ultimately the effect is that something works as expected in version N and then doesn't in version N+1.
If we were to all sit down, discuss, and agree to use different terminology for different kinds of causes and effects, I could start calling them something else, though I think that would be a terrible waste of time.
Anyway, I hope my regression notifications on the pull requests aren't too demotivating. I don't know how I would feel if I received so many regression notifications. I certainly don't intend to accuse anyone of anything - I would like to know if a change that I authored or reviewed introduced a regression, which is why I'm posting the GitHub comments.
Comment #9 by k.hara.pg — 2015-05-29T10:47:24Z
(In reply to Vladimir Panteleev from comment #8)
> You can call it whatever you like, but ultimately the effect is that
> something works as expected in version N and then doesn't in version N+1.
Sorry, I understand that. It was just my complaint against the increasing of regression issues.
Fortunately, adding more escape check for the case is not so difficult. I'll open a PR in this day (JST).