You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fixes for the Starlark transition hash computation (#14251)
* Move transitionDirectoryNameFragment calculation to BuildConfigurationValue
As per discussion in b/203470434, transitionDirectoryNameFragment should completely depend on the current values of the (rest of) the BuildOptions class. Thus, it is far better to have this always computed from BuildOptions when building a BuildConfigurationValue than rely on users keeping it consistent. (Other results of BuildConfigurationValue itself are themselves wholly computed from BuildOptions so placement there is a natural fit.)
This naturally fixes the exec transition forgetting to update transitionDirectoryNameFragment.
This fixes and subsumes #13464 and #13915, respectively. This is related to #14023
PiperOrigin-RevId: 407913175
* Properly account for StarlarkOptions at their default (=null) when calculating ST-hash
Previously, the hash calculation was skipping including StarlarkOptions that happened to be at their default values.
This is wrong since those values may still be in "affected by Starlark transition" (because either the commandline set them and the Starlark transition reset them to their Starlark defaults thus still requiring a hash change OR the commandline did not set them but a series of Starlark transitions did an default->B->default anyways causing the Starlark option to still be 'stuck' in "affected by Starlark transition").
Resolves#14239
PiperOrigin-RevId: 408701552
Co-authored-by: twigg <[email protected]>
0 commit comments