Timm =?utf-8?q?Bäder?= <tbae...@redhat.com>, Timm =?utf-8?q?Bäder?= <tbae...@redhat.com>, Timm =?utf-8?q?Bäder?= <tbae...@redhat.com>, Timm =?utf-8?q?Bäder?= <tbae...@redhat.com> Message-ID: In-Reply-To: <llvm/llvm-project/pull/66514/cl...@github.com>
tbaederr wrote: > > One of the remaining tests fails because `PP->getIdentifierInfo()` ends up > > doing external lookup via `ASTReader`, which ends up emitting a diagnostic > > itself. Not sure what to do about that atm. > > Can we just detect the reentrancy into the highlighting code and skip > computing the highlight information entirely in that case, or is the problem > more insidious than that? (Is the fact that diagnostic emission triggers lazy > identifier deserialization itself a problem?) The problem only happens if the deserialization causes emission of another diagnostic. We're already emitting a diagnostic (that's why we're highlighting the code), so that doesn't work. One solution that seems to work is to just return an empty vector if `PP->getIdentifierTable().getExternalIdentifierLookup()` returns non-`nullptr`. That fixes the test case and my local highlighting still works. I'm just not sure if a) that disables highlighting for all PCH cases and if that's something people do a lot and b) if there might be other cases where identifier lookup might cause emission of a diagnostic. https://github.com/llvm/llvm-project/pull/66514 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
