How to print the line at which a warning occured in yanglint?

[hellt]

Hi all,
I am using yanglint 2.1.55 and am curious if there is a flag that will add line numbers at which warning occurred.
Currently, yanglint output warning like this:

libyang warn: Identityref "type" comparison with identity "bridged" without prefix, consider adding a prefix or best using "derived-from(-or-self)()" functions.

and it is extremely hard to understand which module/line# this warning was generated for?

[michalvasko]

After that there should always be another warning in the form

libyang warn: Previous warning generated by XPath subexpression[<idx>] "<relevant-xpath-part>" with context node "<xpath-of-the-context-node>".

[hellt]

thanks @michalvasko
the following line provides the XPath path of a parent yang element that contains the node with lint problems, but it doesn't say which file the parent node is defined in.

libyang warn: Previous warning generated by XPath subexpression[4] "type != 'bridged'" with context node "/srl_nokia-interfaces:interface/subinterface/mpls".

I suppose this is the best yanglint can do now, but I wonder, can the file information be outputted as well?

[michalvasko]

Not really sure, probably it could but it would be a completely new error information and I do not find it too useful. Most often, the file (module) can be guessed based on the last printed prefix, in this case srl_nokia-interfaces. Except cases when the node is in a submodule or foreign grouping when a simple grep should tell the exact file. So, I think there is enough information printed.

[hellt]

Unfortunately, this is not always the case, as in the example above, the last element in the path mpls - is a container that another module augments srl_nokia-interfaces, so the module name doesn't disclose the file where the error happens.

It would be nice to have a more precise error.

[michalvasko]

I have looked at the place the warning is generated and unfortunately there is no more (accurate) information to provide. It is not possible to get the actual module (and its file) where the XPath is defined, you can only get the (compiled) module of the context node. So sorry, I am not able to help.

[hellt]

no problem, thanks for looking into this 👍