fix issue 3031 - static var and func declaration conflict in different sub scope

[ghost]

I'm glad to propose a fix for this very old (in IT time, 11 years is much !) issue.

The approach of the fix is based on the observation that the fundamental (and only) problem was that allowing such declarations would produce same mangling.
Now when the insertion in the scope fails, and if the declaration was static, its name is changed and a local alias declaration, taking the previous name, is generated.

concrectly, some code showing the lowering:

void main()
{
    // the following ...
    { static int a; }
    { static int a; } // same mangling, but mangling is not useful !
    // is rewritten as
    { static int a; }
    { static int newID; alias a = newID; }
}

This works because:

• the static declaration, the one that needs a unique mangle, has now an unique identifier.
• the code following the declaration use the new alias.

[dlang-bot]

Thanks for your pull request, @NilsLankila!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	3031	major	scoped static var conflicts

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#11250"

[Geod24]

I think this is also related to the aggregated bug Kenji created: https://issues.dlang.org/show_bug.cgi?id=14831
You might want to look it up to see which issues he ran into, particularly the extern (C[++]) ones.

[WalterBright]

My idea was to fix this in the name mangling code. I like your idea of using an alias better.

[ghost]

Is this good now ?

[MoonlightSentinel]

This test should create multiple different instantiations of foo given #11250 (comment)

[ghost]

I don't follow you, it's only called once.

[ghost]

can you expand the problem ?

[rainers]

The problem I meant is that there are only 2 statics generated in foo, one generating the original symbol, one with the aliased symbol. A third static would verify that the generated symbols don't collide. IIRC the version I commented on didn't use generateId so it might be solved now to some extend, but a test (a third static generated at the same location) could verify that.

There is still a problem with generateId, though: with separate compilation units, the same symbol name can be generated, but might have different implementations.

[ghost]

Ok thanks for the explanations. Actually I'm embarassed because this was not supposed to be covered by the PR but it had appeared that the test passed.

[MoonlightSentinel]

Another solution was implemented