D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 10582 - Programmed and Compiler generated symbols clash.
Summary: Programmed and Compiler generated symbols clash.
Status: RESOLVED WORKSFORME
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P2 normal
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-09 09:46 UTC by Iain Buclaw
Modified: 2021-05-11 13:51 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Iain Buclaw 2013-07-09 09:46:05 UTC
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 yebblies 2013-08-20 07:45:18 UTC
From http://dlang.org/lex.html

"Identifiers starting with __ (two underscores) are reserved"

I don't know what else _could_ happen here.
Comment 2 Dicebot 2013-08-20 07:50:36 UTC
Probably it should be a compile-time error to even attempt to define a symbol which identifier starts with "__"?
Comment 3 Iain Buclaw 2013-08-20 07:53:45 UTC
(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 Iain Buclaw 2013-08-20 07:55:58 UTC
(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 yebblies 2013-08-20 08:00:11 UTC
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 Dicebot 2013-08-20 08:02:15 UTC
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 Iain Buclaw 2013-08-20 08:04:21 UTC
One possible suggestion is for compiler generated symbols to check for collisions with user code in the same scope.
Comment 8 Don 2013-08-21 00:50:12 UTC
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 RazvanN 2021-05-11 13:51:53 UTC
I cannot reproduce this. It seems that in the meantime a more clever generation of symbols has been added to dmd.

Closing as w4m.