Might be possible to embedd it like we do in munit https://github.com/scalameta/munit/blob/e32667fa1949608f421180a34b12feec6220f5b7/munit/shared/src/main/scala/munit/internal/difflib/Diff.scala
The structure is different when using
@abc and @x.y.abc..
Mod.Annot
trying to migrate Wither generator to scalafix: https://github.com/sake92/stone#wither
or do you plan to refactor this class by adding the methods explicitely?
ach ok, that makes sense. Please do add the scalafix rule to https://scalacenter.github.io/scalafix/docs/rules/community-rules.html if you manage to get it working!
Hi all! I'm trying to figure out how to render extension methods "as-is". I am calling
showCode on a Select node of an expression e.g. obj.someExtension, but it shows up as MyExt(obj).someExtension. Would appreciate any hints whether it's possible to have it print as obj.someExtension instead?
Hmm, this is done from a macro on a
scala.reflect.api, if that matters... perhaps I should ask this in scala/scala instead?
Hi, I'm trying to get all methods and signatures from a project's libraries, I've been reading this guide
https://scalameta.org/docs/semanticdb/guide.html and the API docs https://www.javadoc.io/doc/org.scalameta/scalameta_2.13/latest/scala/meta/index.html but I'm stil not sure how to procede, in the docs it says that scala bindings are in "org.scalameta" %% "semanticdb" % "4.4.18" which doesn't seem to exist, can anyone point me in thr right direction? Thx!
Hello, I have a short question regarding the
I tried to add it to one of my projects via
I also tried to use
paradise compiler plugin. I guess its possible to use it with scala 2.12.12, right? cos I only see examples for up to scala 2.12.8.I tried to add it to one of my projects via
addCompilerPlugin("org.scalameta" % "paradise" % "3.0.0-M11").cross(CrossVersion.full) but it doesnt find it.I also tried to use
addCompilerPlugin("org.scalameta" % "paradise_2.12.8" % "3.0.0-M11"), there it was found/downloaded but it seems to not take effect.
@alexisquintero the “semanticdb” artifact is now included with the main “scalameta” artifact
Hi! It looks like https://github.com/scalameta/scalameta/commit/8fcb000b8f81059d73eb92bba3e54f308f949da3#diff-0e49038aa6bb62a35909f2706047e756d1345084db2ffec11b6753fbd5cdd7f5 breaks some Scalafix rules which are replacing a parsed
Template (which now includes the extends token) with a pretty-printed one (that does not emit the extends token, unless used within a Defn.Class), resulting in the following rewrite: class Foo extends OriginalSuperClass -> class Foo NewSuperClass. I understand the reason for the change, but I find it confusing because of the asymmetry between parsing vs pretty-printing/quasiquotes. Is there anything similar with other trees? From a scalafix rule author it means that we will need 2 behaviors depending on the runtime scalameta version (brought by scalafix, evicting the one the rule was built against) for a smooth transition.
Hello! Apologies if this is the wrong channel. I would like to programmatically parse and typecheck some Scala 3 code. The parsing part is very easy thanks to scalameta. I understand that typechecking requires more information, like a set of imports and type declarations in a SemanticDB. I'm wondering if it's easy to construct a typechecker given programmatic specification of whatever context is necessary. I have looked a little at metas and the Scala compiler internals, but I don't see a user-friendly entry point for constructing a typechecker. Does anyone have any pointers? Thanks!
@adampauls You should be able to run the compiler typechecker and then get the typecheck tree out of that -> doing soemthing very similar here https://github.com/tgodzik/scala3-compiler-interactions/blob/main/dotty/src/main/scala/parser/dotty/Parser.scala
typechecking is too hard a project to implement it outside the compiler
Thanks for the response! I think that might not quite work for me, since I'd like to construct the set of type declarations programatically and also not run the full compiler -- I really want just parsing and typechecking. I was under the (mistaken?) impression that the Scala compiler could easily import type declarations from a Semantic DB which I could generate myself. Do you happen to know how this works in Metals? When it runs typechecking, does it do so by invoking the compiler directly and bypass the Semantic DB?
Can you elaborate on what you’re trying to accomplish?
I think the nearest neighbor is something like Scala JS -- we want to reuse Scala syntax and type checking, but otherwise emit code in a custom internal language. We also want to be able to depend on function and type declarations generated from external sources. In the ScalaJS analogy, this would mean depending type signatures from function declarations in JS (if they existed). We never want to generate Java bytecode or depend on it.
I had not realized that Semantic DB was something that the neither scalac nor Metals depended on as a source of truth and not just a convenient index. It sounds like the right thing for me to do is to directly generate TASTY trees for programmatic declarations and construct a Compiler with a custom set of Phases to only run parsing, name resolution, and typechecking, is that right? This is of course now a question for the scalac gitter, but I appreciate your help in any case!
Good luck!
hi, in the latest Metals update, the ScalaMeta parser seems to trip over the following syntax (in a Scala 2.12 project):
def f = { (n: Int) =>
{
for {
_ <- scala.util.Success(123)
} yield 42
}.recover(???)
}throwing an Exception: "syntax error: ; expected but . found" at the dot before the recover
is this known already? should I file a bug?
(here's the full output for context: https://gist.github.com/asflierl/1addc743035859f31d86870df2bb811b)
bit sick today, so I am forgot all my manners
trying to fix it here
I asked a question earlier about typechecking and learned that Metals relies on compiler internals for typechecking. I'm curious if the same is true for completions? From looking at the code, I think it does. But I thought I'd ask in any case. I was hoping that perhaps scalameta can parse in a tolerant mode that does not require valid syntactic trees? Failing that, pointers to how Metals or the Scalac itself provides autocomplete given partially written expressions would be really helpful. Thanks!
scalameta doesn’t support partial recovery in files with syntax errors