RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2]

[Hao Sun]

On Mon, 4 Jan 2021 09:41:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I suppose the constructor would be invoked before the copy assignment operator. That is `_vdui` gets initialized already in the ctor `DUIterator_Fast()` for `operator=` case. Right?
>> Take the following code snippet as an example.
>> DUIterator_Fast t1, t2;
>> t2 = t1;    // assignment operator
>> DUIterator_Fast t3 = t1;      // copy constructor. same as "t3(t1)"
>> My point is that, the ctor for `t2` has already invoked, i.e. initializing `_vdui` as false. That's why `operator=` works well.
>> 
>> 
>> Yes. For our newly-added copy constructor for `DUIterator_Fast`, we should initialize `_vdui` as `false`. It may be defined as below.
>> DUIterator_Fast(const DUIterator_Fast& that)
>>     { _outp = that._outp;               debug_only(_vdui = false; reset(that)); }
>
> That's true on the first assignment of `t2`. But what if `t2` is reassigned
> to some other iterator. That assignment sees `_vdui` true, and keeps the old
> value of `_last` rather than updating the value from that other iterator. Is
> that really correct? It certainly seems strange. I'm trying to find someone
> who understands this code to get involved, but holidays.

Thanks for your explanation. Yes, you're right. I didn't realize the re-assignment scenario. 

However, I noticed that there does NOT exist such re-assignment cases. 
Simply grep `= DUIterator_Last(` and `= DUIterator_Fast(`.
Is there anything I missed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1874