[Issue 8847] voldemort + inout confuses "is"
https://issues.dlang.org/show_bug.cgi?id=8847 Andrei Alexandrescu changed: What|Removed |Added Version|unspecified |D2 --
[Issue 8847] voldemort + inout confuses "is"
http://d.puremagic.com/issues/show_bug.cgi?id=8847 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8847] voldemort + inout confuses "is"
http://d.puremagic.com/issues/show_bug.cgi?id=8847 --- Comment #8 from github-bugzi...@puremagic.com 2013-02-03 09:40:26 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1116d6bab4aefad92ff94205a25b82cc51d06237 fix Issue 8847 - voldemort + inout confuses "is" -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8847] voldemort + inout confuses "is"
http://d.puremagic.com/issues/show_bug.cgi?id=8847 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #7 from Kenji Hara 2012-12-17 22:54:17 PST --- https://github.com/D-Programming-Language/dmd/pull/1381 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8847] voldemort + inout confuses "is"
http://d.puremagic.com/issues/show_bug.cgi?id=8847 --- Comment #6 from github-bugzi...@puremagic.com 2012-12-17 21:38:47 PST --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/6022082b29f670095fb082102420c7b331cb7d14 Further strengthen hasSlicing. The extra requirements are not currently enabled because of bug# 8847, but they're now there, and they're listed as their in the documentation so that no one will think that they're not supposed to apply. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8847] voldemort + inout confuses "is"
http://d.puremagic.com/issues/show_bug.cgi?id=8847
--- Comment #5 from Kenji Hara 2012-11-30 23:46:35 PST ---
This is a serious problem about the name mangling rule for Voldemort Type.
At least there is two rules.
1. Mangled name of a function symbol contains the mangled name of its return
type.
2. A nested declaration's mangled name contains its enclosing mangled name.
---
module test;
pragma(msg, "1f: ", foo.mangleof);
// _D4test3fooFZAi
// --> _D [ 4test 3foo / [ FZ / Ai ] ] ...#1(Ai == int[])
int[] foo() {
struct S { int value; }
pragma(msg, "1i: ", S.mangleof);
// S4test3fooFZAi1S
// --> S [ 4test 3foo / [ FZ / Ai ] ] 1S ...#2
return null;
}
---
But, Voldemort Types cannot be mangled based on the rules.
Because, a nested struct requires enclosing function's mangling,
but the function requires return type's mangling. It's circular dependency.
In current, that is *accidentally* working.
---
auto bar() {
struct S { int value; }
pragma(msg, "2i: ", S.mangleof);
// S4test3bar1S
// --> S [ 4test 3bar / [ / ] ] 1S
// ...incorrect
return S(1);
}
pragma(msg, "2f: ", bar.mangleof);
// _D4test3barFZS4test3bar1S
// --> _D [ 4test 3bar / [ FZ / S4test3bar1S ] ]
// ...incorrect
---
And, inout type deduction on function call shoots the rule inconsistency.
---
auto baz(inout int = 0) {
struct S { int value; }
pragma(msg, "3i: ", S.mangleof); // S inside bar
// S4test3baz1S
// --> S [ 4test 3baz / [ / ] ] 1S ...(A)
return inout(S)(1);
}
pragma(msg, "3f: ", baz.mangleof);
// _D4test3bazFNgiZNgS4test3baz1S
// --> _D [ 4test 3baz / [ FNgiZ / Ng S4test3baz1S ] ]
pragma(msg, "3o: ", typeof(baz(0)).mangleof); // S outside bar
// S4test3bazFNgiZNgS4test3baz1S1S
// --> S [ 4test 3baz / [ FNgiZNg / S4test3baz1S ] ] 1S ...(B)
---
Compare:
A. --> S [ 4test 3baz / [ / ] ] 1S
B. --> S [ 4test 3baz / [ FNgiZNg / S4test3baz1S ] ] 1S
Mismatching between A and B is the root cause of this issue.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8847] voldemort + inout confuses "is"
http://d.puremagic.com/issues/show_bug.cgi?id=8847 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com Severity|major |blocker -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8847] voldemort + inout confuses "is"
http://d.puremagic.com/issues/show_bug.cgi?id=8847 --- Comment #4 from monarchdo...@gmail.com 2012-11-30 02:35:04 PST --- (In reply to comment #3) > > Any news? I wanted to add that https://github.com/D-Programming-Language/phobos/pull/982 Is also subject to this issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8847] voldemort + inout confuses "is"
http://d.puremagic.com/issues/show_bug.cgi?id=8847 --- Comment #3 from monarchdo...@gmail.com 2012-10-28 04:01:55 PDT --- (In reply to comment #2) > This is probably the same issue I hit when merging the 2.060 frontend into LDC > a while ago. The issue is that the same type can end up with two different > mangled names, which causes two different TypeInfo instances to be emitted. > > [SNIP] > > I'm not sure what the correct fix is here – Walter? Kenji? Any news? Do you have any idea about the *cost* of fixing this? If there is a fix possible, then I'll wait for it (No problem waiting whatsoever). But if not, then I'll go for bypass, just want to know which direction I should take this... Thanks. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8847] voldemort + inout confuses "is"
http://d.puremagic.com/issues/show_bug.cgi?id=8847
klickverbot changed:
What|Removed |Added
CC||c...@klickverbot.at
--- Comment #2 from klickverbot 2012-10-18 02:29:59 PDT
---
This is probably the same issue I hit when merging the 2.060 frontend into LDC
a while ago. The issue is that the same type can end up with two different
mangled names, which causes two different TypeInfo instances to be emitted.
The test case from
https://github.com/ldc-developers/ldc/blob/master/gen/tocall.cpp#L677:
---
auto iota() {
static struct Result {
this(int) {}
inout(Result) test() inout { return cast(inout)Result(0); }
}
return Result.init;
}
void main() { auto r = iota(); }
---
I'm not sure what the correct fix is here – Walter? Kenji?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8847] voldemort + inout confuses "is"
http://d.puremagic.com/issues/show_bug.cgi?id=8847
--- Comment #1 from monarchdo...@gmail.com 2012-10-18 02:19:29 PDT ---
(In reply to comment #0)
> Which is very strange. I found the root condition that recreates this: It is
> having a voldemort function that is qualified with inout:
>
> //
> import std.stdio;
> import std.conv;
>
> auto S()
> {
> static struct Result
> {
> inout(Result) get() inout {return this;}
> }
> return Result();
> }
>
> void main()
> {
> auto a = S();
> auto b = a.get();
> alias typeof(a) A;
> alias typeof(b) B;
> writeln("Typeof A: ", A.stringof);
> writeln("Typeof B: ", B.stringof);
> assert(is(A == B), text(A.stringof, " is different from " , B.stringof));
> }
> //
> Typeof A: Result
> Typeof B: Result
> core.exception.AssertError@main.d(21): Result is different from Result
> //
Yeah, I forgot to mention, if you remove the "inout" attribute, or if you make
Result a global struct, the problem disappears, so it *really* only ever
appears when inout and voldemort are combined.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
