• mesni (23/23) Jun 04 2022 There is no such error in DMD, but ldc has one:
• kinke (6/13) Jun 04 2022 The D snippet you posted has apparently nothing to do with the
• mesni (29/43) Jun 04 2022 This is a fragment of the string from which the function is
• kinke (9/37) Jun 04 2022 Ah okay, you're using a `void()` signature for all wrappers. If

mesni <mensikovk817 gmail.com> writes:

There is no such error in DMD, but ldc has one:
```
source\api.d(6,5): Error: Function type does not match previously 
declared function with the same mangled name: 
`_D3api8testFuncFiiZi`
source\api.d(6,5):        Previous IR type: void ()
source\api.d(6,5):        New IR type:      i32 (i32, i32)
```
I have a .di with declarations, and a separate module that 
generates stub functions and global pointers from them:

```d
__gshared extern(C) static void* dpford_funcp_DMANGLE;
pragma(mangle, "DMANGLE")
void dpford_func_DMANGLE() {
	asm{
		naked;
		jmp dpford_funcp_DMANGLE;
	}
}
```

I VERY and VERY DO NOT WANT to generate a function body with the 
help of traits. I tried with ldc.attributes.naked but the same 
thing happens.

kinke <noone nowhere.com> writes:

On Saturday, 4 June 2022 at 20:09:45 UTC, mesni wrote:
 ```
 source\api.d(6,5): Error: Function type does not match 
 previously declared function with the same mangled name: 
 `_D3api8testFuncFiiZi`
 source\api.d(6,5):        Previous IR type: void ()
 source\api.d(6,5):        New IR type:      i32 (i32, i32)
 ```

The D snippet you posted has apparently nothing to do with the 
error. It's complaining about 2 different signatures (in 
different modules) for some `int api.testFunc(int, int)`, with 
one being a `void()` (and so definitely not matching the mangled 
signature). Likely an incompatible signature in an `api.di`.

mesni <mensikovk817 gmail.com> writes:

On Saturday, 4 June 2022 at 20:22:31 UTC, kinke wrote:
 On Saturday, 4 June 2022 at 20:09:45 UTC, mesni wrote:
 ```
 source\api.d(6,5): Error: Function type does not match 
 previously declared function with the same mangled name: 
 `_D3api8testFuncFiiZi`
 source\api.d(6,5):        Previous IR type: void ()
 source\api.d(6,5):        New IR type:      i32 (i32, i32)
 ```

 The D snippet you posted has apparently nothing to do with the 
 error. It's complaining about 2 different signatures (in 
 different modules) for some `int api.testFunc(int, int)`, with 
 one being a `void()` (and so definitely not matching the 
 mangled signature). Likely an incompatible signature in an 
 `api.di`.

This is a fragment of the string from which the function is 
generated.

```d
mixin({
     import std.array;
     string result = q{
         __gshared extern(C) static void* dpford_funcp_DMANGLE;
         pragma(mangle, "DMANGLE")
         void dpford_func_DMANGLE() {
             asm{
                 naked;
                 jmp dpford_funcp_DMANGLE;
             }
         }
     };
     return result.replace("DMANGLE", n.mangleof);
}());
```
The function declarations themselves
```d
In api.di

module api;

enum SorrelAPI;

 SorrelAPI
int testFunc(int, int);
```

The other module in the mixin template reads all the changled 
function names from that module.

kinke <noone nowhere.com> writes:

On Saturday, 4 June 2022 at 20:32:26 UTC, mesni wrote:
 This is a fragment of the string from which the function is 
 generated.

 ```d
 mixin({
     import std.array;
     string result = q{
         __gshared extern(C) static void* dpford_funcp_DMANGLE;
         pragma(mangle, "DMANGLE")
         void dpford_func_DMANGLE() {
             asm{
                 naked;
                 jmp dpford_funcp_DMANGLE;
             }
         }
     };
     return result.replace("DMANGLE", n.mangleof);
 }());
 ```
 The function declarations themselves
 ```d
 In api.di

 module api;

 enum SorrelAPI;

  SorrelAPI
 int testFunc(int, int);
 ```

 The other module in the mixin template reads all the changled 
 function names from that module.

Ah okay, you're using a `void()` signature for all wrappers. If 
you don't want to bother with a proper signature (possibly 
derivable from `n`), you need to avoid compiling modules using 
the properly typed declaration and the wrapper module(s) *to a 
single object file*, to prevent LDC from detecting the signature 
mismatch. So if you have one or more wrapper modules containing 
nothing but these mixins, compiling those separately to their own 
object file/static lib should work.