Hello, I just realized that these two expressions:
(_: Int, 42).toString and ((_: Int, 42)).toString have exactly the same representation in Scalameta AST. However, these two are completely different things for the scala compiler! The first one is (x: Int) => (x, 42).toString and the second one is ((x: Int) => (x, 42)).toString. How do I tell that difference using scalameta?
@ghik good catch! This looks somewhat related to scalameta/scalameta#1843 I would be interested to hear you thoughts on what would be the expected
scala.meta.Tree structure for those two different programs
Your proposal sounds reasonable, I agree it's tricky with the current AST to figure our when
Term.Placeholder is an anonymous function
Is this something you might be interested in working on? I don't expect I'll look into this anytime soon
It would be essential to fix this before we introduce tree printer in scalafmt
but it's not clear when that will happen yet
@ghik changes would be in
ScalametaParser, iirc, the logic for detecting lambdas is a bit hairy https://github.com/scalameta/scalameta/blob/7c5c020cc0ff9b97d9029b315fb8659590236a2c/scalameta/parsers/shared/src/main/scala/scala/meta/internal/parsers/ScalametaParser.scala#L1554
in what situation would you like to add positions?
Actually, this particular case is probably a bug:
a +: (1,2,3) - this is parsed by scalameta as ApplyInfix with three parameters but scalac parses (1,2,3) in this context as a tuple. So I wanted to workaround this by creating a Tuple tree out of these arguments but apparently I can't do this without losing positions.
I mean, I won't lose positions on arguments themselves but I would like the tuple to have a position, too.
here is my ticket scalameta/scalameta#1867
Is that still a thing?
this cache has historically been global and caused a lot of headache, but I made this cache local in scalameta/scalameta#1914
I'm trying to open the
scalameta project in VS Code with metals and I'm consistently getting error from sbt: Not a valid command: metalsEnable. I tried various workarounds found in already reported issues (e.g. scalameta/metals#685) but nothing works...
otherwise, I don't import the scalameta build into metals since it conflicts with the SemanticDB plugin (which is developed in the scalameta build and Metals uses it)
we do funky stuff like customize the sourceroot setting to be a subdirectory, which doesn't play nicely with Metals
you'll need a bit more work to handle references to overridden methods
You can poke into the Metals codebase to see how "textDocument/references" is implemented
@olafurpg I still can't make it work with current snapshot. I built 0.7.7-SNAPSHOT from today's master and I'm getting this:
java.util.concurrent.ExecutionException: org.eclipse.lsp4j.jsonrpc.ResponseErrorException: DecodingFailure(Attempt to decode value on failed cursor, List(DownField(providesFileWatching), DownField(capabilities)))
at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915)
at scala.meta.internal.metals.BuildServerConnection$.initialize(BuildServerConnection.scala:176)
at scala.meta.internal.metals.BuildServerConnection$.fromStreams(BuildServerConnection.scala:129)
at scala.meta.internal.metals.BloopServers.$anonfun$newServer$1(BloopServers.scala:71)
at scala.util.Success.$anonfun$map$1(Try.scala:255)
at scala.util.Success.map(Try.scala:213)
at scala.concurrent.Future.$anonfun$map$1(Future.scala:292)
at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:33)
at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:33)
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:64)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.eclipse.lsp4j.jsonrpc.ResponseErrorException: DecodingFailure(Attempt to decode value on failed cursor, List(DownField(providesFileWatching), DownField(capabilities)))
at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleResponse(RemoteEndpoint.java:209)
at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:193)
at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.handleMessage(StreamMessageProducer.java:194)
at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:94)
at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:113)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
our CI publishes a SNAPSHOT on every merge BTW http://scalameta.org/metals/docs/editors/vscode.html#using-latest-metals-snapshot
we're waiting for a stable release of bloop to come out before releasing metals v0.8
maybe best to wait until then
but I don't understand why I'm running wrong version of bloop - isn't it set up automatically by metals?
