Skip to content

-Z unpretty=expanded leads to invalid syntax for unicode escapes in format strings #116799

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
narpfel opened this issue Oct 16, 2023 · 3 comments · Fixed by #116811
Closed

-Z unpretty=expanded leads to invalid syntax for unicode escapes in format strings #116799

narpfel opened this issue Oct 16, 2023 · 3 comments · Fixed by #116811
Assignees
Labels
C-bug Category: This is a bug. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@narpfel
Copy link
Contributor

narpfel commented Oct 16, 2023

I tried this code (Godbolt link):

pub fn main() {
    println!("\x1B[1mHello, world!\x1B[0m");
    println!("\u{1B}[1mHello, world!\u{1B}[0m");
    println!("{}", "\x1B[1mHello, world!\x1B[0m");
}

I expected to see this happen: When running rustc -Z unpretty=expanded, the format string literals for the first two println!s should remain valid string literals.

Instead, this happened: This code is generated:

use ::std::prelude::rust_2015::*;
extern crate std;
pub fn main() {
    {
        ::std::io::_print(format_args!("\u{{1b}}[1mHello, world!\u{{1b}}[0m\n"));
    };
    {
        ::std::io::_print(format_args!("\u{{1b}}[1mHello, world!\u{{1b}}[0m\n"));
    };
    {
        ::std::io::_print(format_args!("{0}\n",
                "\x1B[1mHello, world!\x1B[0m"));
    };
}

Note the double {{ and }} in the \u escapes.

The escape sequences in the last println! are correctly preserved.

This is annoying because it makes it impossible to run rustfmt on the macro-expanded source, which is helpful when trying to read macro-generated code.

Meta

rustc --version --verbose:

rustc 1.75.0-nightly (42b1224e9 2023-10-15)
binary: rustc
commit-hash: 42b1224e9eb37177f608d3f6a6f2be2ee13902e4
commit-date: 2023-10-15
host: x86_64-unknown-linux-gnu
release: 1.75.0-nightly
LLVM version: 17.0.2
@narpfel narpfel added the C-bug Category: This is a bug. label Oct 16, 2023
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Oct 16, 2023
@Noratrieb Noratrieb added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. and removed E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. labels Oct 16, 2023
@Noratrieb
Copy link
Member

I haven't looked at it, but this is probably going wrong somewhere in compiler/rustc_ast_pretty when printing FormatArgs.

@narpfel
Copy link
Contributor Author

narpfel commented Oct 16, 2023

Looks like you’re right:

FormatArgsPiece::Literal(s) => {
for c in s.as_str().escape_debug() {
template.push(c);
if let '{' | '}' = c {
template.push(c);
}
}
}

As I understand this, it duplicates curlies regardless of whether they’re part of an escape sequence.

@narpfel
Copy link
Contributor Author

narpfel commented Oct 16, 2023

@rustbot claim

@Noratrieb Noratrieb removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Oct 16, 2023
@bors bors closed this as completed in 05e2056 Oct 17, 2023
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 17, 2023
Rollup merge of rust-lang#116811 - narpfel:unpretty-unicode-escape-in-format-string-literal, r=Nilstrieb

Preserve unicode escapes in format string literals when pretty-printing AST

Fixes rust-lang#116799

Thanks to `@Nilstrieb` for the pointer to the correct location, that was really helpful for someone unfamiliar with the codebase.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-bug Category: This is a bug. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants