Bug 15167 – [REG2.069-devel] conflicting error with repeated alias declaration

cat > bug.d << CODE version (X86_64) alias ulong CARD64; static if (true) alias ulong CARD64; CODE dmd -c bug ---- DMD v2.069-devel-6279af3 DEBUG bug.d(5): Error: alias bug.CARD64 conflicts with alias bug.CARD64 at bug.d(2) ---- It might indeed be treated as conflict but it used to work with 2.068.2 as long as one of the aliases is within a static if.

Introduced in: https://github.com/D-Programming-Language/dmd/pull/4816 > It might indeed be treated as conflict but it used to work with 2.068.2 as long as one of the aliases is within a static if. Yes, it was a bug and fixed as issue 13203. ---- If we will accept the snippet code as valid, it would need additional rule for the overloaded alias declarations: - If two overloaded alias declarations are aliases of an identical type, they don't conflict. // simplest example case alias a = int; alias a = int; // identical, no conflict alias b = int: alias b = const int; // not identical, conflict How about that?

Is there a compelling reason to allow: alias a = int; alias a = int; ? I can't think of one. The CARD64 example also looks like invalid code that happened to be accepted.

(In reply to Walter Bright from comment #2) > Is there a compelling reason to allow: > > alias a = int; > alias a = int; > > ? I can't think of one. The CARD64 example also looks like invalid code that > happened to be accepted. Because today, two different alias declarations aliasing an identical type are allowed if they're accessed beyond the import boundaries. module a; alias ulong CARD64; module b; alias ulong CARD64; module test; import a, b; pragma(msg, CARD64); // OK, ulong is printed (It's handled in ScopeDsymbol.search.) So, if there's no ambiguous, I think accepting such the code would be reasonable.

Implemented. https://github.com/D-Programming-Language/dmd/pull/5169

(In reply to Kenji Hara from comment #3) > Because today, two different alias declarations aliasing an identical type > are allowed if they're accessed beyond the import boundaries. Identical symbol aliases are also allowed via imports. So, I think the following case would also need to be supported. int a15167; alias Var15167 = a15167; alias Var15167 = a15167; void f15167() {} alias Foo15167 = f15167; alias Func15167 = Foo15167; alias Func15167 = f15167;

(In reply to Martin Nowak from comment #0) > version (X86_64) > alias ulong CARD64; > > static if (true) > alias ulong CARD64; @Martin Is there any reasons that you cannot remove the alias repetition? Currently any identical aliases of unoverloadable entities (type, and unoverloadable symbols - variable, module, package, import, template and instance) just always conflict in a scope.

(In reply to Kenji Hara from comment #5) > (In reply to Kenji Hara from comment #3) > > Because today, two different alias declarations aliasing an identical type > > are allowed if they're accessed beyond the import boundaries. > > Identical symbol aliases are also allowed via imports. That's right, and that must be supported, because one doesn't necessarily control the declarations in imports. > So, I think the > following case would also need to be supported. > > int a15167; > alias Var15167 = a15167; > alias Var15167 = a15167; > > void f15167() {} > alias Foo15167 = f15167; > alias Func15167 = Foo15167; > alias Func15167 = f15167; I don't believe that follows, and I can't think of a valid use case for it that doesn't look like a bug. Note that one does always control the declarations within a module, so there's no reason to allow this.

(In reply to Walter Bright from comment #7) > Note that one does always control the > declarations within a module, so there's no reason to allow this. Make sense to me. I'll close my PR, and wait the answer for my comment #6 question.

(In reply to Kenji Hara from comment #6) > (In reply to Martin Nowak from comment #0) > > version (X86_64) > > alias ulong CARD64; > > > > static if (true) > > alias ulong CARD64; > > @Martin Is there any reasons that you cannot remove the alias repetition? Nope, as I said initially > It might indeed be treated as conflict but it used to work with 2.068.2 I found this in a often used dub binding for X11 and made a PR to fix it. https://github.com/nomad-software/x11/pull/12