Perform member lookup on FacetAccessType #5058
Conversation
The name scope lookup and member name lookup both need to handle the case where the base inst is a FacetAccessType. Then we move from the FacetAccessType to the FacetType which is the type of the instruction inside the FacetAccessType. We do name lookup on FacetType already, so "unwrapping" the FacetAccessType to the FacetType just makes use of that path. Similarly we do member access on FacetType already, so we can reuse that codepath with the FacetType found in the FacetAccessType.
toolchain/check/member_access.cpp
Outdated
| if (auto facet_type = context.insts().TryGetAs<SemIR::BindSymbolicName>( | ||
| context.constant_values().GetInstId(base_type_const_id))) { | ||
| llvm::errs() << "hi\n"; | ||
| } | ||
|
|
There was a problem hiding this comment.
I'm expecting this wasn't meant to be left in the PR.
There was a problem hiding this comment.
Oh argh no, this was giving me a place to breakpoint. Removing
| @@ -234,6 +234,19 @@ auto AppendLookupScopesForConstant(Context& context, SemIR::LocId loc_id, | |||
| -> bool { | |||
| auto base_id = context.constant_values().GetInstId(base_const_id); | |||
| auto base = context.insts().Get(base_id); | |||
|
|
|||
| if (auto base_as_facet_access_type = base.TryAs<SemIR::FacetAccessType>()) { | |||
There was a problem hiding this comment.
Doesn't have to be this PR, but this is starting to look like a common operation (#5060 should possibly also do this) that I wonder if it could be moved into its own function?
There was a problem hiding this comment.
The issue with moving it to another function is that in both cases we are also overwriting/replacing a few other derived variables, like here the base_const_id which also requires changing base_id and base, and in the other case base_id which requires changing base_type_id. In one case the resulting inst is directly from the FacetAccessType and in the other its from the constant value of that inst (because we needed a constant value first).
Maybe we could unconditionally get the constant value and return that inst and its type as a pair or something? I'm not sure - let's leave it out of this PR at least
The name scope lookup and member name lookup both need to handle the case where the base inst is a FacetAccessType. Then we move from the FacetAccessType to the FacetType which is the type of the instruction inside the FacetAccessType.
We do name lookup on FacetType already, so "unwrapping" the FacetAccessType to the FacetType just makes use of that path. Similarly we do member access on FacetType already, so we can reuse that codepath with the FacetType found in the FacetAccessType.