[YANGTOOLS-602] Reference type in same module with prefix fails to compile Created: 12/Apr/16 Updated: 10/Apr/22 Resolved: 18/Apr/16 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | David M. Karr | Assignee: | Peter Kajsa |
| Resolution: | Cannot Reproduce | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 5712 |
| Description |
|
Using latest Boron snapshots. Using the following simple module description: revision 2016-04-11 { description "Initial revision"; }typedef thing { type uint32; }typedef thing2 { type bad:thing; // Error on this line //type thing; }} Yangtools apparently fails to compile this. It can't resolve the type reference in the line marked "Error on this line". If I instead comment out that line and comment back in the second line, it compiles without error. The reason I stated "apparently" is because I see this error when I view the module in the Eclipse YangIDE plugin, but if I build the corresponding project on the command line, I do not see any error for this. |
| Comments |
| Comment by David M. Karr [ 12/Apr/16 ] |
|
Oh, and if it matters, I only accidentally discovered this, because the same pattern is found in "ietf-yang-types.yang". The particular copy I was using is vesion "2010.09.24.7.5-SNAPSHOT". |
| Comment by Peter Kajsa [ 14/Apr/16 ] |
|
Hi, we test the attached model with both old and new yang parser and everything works fine. You said that you find the same pattern in ietf-yang-types.yang, so therefore it must work ok, because this yang model is parsed by almost each schema context build. Here is the unit test: If the issue still persists, please can you attach also the stacktrace or the log. Thanks |
| Comment by David M. Karr [ 14/Apr/16 ] |
|
Ok, we can close this. For some reason, the YangIDE does additional validation after the parse completes, and this wasn't looking at prefixes properly. |