Always normalize paths used in apply_edit.py
The same header file may be included in multiple compilation units. When the rewriter emits replacement/edit directives for such header file, then the replacements may be emitted multiple times - once for each compilation unit that includes the header. There is a risk that the replacements will refer to the file using different paths. If apply_edits.py doesn't consistently normalize file paths, then it won't deduplicate replacement/edit directives applying to a given file. This will mean that edits using the first filename will shift offsets within the file and cause edits using the second filename to be applied to random chunks of the file. It is not well understood what may lead the rewriter to use different paths when emitting replacements for the same file (from different compilation units). One hypothesis is that include paths passed to the compiler may differ (e.g. use absolute VS relative paths). Whatever the root cause, varying file paths do happen in the wild - for example: $ grep gl_bindings.h rewriter.out | \ sed -e 's/[^:]*::://' | sed -e 's/:::.*//' | sort | uniq ../../ui/gl/gl_bindings.h /usr/local/google/home/bartekn/chromium3/src/out/rewrite/../../ui/gl/gl_bindings.h Bug: 1069567 Change-Id: Ie67cfaaeaa5c958875733634826c9bb46782c73d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2222542 Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org> Reviewed-by:Daniel Cheng <dcheng@chromium.org> Cr-Commit-Position: refs/heads/master@{#776812}
Showing
Please register or sign in to comment