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

Open
#1,835 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
cpp, csharp
Domain
tooling

Research direction

Start at TypeMap.SignatureType and the calls to SignatureType(ctx).ToString() described in the issue, then trace how Type.ToString re-enters type-map handling. Reproduce the same-name MyFlags mapping and verify that printing the mapped type completes without stack overflow while retaining the desired enum parameter representation.

Written by the indexing model from the issue text.

Description

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.

Dominant language
C#
Stars
3.4k
Forks
541
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mono/CppSharp

All issues in mono/CppSharp

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.