core-trace: SpanBuilder use macro to preserve laziness

[iRevive]

Fixes #725.

Let's take a look at how the following code will be unwrapped:

val result = b.withSpanKind(kind).withStartTimestamp(timestamp).withParent(ctx)

Scala 2 (chained calls are optimized manually by the macro):

val result = if (b.meta.isEnabled) {
  b.modifyState(_.withSpanKind(kind).withStartTimestamp(timestamp).withParent(ctx))
} else {
  b
}

The Scala 3 chained calls aren't optimized:

val result = {
  val SpanBuilderMacro_this: org.typelevel.otel4s.trace.SpanBuilder[[A >: scala.Nothing <: scala.Any] => cats.effect.IO[A]] = b
  val `SpanBuilderMacro_this₂`: org.typelevel.otel4s.trace.SpanBuilder[[A >: scala.Nothing <: scala.Any] => cats.effect.IO[A]] = (if (SpanBuilderMacro_this.meta.isEnabled) SpanBuilderMacro_this.modifyState(((_$11: org.typelevel.otel4s.trace.SpanBuilder.State) => _$11.withSpanKind(kind))) else SpanBuilderMacro_this: org.typelevel.otel4s.trace.SpanBuilder[[A >: scala.Nothing <: scala.Any] => cats.effect.IO[A]])
  val `SpanBuilderMacro_this₃`: org.typelevel.otel4s.trace.SpanBuilder[[A >: scala.Nothing <: scala.Any] => cats.effect.IO[A]] = (if (`SpanBuilderMacro_this₂`.meta.isEnabled) `SpanBuilderMacro_this₂`.modifyState(((_$13: org.typelevel.otel4s.trace.SpanBuilder.State) => _$13.withStartTimestamp(timestamp))) else `SpanBuilderMacro_this₂`: org.typelevel.otel4s.trace.SpanBuilder[[A >: scala.Nothing <: scala.Any] => cats.effect.IO[A]])

  (if (`SpanBuilderMacro_this₃`.meta.isEnabled) `SpanBuilderMacro_this₃`.modifyState(((_$15: org.typelevel.otel4s.trace.SpanBuilder.State) => _$15.withParent(org.typelevel.otel4s.trace.SpanBuilderMacro.inline$Explicit$i1(_root_.org.typelevel.otel4s.trace.SpanBuilder.Parent).apply(ctx)))) else `SpanBuilderMacro_this₃`: org.typelevel.otel4s.trace.SpanBuilder[[A >: scala.Nothing <: scala.Any] => cats.effect.IO[A]])
}

It's not the end of the world for Scala 3, JIT compiler will inline the if statements in the runtime, but still sad that we produce non-optimized code.

---

Pros

• Zero allocation builder when instrumentation is disabled

Cons

• It's a macro, a complicated one
• Scala 3 generated code could be improved

[NthPortal]

I love this. on the surface, it seems like we've made things much more complicated, but:

• no more Tracer.Meta
• substantial deduplication of SpanBuilder implementations
• huge simplification of the Scala 3 TracerMacro

[NthPortal]

that's very kind of them

[NthPortal]

I love how the only sense in which this is even a macro now is that everything is inline

[iRevive]

Yes, exactly. Scala 3 macro feels much better now.