Use createMessage() of type GeneratedMessage Function() in Dart protoc compiler

[mkustermann]

Often apps use extensive numbers of protos. The BuilderInfo of a proto will refer to sub proto messages via using Foo.create tear-offs.

Big apps can end up with tens of thousands of those <name>.create closures. All of them currently have a unique <name> Function() function type.

Though the actual usage of those closures is only in contexts where the caller of the closure expects a GeneratedMessage as return type. If a caller knew the actual return type, then the caller could call the constructor directly.

To avoid having to create potentially tens of thousands of unique function types, we make those closures have the
GeneratedMessage Function() type.

[sigurdm]

LGTM

This is probably a breaking change though.

[mkustermann]

@sigurdm Do you know how I can fix the PR failures? I formatted locally before pushing, but it still seems fail. Maybe the bot uses a slightly different Dart SDK with slightly different analyzer infos?

[mkustermann]

This is probably a breaking change though.

I will try this in g3 before landing & measure impact on some apps before landing.

In reality I hope this doesn't break anyone as it'd be strange to use Foo.create() instead of just Foo() in user code.
How should we reflect this change in the version numbers?

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:protobuf	6.1.0	ready to publish	protobuf-v6.1.0
package:protoc_plugin	25.1.0	ready to publish	protoc_plugin-v25.1.0

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[sigurdm]

Yeah it would be strange, but people do the strangest things...

If we cannot find any breakages I'm ok with a minor release
@mosuem @jonasfj WDYT?

At least we should try see how this fares against google3.

The protoc_plugin pubspec should have its constraint on protobuf updated to require at least this new version.

[mkustermann]

/cc @rakudrama