On Thu, Apr 27, 2017 at 7:23 AM, Nathan Sidwell <nat...@acm.org> wrote:
> On 04/26/2017 12:34 PM, David Malcolm wrote:
>
>> Thanks - yes; that gives information on the const vs non-const of the
>> "this" parameter, but doesn't say whether the argument was const vs non
>> -const.
>
>
>> However, within:
>>
>> int test_const_ptr (const t1 *ptr)
>> {
>> return ptr->m_color;
>> }
>> from which we can see the const-ness of the t1:
>
>
> correct.
>
>> but the call to lookup_member from within
>> finish_class_member_access_expr discards this information, giving just
>> "access_path": a BINFO that wraps the RECORD_TYPE for t1 directly.
>
>
> Correct.
>
> lookup_member just looks for a matching name. the BINFO represents the
> class hierarchy - it's not modified depending on the cvquals of where you
> came from.
>
>> A somewhat invasive solution would be for lookup_member to grow an extra:
>> tree object
>> parameter, and to pass this information down through the access
>> -enforcement code, so that locate_field_accessor can look at the const
>> -ness of the lookup, and avoid suggesting const methods when the object
>> is const. The code would probably need to support the new param being
>> NULL_TREE for cases where we're looking up a static member. Or maybe
>> an enum of access style for const vs non-const vs static.
>> Maybe name the param "access_hint" to signify that it's merely there
>> for the purpose of hints for the user, and not to affect the parsing
>> itself?
>
> Hm, that does seem rather unfortunate.
>>
>> Another solution would be to not bother offering non-const methods as
>> accessors.
>
>
> I think that would be very unfortunate.
>
> How about adding a tsubst_flag value?
>
> tf_const_obj = 1 << 11, /* For alternative accessor suggestion help. */
>
> and pass that in? the tsubst flags have grown in meaning somewhat since
> they first appeared -- their name is no longer so appropriate.
>
> (of course we have the same problem with volatile, but that's probably
> overkill for first attempt.)
>
> Jason, WDYT?
I'd suggest handling this diagnostic in
finish_class_member_access_expr, rather than try to push down context
information into lookup_member. Perhaps by adding another parameter
to lookup_member for passing back the inaccessible or ambiguous lookup
result?
Jason
