Protoc emitting ill-formed C++ code when a message is named "target", "base" or "stream".

[ognian-]

Protoc will successfully generate C++ code, that cannot be compiled afterwards. If a message is named "target", "base" or "stream" the generated code will contain naming collision with internally used arguments of the same name. I expect that protoc would either produce an error, or emit correct code. A proposed fix is in PR #24204

[mkruskal-google]

I don't think that PR is really a scalable fix. There would be nothing preventing us from accidentally introducing similar issues in the future. There are also likely many such cases where going against our style guide with unexpected names can break things due to conflicts. This is one of the reasons we've started enforcing these naming rules in edition 2024 (with an opt-out for backwards compatibility).

Something more scalable might be to stop embedding $classname$ everywhere and use some fixed alias that couldn't conflict with local variables (without breaking every build). Of course, even then it could conflict with other messages you've defined...

[ognian-]

The problem manifests when introducing internal names in the emitted code, and there are no existing mitigations for that. Such names are not covered by ResolveKnownNameCollisions() et al. Thus any proposed fix will seem ad-hoc, as opposed to something already addressed, like keywords for example.

I don't think not addressing the issue is a valid decision, as it breaks backwards compatibility with the same major version (for example v4.22.0). Given that there is a simple way to ensure backwards compatibility all the way back, it's even harder to ignore it.

A more scalable approach may be to create a list of internally used names (similar to MessageKnownMethodsCamelCase), and let io::Printer validate the provided input, failing on words not found in the list. Then Protobuf developers won't be able to introduce new local names without adding them in the list.