Yes, setting cperl-fontify-trailer to comment fixes the bug. In my case, the lines after the __END__ are more than just comments and get corrupted when they are indented. There is also the __DATA__ keyword and the default setting of cperl-fontify-trailier causes the data to be indented which alters the behavior of the program (corrupts the result). Consider:

while (my $line = <DATA>) { print $line; }
close DATA;
__DATA__
This is not
perl code

If you indent, C-x h followed by C-M-\, the results change. Indenting shouldn't change results.

Could you consider changing the default value of cperl-fontify-trailer to comment so that cperl-mode doesn't indent them? Also, the name is a little misleading because the more important piece is whether to semantically treat the lines after these keywords as perl code. The Perl interpreter never treats these as perl code, so it's odd cperl-mode treats them as perl code. The only case I'm aware of where the lines following these keywords is perl is to use the trick to put __END__ to comment out the bottom part of a perl program, but even in that case, it should be colored as comments.

Thanks


From: Mauro Aranda <maurooaranda@gmail.com>
Sent: Saturday, March 8, 2025 10:51 AM
To: John Ciolfi <ciolfi@mathworks.com>; 76868@debbugs.gnu.org <76868@debbugs.gnu.org>
Subject: Re: bug#76868: 29.4; cperl-mode __END__ is incorrectly handled
 
On 8/3/25 12:34, John Ciolfi via Bug reports for GNU Emacs, the Swiss
army knife of text editors wrote:
>
> Hi
>
> Given the following cperl-mode program, test.pl
>
> # -*- mode: cperl; -*-
> print "hello\n";
> __END__
> This is not
> perl code!
>
> The lines after the __END__ are treated as perl code. They are
syntactically colored and indented
> which is incorrect. In perl, __END__ defines the end of the Perl code
in the file. Any text that
> appears after __END__ is ignored by the Perl compiler.
>
> All lines after __END__ should be treated as comments.
>

Any chance that the option cperl-fontify-trailer helps here?

I remember reporting something similar in:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66161