GeezerVison

When source is passed to exec() or eval() as a str, or via -c, a lone \r inside a string literal stays '\r'. CPython reads it as '\n', as it does for CRLF. The language reference says line-ending sequences are replaced by LF "even inside string literals". Docstrings with CR-only breaks also went uncleaned, and exec(text) differed from exec(text.encode()).

These paths skip the source decoder and reach compile_with_syntax_warning_handler, which only replaced "\r\n". The parser copies literal text from the source as is, so an unnormalized CR ended up in the value.

• crates/compiler/src/lib.rs: compile_with_syntax_warning_handler now also replaces any remaining \r with \n, after the CRLF replacement.

eval('"""a\rb"""')   # before: 'a\rb'   after: 'a\nb'

• The #[cfg(windows)] \r\n replacement near line 2082 is untouched.
• No regression test is added.

• Fixes exec(), eval() and -c keep a lone CR in string literals when the source is a str #9761