Bug 22021 – pragma(mangle) not accepted in function body
Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2021-06-13T10:29:06Z
Last change time
2023-12-16T21:40:24Z
Assigned to
No Owner
Creator
Max Samukha
Comments
Comment #0 by maxsamukha — 2021-06-13T10:29:06Z
void main() {
pragma(mangle, "bar")
extern(C) static void foo() {
}
}
onlineapp.d(4): Error: unrecognized `pragma(mangle)`
To workaround, use a dummy struct:
void main() {
static struct S {
pragma(mangle, "bar")
extern(C) static void foo() {
}
}
}
Comment #1 by kinke — 2021-06-14T16:15:16Z
I'm not sure this should work - `extern(<lang>)` doesn't affect the mangling of nested functions either, only ABI/calling convention. The reason is simple, nested functions are D only, and the D mangling makes sure there are no duplicates/conflicts (as it includes the parent function(s)).
The IMO more intuitive workaround is a freestanding function. Exposing a nested D function for consumption from C[++] is probably not very common; I guess the main usage would be consuming an external function from D, and declaring it as nested function in D for locality.
Comment #2 by maxsamukha — 2021-06-14T19:58:28Z
(In reply to kinke from comment #1)
> I'm not sure this should work - `extern(<lang>)` doesn't affect the mangling
> of nested functions either, only ABI/calling convention. The reason is
> simple, nested functions are D only, and the D mangling makes sure there are
> no duplicates/conflicts (as it includes the parent function(s)).
>
I needed that when I was trying to implement a poor man's decorator in the least ugly way:
mixin template ISR(int number, alias impl) {
static struct Impl {
extern(C) static
pragma(mangle, "__vector_" ~ number.stringof)
@signal @used /* @externally_visible */ void isr() {
impl();
}
}
}
/// ditto
mixin template ISR() {
enum dummy = 0;
alias impl = __traits(parent, dummy);
enum number = mixin(__traits(identifier, impl), "_vect");
mixin ISR!(number, impl);
}
@always_inline void USART_UDRE() {
mixin ISR; // magic
...
}
> The IMO more intuitive workaround is a freestanding function. Exposing a
> nested D function for consumption from C[++] is probably not very common; I
> guess the main usage would be consuming an external function from D, and
> declaring it as nested function in D for locality.
Nested functions are conceptually very similar to member functions. It is a matter of good taste to try and make them consistent.