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