On 3/10/21 4:14 PM, Anthony Sharp wrote:
Hiya
That's because none of the names are overloaded within a single base
class.
Ah, thanks. Thought there must be something I wasn't thinking of.
Also, you can use == instead of cp_tree_equal for comparing FUNCTION_DECLs.
Changed it.
Latest patch
ompiles fine and no regressions.
Anthony
From 0b2dd8d8818c6e23b3c8d1b0de7b71c1bb86e6c3 Mon Sep 17 00:00:00 2001
From: Anthony Sharp
Date: Wed, 10 Mar 2021 20:36:03 +0000
Subject: [PATCH] c++: Private parent access check for using decls [PR19377]
This bug was already mostly fixed by the patch for
On 3/1/21 5:11 PM, Anthony Sharp wrote:
Hi all,
Here is the patch as promised. Regression tested on the c++ side and
everything seems okay. Compiles fine.
Sounds good, though strip_using_decl (parent_field) may be overloaded if
the using-decl brings in multiple functions with that nam
trip 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
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) a
> "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 d
On 2/15/21 7:45 AM, Anthony Sharp wrote:
PARENT_BINFO, has private access to DECL. Examine certain sepcial cases
"special"
I did try the name
lookup as Jason suggested but, as I say, in the case of overloaded
functions it returns multiple values, so it didn't help in determining
what DEC
Scan the fields of BINFO for an exact match of DECL. If found, return
DECL. Otherwise, return NULL_TREE. DECL is really the type "tree". */
Should say
Scan the fields of BINFO for an exact match of DECL. If found, return
the field. Otherwise, return NULL_TREE. DECL is really the type
Hi all,
This overloaded functions issue has been a pain in the ass but I have
found a solution that seems to work. I could really do with some
feedback on it though since I'm not sure if there's a better way to do
it that I am missing.
Here's the problem. When a using statement causes an access f
On 2/9/21 6:18 AM, Anthony Sharp wrote:
The parens are to help the editor line up the last line properly. If
the subexpression fits on one line, the parens aren't needed.
A okay.
No; "compile" means translate from C++ to assembly, "assemble" means
that, plus call the assem
>
> The parens are to help the editor line up the last line properly. If
> the subexpression fits on one line, the parens aren't needed.
A okay.
No; "compile" means translate from C++ to assembly, "assemble" means
> that, plus call the assembler to produce an object file. Though since
> co
On 2/5/21 12:28 PM, Anthony Sharp wrote:
Hi Marek,
+ if ((TREE_CODE (parent_field) == USING_DECL)
This first term doesn't need to be wrapped in ().
I normally wouldn't use the (), but I think that's how Jason likes it
so that's why I did it. I guess it makes it more readable.
Ah, no,
t; > +
>> basetype_path);
>> > > >
>> > > > - /* If a parent had private access, then the diagnostic
>> > > > - location DECL should be that of the parent class, since
>> it
>> > > > - failed to give
>
> I think at least something like "Improve private access checking." would
> be better. No need to be verbose in the ChangeLog. :)
That sounds like a good idea, I will change it.
Yup, this one.
Awesome.
Yeah, that can be a pain. Best if your editor does it for you. If you
> use vim, you
On Fri, Feb 05, 2021 at 05:28:07PM +, Anthony Sharp wrote:
> Hi Marek,
>
> > Pedantically, "Altered function." is not very good, it should say what
> > in enforce_access changed.
>
> I would normally 100% agree, but the changes are a bit too complicated
> to be concisely (and helpfully) descr
Hi Marek,
> Pedantically, "Altered function." is not very good, it should say what
> in enforce_access changed.
I would normally 100% agree, but the changes are a bit too complicated
to be concisely (and helpfully) described there. I think the patch
description covers it well enough; not sure wha
Hi,
a few comments:
On Fri, Feb 05, 2021 at 03:39:25PM +, Anthony Sharp via Gcc-patches wrote:
> 2021-02-05 Anthony Sharp
>
> * semantics.c (get_class_access_diagnostic_decl): New function.
> (enforce_access): Altered function.
Pedantically, "Altered function." is not very go
Sorry - last one had a formatting error. This one might be better.
Linux text editor doesn't consistently show whitespace for me!
On Fri, 5 Feb 2021 at 15:39, Anthony Sharp wrote:
>
> > I'm imagining member functions, i.e. A::f() and A2::f(int).
>
> You're right - good spot.
>
> > == is enough, i
> I'm imagining member functions, i.e. A::f() and A2::f(int).
You're right - good spot.
> == is enough, identifiers are unique.
Done.
> Agreed, but the using-declaration might not be introducing DECL. This
> would be another way to skip irrelevant usings.
Okie dokie.
New patch attached (tha
On 2/4/21 12:46 PM, Anthony Sharp wrote:
Yes, thanks; it would take a lot to make me request less comments.
Awesome.
The second lines of arguments are indented one space too far in both these
calls.
Oops! I will fix that.
Well, I guess it could be using a declaration of the same name fro
> Yes, thanks; it would take a lot to make me request less comments.
Awesome.
> The second lines of arguments are indented one space too far in both these
> calls.
Oops! I will fix that.
> Well, I guess it could be using a declaration of the same name from another
> base.
Yes I had been wor
On 2/4/21 11:24 AM, Jason Merrill wrote:
On 2/4/21 10:02 AM, Anthony Sharp via Gcc-patches wrote:
Hello,
New bugfix for PR19377
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377). This is
basically an extension of what I did before for PR17314 except it also
fixes this other bug.
I hope I di
On 2/4/21 10:02 AM, Anthony Sharp via Gcc-patches wrote:
Hello,
New bugfix for PR19377
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377). This is
basically an extension of what I did before for PR17314 except it also
fixes this other bug.
I hope I didn't over-comment in the code ... better t
Hello,
New bugfix for PR19377
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19377). This is
basically an extension of what I did before for PR17314 except it also
fixes this other bug.
I hope I didn't over-comment in the code ... better to say too much
than too little! It's a niche bug so I thoug
24 matches
Mail list logo
