I've rebased this patch to be independent of the others, to perhaps
parallelize the review process.
As mentioned before, this patch enforces canonicalization of ranges upon
creation. This makes it easier to compare results of range
implementations and avoids multiple representations for the s
On 7/3/19 3:35 AM, Aldy Hernandez wrote:
> On 7/2/19 5:36 PM, Jeff Law wrote:
>
>> I don't see anything inherently concerning here. I do wonder if there's
>> any value in having a debugging function in the class that would iterate
>> over the ranges and check them for proper canonicalization, ver
On 7/2/19 5:36 PM, Jeff Law wrote:
I don't see anything inherently concerning here. I do wonder if there's
any value in having a debugging function in the class that would iterate
over the ranges and check them for proper canonicalization, verify that
VR_{VARYING,UNDEFINED} objects do not have
On 7/1/19 3:02 AM, Aldy Hernandez wrote:
> As discussed prior. This enforces canonicalization at creation time,
> which makes things a lot more consistent throughout.
>
> Since now [MIN, MAX] will be canonicalized into VR_VARYING, we can no
> longer depend on normalizing VARYING's into [MIN, MAX]
As discussed prior. This enforces canonicalization at creation time,
which makes things a lot more consistent throughout.
Since now [MIN, MAX] will be canonicalized into VR_VARYING, we can no
longer depend on normalizing VARYING's into [MIN, MAX] for more general
handling. I've adjusted the
