ScalaTest macros

[liufengyun]

This is thread for issues about implementation of ScalaTest macros (related meta issue #5489)

TODOS

• Line number (source)
• Position macros (source)
• Assert & Assume macros (source)
  • ==
  • !=
  • === blocked by Some useful tree constructors #5567 Macro expansion exception related to Select #5786
  • >=, <=, >, <: blocked by Some useful tree constructors #5567, but we use Term.Select.copy as walkaround
• assertTypeError (source) blocked by missing c.parse + c.typecheck
• assertDoesNotCompile (source) blocked by missing c.parse + c.typecheck
• assertCompiles (source) blocked by missing c.parse + c.typecheck
• GenFactories macros (source)
• Requirements macros (source)
  • require(boolean)
  • requireNonNull(args: Any*)
  • requireState
• Snapshot macros (source)
• DiagrammedAssertion macros (source)
  • macro implementation
  • usage blocked by overriding macros
• Expectation macros (source)
  • expect
  • expect compile: blocked by missing c.parse + c.typecheck
• Matcher macros (source)
• Matchers macros (source)
  • shoud
  • should compile: blocked by missing c.parse + c.typecheck
• MatcherPatternMacro (source)
• MatchPatternWord (source)
• BeWord (source)
• NoWord (source)
• ResultOfNotWordForAny (source)
• LongAnyVal (source)
• CharAnyVal (source)
• FloatAnyVal (source)
• DoubleAnyVal (source)
• IntAnyVal (source)
• NumericString (source)
• PercentageInt (source
• RegexString (source)

Issues

• Overriding of macros (source, source)
• Implementation of macro are private (source, issue Inline proxy cannot be generated on package #5492 )
• liftSeq in lib ( Add List[Expr[T]] to Expr[List[T]] conversion in the library #5543)

  private def liftSeq(args: Seq[Expr[Any]]): Expr[Seq[Any]] = args match {
    case x :: xs  => '{ (~x) +: ~(liftSeq(xs))  }
    case Nil => '(Seq(): Seq[Any])
  }

• import Term._ and import refl._ are tedious
• bug Error in reify/seal implementation #5533
• bug Error in reify/seal implementation (2) #5536
• bug Macros: Imprecise error for string lifting #5547
• constructors required to support generic > operation that work on unknown types. Blocked by Add TASTy reflect constructors #5438 Some useful tree constructors #5567
• a helper method like def typeOf[T]: Type will be helpful
• seal to a method type: useful in === case Syntax for method types or tree constructors useful in meta-programming #5563
• bug with line number Incorrect line positions in macro expansion #5629
• Runtime reflection support Meta-programming: runtime reflection support? #5639
• IsSelectModule not friendly Proposal for replacing IsXxx extractors in tasty-reflect #7204
• copy not useful
• missing selectApply on any term
• bug Compiler crash during macro expansion #5715
• report warnings with precise positions
• bug Macro expansion exception related to Select #5786
• bug Weird versioning issues with SBT after upgrade to 2.12.8 #5612
• bug Incorrect RefChecks in Scala2 mode #5831
• bug Function5.curried not implemented #6109
• bug Phase consistency involving higher-kinded types #5962
• bug Macro expansion failed with missing positions #6048
• bug Missing constructor for Term.Ident #5951
• bug Illegal field modifiers in class Matchers: 0x9 #5924
• bug An implicit val should not be available for defining itself? #6114
• bug StackOverflowError related to implicits #6119

[liufengyun]

While working on ScalaTest, generally quote/splice improves a lot experience (though we still lack useful constructors #5567 ).

However, there is a potential problem, which is encountered when working on ScalaTest. There are two projects in ScalaTest:

• Scalactic
• Scalactic-Macros

In Scala2, Scalactic depends on Scalactic-Macros. In Scala 3, if we use quote/splice, Scalactic-Macros has to dependent on Scalactic to resolve names. This creates mutual dependencies!

If there is always mutual dependencies between macros project and its main project, quotes & splices will be useless for writing macros. Macro authors will be forced to use constructors & extractors to break the cycles.

[LPTK]

If there is always mutual dependencies between macros project and its main project, quotes & splices will be useless for writing macros.

Can't you define the macros in the same project as the classes they quote? In both scala.reflect and Squid, that's how it works. It's just that you won't be able to call these macros from the same project.

For example, in scala.reflect you can write:

class A { val x = 42 }
def A: Int = macro `A macro`
def `A macro`(c: whitebox.Context): c.Expr[Int] = {
  c.universe.reify{new A().x}  // similar to a typed quote
}

[liufengyun]

@LPTK If the macros are not used in the main project, then it makes sense to merge the two projects. This is the walkaround I took dotty-staging/scalatest@642050c for ScalaTest.

However, I assume there are a lot of projects where the macros are used in the main project and refer to symbols defined in the main project, then things become subtle.

[liufengyun]

ScalaTest use Context.parse and Context.typecheck to implement assertCompiles, assertTypeError and assertDoesNotCompile, which are not available in Dotty (source):

      val tree = c.parse("{ "+codeStr+" }")
      if (!containsAnyValNullStatement(c)(List(tree))) {
        c.typeCheck(tree) // parse and type check code snippet

• add show for Type[T] link

[liufengyun]

@nicolasstucki Just discussed with @cheeseng and @bvenners, I learned that macros like assertDoesNotCompile are super useful for library authors.

Github search for assertDoesNotCompile shows 299 results.

[nicolasstucki]

@liufengyun can we close this issue? All the macro related issues have been fixed. All remaining tasks have their own issue.

[liufengyun]

We may close now. We need to make an upstream PR after the meta-programming API refactoring.