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

.expand() treats expression $1_cpu as named capture group #1021

Closed
dvolodin7 opened this issue Jul 3, 2023 · 1 comment
Closed

.expand() treats expression $1_cpu as named capture group #1021

dvolodin7 opened this issue Jul 3, 2023 · 1 comment

Comments

@dvolodin7
Copy link

What version of regex are you using?

1.8.4

Describe the bug at a high level.

The documentation declares:

Capture group names must be any sequence of alpha-numeric Unicode codepoints, in addition to ., _, [ and ]. Names must start with either an _ or an alphabetic codepoint. Alphabetic codepoints correspond to the Alphabetic Unicode property, while numeric codepoints correspond to the union of the Decimal_Number, Letter_Number and Other_Number general categories.

so i consider the expan expression $1_cpu will refer to the capture group index 1. Actually, expand treats it as named capture group 1_cpu, which lead to empty result. This behavior is incorrect, because capture group name cannot start with digit.

What are the steps to reproduce the behavior?

What is the actual behavior?

use regex::Regex;

fn main() {
    let s = "cpu_user";
    let rx = Regex::new("cpu_(.*)").unwrap();
    let caps = rx.captures(s).unwrap();
    let mut x = String::new();
    caps.expand("$1_cpu", &mut x);
    println!("result = {:?}", x);
}

Returns output:

result = ""

What is the expected behavior?

Expected output:

result = "user_cpu"

Other notes

Expanding of ${1}_cpu works as expected. The expression cpu_$1 is already expanded properly.

@BurntSushi
Copy link
Member

The behavior is correct amd consistent with documentation: https://docs.rs/regex/latest/regex/struct.Captures.html#method.expand

It is definitely not optimal though. That's why #69 exists (and this is a dupe of that) and is labeled regex2.

@BurntSushi BurntSushi closed this as not planned Won't fix, can't repro, duplicate, stale Jul 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants