Remove old druntime interface

[braddr]

The new non-vararg interfaces to druntime works for both 32 and 64, so let's drop the old version in favor of the new one. It's simpler, more portable, and having just one interface reduces maintenance costs.

[WalterBright]

I want to wait on this a while longer before breaking old compiled code.

[yebblies]

It's been over 6 months, is there a plan for when this will get merged in?

[braddr]

I'd be happy to update it to current, but it's also very low priority cleanup. I mostly did it because it was easy and it was a good way to play with the pull system back right after we'd moved to github.

[yebblies]

I consider anything that removes redundant or dead code from the glue layer to be very useful. It's a very scary and confusing part of the compiler for me.

As it's also one of the oldest pull requests, and fairly straightforward, I was wondering how long Walter planned to wait.

[WalterBright]

Brad, if you want to update the pull request, I'll fold it in. Also, a lot of the changes appear to be gratuitous whitespace changes - please run detab over files before checking them in.

[braddr]

On Monday, August 29, 2011 8:40:23 PM, WalterBright wrote:

Brad, if you want to update the pull request, I'll fold it in. Also, a lot of the changes appear to be gratuitous whitespace changes - please run detab over files before checking them in.

I'll update. They're not gratuitious whitespace changes though.. it's
removal of a layer of if()'s.

[braddr]

Hrm.. updating it to current code is trivial, but one of the interpret tests is failing and the stack trace looks very familiar.. something I hit when I played with this before. I don't recall what I did to fix it, or if I even did. Essentially everything passes except for the dmd test compilable/interpret3.d. The problem has to do with AA Literals:

#0 0x0818a637 in TemplateInstance::semantic (this=0x8468b08, sc=0x0, fargs=0x0) at template.c:3795
#1 0x0818a5f2 in TemplateInstance::semantic (this=0x8468b08, sc=0x0) at template.c:3765
#2 0x081405b3 in TypeAArray::getImpl (this=0x8276268) at mtype.c:3989
#3 0x08197825 in TypeInfoAssociativeArrayDeclaration::toDt (this=0x8468958, pdt=0x84679b8) at typinf.c:428
#4 0x0819898a in TypeInfoDeclaration::toObjFile (this=0x8468958, multiobj=0) at typinf.c:748
#5 0x081967e6 in Type::getTypeInfo (this=0x8276268, sc=0x0) at typinf.c:147
#6 0x08197776 in TypeInfoAssociativeArrayDeclaration::toDt (this=0x84687e8, pdt=0x84675f0) at typinf.c:421
#7 0x0819898a in TypeInfoDeclaration::toObjFile (this=0x84687e8, multiobj=0) at typinf.c:748
#8 0x081967e6 in Type::getTypeInfo (this=0x837af08, sc=0x0) at typinf.c:147
#9 0x080c8432 in AssocArrayLiteralExp::toElem (this=0x837ae78, irs=0xbfffedf0) at e2ir.c:4733
#10 0x080c15b5 in BinExp::toElemBin (this=0x837afb8, irs=0xbfffedf0, op=56) at e2ir.c:2066
#11 0x080c3c3d in AssignExp::toElem (this=0x837afb8, irs=0xbfffedf0) at e2ir.c:2930
#12 0x080bec3b in Dsymbol_toElem (s=0x8276de0, irs=0xbfffedf0) at e2ir.c:1166
#13 0x080bef3d in DeclarationExp::toElem (this=0x8276e90, irs=0xbfffedf0) at e2ir.c:1230
#14 0x080bdf70 in Expression::toElemDtor (this=0x8276e90, irs=0xbfffedf0) at e2ir.c:695
#15 0x0816c394 in ExpStatement::toIR (this=0x8276e78, irs=0xbfffedf0) at s2ir.c:1314
#16 0x0816c461 in CompoundStatement::toIR (this=0x8276fb8, irs=0xbfffedf0) at s2ir.c:1351
#17 0x0816c461 in CompoundStatement::toIR (this=0x837b0c8, irs=0xbfffedf0) at s2ir.c:1351
#18 0x08116158 in FuncDeclaration::toObjFile (this=0x8276c70, multiobj=0) at glue.c:928
#19 0x0804b727 in AttribDeclaration::toObjFile (this=0x8277508, multiobj=0) at attrib.c:242
#20 0x08114a5a in Module::genobjfile (this=0x8230270, multiobj=0) at glue.c:276
#21 0x0813465a in main (argc=13, argv=0x8226520) at mars.c:1319

frame 0 is:
3795 tinst = sc->tinst;

frame 9 is here:
4731 e = el_params(el_pair(TYdarray, el_long(TYsize_t, dim), el_ptr(svalues)),
4732 el_pair(TYdarray, el_long(TYsize_t, dim), el_ptr(skeys )),
4733 --> ta->getTypeInfo(NULL)->toElem(irs),
4734 NULL);

Given that this isn't urgent at all, I'm going to set it aside. If anyone else wants to dive into it, the changes shown in the diff are essentially search for aaGetSymbol in e2ir.c and make the I64 branch the only case. The variable in those cases isn't about 64 bitness but about druntime api versioning.

[yebblies]

It's trying to run semantic on the AA template without a scope. I think using object.d's global scope is the correct solution.

yebblies@4b3b7d5#diff-2

[braddr]

Key question: Why is that new block of code required? It wasn't before and isn't required on 64 bits, just 32 bits. Secondary becomes, why doesn't the type instance have a scope already? Is it really ok to borrow the parent scope? My instincts tell me to figure out why it doesn't already have one, not figure out how to get one.

[yebblies]

Fair enough, I'll find the answer tomorrow. My instinct tells me the explanation is that the semi-library aa implementation is borked, as usual.

[yebblies]

By tomorrow I meant 2 weeks. The reason it doesn't fail on 64bit is this - you disabled it.

[yebblies]

#381 should fix the segfault.
Would you like to update this patch now there's a solution?

[braddr]

Aren't you glad I pushed for a better root cause determination? :) I'd forgotten all about that other bug (filed quite a few 64 bit bugs that still aren't fixed while doing the d2 x86/64 work). After pull 381 is incorporated I'll update this one and re-test it. Assuming all goes well, then this can be pulled in.

Thanks for doing the research.

[yebblies]

sigh, yes. Hopefully one day I'll be able to push myself to do it.

[braddr]

Re-creating as a new pull request.