[Bug d/95198] [D] extern(C) private final functions should use 'local' linker attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95198
Iain Buclaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Iain Buclaw ---
(In reply to Witold Baryluk from comment #3)
> > The main example to demonstrate the current behaviour is correct would be
> > the following:
>
> ```
> extern(C)
> private final int f() {
> return 5;
> }
>
> auto pubf()() {
> return f();
> }
> ```
>
> I see, I guess you are right. I don't know how would one go to fix this to
> work correctly with existing linkers and not break other code.
>
> Thanks for clarifications.
To close this issue, I'll leave my thoughts on a similar topic that was touched
on the D ML (this time, regarding the linkage of inline functions).
I'm of the opinion that there is no concept of external (global) or internal
(local) linkage in D. Rather there's language linkage and module linkage.
Language linkage as in `extern(C++)`, `extern(C)`, `extern(Objective-C)`...
Module linkage as in for a given declaration resolves to the same symbol across
all TUs that import its residing module, but otherwise not strictly visible
outside of that.
It might do well to familiarize yourself with C++2a modules as a primer. But
even then, you'll have to unlearn a lot of things.
[Bug d/95198] [D] extern(C) private final functions should use 'local' linker attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95198
--- Comment #3 from Witold Baryluk ---
> The main example to demonstrate the current behaviour is correct would be the
> following:
```
extern(C)
private final int f() {
return 5;
}
auto pubf()() {
return f();
}
```
I see, I guess you are right. I don't know how would one go to fix this to work
correctly with existing linkers and not break other code.
Thanks for clarifications.
[Bug d/95198] [D] extern(C) private final functions should use 'local' linker attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95198
--- Comment #2 from Iain Buclaw ---
(In reply to Witold Baryluk from comment #0)
> ```
> module t1;
>
> extern(C)
> private final int f() {
> return 5;
> }
> pragma(msg, f.mangleof);
>
> ```
>
> `gdc -c t1.d -o t1.o` results in object with this symbols:
>
> D _D2t111__moduleRefZ
> D _D2t112__ModuleInfoZ
> U _d_dso_registry
> T f
> W gdc.dso_ctor
> W gdc.dso_dtor
> u gdc.dso_initialized
> u gdc.dso_slot
> 0016 t _GLOBAL__D_2t1
> 000b t _GLOBAL__I_2t1
> U _GLOBAL_OFFSET_TABLE_
> U __start_minfo
> U __stop_minfo
>
>
>
> Symbol, ' T f' should instead be ' t f'
>
> Additional when using optimizations, I would expect the f to not be emitted
> at all, but it is still there (unless compiler decides not to inline it or
> its address is not taken and passed around), even with `gdc -O3`.
>
> gcc for C does use LOCAL for static functions and variables in translation
> unit. Similarly probably for C++ symbols in anonymous namespaces.
>
There isn't really a notion of a translation unit in D, the minimal
encapsulation unit is a module.
There are a number of reasons why static in the C sense doesn't exist though.
The main example to demonstrate the current behaviour is correct would be the
following:
```
extern(C)
private final int f() {
return 5;
}
auto pubf()() {
return f();
}
```
In this module, 'f' is unused, but it can neither be local or discarded because
if another module instantiates 'pubf', you'll run into linker errors.
(In reply to Witold Baryluk from comment #1)
> BTW.
>
> Using:
>
> ```
> extern(C) private final static int f() { ... }
> ```
>
>
> doesn't change anything.
static has no effect on module-level declarations
(https://dlang.org/spec/attribute.html#static)
final has no effect on anything that isn't a virtual member function (and I'm
not sure it even makes sense to allow it otherwise).
private is a visibility/access attribute that only affects symbol name lookup
resolution (https://dlang.org/spec/attribute.html#visibility_attributes).
DECL_VISIBILITY could be set as a further hint for 'private', but that won't
remove the fact you'll still get multiple definition errors.
Note: dmd marks top-level functions as weak, a behaviour I have no intention of
replicating.
[Bug d/95198] [D] extern(C) private final functions should use 'local' linker attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95198
--- Comment #1 from Witold Baryluk ---
BTW.
Using:
```
extern(C) private final static int f() { ... }
```
doesn't change anything.
