Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

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

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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