fix Issue 23658 - .di generation of variables should turn them into d…

[WalterBright]

…eclarations

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	23658	normal	.di generation of variables should turn them into declarations

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#14851"

[WalterBright]

ping @rainers

[rainers]

Looks good for regular variables. For export variables, it might change the interpretation from dllexport to dllimport, most of the time to the better. But it could theoretically break linking to a static library (used via di files) that actually wants to export that variable from the final DLL. But I doubt that such a library exists.

You could also declare variables with initializer and inferred type extern by emitting them as extern typeof(initializer) var;.

Test coverage seems a bit low with just a single variable, and this one now has a rather odd combination of static and extern. So I'd suggest adding a couple more declarations, including export.

[rikkimax]

So I just received your email @WalterBright, it ended up in my Spam folder.

I haven't got anything to add to Rainer's comment except to say I really want to leave .di generator until after redesigning export, its current model does not fit Windows. If you'd like to talk about why it's required I'm on BeerConf for the next couple of hours.

[WalterBright]

@rainers for the static library thing, the user can always craft the .di file as he sees fit.

I like your typeof suggestion, I didn't think about that.

I'm not quite sure what to do with static mixed with extern. static is pretty much ignored at the global level anyway, so I don't think it's a problem.

@rikkimax this change to .di generation has to happen regardless. I'm surprised nobody brought it up before that I recall.

[WalterBright]

this is ready to go

[rainers]

LGTM, though still a bit low on test cases.

BTW: not related to this PR, but the di file generated from header1.d doesn't compile:

header1.di(666): Error: undefined identifier `tuple`
header1.di(666): Error: undefined identifier `tuple`

[WalterBright]

not related to this PR, but the di file generated from header1.d doesn't compile:

You know what to do: file a bugzilla issue!