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.



cfe-commits mailing list

Reply via email to