[cfe-dev] Identifiying (successfully resolved) overloaded function references.

[Douglas Gregor]

Sent from my iPhone

On Oct 5, 2011, at 10:20 AM, John McCall <rjmccall at apple.com> wrote:

> On Oct 5, 2011, at 9:01 AM, Enea Zaffanella wrote:
>> Would there be objections to the "splitting" of the current NoOp cast
>> kind into a few, slightly different flavors of NoOp providing a clearer
>> distinction, that will be useful for source code based tools?
>> 
>> For instance, in the case of the example above, the explicit NoOp
>> static_cast kind could be replaced (when there are indeed multiple
>> candidates) by an "OverloadResolution" cast kind.
>> 
>> Another example is that of (usually implicit) NoOp casts resulting from
>> qualification conversions, i.e., when the "const" qualifier is added to
>> a modifiable lvalue argument expression passed to a function by const&:
>> in this case, we would opt for a "QualificationConversion" cast kind.
>> 
>> The final goal would be to have a NoOp cast kind only for those casts
>> that are NoOp under all points of view: no change for the type, no
>> change for the value and no change for the lvalue-ness of the argument
>> expression.
>> 
>> Clearly, the new "source code based" cast kinds will be treated in
>> other compilation phases as if they were plain NoOp.
>> (If deemed useful, for clarity, we can even uses names such as
>> NoOp_OverloadResolution and NoOp_QualificationConversion).
> 
> I have no problem with sub-dividing NoOp, but I seem to remember
> Doug having opinions in this area, so I've CC'ed him.

I'm fine with subdividing NoOp further.