Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Kasper Kondzielski
    @ghostbuster91
    Thanks, I was just looking for exactly that code :)
    Sakib Hadžiavdić
    @sake92
    Hello! How can I test if a class is annotated with a specific annotation?
    The structure is different when using @abc and @x.y.abc..
    Tomasz Godzik
    @tgodzik
    @sake92 I think it you're doing it from the parser then it should have additional mod
    Mod.Annot
    Sakib Hadžiavdić
    @sake92
    @tgodzik yeah. But it's hard to test for FQN. Nevermind, I'll go with simplest solution. YOLO :smile:
    trying to migrate Wither generator to scalafix: https://github.com/sake92/stone#wither
    Tomasz Godzik
    @tgodzik
    @sake92 scalafix usually applies rules on the existing code to change it , not sure how you can use that for wither :thinking:
    or do you plan to refactor this class by adding the methods explicitely?
    Sakib Hadžiavdić
    @sake92
    yeah, just add them explicitly, if they're missing in source
    Tomasz Godzik
    @tgodzik
    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!
    Sakib Hadžiavdić
    @sake92
    sure, thanks! :)
    Igal Tabachnik
    @hmemcpy
    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?
    Ólafur Páll Geirsson
    @olafurpg
    @hmemcpy scala/scala or scala/contributors is a better place to ask
    Igal Tabachnik
    @hmemcpy
    Cheers. Will try there!
    Alexis Quintero
    @alexisquintero
    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!
    David Leonhart
    @leozilla
    Hello, I have a short question regarding the 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.
    Ólafur Páll Geirsson
    @olafurpg
    @leozilla the scalameta paradise plugin has been discontinued for several years. Please use the scalamacros paradise plugin instead
    @alexisquintero the “semanticdb” artifact is now included with the main “scalameta” artifact
    Brice Jaglin
    @bjaglin
    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.
    Tomasz Godzik
    @tgodzik
    @bjaglin I think we should fix that, should not be too hard to do. The change was intended to simplify the ownership a bit, since it made sense to have extend belong to the template. Could you create an issue so that we don't forget about it?
    Brice Jaglin
    @bjaglin
    Tomasz Godzik
    @tgodzik
    Thanks! I will take a look at it tomorrow
    adampauls
    @adampauls
    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!
    Tomasz Godzik
    @tgodzik
    @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
    Tomasz Godzik
    @tgodzik
    I am getting the untyped tree there, but it should not be an issue to get the typed one
    adampauls
    @adampauls
    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?
    Ólafur Páll Geirsson
    @olafurpg
    Metals calls the compiler directly to do stuff like completions
    Can you elaborate on what you’re trying to accomplish?
    adampauls
    @adampauls

    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!

    Ólafur Páll Geirsson
    @olafurpg
    @adampauls it sounds like you want to implement a compiler plugin. I don’t think scalameta/semanticdb will be helpful for this use-case
    adampauls
    @adampauls
    Heh, well, the reason I came here is because I do not want to implement a compiler plugin, just like folks who want to parse Scala would prefer a standalone library like Scalameta over a compiler plugin. But I understand that I have no other option, thanks for the help!
    Ólafur Páll Geirsson
    @olafurpg
    As soon as you need general purpose typechecking information you typically want to stick to compiler APIs. SemanticDB only supports cery limited semantic analysis
    Good luck!
    Andreas Flierl
    @asflierl

    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?
    Andreas Flierl
    @asflierl
    Tomasz Godzik
    @tgodzik
    that's an issue with some recent changes
    Andreas Flierl
    @asflierl
    if y'all are already aware of it, all is dandy 😊
    Tomasz Godzik
    @tgodzik
    actually I wasn't, so thanks for raising that!
    bit sick today, so I am forgot all my manners
    Andreas Flierl
    @asflierl
    no worries 👍🏻 and feel better soon 🤒
    Tomasz Godzik
    @tgodzik
    trying to fix it here
    adampauls
    @adampauls
    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!
    Ólafur Páll Geirsson
    @olafurpg
    @adampauls metals uses the compiler for completions
    scalameta doesn’t support partial recovery in files with syntax errors