jimingham wrote:
> > When you are about to use a cached formatter, just run the validator
> > function from that formatter on the candidate VO. If it doesn't pass the
> > validator, fall back to the full search.
>
> I think for this, it's easier to save the validator per
> formatter/summary/synthetic, because we need the validator when retrieving
> from the cache, right? That shouldn't be a big issue, just a refactoring.
>
> > You could even make the cache hold the "match string" and a LIST of
> > matching formatters. If a VO passes the typename string match, then we run
> > through the list of matching formatters and choose the first one whose
> > validator accepts this VO.
>
> I think in almost all cases, having one entry in the cache is better. Sure,
> there might be scenarios where you have different types with the same name,
> but realistically, when you're formatting you're formatting (e.g. at a
> breakpoint), you'll most likely have one type per name.
If you have two Targets in lldb, and they each have a variant of some type that
you've discriminated by a TypeValidator, then it's quite possible that Target A
and Target B hit breakpoints in a location that contains a local of the given
type in sequence. For instance, if I were trying to follow some RPC from
client to server and back, I'd be stopping with the "client" view of the
message first, then stopping on receipt with the "server" view of the message,
etc.
So one {typename, validator} pair will get set in the cache when you first
stop in the client. Then when you stop in the server, we'll answer that the
type is not cached because the validator fails. I think we'll then cache the
{typename, second_validator} so at that point we're getting no benefit from
caching...
https://github.com/llvm/llvm-project/pull/143748
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
