-
-
Notifications
You must be signed in to change notification settings - Fork 14
Description
Issue
s created within yang-lsp source have a precise context of start
and end
within LSP diagnostics
, whereas Issue
s created within extensions only retain context of start
but not the end
which defaults(?) to [0,0] i.e., Line 1 Col 1, and eventually start
and stop
are swapped resulting in a misleading context of the issues.
Example extension for trial
package my.pack
import io.typefox.yang.validation.IValidatorExtension
import io.typefox.yang.validation.IssueFactory
import io.typefox.yang.yang.AbstractModule
import io.typefox.yang.yang.YangPackage
import org.eclipse.xtext.util.CancelIndicator
import org.eclipse.xtext.util.IAcceptor
import org.eclipse.xtext.validation.Issue
class MyExampleValidator implements IValidatorExtension {
override validate(AbstractModule module, IAcceptor<Issue> issueAcceptor, CancelIndicator cancelIndicator) {
if (module.getName().equals("foo")) {
issueAcceptor.accept(IssueFactory.createIssue(module,
YangPackage.Literals.ABSTRACT_MODULE__NAME,
"'foo' is a bad name", "bad_name"))
}
}
}
Verbose trace excerpt from YANG Language server - foo.log
Manifestation of the issue in VS Code Yangster extension
In the example above precisely foo
is expected to be underlined
The editor user experience is degraded to a large extent, specially if an Issue pertaining to a context towards the end of a YANG file which ends up underlining from the start of the file till what is actually the start of the issue context. This further gets complicated when there are multiple issues raised via extensions since a list of issues are presented in the context that precedes the actual errors.