[Ram-blip]

Summary

ProtoJSON currently rejects null elements in repeated google.protobuf.NullValue fields before enum conversion runs.

Repeated null elements are generally rejected, but google.protobuf.NullValue is the documented exception because its JSON representation is null. This change allows repeated google.protobuf.NullValue elements to reach the existing readEnum handling, which already converts null to NULL_VALUE.

Behavior

Before this change:

protojson.fromJson(NullMsg, {
  nullValues: [null, null]
});

throws:

.test.NullMsg.nullValues: null element: null

After this change, the same input parses as:

{
  nullValues: [0, 0]
}

and serializes back to:

{
  nullValues: [null, null]
}

Ordinary repeated null elements remain rejected.

Tests

Added regression coverage in tests/api_protojson.js for repeated google.protobuf.NullValue fields.

The test extends the existing test.NullMsg fixture with:

repeated google.protobuf.NullValue null_values = 7;

It then verifies both supported well-known-type root paths already used by the ProtoJSON tests:

• parsed .proto root
• JSON descriptor root

For each root, the test checks both directions:

• fromJson accepts nullValues: [null, null] and parses it as [0, 0]
• toJson serializes [0, 0] back as nullValues: [null, null]

This specifically covers the bug where repeated null elements were rejected before the existing readEnum handling could convert google.protobuf.NullValue from null to NULL_VALUE.

Existing tests continue to cover the general rule that ordinary repeated null elements are rejected, so this change only adds the documented google.protobuf.NullValue exception.