[YANGTOOLS-1042] ModuleEffectiveStatement fails to index statements from submodules Created: 25/Nov/19  Updated: 27/Nov/19  Resolved: 27/Nov/19

Status: Resolved
Project: yangtools
Component/s: parser
Affects Version/s: None
Fix Version/s: 4.0.3, 3.0.7

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

Issue Links:
Blocks
blocks YANGTOOLS-1040 Cleanup unknownSchemaNode/mustConstra... Resolved
blocks YANGTOOLS-1041 Index SchemaNode substatements lazily Resolved
Relates
relates to YANGTOOLS-1044 Rework Uses statement ordering Confirmed

 Description   

Our implementation for ModuleEffectiveStatement indexes effective statements in the StmtContext before considering submodules, simply because the context is passed to AbstractSchemaEffectiveDocumentedNode without these statements.

This is then worked around by AbstractEffectiveModule constructor, which manually attaches these modules before indexing them (for SchemaNode-only indexes).

Code structure here seems to be very difficult and hacky, which points towards the fact the code needs to be restructured.



 Comments   
Comment by Robert Varga [ 25/Nov/19 ]

It looks as though either 'include' or 'belongs-to' statements should really end up inlining the definitions once the submodule has been completely defined. From these two the 'include' statement looks like a better fit, as it is already used in this capacity for linkage resolution.

A slight wrinkle here is that submodules may have recursive includes, which really are not instructions to inline the particular submodule but rather reference it. To resolve this, I think the overall behaviour of 'include' needs to be different based on whether it is used in a submodule or a module.

This way all effective statements for a particular module should be resolved in StmtContext before EffectiveModuleStatement is instantiated, resolving this issue.

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