protoc --csharp_out: .proto comment text escapes the generated /// comment via CR/NEL/LS/PS

What version of protobuf and which language are involved?

Version: v36.2 (official release binary) and main at edf1b891d4fc09bad8e73492bdc9c0d2e8b93967
Language: C# (protoc --csharp_out)

What operating system and version were used?

Linux x86_64 (Debian-based). The issue is not OS-specific.

What was tested?

A .proto file containing a documentation comment with U+2028 (LINE SEPARATOR) was compiled. CR (U+000D), NEL (U+0085), and PS (U+2029) produce the same behavior.

syntax = "proto3";
message Foo {
  // Doc comment.<U+2028>NotCode();
  int32 bar = 1;
}

protoc --csharp_out=out --proto_path=. foo.proto

What was the expected behavior?

NotCode(); should remain inside the generated /// documentation comment, along with the rest of the comment text.

What was the observed behavior?

protoc exits successfully and generates out/Foo.cs, but NotCode(); is emitted at code position, outside the documentation comment.

Field documentation comments are generated inside the message class body, where a member declaration is valid C#. As a result, the generated file still compiles, and content that was originally part of the .proto comment becomes part of the generated assembly.

The root cause appears to be the difference between how protobuf and C# recognize line terminators.

A .proto line comment ends only at \n (Tokenizer::ConsumeLineComment in io/tokenizer.cc). As a result, CR, NEL, LS, and PS can remain in SourceCodeInfo.leading_comments.

WriteDocCommentBodyImpl in compiler/csharp/csharp_doc_comment.cc escapes only & and <, then splits the comment on \n and emits each part as a /// single-line comment.

C#, however, recognizes all four characters as line terminators (ECMA-334 6.3.2), and a comment ends at any of them (ECMA-334 6.3.3).

This creates a mismatch between protobuf's comment parsing and C#'s lexical rules: content that protobuf considers part of a comment can become C# source code after generation.

One detail that can make the issue easy to miss is how the generated file is inspected. grep and git diff split text on \n only, so they can show NotCode(); as if it were still part of the comment. The C# compiler interprets the file differently.

The C# generator already treats this character class as dangerous in another code-generation path. kBannedNamespaceChars in csharp_generator.cc rejects \n and \r in option csharp_namespace, with the comment:

"Characters that could enable code injection in generated C# code"

The same validation is not applied to documentation comment text. In addition, that check iterates over bytes, so the three non-ASCII line terminators also bypass it.

Other generators that copy .proto comments do not appear to be affected in the same way. Java, PHP, and Objective-C emit block comments (/** ... */) with their own escaping, while the Ruby RBS output is not executable.

Start with io/tokenizer.cc and compiler/csharp/csharp_doc_comment.cc to trace how line comments and generated /// text handle CR, NEL, LS, and PS; compare the existing kBannedNamespaceChars check in csharp_generator.cc. Reproduce with the supplied foo.proto and protoc --csharp_out command. Done means the generated Foo.cs keeps NotCode(); inside the documentation comment and the output remains valid C#.