Bug 10582 – Programmed and Compiler generated symbols clash.
Status
RESOLVED
Resolution
WORKSFORME
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-07-09T09:46:05Z
Last change time
2021-05-11T13:51:53Z
Assigned to
No Owner
Creator
Iain Buclaw
Comments
Comment #0 by ibuclaw — 2013-07-09T09:46:05Z
This is more of a pathological case, but produces an unexpected error nonetheless. Ditto for any other type of compiler generated temporary symbol.
struct Bug
{
~this() { }
int opApply(in int delegate(int i) dg) { return 0; }
}
void main()
{
int __sl5;
int __sl6;
foreach (i; Bug()) {} // Error: declaration __sl6 is already defined
}
Comment #1 by yebblies — 2013-08-20T07:45:18Z
From http://dlang.org/lex.html
"Identifiers starting with __ (two underscores) are reserved"
I don't know what else _could_ happen here.
Comment #2 by public — 2013-08-20T07:50:36Z
Probably it should be a compile-time error to even attempt to define a symbol which identifier starts with "__"?
Comment #3 by ibuclaw — 2013-08-20T07:53:45Z
(In reply to comment #2)
> Probably it should be a compile-time error to even attempt to define a symbol
> which identifier starts with "__"?
You can't do that. eg: gdc defines internal library functions beginning with '__', such as __gdc_personality_sj0/__gdc_personality_v0
Comment #4 by ibuclaw — 2013-08-20T07:55:58Z
(In reply to comment #3)
> (In reply to comment #2)
> > Probably it should be a compile-time error to even attempt to define a symbol
> > which identifier starts with "__"?
>
> You can't do that. eg: gdc defines internal library functions beginning with
> '__', such as __gdc_personality_sj0/__gdc_personality_v0
And there's quite a few symbols in core.stdc that use __
Picking out a few from grep:
___pthread_cond_flags __pthread_cond_flags;
c_long __align;
enum __SIZEOF_PTHREAD_BARRIER_T = 20;
Comment #5 by yebblies — 2013-08-20T08:00:11Z
Soo... we don't have many options really.
- leave it as is
- add a warning
- use 40000 leading underscores and/or obscure prefixes
Comment #6 by public — 2013-08-20T08:02:15Z
Ah, it is probably a minor issues with the spec too then - it does not state
_for what_ those are reserved. I'd expect it to be reserved by compiler but
looks like it is closer to "reserved by compiler, core lib and people who know
what they are doing" ;)
I don't see what can be done with this bug report in this case.
Comment #7 by ibuclaw — 2013-08-20T08:04:21Z
One possible suggestion is for compiler generated symbols to check for collisions with user code in the same scope.
Comment #8 by clugdbug — 2013-08-21T00:50:12Z
I don't think we should attempt to do anything about this.
"Using a symbol beginning with a double underscore voids your warranty."
It's like complaining that your power supply became unsafe after you pulled it apart. Well, you shouldn't be messing with it unless you're an electrician.
Comment #9 by razvan.nitu1305 — 2021-05-11T13:51:53Z
I cannot reproduce this. It seems that in the meantime a more clever generation of symbols has been added to dmd.
Closing as w4m.