…"identity", and "refine"

Also add support for notifications to be tied to data nodes.

See https://tools.ietf.org/html/rfc7950#section-1.1

This perserves the Augment *Entry and Uses *Entry so their when statements can be enforced, among other things.

This is my attempt at fixing issue #89

extension keyword is not currently implemented, but extension statements found in YANG files are stored in *yang.Entry.Exts field. ygot can retrieve extension statements from this field and perform further processing.

However, because uses's grouping are returned as a deep-copy in ToEntry() (https://github.com/openconfig/goyang/blob/master/pkg/yang/entry.go#L584), and that the deep-copying function does not copy the Exts field (https://github.com/openconfig/goyang/blob/master/pkg/yang/entry.go#L1278), extension statements defined within a uses's grouping are effectively lost. This impacts downstream ygot and protogen usage.

The comment at https://github.com/openconfig/goyang/blob/master/pkg/yang/entry.go#L1281 said there wasn't a clear use case of copying the Ext field, but I believe we do now.

What's your opinion on this matter?

In this Patch I'm doing 2 things

1. Removing the exclusion of Extras from JSON, and excluding down the line the Parent and Source of Extra elements

2. Improving how items are added to the Extras slice. When the item is a Slice add its elements individually.

I can break this up in to 2 separate patches if necessary

Hi @robshakir @wenovus,

I am struggling to make goyang parse the modules which have import statements with a specified revision.

To keep things real, lets take an example of Juniper yang modules, which come in the form of YANG files with [email protected] pattern - https://github.com/Juniper/yang/tree/master/20.2/20.2R1/junos/conf

1. If the module imports another module with a specified revision (example)

   import junos-common-types {
    prefix jt;
    revision-date 2019-01-01;
   }
   

   the goyang doesn't seem to use the specified revision when it tries processes the imports. Instead it uses the "bare" name. In the linked code snippet name is the bare module name, without revision suffix.

2. this results in ms.Read to operate on junos-common-types instead of junos-common-types@2019-01-01 name.
3. The ms.Read in its turn uses findFile that promises to pick the latest revision found, which is not what the import statement wanted.

Shoudn't we instead read the module by revision by doing:

	// Try to read it in.
	if err := ms.Read(rev); err != nil {
		return nil
	}

Hi team, thank you all for making goyang a reality.

I would like to know if the maintainers are up to adopt the semantic versioning for goyang? I think the common benefits of a versioned package are well-known. Aside from the common versioning benefits the adoption will also make it possible to create an automatic release pipeline powered by goreleaser and github actions (like we did for gnmic).

Having pre-built goyang binaries ready available and downloadable (via github releases) will help users to leverage one of the best yang compilers out there. I am willing to contribute the release pipeline if the OC community is up for maintaining the versioning.

This change adds support for the YANG 1.1 construct:

import foo {
  prefix "bar";
  reference "bat";
}

to goyang. The test added provides an extensible way to add tests for the contents of opaque Node structures to the goyang pkg.

 * (M) pkg/yang/{entry,entry_test,options}.go
  - Control whether Uses is populated based on an input flag. With
    large sets of schemas, the Uses data can cause a significant increase
    in the output size of the Entry data - which has memory footprint
    implications. Flag control the population of such fields.

Consider the case of the following yang that is missing the final closing brace for module foo

module foo {
  namespace foo;
  prefix f;

  container top {
     leaf f1 {
        type string;
     }
  }

parsing that with ./goyang -f tree test.yang results in no error and no output.

With this patch we output an error that says we are missing a closing brace.

To avoid a deadlock when sending a *token to the lexer's items channel - which can occur if too many errors occur within a single token - instead panic when the items channel fills up.

Non-error items (i.e., normal tokens) should not overflow the channel, so use a different panic message (indicating a library bug) if this occurs.

Avoids a deadlock and addresses #116 .

Hello,

I am using your great library while working on an implementation of a library that is parsing yang files and does some processing with them (in relation to this). Recently I realized parsing many models makes my library leak memory. After some debugging I discovered that it should be because of the use of typeDict that is growing with each model parsing. I would be willing to work on resolving this issue, but as I saw that there is already a TODO comment around it, I imagine you already have an idea what would be a good solution for you. The best solution for me would be to have reference to the typeDict in the Modules type, but it seems that some initialization is done for the default types, which would make that more difficult (we can have separate typeDict for the built-in types and the parsed ones). Do you have better ideas and would you be willing to review and possibly merge such a change?

Thank you in advance!

Hi all, this issues is a feature request to add support for modifier pattern substatement as per https://datatracker.ietf.org/doc/html/rfc7950#section-9.4.6

Need to write a reproducing YANG file first, but the reported problem is that a deviation without the proper prefix for an element in the path still compiles but shouldn't.

deviate statement and refine statement should allow multiple default substatements for leaf-list types (YANG1.1).

Some examples at https://github.com/mbj4668/pyang/issues/756