This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C++: fix-it hints suggesting accessors for private fields
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?
nathan
--
Nathan Sidwell