Errors while parsing third party headers

[hemp...@imagic.ch]

Hi,

Im having trouble to build a BridJ interface a third party SDK and stumbled upon a few  difficulties while parsing the headers with jnaerator jnaerator-0.13-20150328.111636-4-shaded.jar:

Invoking jnanerator with:

java -Xmx1g -jar jnaerator-0.13-20150328.111636-4-shaded.jar  -library EnumResolveTestLibrary -o ./GeneratedForEnumResolveFailure/ -v -f -mode Directory "jnaerator - enum from different namespace not resolved.h"

on the following sample code

#pragma once

namespace a {
    typedef enum eReservedPropertyIdRanges {
        RESERVED_PROPID_FIRST = 0x4000,
    } EReservedPropertyIdRanges;
};

namespace b {
    enum UNIT_TYPE
    {
        __UNIT_TYPE_START                        = a::RESERVED_PROPID_FIRST,
        DRIVER                                = __UNIT_TYPE_START
    };
}

results in a java.lang.StackOverflowError

Generating libraries...
java.lang.StackOverflowError
        at java.util.regex.Pattern.range(Unknown Source)
        at java.util.regex.Pattern.clazz(Unknown Source)
        at java.util.regex.Pattern.sequence(Unknown Source)
        at java.util.regex.Pattern.expr(Unknown Source)
        at java.util.regex.Pattern.compile(Unknown Source)
        at java.util.regex.Pattern.<init>(Unknown Source)
        at java.util.regex.Pattern.compile(Unknown Source)
        at java.lang.String.split(Unknown Source)
        at java.lang.String.split(Unknown Source)
        at com.ochafik.lang.jnaerator.Result.camelCase(Result.java:629)
        at com.ochafik.lang.jnaerator.Result.getLibraryClassSimpleName(Result.java:639)
        at com.ochafik.lang.jnaerator.Result.getLibraryClassFullName(Result.java:643)
        at com.ochafik.lang.jnaerator.TypeConversion.findEnumItem(TypeConversion.java:1042)
        at com.ochafik.lang.jnaerator.BridJTypeConversion.getEnumItemValue(BridJTypeConversion.java:79)
        at com.ochafik.lang.jnaerator.TypeConversion.convertVariableRefToJava(TypeConversion.java:1443)
        at com.ochafik.lang.jnaerator.TypeConversion.convertExpressionToJava(TypeConversion.java:1327)
        at com.ochafik.lang.jnaerator.BridJTypeConversion.convertExpressionToJava(BridJTypeConversion.java:488)
        at com.ochafik.lang.jnaerator.TypeConversion.getEnumValuesAndCommentsByName(TypeConversion.java:1401)
        at com.ochafik.lang.jnaerator.BridJTypeConversion.getEnumItemValue(BridJTypeConversion.java:73)
        at com.ochafik.lang.jnaerator.TypeConversion.convertVariableRefToJava(TypeConversion.java:1443)
        at com.ochafik.lang.jnaerator.TypeConversion.convertExpressionToJava(TypeConversion.java:1327)

Jnaerator produces the following error:

com.ochafik.lang.compiler.CompilerUtils$CompilationError: Error in ? at line 33, col 63 :
    __UNIT_TYPE_START cannot be resolved or is not a field

    at com.ochafik.lang.compiler.CompilerUtils$CompilationError.throwErrors(CompilerUtils.java:85)
    at com.ochafik.lang.jnaerator.JNAerator.jnaerate(JNAerator.java:1033)
    at com.ochafik.lang.jnaerator.studio.JNAeratorStudio$15.run(JNAeratorStudio.java:691)

and produces the folllowing output:

    public static interface UNIT_TYPE {
        /**
         * SKIPPED:<br>
         * <i>native declaration : line 21</i><br>
         * __UNIT_TYPE_START = a::RESERVED_PROPID_FIRST
         */
        /** <i>native declaration : line 22</i> */
        public static final int DRIVER = (int)TestLibrary.UNIT_TYPE.__UNIT_TYPE_START;
    };

As it looks, the parser fails to resolve the value of a::RESERVED_PROPID_FIRST

The other problem we have may be related, because it also happens when using namespaces.

Invoking

java -Xmx1g -jar jnaerator-0.13-20150328.111636-4-shaded.jar -library TypeInNamespace -o ./GeneratedForTypeDefFailure/ -v -f -mode Directory "jaenerator - tyedef in namespace error.h"

on the following sample code

namespace a {
    typedef const char * string;
    typedef const wchar_t *unicode_string;
    typedef int int32;
    typedef unsigned int uint32;
    typedef double float64;
    typedef unsigned char byte;
    typedef long long int64;
}

// correct generation
const int32 MAX_INT32 = 0x7fffffff;
const int64 MAX_INT64 = 0x7fffffffffffffff;

// wrong: typedefs are generated as interfaces
class Model {
public:
    int test();
    virtual a::string version() = 0;
    virtual a::unicode_string value() = 0;
    virtual a::int32 numIds() = 0;
    virtual a::byte* pixelData() = 0;
};

produces the follwoing (in my eyes) wrong code:

@Library("TypeInNamespace")
@Runtime(CPPRuntime.class)
public class TypeInNamespaceLibrary {
    static {
        BridJ.register();
    }
    /** correct generation */
    public static final int MAX_INT32 = 0x7fffffff;
    public static final long MAX_INT64 = 0x7fffffffffffffffL;
    /** Undefined type */
    public static interface string {
    };
    /** Undefined type */
    public static interface unicode_string {
    };
    /** Undefined type */
    public static interface int32 {
    };
    /** Undefined type */
    public static interface byte {
    };
}

For each typedef from namespace "a" that is used (and only for those) in the model class jnaerator generates an interface. However all types are integral type, which - when not typedef'd - are parsed fine.

I've used BridJ and Jnaerator successfully before for a couple of third party SDK, but the latest one seems to be really tricky. Any chance you could help?

Cheers, Jens