Fix issue 23148, 21723: Generate invariant id on the basis of location rather than counter.

[FeepingCreature]

This makes it more resilient to template order issues.
Thanks Basile B. for the proposal!

Let's see what breaks...

[dlang-bot]

Thanks for your pull request and interest in making D better, @FeepingCreature! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21723	normal	Linker error: two module static library, main compiled inline, invariant that defines a function, type alias, and an alias lambda
✓	23148	regression	Missing invariant symbol with static library when template function declares struct with destructor and invariant that instantiates template with lambda, also main has a lambda

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 "stable + dmd#14176"

[thewilsonator]

Please include the test case from the bug report, removing the use of the standard library.

[FeepingCreature]

Will add the testcase, soon as I figure out what's going on with the failures.

[FeepingCreature]

Should be good now, tests pass locally. Test case added.

Note: There is nothing using the standard library in the bug report. It's reduced from std.sumtype, that's why it looks like that, but it's freestanding.

[FeepingCreature]

Since this also fixes 21723, I'll add a testcase for that too.

[dkorpel]

Are locations unique though? I thought this wasn't done because in static foreach you can have multiple definitions with the same location.

[FeepingCreature]

Ah shit, I noticed templates but I forgot about static foreach. Hm.

[FeepingCreature]

Hm, I'm actually having a hard time constructing a test case of a static foreach with two struct or class definitions with different names (so they don't collide), but the same mangling and the same type location. Note that if they have different type mangling, you're disambiguated on that basis.

If it's nested in a function, struct, class or template, even if it has the same name, it's mangled with that type and can disambiguate on that basis.

edit: Hang on, isn't that impossible? If the structs have the same mangling, every function in them should collide, not just invariant.

The only reason we need the line/column number, or counter, is that we have structs with multiple invariants. We could just count from the start of the struct and get the same effect.

So maybe static foreach in the struct would collide?

[FeepingCreature]

Oh wait, looking at Identifier.d, it has another counter that's site specific. So we're good.

Ie. with invariant in a foreach loop, you get _L5_C3_1, _L5_C3_2, etc.

Man DMD really likes global variables though.

[FeepingCreature]

Ah, but that global counter causes another undefined-reference bug that I'll probably have to dustmite.

The fun never stops with global variables!!! 🤮