[MDSAL-321] Binding V1 generates incorrect code for nested classes Created: 12/Mar/18  Updated: 02/May/18  Resolved: 02/May/18

Status: Resolved
Project: mdsal
Component/s: Binding codegen
Affects Version/s: None
Fix Version/s: Oxygen SR1, Fluorine

Type: Bug Priority: Medium
Reporter: Robert Varga Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
blocks MDSAL-320 Binding V1 fails to generate code for... Resolved

 Description   

A simple test model:

    container foo {
        leaf foo {
            type enumeration {
                enum "foo";
            }
        }
    }

results in compilation failure:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project mdsal-binding-test-model: Compilation failure: Compilation failure:
[ERROR] /home/nite/odl/mdsal/binding/mdsal-binding-test-model/target/generated-sources/mdsal-binding/org/opendaylight/yang/gen/v1/opendaylight/nested/types/norev/Foo.java:[98,69] cannot find symbol
[ERROR]   symbol:   class Foo
[ERROR]   location: interface org.opendaylight.yang.gen.v1.opendaylight.nested.types.norev.Foo
[ERROR] /home/nite/odl/mdsal/binding/mdsal-binding-test-model/target/generated-sources/mdsal-binding/org/opendaylight/yang/gen/v1/opendaylight/nested/types/norev/Foo.java:[31,12] interface org.opendaylight.yang.gen.v1.opendaylight.nested.types.norev.Foo is already defined in package org.opendaylight.yang.gen.v1.opendaylight.nested.types.norev


 Comments   
Comment by Robert Varga [ 12/Mar/18 ]

This failure is a violation of JLS9 section 8.1:

It is a compile-time error if a class has the same simple name as any of its enclosing classes or interfaces.

Which means that we need to understand nesting so that we do not ever generated something like:

class Foo {
    public static class Foo {
        public static class Foo {
        }
    }
}

In that block the first nested class must not have the name 'Foo'. Assuming we pick 'Foo$' as the replacement, the second nested class must not have names 'Foo' or 'Foo$'.

Comment by Robert Varga [ 12/Mar/18 ]

At first glance this seems to be specifically triggered by enumerations.

Comment by Robert Varga [ 12/Mar/18 ]

Solving this will be a bit of a ride, as we do not have the FQCN hierarchy captured anywhere – we use packageName to represent both the root module package and nested class's parent, hence crawling back is not a nice option, fraught with performance and correctness issues.

Comment by Robert Varga [ 12/Mar/18 ]

Preliminary cut:

remote:   https://git.opendaylight.org/gerrit/69407 Add binding.model.api.TypeName
remote:   https://git.opendaylight.org/gerrit/69408 Integrate TypeName as Identifier

 

Comment by Robert Varga [ 12/Mar/18 ]

This will be deeply invasive change, as it is forcing getting the packageName story in the codebase straight.

Comment by Robert Varga [ 19/Mar/18 ]

The fix itself: https://git.opendaylight.org/gerrit/69599

 

Generated at Wed Feb 07 20:09:31 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.