Details
-
Bug
-
Status: Resolved
-
Resolution: Done
-
None
-
None
-
None
-
None
-
Operating System: All
Platform: All
-
6771
Description
I've found 2 problems with nested typedefs. Both are exhibited by the attached model.
1) when a typedef is in a container that is in an augment, the YANG parser produces an error.
This can be seen in the attached model by uncommenting the leaf-container-b in typedef-bug.yang). The error produced is then:
...
Caused by: org.opendaylight.yangtools.yang.parser.spi.meta.InferenceException: Type [(http://www.example.com/typedef-bug?revision=2016-09-21)type-container-b] was not found. [at typedef-bug:35:14]
at org.opendaylight.yangtools.yang.parser.spi.meta.InferenceException.throwIf(InferenceException.java:47)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.TypeStatementImpl$Definition$1.prerequisiteFailed(TypeStatementImpl.java:225)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.ModifierImpl.failModifier(ModifierImpl.java:91)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.SourceSpecificContext.failModifiers(SourceSpecificContext.java:290)
The equivalent definition without an augment is working fine (see the leaf-container-a in typedef-bug.yang).
2) Typedefs on RPCs are not returned by the ODL parser.
In the attached model, the definition of the rpc-a parses fine, but the getTypeDefinitions() method of the RpcDefinition is returning an empty list.
Note that this is on Beryllium-SR3. We haven't tried on Boron yet.
Attachments
Issue Links
- is blocked by
-
YANGTOOLS-645 RpcEffectiveStatementImpl's constructor does not initialize typedef substaments correctly
- Resolved