TypeFox / yang-lsp

A Language Server for YANG
http://www.yang-central.org
Apache License 2.0
52 stars 13 forks source link

[Bug] In some cases, element.eResource() will be null, then NPE will be thrown out. #136

Closed huyuwen closed 6 years ago

huyuwen commented 6 years ago

https://github.com/theia-ide/yang-lsp/blob/094e039770307fb501df89bd3657c72cbe266c6e/yang-lsp/io.typefox.yang/src/main/java/io/typefox/yang/scoping/Linker.xtend#L49

I don't know why element.eResource will return null. And I also doubt whether eResource() return null is correct here. But for robustness purpose, it's better to check the element.eResource return value before getURI

JanKoehnlein commented 6 years ago

When element.eResource() it is likely a proxy (i.e. unresolved cross reference). So this sounds like a follow up error on something else.

We could fix this, but maybe we're better off trying to reproduce it and fixing the root cause. Do you have a stacktrace?

huyuwen commented 6 years ago

Hi Jan, I have the same feeling, there has unresolved cross reference somewhere else. I will try to simplify my test case, the original test data is quite complex.

JanKoehnlein commented 6 years ago

A stacktrace could give a valuable hint which kind of elements to look at.

huyuwen commented 6 years ago

Here is the stacktrace. [18-07-04 09:00:35.744] ERROR LazyLinkingResource:getEObject:227 - resolution of uriFragment '|5' failed. java.lang.NullPointerException at io.typefox.yang.scoping.Linker.getLinkingName(Linker.java:68) at io.typefox.yang.scoping.Linker.link(Linker.java:44) at io.typefox.yang.scoping.xpath.XpathResolver._internalResolveStep(XpathResolver.java:703) at io.typefox.yang.scoping.xpath.XpathResolver.internalResolveStep(XpathResolver.java:961) at io.typefox.yang.scoping.xpath.XpathResolver._internalResolve(XpathResolver.java:523) at io.typefox.yang.scoping.xpath.XpathResolver.internalResolve(XpathResolver.java:912) at io.typefox.yang.scoping.xpath.XpathResolver._internalResolve(XpathResolver.java:373) at io.typefox.yang.scoping.xpath.XpathResolver.internalResolve(XpathResolver.java:926) at io.typefox.yang.scoping.xpath.XpathResolver._internalResolve(XpathResolver.java:373) at io.typefox.yang.scoping.xpath.XpathResolver.internalResolve(XpathResolver.java:926) at io.typefox.yang.scoping.xpath.XpathResolver.doResolve(XpathResolver.java:306) at io.typefox.yang.scoping.ScopeContextProvider.lambda$_computeScope$21(ScopeContextProvider.java:609) at io.typefox.yang.scoping.ScopeContext.lambda$resolveAll$12(ScopeContext.java:426) at java.util.ArrayList.forEach(ArrayList.java:1249) at io.typefox.yang.scoping.ScopeContext.resolveAll(ScopeContext.java:428) at io.typefox.yang.resource.YangResource.getEObject(YangResource.java:39) at org.eclipse.xtext.linking.lazy.LazyLinkingResource.getEObject(LazyLinkingResource.java:222) at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getEObject(ResourceSetImpl.java:223) at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:199) at org.eclipse.emf.ecore.util.EcoreUtil.resolve(EcoreUtil.java:259) at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eResolveProxy(BasicEObjectImpl.java:1477) at io.typefox.yang.yang.impl.XpathNameTestImpl.getRef(XpathNameTestImpl.java:117)

huyuwen commented 6 years ago

Hi Jan,

I think I found the root cause of this issue. It is not a bug in yang_lsp, but a wrong operation in our own code. I changed original yang model eobject which breaks the crossreference.

So I think this issue could be closed.