On 2/24/21 4:17 PM, Anthony Sharp wrote:
"special"It wouldn't be my code if it didn't have sp3ling mstakes innit! Actually to be fair I already changed that spelling mistake a few days ago in my local code ;) I was actually thinking about this last night as I was falling asleep (as you do) and I realised that the whole of my using decl lookup is redundant. I can simply do this (formatting probably messes up here): /* 1. If the "using" keyword is used to inherit DECL within the parent, this may cause DECL to be private, so we should return the using statement as the source of the problem. Scan the fields of PARENT_BINFO and see if there are any using decls. If there are, see if they inherit DECL. If they do, that's where DECL must have been declared private. */ for (tree parent_field = TYPE_FIELDS (BINFO_TYPE (parent_binfo)); parent_field; parent_field = DECL_CHAIN (parent_field)) { /* Not necessary, but also check TREE_PRIVATE for the sake of eliminating obviously non-relevant using decls. */ if (TREE_CODE (parent_field) == USING_DECL && TREE_PRIVATE (parent_field)) { /* If the using statement inherits DECL, it is the source of the access failure, so return it. */ if (cp_tree_equal (strip_using_decl (parent_field), decl)) return parent_field; } } I was wrong to say that the using decl does not store "where it came from/what it inherits" - that's exactly what strip_using_decl achieves. I think the problem was that when I did my initial testing in trying out ways to get the original decl, I didn't strip it, so the comparison failed, which led me to make the whole redundant lookup, blah blah blah. I've run a quick test and it seems to work, even with the overloads. Will test it some more and if all's good I will probably send a new patch some time this weekend.
Sounds good, though strip_using_decl (parent_field) may be overloaded if the using-decl brings in multiple functions with that name.
Jason
