Bug 3029 – Bug in array value mangling rule

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2009-05-27T05:40:00Z
Last change time
2015-06-09T01:27:57Z
Keywords
patch, spec, wrong-code
Assigned to
nobody
Creator
rsinfu
Blocks
3104

Comments

Comment #0 by rsinfu — 2009-05-27T05:40:07Z
This valid code: -------------------- module test; import std.stdio; struct S(alias init) { int[] content = init; } void main() { S!([12, 3]) s1; S!([1, 23]) s2; writeln(s1.content); writeln(s2.content); } -------------------- prints wrong values: -------------------- 12 3 12 3 -------------------- The second line should be "1 23", not "12 3". That is caused by a bug in the current array value mangling rule: -------------------- Value: A Number Value... -------------------- Under this rule, both S!([12, 3]) and S!([1, 23]) get mangled to the same name "S4test15__T1SVG2iA2123Z". (Name collision!!!) There should be delimiters in Values. For example: -------------------- Value: A Number Values Values: Value Value _ Values --------------------
Comment #1 by rsinfu — 2009-05-27T05:54:04Z
Struct literals and associative array literals have the same bug too.
Comment #2 by rsinfu — 2009-06-06T09:07:02Z
Another (possibly better) option is to fix the numeric literal mangling rule as this: -------------------- Value: i Number // positive numeric literal i N Number // negative numeric literal -------------------- The prefix 'i' avoids the mangled-name collision. And this rule is consistent with other literal mangling rules, which are prefixed by some character (e.g. 'e' for floating point literals). Patch (expression.c): -------------------- void IntegerExp::toMangleBuffer(OutBuffer *buf) { if ((sinteger_t)value < 0) - buf->printf("N%jd", -value); + buf->printf("iN%jd", -value); else - buf->printf("%jd", value); + buf->printf("i%jd", value); } --------------------
Comment #3 by bugzilla — 2010-02-05T19:27:30Z
changeset 370
Comment #4 by braddr — 2010-02-05T19:33:46Z
Why keep the backwards compatibility in D2?
Comment #5 by clugdbug — 2010-02-05T22:09:00Z
(In reply to comment #4) > Why keep the backwards compatibility in D2? Yes. With things like the recent change to ModuleInfo, you can't even update the compiler one revision without recompiling. So I don't think we have to worry about D2 backwards compatibility for the next month (which is why it's crucial to get these types of bugs fixed now).
Comment #6 by Kosmonaut — 2010-02-05T23:41:50Z
(In reply to comment #3) > changeset 370 http://www.dsource.org/projects/dmd/changeset/370
Comment #7 by bugzilla — 2010-03-08T22:19:22Z
Fixed dmd 1.057 and 2.041
Comment #8 by yebblies — 2012-02-21T07:18:23Z
What happened here? Are we really maintaining backwards compatibility in only the cases that _weren't_ buggy? What legacy compiled code base is this supposed to be supporting? I seriously doubt anyone expects to be able to use a new version of dmd without recompiling their code at this point. See expression.c:2128
Comment #9 by github-bugzilla — 2014-01-24T11:19:09Z
Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/24ae9f83b94227f758ae5b367b355ab309421e72 Remove 'awful hack' introduced when fixing issue 3029 https://github.com/D-Programming-Language/dmd/commit/533149070309231924cee30ddf1899151a097332 Merge pull request #3134 from yebblies/issue3029 Remove 'awful hack' introduced when fixing issue 3029