Skip to content

Conversation

matts1
Copy link
Contributor

@matts1 matts1 commented Jul 17, 2025

Checklist

If applicable:

  • I have updated CHANGELOG.md
  • I have updated the documentation (README.md, docs/, demos/)
  • I have updated the config schema (cli/src/config-schema.json)
  • I have added/updated tests to cover my changes

@matts1 matts1 marked this pull request as ready for review July 17, 2025 01:21
@matts1 matts1 requested a review from a team as a code owner July 17, 2025 01:21
@matts1
Copy link
Contributor Author

matts1 commented Jul 17, 2025

My use case here is that I want a template that outputs the canonical form of a list of bugs associated with a commit. Our bugs can be:

  • b:12345
  • b/12345
  • 12345

Additionally, they can be seperated by spaces, commas, or ", ". Replace is required to canonicalize this.

This is required to be done in the templating language because I'd like to be able to pre-fill a commit description with the bugs from all of its parents.

@yuja
Copy link
Contributor

yuja commented Jul 17, 2025

cc @lf-

We have ongoing PRs that add regex:<pattern>. I think it's better to add .replace(pattern, subst) after these PRs get merged.

#6893

@lf-
Copy link
Contributor

lf- commented Jul 17, 2025

yeah here: #6899

i think that we might want to do some way to grab capture groups while doing the api design for replacement

@PhilipMetzger
Copy link
Contributor

Can you put your motivation into the commits description, thanks.

@joneshf
Copy link

joneshf commented Jul 29, 2025

This is great!

Could this be given an optional count: Integer argument, so we can choose the maximum number of replacements to make (like String#replacen in Rust)? So it'd be something like:

.replace(from: Stringify, to: Stringify[, count: Integer]) -> String: Replaces up to count instances
of from with to. With no count, replaces all instance of from with to.

Or however makes sense to word it.

@lf-
Copy link
Contributor

lf- commented Sep 2, 2025

#6899 is merged, feel free to rebase and integrate with the new state of the world now that you can take string templates as parameters :)

"replace",
|language, diagnostics, build_ctx, self_property, function| {
let [from, to] = function.expect_exact_arguments()?;
let from = expect_stringify_expression(language, diagnostics, build_ctx, from)?;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should take a string template like match does.

|language, diagnostics, build_ctx, self_property, function| {
let [from, to] = function.expect_exact_arguments()?;
let from = expect_stringify_expression(language, diagnostics, build_ctx, from)?;
let to = expect_stringify_expression(language, diagnostics, build_ctx, to)?;
Copy link
Contributor

@lf- lf- Sep 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this should be stringify at all, if it should be a non-coercing string, or if it should be forced to be a literal string. The reason to not allow it to be stringify is that dealing with dynamic template strings is a known problem spot in basically every language (c.f. printf vulnerabilities in C, etc) since you have to deal with invalid ones, and it would probably be surprising behaviour to the user to allow them to shoot themselves in the foot with this not being interpreted as a literal string.

Specifically, in a world where this supports $1, $2, etc regex capture group references, allowing this to vary could prove somewhat annoying.

@@ -408,6 +408,8 @@ defined.
* `.lines() -> List<String>`: Split into lines excluding newline characters.
* `.upper() -> String`
* `.lower() -> String`
* `.replace(from: Stringify, to: Stringify) -> String`: Replaces all instances
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as mentioned, should support a number of replacements to make as optional arg :)

@matts1
Copy link
Contributor Author

matts1 commented Sep 3, 2025

I don't think I really have time to finish this off. My other PRs are much higher priority, and have been a pretty large time sink. If anyone else wants to finish this off, they're welcome to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants