StrReplaceFile reports too few total replacements for chained edits

[Sreekant13]

What issue are you seeing?

StrReplaceFile applies its edits sequentially, but it counts the total number of replacements against the original file content instead of the running (progressively edited) content. When one edit's old string is text produced by an earlier edit, that edit is not present in the original content, so it is counted as zero even though it is applied correctly.

The file is written correctly; only the "total replacement(s)" number in the tool result message is wrong.

Steps to reproduce

Apply two chained edits to a file containing hello world:

edits = [
    Edit(old="hello",   new="goodbye"),
    Edit(old="goodbye", new="farewell"),
]

The file correctly becomes farewell world, but the tool reports:

File successfully edited. Applied 2 edit(s) with 1 total replacement(s).

The second edit (goodbye -> farewell) is counted as 0 because goodbye does not appear in the original content, only in the content produced by the first edit.

Expected behavior

The reported count should reflect the replacements actually performed, i.e. 2 total replacement(s) for the example above. Each edit should be counted against the content it is applied to (the running content), not the original.

Additional information

Found by reading the tool source. I have a fix ready with a regression test.

[ayaangazali]

Ran into this same thing a bit earlier and opened #2554 for it, which should cover exactly this case. The count is summed against the original file content while the edits themselves apply sequentially, so any edit whose old was produced by an earlier edit gets counted as zero.

Linking in case it saves someone duplicate work. Your hello -> goodbye -> farewell example is a nicer minimal repro than the one I used.