On 5/30/19 12:58 AM, Aldy Hernandez wrote:
Hi.
We have zero_p in the API, but we don't have non_zero_p. Instead we use
a non-API function range_is_nonnull. I've fixed this.
I have also gotten rid of the duplicity of using the non-API
range_is_null in favor of value_range_base::zero_p().
Furthermore, there's value_range*::set_null and
value_range*::set_nonnull(). It's inconsistent to use null/nonnull as
well as zero/non_zero throughout. I've moved everything to *zero.
With the -Wformat-diag cleanup still fresh in my memory, I can't
help but point out that the GCC spelling convention calls for
"nonzero" vs "non-zero" or "non zero".
Naming the function set_nonzero() would be in line with both
the convention and established practice (over 2000 instances)
and set_non_zero would not be (only 22 instances of non_zero
in GCC sources).
This, of course, is in contrast to things like bit-field and
built-in where the convention calls for the hyphen but where
in code we seem to prefer "bitfield" nonetheless ;-) (Names
like get_bit_field_ref_def and bit_field_size being
the exceptions).
Martin
Finally, it seems to me that the derived value_range versions of
set_*zero/null are a bit confusing in that they clear equivalences
behind the scenes. There's no intuitive reason why setting a range of
[0,0] versus [5,10] should clear equivalences. I've made the
equivalence nuking explicit in the handful of places where we do this,
and thus reduced the need for separate value_range versions.
I believe with these changes, as well as the pending intersect patch,
we've cleaned up the remaining value_range uses where we actually wanted
to use value_range_base. Or at least the remaining "value_range tem"
business.
OK?
Aldy
