The proptools functions took an inconsistent variety of
struct and *struct types. Some methods even took a struct
but returned a *struct. Make all the exported methods
take a *struct, with internal helpers for the ones that need
to take a struct.
Test: proptools tests
Change-Id: I60ce212606e96adcef66c531d57f69c39e1a1638
When CopyProperties comes across private properties, it silently ignores
them. This is error-prone and can result in a bug very hard to debug if
the developer is unaware of the behavior.
Change-Id: Id6a0752e384ec7fed35728c1e87dbfa95fea84f2
The type field cache was using an atomic pointer to an immutable
map, which required copying the entire map each time a cache
entry was added. Profiling showed that this was a significant
hot spot. Use sync.Map instead.
Change-Id: Ie7c779c5e9e2be1cd530747d74025dcfd206763a
Property structs can now contain slices of structs and other
non-strings as long as they are tagged with `blueprint:"mutated"`.
Test: clone_test.go
Test: unpack_test.go
Change-Id: Ib77348dc6e7314a24f17caba10040f7d3ac54e54
Support int64 number instead of int to be more fixed to bit size so
that the underlying arch won't affect overflow cases. Besides,
refection: func (v Value) Int() int64 always cast to int64 no matter the
input is int, int16, int32. Currently we always treat "-" as negative
sign to bind to next value, and "+" as plus operator to add operands
together.
So we allow:
a = 5 + -4 + 5 or a = -4 + 5
But we don't allow:
a = +5 + 4 + -4 since we don't treat "+" as a positive sign, otherwise,
a = 5 + +5 would exist which looks pretty weird. In the future, we may
want fully support number calculator logic eg, "+"/"-" can be
positive/negative sign or operator, and "(" and ")" will be considered
to group expressions with a higher precedence.
int & uint properties within struct keeps unchanged, which is only
allowed when tagged with 'blueprint:mutated'. We only allow *int64
property instead of int64 property within struct since it does't make
sense to do prepending or appending to int64.
Change-Id: I565e046dbd268af3538aee148cd7300037e56523
Allow primary builders to reduce allocations of empty structures by
allowing nil pointers to concrete struct types. Property readers will
not recurse into nil pointers, property writers will replace the nil
pointer with a pointer to the zero value of the pointer element type.
Allows a >50% primary builder time improvement with a trivial change in
Soong.
Change-Id: If6ad674bf7bf2a694c335378a074643a97d3c50b
proptools cloning and extending are a significant portion of the run
time for Soong. Optimize out calls to reflect.Type.Field(), which must
allocate a []int to store the index, by caching all the fields of each
type as it is seen, and by iterating over a slice of cached fields
instead of calling Field(i) for each one. Also avoid calling
reflect.Value.Interface() twice on the same Value.
Change-Id: I4e13fc85f30d8614a5586283e928c0a6d7f24809
ZeroProperties was setting nested structs to their zero value, even if
they contained an interface that should be recursed into, not replaced
with nil.
The only append semantics for bool that result in a no-op when the zero
value is appended is to OR the two values together, but that is rarely
the desired semantics. Add support for *bool and *string as property
types, where appending a nil pointer is a no-op. For *bool, appending a
non-nil pointer replaces the destination with the value. For *string,
appending a non-nil pointer appends the value.
This also provides a more reliable replacement for
ModuleContext.ContainsProperty, as the build logic can tell that the
property was set, even if it was set by a mutator and not by the
blueprints file, by testing against nil.
[]string already provides these semantics for lists.
Setting a *bool or *string property from a blueprints file is the same
syntax as setting a bool or a string property.
Add tests for CloneProperties, CloneEmptyProperties and ZeroProperties
and fix detected bugs related to nil pointers to structs and interfaces
containing nil pointers to structs.
