Code generation error when transforming protobuf generated classes

[wienczny]

When trying to transform the classes generated using protobuf an error message is issued for every message:

'prefix5' has no member named 'reflectable_generated_main_library#_ReadonlyEnvelope'.

This message is repeated for every _Readonly* class generated.
(see dart-archive/dart-protoc-plugin#51 for an initial description)

[eernstg]

Thanks! Do you have code which will reproduce the problem? (I couldn't see any references to code at dart-archive/dart-protoc-plugin#51, and I'm not sure git clone https://github.com/dart-lang/dart-protoc-plugin will do).

[eernstg]

Tried

...$ git clone 'https://github.com/dart-lang/dart-protoc-plugin'
...$ cd dart-protoc-plugin
...$ pub get
...$ pub build --mode=debug test

where the latter produces 14919 lines of diagnostic messages, but it ends in 'Build failed.', none of the messages mention _Readonly, and the 'build' directory tree is empty, so that wasn't enough.

Could you give some more input on how you can reproduce the problem?

[wienczny]

It took some time to prepare a minimal example: https://github.com/wienczny/ReflectableBugExample
dart-protoc-plugin used is dart-archive/dart-protoc-plugin@58a031c
The bug can be triggered inside the ReflectableBugExample by running pub build

[eernstg]

Got it, thanks a lot!

[eernstg]

Ah, sorry -- this is a very simple issue: The problem is that there is an attempt to access a private declaration in 'messages.pb.dart' and reflectable does not support access to private declarations.

It is common for Dart tools to react to this situation (access to private declarations across library boundaries) by claiming that the requested name does not exist. The underlying reason is that the private names are renamed such that there is no way to access them (not even with dynamic invocation).

Couldn't you simply make _ReadonlyEnvelope public?

[eernstg]

Duplicate of #33.

[wienczny]

If you mean manually modifying all _Readonly* in the generated code - I could do that.
I just prefer a solution that worked across rebuilds, though.

[eernstg]

And you don't have enough control over that code generation process to avoid the generation of that as a private name in the first place?

For instance, if there is a transformer somewhere which will consistently create this type of problem for many of its users then the maintainer of that transformer might be persuaded to make that change..

[sigurdm]

We can sort private classes away when generating the code, I guess that is better than generating invalid code - not all classes might be in the users control to make public.

When sorting away a private member it could be logged with logger.fine so a pub build --verbose would reveal that it happened.

[eernstg]

Reclassified as a bug: I forgot that we are actually generating that private name, which shouldn't happen in any case.

[eernstg]

We're now avoiding to create the expressions that will not compile because they attempt to access a private declaration in a different library (commit 2d9b6f5 on reflectable).

Looking at your explanation again, it looks like the private class was not annotated directly by you, it may instead have been selected by subtype quantification in a reflector that you hadn't even written, and the class itself might even have been generated. That would of course make it quite difficult to avoid that it gets included. But the above-mentioned update should help you, and it does eliminate the problem in the example you provided.