Try to extract name when backtick is missing #13369
Conversation
| val content = ref.source.content() | ||
| // if the error resulted from unclosed back tick | ||
| if content(ref.span.start) == '`' then | ||
| content.slice(ref.span.start + 1, ref.span.end).mkString |
There was a problem hiding this comment.
I'm just wondering whether this is enough to tell that an unclosed backtick was the actual problem. Could we have a different kind of error if the backtick was closed?
There was a problem hiding this comment.
It should be enough especially if backtick is first, otherwise anything inside backticks should be ok.
| @@ -842,4 +842,10 @@ class CompletionTest { | |||
| |object Main { "abc".xx${m1} }""".withSource | |||
| .completion(m1, Set()) | |||
| } | |||
|
|
|||
| @Test def wrongAnyMember: Unit = { | |||
| code"""|import scala.util.chaining.`sc${m1} | |||
There was a problem hiding this comment.
It would be good to test some cases with more natural usages of backticks - if the name clashes with a keyword or contains spaces or would be normally disallowed for some other reason
There was a problem hiding this comment.
I added some more test cases, let me know if you have any other ideas!
tgodzik
force-pushed
the
fix-unclosed-backtick
branch
from
e27d3ac to
315f7cf
Compare
tgodzik
force-pushed
the
fix-unclosed-backtick
branch
from
315f7cf to
705d30b
Compare
I added the additional tests! |
| @@ -138,4 +138,50 @@ class TabcompleteTests extends ReplTest { | |||
| tabComplete("import quoted.* ; def fooImpl(using Quotes): Expr[Int] = { import quotes.reflect.* ; TypeRepr.of[Int].s")) | |||
| } | |||
|
|
|||
| @Test def wrongAnyMember: Unit = fromInitialState { implicit s => | |||
There was a problem hiding this comment.
I didn't mean repeating the tests performed in CompletionTest.scala but rather directly reproducing the issue reported in #12514:
Starting with a fresh REPL try invoking completion on import scala.util.chaining.`s and then on import scala.util.chaining.`sc inside the same session
tgodzik
force-pushed
the
fix-unclosed-backtick
branch
from
705d30b to
96b3909
Compare
Previously, completion prefix would show up as an empty string if we had an unclosed backtick. Now, we try to extract the prefix from the file contents in that case. An alternative approach would be to tranfer somehow the name string in `nme.Error`, but I didn't see anything like that done before, so not sure how to properly address that. Fixes #12514
tgodzik
force-pushed
the
fix-unclosed-backtick
branch
from
96b3909 to
ffc202d
Compare
|
Ok, checked it with REPL and it should work ok now. |
|
@prolativ is taking some further look into it |
|
Will close it for now. |
Previously, completion prefix would show up as an empty string if we had an unclosed backtick. Now, we try to extract the prefix from the file contents in that case.
An alternative approach would be to tranfer somehow the name string in
nme.Error, but I didn't see anything like that done before, so not sure how to properly address that.Fixes #12514
@odersky is there a sensible way to fix this in the parser? Should we just fallback to using the name after the backtick with a reduced span?