[YANGTOOLS-703] Rework 'type decimal64' lookup Created: 26/Oct/16 Updated: 10/Apr/22 Resolved: 14/Apr/17 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Robert Varga | Assignee: | Peter Kajsa |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| Issue Links: |
|
||||||||||||||||
| External issue ID: | 7038 | ||||||||||||||||
| Description |
|
SourceSpecificContext contains a hack, attempts to lookup specific complex types by considering only a QName's localName and routes it via BUILTIN_TYPE_SUPPORTS to specific statement support. This may produce wrong results on wrong use, for example if one were to do: module foo { module bar { Note how bar's use of extension should fail – but it will instead being routed to Decimal64SpecificationImpl.Definition. Identify the caller, which is probably to a 'type decimal64' or similar construct and is attempting to create a declared statement for it. This needs to be resolved in a way which does not go through SourceSpecificContext, if at all possible. |
| Comments |
| Comment by Robert Varga [ 27/Oct/16 ] |
|
This issue boils down to the ANTLR -> SourceSpecificContext mapping, which does not emit an event for 'type' statement. In order to fix this, we need to add an abstraction to StatementSupport, which will allow it to plug into ContextBuilder.build(), so it can actively participate on how the context is being built – probably by providing a way for StatementSupport to mutate itself to a different one based on the argument provided. There also seem to be special-cases for three Rfc6020Mapping types (with TYPE among them), so we should consider them if we are touching this area. |
| Comment by Peter Kajsa [ 11/Apr/17 ] |
|
master: https://git.opendaylight.org/gerrit/#/c/54524/ |