[PATCH] D54547: PTH-- Remove feature entirely-
voskresensky.vladimir added a comment. In https://reviews.llvm.org/D54547#1301359, @erichkeane wrote: > > I thought clang-d service is using it to speed up indexing. > > Presumably, I could also just make PTH use another bit or two for the TokenID > and it would work fine. However, when I mentioned this on IRC the general > response was that it is a 'failed experiment'. In your use case, I wonder > why you couldn't just use PCH and get even further performance improvements? To be fair, I don't remember exactly. :-) I remember we shared the same PTH for all C and C++ files and built some preprocessor-based features for incomplete code written in editor based on that. Hmm... One more thing I had to fix was: lex in mode where we emit all preprocessor tokens there as well (like "#define MACRO A" => #, define, MACRO, A) PHT was also used for rebuilding PCH, when something is changed. Because often single changed file can completely invalidate PCH, while PTH just contain pp-lexed tokens which doesn't carry semantic. So, PTHManager could skip providing tokens for changed file, but keep proved them for all other files. https://reviews.llvm.org/D54547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D54547: PTH-- Remove feature entirely-
voskresensky.vladimir added a comment. I have some experience with PTH implementation, because had to fix it for Java-port of Clang (https://github.com/java-port/clank). It was sometime ago, but making it completely workable was not hard. As I remember the key fix was just to have PTH be EMITTED using raw-Lex mode (where real keyword-IDs are not used, so all Token Kinds nicely fit 8-bits). It worked, because on token automatically became keyword by PTHLexer::Lex: ... // Change the kind of this identifier to the appropriate token kind, e.g. // turning "for" into a keyword. Tok.setKind(II->getTokenID()); ... We used PTH, because multiple translation units are parsed in the context of single run. In this case preprocessing phase was be upto 10x faster when take token stream was deserialized from PTH (i.e. for all system headers lexed once). Also it was also helpful, because we were able to parse from concurrent thread using the same shared immutable PTH. I thought clang-d service is using it to speed up indexing. https://reviews.llvm.org/D54547 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D34766: fix NSAPI constants to reflect the current state of NSStringMethodKind/NSDictionaryMethodKind enums
voskresensky.vladimir added a comment. In https://reviews.llvm.org/D34766#795087, @arphaman wrote: > LGTM, Thanks! Do you have commit access? No. Could you commit, please. Thanks! https://reviews.llvm.org/D34766 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D34263: [preprocessor] When preprocessor option 'SingleFileParseMode' is enabled, parse all directive blocks if the condition uses undefined macros
voskresensky.vladimir added a comment. > Here's an example to clarify the difference: Thanks for the example. You are right, I missed this difference in patch. https://reviews.llvm.org/D34263 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D34263: [preprocessor] When preprocessor option 'SingleFileParseMode' is enabled, parse all directive blocks if the condition uses undefined macros
voskresensky.vladimir added a comment. In https://reviews.llvm.org/D34263#782391, @akyrtzi wrote: > Hey Vladimir, what you are proposing is orthogonal to this patch. You are > proposing for "the client to provide the value for an undefined identifier", > and the patch is about the client not knowing what the value should be so it > fallbacks to parsing all tokens to get the max amount of info. Note that both > of the techniques can be combined well, if the client provides the value, the > preprocessor will take it into account, otherwise if it is stays unresolved > it will fallback to lexing all tokens. > But what you are proposing is not a replacement for what the patch is doing. I'm not sure :-) What I find problematic in this patch is PPOpts->SingleFileParseMode checks. Let's suppose we implement what I mentioned above => how is it going to co-exist nicely? I think code will be less understandable with both: check of flag and call to PPCallbacks. What I propose is to move the logic from the PPOpts single flag into PPCallbacks. And from check of flag to query of PPCallbacks. Of course when you create PPCallbacks you can consult global SingleFileParseMode to create default implementation to answer "any symbol is defined", so you get your use-case easily handled, but it also gives others more flexibility. Thanks, Vladimir. https://reviews.llvm.org/D34263 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D34263: [preprocessor] When preprocessor option 'SingleFileParseMode' is enabled, parse all directive blocks if the condition uses undefined macros
voskresensky.vladimir added a comment. Hello Argyrios, This is a good addition to simplify reuse of preprocessor in IDEs. Thanks for doing this. From our experience of integrating clang PP into NetBeans, the following change gives more flexibility: - introduce method in PPCallbacks and consult it what is the preferred value for undefined symbol It will be similar to approach used for unresolved includes and FileNotFound method. It also gives dynamic behavior for clients: client might still prefer to keep skipping some blocks like unix, mac, win, solaris, LP64, cplusplus, ... Thanks, Vladimir. https://reviews.llvm.org/D34263 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
