jimingham wrote:
> On Oct 2, 2024, at 9:22 AM, David Blaikie ***@***.***> wrote: > > > Not quite sure how we get to caching and template specializations and pretty > printers. > > If we're still producing the typedef-style DWARF for these alias template > specializations - perhaps lldb could not cache pretty printers for typedefs? > (I guess the pretty printers shouldn't be typedef-specific, right, since > typedefs are transparent anyway - but I guess maybe pretty printers can be > typedef-specific because typedefs can be intended to communicate what kind of > a thing is and possibly how to render it?) - it'll cache teh pretty printer > for the underlying type anyway, yeah? > lldb has always allowed you to match formatters to typedef's, regardless of whether something past that typedef in the chain has it's own formatter. That way, for instance, if you have some constraint you intend for the values of the typedef, you can alert yourself (e.g. color the summary red) when the values don't follow those constraints. And when you do that you shouldn't have to worry about formatters lower down in the typedef chain. OTOH, if you have a variable whose immediate type is a typedef that doesn't itself have a formatter match, but that typedef has a type lower in the typedef chain that DOES have a formatter, we will use that formatter for the typedef. Again, if this typedef is telling the author about some intent for that set of instances of the type, we shouldn't make using typedef's that way annoying by forcing people to recreate the useful formatter every time they introduce such a typedef. To be clear, neither of these design decisions is causing any problem here. The problem comes in here because we try to speed up the type recognizer matching by caching hits we found by inserting the matched type name to the found formatter in our "exact name" lookup table. In this case, we can save ourselves from having to reconstruct this typedef chain every time we do the match on the original typedef in the future by caching the "original typedef"->"formatter from lower in the typedef chain" as an exact match. Normally, that's a fine thing to do, but in this case, we saw a typedef named "std::remove_cv_t<value_type>" that was a typedef for `std::string`. So we registered std::string as the formatter for the name "std::remove_cv_t<value_type>". Then the next time we saw something named this way, we found it in our cache and tried to use the `std::string` formatter. That failed because this time round <value_type> is in fact an "int"... Prior to this, these templated types wouldn't have had this generic looking name but would have had the resolved type in the name, which wouldn't have been ambiguous. The narrowest solution is that when you go to cache a type name -> formatter pair, you should first check whether the type name is generic. If it is, then you can't guarantee it will resolve to the same base type in the future, so you should not cache it. IIUC, Michael started down this path but found there wasn't a way to tell straightforwardly whether a type was generic. Since this is just an optimization, we should first prove to ourselves that failing to put one of these type names in the exact matches really makes enough difference to bother with a complex solution. If the gains are some but not huge, some boneheaded solution like never caching anything where the from type has a '<' and a '>' is probably sufficient. Hope that helps... Jim > — > Reply to this email directly, view it on GitHub > <https://github.com/llvm/llvm-project/pull/110767#issuecomment-2389089898>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ADUPVW4EZX3ZDOJGESSRMVDZZQMVTAVCNFSM6AAAAABPGTLBXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBZGA4DSOBZHA>. > You are receiving this because your review was requested. > https://github.com/llvm/llvm-project/pull/110767 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
