nscn.polaris2.protoc.codegen

What a field's element is, once the proto type has been classified.

Emits a proto enum as a Scala 3 enum plus its companion.

This project's option extensions, typed as ExtensionLite.

The annotation is what makes them usable from Scala at all. hasExtension/getExtension are overloaded three ways - for GeneratedExtension, Extension and ExtensionLite - and since the generated constant's type satisfies all three, Scala reports "Ambiguous overload" where Java would pick the most specific one. Widening each constant to the least specific type leaves exactly one applicable overload.

One field, with every decision the printers need already made.

The reason this is a class rather than a pile of functions on FieldDescriptor is that most of the decisions - presence, packing, the Scala type, whether a TypeMapper is in play - are interdependent, and computing them once keeps the printers free of conditionals.

Resolves the effective ScalaFileOptions for a file, including package-scoped ones.

A file can declare options for its whole proto package (scope = PACKAGE), which then apply to every file in that package and its subpackages. That exists so a file that cannot import nscn/polaris2/protoc/options.proto - a third-party schema, say - can still be configured, and it means the options on a descriptor are not the whole story.

Emits every Scala file for one .proto.

An immutable, indentation-aware accumulator of source lines.

Ported from ScalaPB's printer of the same name. Generated code is built by threading one of these through the generators, which keeps indentation out of every string literal and makes a generator a plain FunctionalPrinter => FunctionalPrinter.

Everything the generators need that is not on a descriptor.

The generator's command-line parameters, i.e. what protoc passes after --scala3_opt=.

These are the settings a build tool sets for a whole invocation. Anything that should vary per file, message or field belongs in nscn/polaris2/protoc/options.proto instead.

Emits a proto message as a Scala 3 case class plus its companion.

The shape is fixed by runtime/test's hand-written Person, which is checked against protobuf-java's class for the same schema. Reading that file alongside this one is the quickest way to see what any given piece here is building.

Translating proto names into Scala ones.

Emits a proto oneof as a nested Scala 3 enum.

This is the shape that makes a oneof pleasant to use: exhaustive matching, no "which getter is valid" question, and an explicit Empty case instead of a null.

Emits a message's parser.

The parser is expressed as mergeFrom(input, prev) with parseFrom delegating to it against the default instance. That is not a convenience: protobuf says a singular message field occurring twice is merged, and a parser that can continue from an existing value gets that for free, where a parseFrom-only design needs a separate hand-written merge for every message.

Fully-qualified names of everything the generated code refers to.

The protoc plugin.

Runs as a protoc-gen-scala3 executable, or in-process through the bridge. Everything interesting is in the printers; this is the entry point, the parameter parsing, and the validation that turns an unsupportable schema into a readable error rather than generated code that will not compile.

The main entry point, for running the generator as a protoc plugin executable.

How one scalar proto type is spelled in Scala and on the wire.

codedName is the suffix protobuf-java uses consistently across computeXSize / writeX / readX, which is what lets the generators emit all three from one table entry.

The Well-Known Types that map to a standard library type by default.

The base of each mapping is protobuf-java's own class, so RAW needs no generated message and the mapped form needs no second implementation of the semantics.

This table is the generator's half of a pair; the other half is nscn.polaris2.protoc.runtime.WellKnownTypes, which the generator cannot link against because the two modules are on different Scala versions. The e2e tests compile generated code against the real runtime, which is what keeps the two in step.