Apply the given pg-map via graph lense.
While visiting types in a subtyping order, mappings in the pg-map will
be converted to a custom graph lense. One caveat is to detect mapping
conflicts, e.g., so-called diamond problem.
Another caveat is to apply class mappings on-the-fly. We should rename
all the occurrences of renamed types while applying member mappings.
Yet another caveat is uses of renamed lib classes inside pgr classes.
We have a separate step that fixes trees by explicitly substitute those
type appearances with applied names.
------
Note that, instead of way too general support (http://go/r8g/4880),
we decided to support only the simple use case: compile a new piece
of code (e.g., test) against an obfuscated app.
See http://b/64802420#comment7 for more details.
Bug: 64802420
Change-Id: Ib3cb35811061c046e94a4fc9a021a783f15050dc
diff --git a/src/test/examples/minification/conflict-mapping.txt b/src/test/examples/minification/conflict-mapping.txt
new file mode 100644
index 0000000..a4453da
--- /dev/null
+++ b/src/test/examples/minification/conflict-mapping.txt
@@ -0,0 +1,4 @@
+minification.InterfaceA -> ItfA:
+ int functionFromIntToInt(int) -> foo
+minification.InterfaceB -> ItfB:
+ int functionFromIntToInt(int) -> bar
