[pigeon] Use a const for custom type ids for gobject generated files (#156100)

[JesseRiemens]

Adds a custom type identifier to generated gobject headers for the user. Calling fl_value_new_custom_object is now possible with that constant.

This fixes flutter/flutter#156100

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩² ↩³

[JesseRiemens]

The FLValue headers in some places use int, and in some places use uint8_t:

// fl_value.h:303
FlValue* fl_value_new_custom(int type, // uses int
                             gconstpointer value,
                             GDestroyNotify destroy_notify);

// fl_standard_message_codec.h:148
gboolean fl_standard_message_codec_write_value(FlStandardMessageCodec* codec,
                                               GByteArray* buffer,  // uses GByteArray*, which is used (subclassed) in generated files:
                                               FlValue* value,
                                               GError** error);
// core_tests.gen.cc:2422
static gboolean
core_tests_pigeon_test_message_codec_write_core_tests_pigeon_test_an_enum(
    FlStandardMessageCodec* codec, GByteArray* buffer, FlValue* value,
    GError** error) {
  uint8_t type = core_tests_pigeon_test_an_enum_type_id; // appends uint8_t to buffer
  g_byte_array_append(buffer, &type, sizeof(uint8_t));
  return fl_standard_message_codec_write_value(codec, buffer, value, error);
}

I think this might be related to #152916. Maybe it is best to leave it as is, and for this PR use int for the types.

[stuartmorgan-g]

The FLValue headers in some places use int, and in some places use uint8_t:

Where is the header using uint8_t for the type? I'm seeing in your snippet:

• A header declaration that uses int for the type.
• A header declaration that doesn't have the type at all.
• A file that's not an engine header.

[JesseRiemens]

My mistake, it's not the FlValue header that uses uint8_t, but only the generated code using the engine header.
I did not fully understand how it worked, but now I see that the generated dart code at the other side also uses uint8:

class DartGenerator extends StructuredGenerator<InternalDartOptions> {
  (...)
  void writeGeneralCodec() {
    (...)
          indent.writeln('buffer.putUint8(4);');

dart_generator.dart:432

That makes more sense to me now. I guess that means we can keep it like it is.

[tarrinneal]

Pr looks good, just one question and I can lgtm

[stuartmorgan-g]

We should output an explanatory comment (if customTypes is not empty) about what the constants are (one comment for the whole block, not one per type).

[JesseRiemens]

I put a comment, but it's not exactly in gdoc style as there's no direct symbol to refer to. (as the comment concerns a block of consts.)

If you don't like it, please give me a suggestion and I'll put it in.

/**
 * Custom type ID constants:
 *
 * Constants used to identify custom types in the codec.
 * They are used in the codec to encode and decode custom types.
 * They may be used in custom object creation functions to identify the type.
 */

[JesseRiemens]

If you'd like to compare, this commit contains the changes since the last review