Both outline and codelenses support can now handle error trees #491
Conversation
rascal-lsp/src/main/java/org/rascalmpl/vscode/lsp/rascal/RascalLanguageServices.java
Show resolved
Hide resolved
| children += [symbol(clean("<v.name>"), variable(), v@\loc, detail="variable <t> <v>") | v <- vars, !hasErrors(v)]; | ||
| } | ||
|
|
||
| case decl: (Declaration) `<Tags _> <Visibility _> anno <Type t> <Type ot>@<Name name>;`: |
There was a problem hiding this comment.
once the match succeeds we now this node is not in error, so we don't need to check hasErrors for that.. but...
|
|
||
| case decl: (Declaration) `<Tags _> <Visibility _> anno <Type t> <Type ot>@<Name name>;`: | ||
| if (!hasErrors(decl)) { | ||
| children += [symbol(clean("<name>"), field(), t@\loc, detail="anno <t> <ot>")]; |
There was a problem hiding this comment.
here you see only bound variables are yielded to string, and that is supported by error trees as well, so no problem..
|
|
||
| case decl: (Declaration) `<Tags _> <Visibility _> alias <UserType u> = <Type al>;`: | ||
| if (!hasErrors(decl)) { | ||
| children += [symbol(clean("<u.name>"), struct(), u@\loc, detail="<u> = <al>")]; |
There was a problem hiding this comment.
but here we use field projecten u.name and u might not even have a name if UserType u is an error tree. This is going to happen all over the place for error trees, so I'd like a more reusable/generic solution then having to guard all the field projections. It will become a cross-cutting and scattered concern everywhere otherwise, while error trees are a builtin language concept that features like . projection {c,sh,w}ould handle gracefully.
There was a problem hiding this comment.
I think we may assume that if a programmer uses u.name then in that place u.name normally does not fail, and so it should also not fail for error children.
- if u is an error tree, and the error "dot" is after the
namefield, then field projection can still work as it was supposed to. - otherwise if the "dot" is before the
namefield or on it, then it may be possible to return an empty stub error tree fornameinstead of failing.
If we have such a semantics for field projection, there would be a lot less pressure on user code for dealing with all kinds of exceptions. In general for productions with n children, there are I guess something like n!/(2 * (n-2)!) possible combinations of having and not having error children, so that can become untenable.
Another option is to rewrite all field projections to pattern matches, which would fail in the absence of a field. But in this example that would lead to a lot of superfluous case distintions:
syntax UserType
= name: QualifiedName name
| parametric: QualifiedName name >> "[" "[" {Type ","}+ parameters "]" ;Here we really do not care about the difference between the two rules but rather their commonality which is fine by the .name field projection. So I guess pattern matching is not a solution here.
Both
locateCodeLenses(inRascalLanguageServices.java) andoutlineRascalModule(inOutline.rsc) would crash if they encountered trees with error nodes.This PR fixes these problems.
In case of the outline, elements with errors are removed from the outline.
In case of the code lenses, top-level elements with errors are ignored for code lenses.