On 4/29/26 10:09 AM, feedable wrote:
On 29/04/2026 05:27, Jason Merrill wrote:
On 4/28/26 4:17 PM, feedable wrote:
On 28/04/2026 22:10, Jason Merrill wrote:
On 4/27/26 7:14 PM, feedable wrote:
On 28/04/2026 01:03, Jason Merrill wrote:
On 4/27/26 2:14 PM, feedable wrote:
+ else if (BASELINK_P (expr))
+ expr = build_baselink (access_path,
BASELINK_BINFO (expr),
Extra space before =. Also I guess BASELINK_ACCESS_BINFO
instead of
BASELINK_BINFO?
We want to use access_path (relative to the actual
object_type) in place of
BASELINK_ACCESS_BINFO, but indeed the access path should be
the second
argument rather than the first in both this call and the
existing one.
If I understand correctly, access_path is the endpoint of the
search, so it
should go into BASELINK_BINFO, and it's the object type that
should go
into BASELINK_ACCESS_BINFO (in both cases, actually), since
it's the
place where we started the search.
Ah, true.
Apparently, the start would actually correspond to the time when
we got
the reflection in the first place (as we are essentially performing
x.C::m, but with C::m being spliced); so obtaining the access
binfo from the
reflection here is correct.
I think you were right before; the reflection of a member does not
include any information about how it was produced, whether from ^^
directly or otherwise. And normally BASELINK_ACCESS_BINFO needs
to represent either the object type or a base thereof.
I believe that information is set in https://forge.sourceware.org/
gcc/ gcc-TEST/src/commit/c607c686100689e3e68487cd8097c2fbd3904168/
gcc/cp/ parser.cc#L10181, at least for the ^^ case.
So using TYPE_BINFO (object_type) as in v3 makes sense. Of course
we're suppressing access checking anyway so it doesn't much
matter, but better to be correct if it isn't a burden.
Consider this case:
```
struct X {};
struct Y { template<class T> T f(T); };
auto _ = X{}.[:^^Y::f:]<int>(1);
```
Here, in v3 we build a BASELINK with the start point at X, even
though X has nothing to do with Y::f, we couldn't've possibly found
Y::F through X.
Hmm, in that case lookup_base should fail so we don't build a
BASELINK at all.
The call to lookup_base probably should fail, yes. That said, we
still do build the BASELINK even if the result is NULL. We want that
because code later really really wants that BASELINK even if it has
no BINFO, to perform access checks on.
Ah, yes, I was forgetting null return for "not a base". But I would
think we want to error immediately in that case and set expr =
error_mark_node rather than build a BASELINK.
finish_class_member_access_expr does that for us already if we just
leave the BINFO as NULL in such cases.
Only accidentally; better to give an error here as well rather than
build a broken BASELINK that's likely to cause crashes if something
looks at it closely.
Incidentally, the above case doesn't seem to be represented in the tests.
Jason
