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

[Go] GolangGenerator nested composite types are malformed #849

Closed
neomantra opened this issue May 13, 2021 · 0 comments
Closed

[Go] GolangGenerator nested composite types are malformed #849

neomantra opened this issue May 13, 2021 · 0 comments

Comments

@neomantra
Copy link
Contributor

Given the following schema:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<sbe:messageSchema xmlns:sbe="http://fixprotocol.io/2016/sbe"
    package="issue849"
    id="1"
    version="0"
    semanticVersion="1.0"
    description="test case 849 20210512"
    byteOrder="littleEndian">
    <types>
        <composite name="Comp1" description="Comp1">
            <type name="abc"  primitiveType="uint32"/>
            <type name="wxyz" primitiveType="uint32"/>
        </composite>
        <composite name="messageHeader" description="MH">
            <type name="blockLength" primitiveType="uint16"/>
            <type name="templateId"  primitiveType="uint16"/>
            <type name="schemaId"    primitiveType="uint16"/>
            <type name="version"     primitiveType="uint16"/>
            <ref  name="c1"          type="Comp1"/>
            <type name="lmn"         primitiveType="uint32"/>
            <type name="opq"         primitiveType="uint32"/>
        </composite>
    </types>
    <sbe:message name="barmsg" id="4">
        <field name="header" id="1" type="messageHeader"/>
    </sbe:message>
</sbe:messageSchema>

The generated nested types have too many fields (Lmn):

type MessageHeaderComp1 struct {
    Abc  uint32
    Wxyz uint32
    Lmn  uint32
}

And compilation brings up these errors:

./MessageHeaderComp1.go:53:7: m.LmnInActingVersion undefined (type *MessageHeaderComp1 has no field or method LmnInActingVersion)
./MessageHeaderComp1.go:54:12: m.LmnNullValue undefined (type *MessageHeaderComp1 has no field or method LmnNullValue)
./MessageHeaderComp1.go:74:6: m.LmnInActingVersion undefined (type *MessageHeaderComp1 has no field or method LmnInActingVersion)
./MessageHeaderComp1.go:75:15: m.LmnMinValue undefined (type *MessageHeaderComp1 has no field or method LmnMinValue)
./MessageHeaderComp1.go:75:42: m.LmnMaxValue undefined (type *MessageHeaderComp1 has no field or method LmnMaxValue)
./MessageHeaderComp1.go:76:69: m.LmnMinValue undefined (type *MessageHeaderComp1 has no field or method LmnMinValue)
./MessageHeaderComp1.go:76:93: m.LmnMaxValue undefined (type *MessageHeaderComp1 has no field or method LmnMaxValue)

After exploring this, I got it down to this line:

// old -- recursing with all the the rest of the tokens
generateComposite(tokens.subList(i, tokens.size()), typeName);
i += token.componentTokenCount() - 2;

// new -- recursing with only the composite's tokens
generateComposite(tokens.subList(i, i + token.componentTokenCount()), typeName);
i += token.componentTokenCount() - 1;    // get past the components, then -1 offset the for's +1

I went back to #844 and verified that this was the underlying reason behind that failure (my failing schema worked with just this change). PR coming....

neomantra added a commit to neomantra/simple-binary-encoding that referenced this issue May 13, 2021
Too many tokens were passed to `generateComposite` causing weird
errors like(real-logic#844 and real-logic#849).
mjpt777 pushed a commit that referenced this issue May 14, 2021
* [Go] Fix tokens passed to generateComposite (#849)

Too many tokens were passed to `generateComposite` causing weird
errors like(#844 and #849).

* [Go] Fix Group decoder style warning

The `Decode` generator for groups would produce the following code:

```
for i, _ := range o.GroupName {
```

The `gofmt` tools suggest [simplify range expression](https://github.com/golang/tools/blob/master/internal/lsp/analysis/simplifyrange/simplifyrange.go#L23):

```
A range of the form:
    for x, _ = range v {...}
will be simplified to:
    for x = range v {...}
```

This patch fixes that.
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