Thread overview
Very clever compiling error with mangling
Jun 04, 2022
mesni
Jun 04, 2022
kinke
Jun 04, 2022
mesni
Jun 04, 2022
kinke
June 04, 2022

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:

__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.

June 04, 2022

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.

June 04, 2022

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.

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

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.

June 04, 2022

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.

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

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.