go-clang / gen Goto Github PK

• Rename "Conversion" to "Type"
• Rename Type.GoType to Type.Name and add a Type.CName (if it is not already there somehow)
• Use Type everywhere and refactor "ElementType" and "PrimitiveType" so they are in the renamed "Type" structure

For every fixed sized C Array a Go array should be inserted, this includes
struct members
function parameters
return arguments
...

The receiver code is all over the code and in general it is one big mess. Refactor it so that the receiver gets set during or right before the method generation, or remove the receiver struct altogether.

"void" is not a valid Go type so it is questionable what we should do with it e.g. what should happen with a void pointer?

Each function/method/struct/... which does not belong to the API binding needs documentation

We need to inform the user (like for functions) that we do not implement some enums and structs.

Can we handle doxygen defgroups? Would that make sense for a Go documentation? e.g.
\defgroup CINDEX_CURSOR_TRAVERSAL Traversing the AST with cursors

• Errors should have an Error() method
• Use Spelling() in String() if it exist
• Generate String() out of the Enum's items

func (ck CommentKind) String() string {
    switch ck {
    case Comment_Null:
        return "Null"
    case Comment_Text:
        return "Text:"
    default:
             return fmt.Sprintf(“Unknown CommentKind value (%d)”, int(ck))
    }
}

func (c CursorKind) to_c() uint32 {
    return uint32(c)
}

func (c CursorKind) String() string {
    return c.Spelling()
}

/* for debug/testing */
func (c CursorKind) Spelling() string {
    cstr := cxstring{C.clang_getCursorKindSpelling(c.to_c())}
    defer cstr.Dispose()
    return cstr.String()
}

func (tle TypeLayoutError) Error() string {
    switch tle {
    case TLE_Invalid:
        return "TypeLayout=Invalid"

    case TLE_Incomplete:
        return "TypeLayout=Incomplete"

    case TLE_Dependent:
        return "TypeLayout=Dependent"

    case TLE_NotConstantSize:
        return "TypeLayout=NotConstantSize"

    case TLE_InvalidFieldName:
        return "TypeLayout=InvalidFieldName"
    }

    return fmt.Sprintf("TypeLayout=unknown (%d)", int(tle))
}

e.g.

func (cs CompletionString) Chunks() (ret []CompletionChunk) {
    ret = make([]CompletionChunk, C.clang_getNumCompletionChunks(cs.c))
    for i := range ret {
        ret[i].cs = cs.c
        ret[i].number = C.uint(i)
    }
    return
}
func (ccr CodeCompleteResults) Diagnostics() (ret Diagnostics) {
    ret = make(Diagnostics, C.clang_codeCompleteGetNumDiagnostics(ccr.c))
    for i := range ret {
        ret[i].c = C.clang_codeCompleteGetDiagnostic(ccr.c, C.uint(i))
    }
    return
}

• Currently it does not work with the testdata directory -> fix it
• Write a simple test like go-clang-dump

We use LengthOfSlice of the slice type to lookup the length member during the getter generation. That is a workaround since LengthOfSlice was not meant for that usage.

Add travisci and coverall for project

typedef … if “...” is a enum/struct, which name should we use?

The function comment during the generation is added not with the AST but by adding it to the generated string. This is needed because otherwise the comment would be on the line of the function signature and not one line before the signature. This can be surely done via a Go package.

Work down the TODO markers in the source code.

Include the rest of the Header files in the clang-c folder (e.g. for CompilationDatabase)

travis-ci/apt-package-safelist#1780
travis-ci/apt-package-safelist#1781
travis-ci/apt-package-safelist#1782
travis-ci/apt-package-safelist#1783
travis-ci/apt-package-safelist#1784

(ccr *CodeCompleteResults) Diagnostics() []Diagnostic, (tu TranslationUnit) Diagnostics() []Diagnostic and others can be easily generate.

What should happen with “CXString clang_TextComment_getText(CXComment Comment);”

So that we can reuse the general package for other APIs.

Add make target for linting and testing

E.g.

// A string that describes the platform for which this structure provides availability information. Possible values are "ios" or "macosx".
func (pa PlatformAvailability) Platform() cxstring {
    value := cxstring{pa.c.Platform}
    return value
}

This includes updating all clang branches

• The linters should handle only code that is not included in the "API binding"
• Resolve all errors

Print out if something of the C API is NOT handled by any generation

There is a lot of code that checks for const char * which is then handled differently e.g. converting it from/to a Go string. The check itself is repeated throughout the code. This should be refactored so that the check is done in a global function.

The function generation has a workaround which adds a fake statement to the function and later removes it by removing a string. This should be refactored so that adding an empty line is done using some go package.

Transform comments into Go style comments? e.g. what should happen with \param and \returns; there are still a lot of doxygen annotations left

If a enum has no direct comment in the C header it uses the last comment group as its comment …. see “VisitorResult”

E.g. for clang_Comment_getChild(CXComment Comment, unsigned ChildIdx);

Just execute the "String()" method in generateASTFunction if a Go "string" is needed. And call "Dispose" if needed on any type that has a Dispose method.

Looks like this should be a normal function, but currently it is a method.

See "TypeKind" for an example. If there is not comment, there should not be a generated comment. Maybe this is a problem in the Clang API?

Do a better naming job for functions e.g. see the getter for clang_getCXXAccessSpecifier

The API is often inconvenient to use since casts to/from int16/uint16/... are needed. We could relax this by just using "int" everywhere. Is there a downside to it?

e.g. CodeCompleteAt

Return "nil" if they are null instead of an object.

• Work out how we should branch for different Clang versions
• Document the process
• Branch of and test using TravisCI
• Some functions are not compiled in libClang 3.4 see https://lists.launchpad.net/desktop-packages/msg75835.html (search for this URL in the code) maybe we can reenable them for a later version? This is also the case for 3.7

This should add the following:

• A vagrant configuration for the OS, repository and packages that are needed to develop with go-clang-phoenix
• Scripts to setup a new clang branch. This includes installing needed packages and bootstraping it

Document what is needed to branch a new version

They are defined in the file, but not generated.

Should we add “AccessSpecifier” to the enum items?

E.g. clang_parseTranslationUnit the fname parameter needs to be null instead of an empty string if an empty string is provided in Go. How can we do that? And are there other instances?

Return arguments should be named so that the Clang API is easier to read. Especially have a look at "clang_getDiagnosticOption" which seems to be a special case of the Clang API.

Two cases could be improved

• There are some parameters named "is*" which should be booleans
• Some parameters are still of type "cxstring" which should be a Go string

This is temporarily disabled