tree 3f97f9d72425c71857d9f55fef063acfeed34fb2
parent 79c10fe71304b74d92b41313287249f56b6f2134
author Jinseong Jeon <jsjeon@google.com> 1522816994 -0700
committer Jinseong Jeon <jsjeon@google.com> 1522816994 -0700

Add support for -if rule (without <n>th wildcards).

Fourth design (PS 21):

In RootSetBuilder, only -if rule itself is collected. A partial builder
that can share the same logic in RootSetBuilder is introduced to build
ConsequentRootSet, though.

In Enqueuer, using live items, both of -if conditional and consequent
parts are evaluated. Refer to 3rd design below for some other details.

------

Third design (PS15 ~ PS19):

In RootSetBuilder, only consequent -keep rule are evaluated to collect
which types/members will become live, depending on -if conditional rule.

In Enqueuer, which trace live items based on keep rules, -if conditional
rule is evaluated against newly-became-live items. Depending on the
modifiers of consequent rule, e.g., -keep*names, dependent items would
be enqueued, moved to no-optimization set or no-obfuscation set.

Abandoned to prepare back reference in mind.

------

Second design (PS13):

In RootSetBuilder, -if rule and consequent -keep rule are evaluated just
to collect which DexItem's, such as DexClass (will be hoisted to DexType
for minification), DexEncodedField and DexEncodedMethod, are bound.
Those bindings are maintained in a RootSet.

When Enqueuer records which type/field/method are live, the enablement
of involved -if rule is updated, and once enabled, dependent items are
either enqueued (-keep) or moved to no-obfuscation set (-keep*names).

Abandoned because member rules for any member (e.g., * or <fields>) are
not treated properly. They should be evaluated while tracing live items.

------

First design (PS1 ~ PS11):

In the first round of rule matching, root set builder will figure out
which types match with -if part. Then, in the second round, it will
iterate over subsequent part and bind matched types with precondition
types.

For -if/-keep*names that don't allow obfuscation, but allow shrinking,
dependentNoObfuscation, which mimics dependentNoShrinking, is added.

Abandoned because dependent items are *AND* logic, and both of
dependentNoShrinking and dependentNoObfuscation are bound to one item.

Bug: 73708139
Change-Id: I407ea9c6e20a7e49a36be66838696584c8968cfc