[cfe-dev] Identifiying (successfully resolved) overloaded function references.
rjmccall at apple.com
Wed Oct 5 10:20:00 PDT 2011
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
> 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.
More information about the cfe-dev