Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapping a type to a type of the same name causes stack overflow #1835

Open
Saalvage opened this issue Mar 13, 2024 · 0 comments
Open

Mapping a type to a type of the same name causes stack overflow #1835

Saalvage opened this issue Mar 13, 2024 · 0 comments

Comments

@Saalvage
Copy link
Contributor

I have the following header:

typedef int MyFlags;

#define FLAG_ONE 1
#define FLAG_TWO 2

class Test {
public:
    void MyMethod(MyFlags a);
};

I would like to end up with Test.MyMethod having MyFlags as a parameter instead of int.

To this end at first I var @enum = ctx.GenerateEnumFromMacros("MyFlags", "FLAG_(.*)").

I then use the following TypeMap:

[TypeMap("MyFlags")]
public class MyFlagsMap : TypeMap {
    internal static TagType Type { private get; set; }

    public override Type SignatureType(TypePrinterContext ctx) {
        return Type;
    }
}

whereas MyFlagsMap.Type = new TagType(@enum).

This results in a stack overflow on calls such as typeMap.SignatureType(ctx).ToString() (which are used at various points) as ToString on Type again goes over the type maps and calls ToString on the signature type, repeat ad infinitum.

One potential solution is adding the following method to TypeMap:

public virtual string Print(TypePrinterContext ctx)
{
    return SignatureType(ctx).ToString();
}

and replacing all calls such as typeMap.SignatureType(ctx).ToString() with typeMap.Print(ctx).

However, this would require modifications on the end of the user which is not ideal. Some other way to avoid the cycles here seems preferable, but I don't see a straightforward way of achieving that atm..

P.S.: For anyone stumbling across this issue seeking to accomplish something similar to me while a fix hasn't yet been implemented:
A simple workaround is initially picking a different name for the generated enum and renaming it it in the Postprocess step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant