redhat-developer / vscode-quarkus

Quarkus Tools for Visual Studio Code, by Red Hat
https://quarkus.io
Apache License 2.0
72 stars 27 forks source link

Qute Text incorrect syntax highlighting #199

Open xorye opened 4 years ago

xorye commented 4 years ago

In this case:

{test
    {! qute-style comments should work !}
}

image

The first and the third line should not have syntax highlighting (should just be white). The second line should have syntax highlighting (in green) because it is a comment.

The second line should look like this: image

rgrunber commented 2 years ago

qute-comments

Just found this issue from well before we had Qute support. We've made some progress on this since, but seems like this isn't addressed in our grammar.

rgrunber commented 2 years ago

In fact, the above syntax is not currently supported by the engine! So if users want this, it should be brought upstream first. (Tried with 2.6.2.Final also)

Exception in thread "main" io.quarkus.qute.TemplateException
    at io.quarkus.qute.CompletedStage.get(CompletedStage.java:44)
    at io.quarkus.qute.MultiResultNode.process(MultiResultNode.java:20)
    at io.quarkus.qute.MultiResultNode.process(MultiResultNode.java:20)
    at io.quarkus.qute.MultiResultNode.process(MultiResultNode.java:20)
    at io.quarkus.qute.TemplateImpl$TemplateInstanceImpl.lambda$renderData$3(TemplateImpl.java:110)
    at java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
    at java.base/java.util.concurrent.CompletableFuture.uniWhenCompleteStage(CompletableFuture.java:883)
    at java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:2251)
    at java.base/java.util.concurrent.CompletableFuture.whenComplete(CompletableFuture.java:143)
    at io.quarkus.qute.TemplateImpl$TemplateInstanceImpl.renderData(TemplateImpl.java:104)
    at io.quarkus.qute.TemplateImpl$TemplateInstanceImpl.renderAsync(TemplateImpl.java:90)
    at io.quarkus.qute.TemplateImpl$TemplateInstanceImpl.render(TemplateImpl.java:55)
    at sandbox.TestArrayQute.main(TestArrayQute.java:34)
Caused by: io.quarkus.qute.TemplateException: Method "{!(this)" not found on the base object "sandbox.Item" in expression {element.{!(this).is(a).test(!)} in template 1 on line 11
    at io.quarkus.qute.EvaluatorImpl.propertyNotFound(EvaluatorImpl.java:208)
    at io.quarkus.qute.EvaluatorImpl.resolve(EvaluatorImpl.java:169)
    at io.quarkus.qute.EvaluatorImpl.resolveReference(EvaluatorImpl.java:113)
    at io.quarkus.qute.EvaluatorImpl.lambda$resolveReference$2(EvaluatorImpl.java:117)
    at io.quarkus.qute.CompletedStage.thenCompose(CompletedStage.java:228)
    at io.quarkus.qute.EvaluatorImpl.resolveReference(EvaluatorImpl.java:117)
    at io.quarkus.qute.EvaluatorImpl.lambda$resolveReference$2(EvaluatorImpl.java:117)
    at io.quarkus.qute.CompletedStage.thenCompose(CompletedStage.java:228)
    at io.quarkus.qute.EvaluatorImpl.resolveReference(EvaluatorImpl.java:117)
    at io.quarkus.qute.EvaluatorImpl.lambda$resolveReference$2(EvaluatorImpl.java:117)
    at io.quarkus.qute.CompletedStage.thenCompose(CompletedStage.java:228)
    at io.quarkus.qute.EvaluatorImpl.resolveReference(EvaluatorImpl.java:117)
    at io.quarkus.qute.EvaluatorImpl.evaluate(EvaluatorImpl.java:81)
    at io.quarkus.qute.ResolutionContextImpl$ChildResolutionContext.evaluate(ResolutionContextImpl.java:86)
    at io.quarkus.qute.ExpressionNode.resolve(ExpressionNode.java:25)
    at io.quarkus.qute.SectionNode$SectionResolutionContextImpl.execute(SectionNode.java:153)
    at io.quarkus.qute.SectionHelper$SectionResolutionContext.execute(SectionHelper.java:47)
    at io.quarkus.qute.LoopSectionHelper.nextElement(LoopSectionHelper.java:124)
    at io.quarkus.qute.LoopSectionHelper.lambda$resolve$0(LoopSectionHelper.java:54)
    at io.quarkus.qute.CompletedStage.thenCompose(CompletedStage.java:228)
    at io.quarkus.qute.LoopSectionHelper.resolve(LoopSectionHelper.java:42)
    at io.quarkus.qute.SectionNode.resolve(SectionNode.java:34)
    at io.quarkus.qute.SectionNode$SectionResolutionContextImpl.execute(SectionNode.java:153)
    at io.quarkus.qute.SectionHelper$SectionResolutionContext.execute(SectionHelper.java:37)
    at io.quarkus.qute.Parser$1.resolve(Parser.java:1040)
    at io.quarkus.qute.SectionNode.resolve(SectionNode.java:34)
    ... 4 more
AlexXuChen commented 2 years ago

@mkouba Should this syntax highlighting use-case be supported or is the thrown error https://github.com/redhat-developer/vscode-quarkus/issues/199#issuecomment-1016571673 intended?

mkouba commented 2 years ago

TLDR> read the last sentence of this comment :smile:

@AlexXuChen Well, I would not expect anyone to use a comment inside an output expression in the first place, as it just does not make any sense. Anyway, the docs is not exactly clear when it comes to similar corner cases.

It's clear that each tag must start with a digit, an alphabet character, underscore, or a built-in command (#, !, @, /). Then we also introduce the notion of an identifier which is a sequence of non-whitespace characters. An output expression is a sequence of identifiers separated by dot (foo.name) or bracket (foo['name']), plus an infix notation can be used for virtual methods with single param ({one plus two} -> {one.plus(two)}). One exception that comes into my mind are string literals that can contain anything (foo.get('this is a string literal used as a method param!'))

That said, the output expression {element {! this is a test !}} (translated to {element.{!(this).is(a).test(!)} + standalone }) is legal but of course non-sense. As for the expression bellow - Qute parser currently calls String.trim() for each part of the expression to identify valid identifiers and so the expression bellow is interpreted as {test {! qute-style comments should work !} (which is translated to {test.{!(qute-style).comments(should).work(!)}; see the infix notation mentioned above). \n} is not considered part of the output expr. }

{test
    {! qute-style comments should work !}
}

@rgrunber the TemplateException is thrown at runtime and has nothing to do with the syntax but with the fact that there is no value resolver that would be able to resolve a virtual method {! with param this (see my explanation above).

In any case, although it's "legal" I'd recommend to mark similar syntax as an user error because it's unintended in 99.99% of cases.

rgrunber commented 2 years ago

Thanks for the explanation. So this should probably be a lower priority for us to support, if at all.