diff options
| author |  gregce <gregce@google.com> | 2017-06-01 19:51:00 +0200 |
|---|---|---|
| committer |  László Csomor <laszlocsomor@google.com> | 2017-06-02 15:26:15 +0200 |
| commit | e6392cd380fce14d719890c78d5eb2657e8a6cfc (patch) | |
| tree | 435fc1817624afe9bbb20eec91d0d9721698463a /src/test/java/com/google/devtools/build/lib | |
| parent | 202d5910a194ae5a0dfbc11692a17e8013017aca (diff) | |
Add .equals(), .hashCode() to EnableLipoTransition.
This fixes a subtle integration bug between PatchTransition, ConfiguredTargetFunction, and DependencyResolver.
Short story: ConfiguredTargetFunction.getDynamicConfigurations assumes at most one <Attribute, Label, Transition> entry per configured target dep. DependencyResolver.dependentNodeMap faithfully supplies this by returning an OrderedSetMultimap<Attribute, Dependency>, where each Dependency is a <Label, Transition>. OrderedSetMultimap guarantees no <key, value> repeats, but if you have two semantically equal EnableLipoTransition instances that don't satisfy .equals(), deduping fails.
Most PatchTransitions don't have this problem because they're singletons. But each EnableLipoTransition is instantiated with a Rule, so singletons don't work here.
This problem can only happen when a rule has multiple instances of the same C++ dep under the same attribute. But this isn't actually possible for normal attributes like "deps" because they don't allow duplicates (see RuleClass#checkForDuplicateLabels). Only non-LABEL_LIST attributes can trigger this.
PiperOrigin-RevId: 157733284
Diffstat (limited to 'src/test/java/com/google/devtools/build/lib')
0 files changed, 0 insertions, 0 deletions