[PATCH] D137020: [clang][AST] Handle variable declaration with unknown typedef in C
Dilshod Urazov via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Nov 7 03:34:27 PST 2022
urazoff added inline comments.
================
Comment at: clang/lib/Parse/ParseDecl.cpp:5392-5394
+ case tok::amp:
+ case tok::ampamp:
+ return getLangOpts().CPlusPlus;
----------------
aaron.ballman wrote:
> Looking for `*`, `&`, and `&&` will help catch some cases... but it's not really going to help for situations like `unknown const *` or other qualifiers...
Actually, this `Parser::isDeclarationSpecifier` is never called in case of C++. So I am not sure if we need to cover C++ specific constructs or not. But `unknown const *` is a good catch, I missed it for some reason. I will update the patch soon.
================
Comment at: clang/lib/Parse/ParseDecl.cpp:5425
+ // node in AST for such cases which is good for AST readers.
+ if (IsUnknownTypedefName() && !getLangOpts().ObjC)
+ return true;
----------------
aaron.ballman wrote:
> Why is ObjC exempted from this?
>
> I need to think about this a whole lot more. On the one hand, I like the changes happening in the test cases; those look like good changes to me. But on the other hand, this function is called in a fair number of places to make parsing decisions and I'm not convinced that speculative answers are the best way to go from this interface. I need to see if I can find any situations where this is called and we'd get worse parsing behavior (or incorrect parsing behavior!).
There is weird behavior in case of ObjC range-based for loop. For example, in `for (NSString* key in xyz)` token for `in` keyword is of type `Identifier` by the call of `Parser::isDeclarationSpecifier`. So I decided to exempt it in first version and discuss it in review.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D137020/new/
https://reviews.llvm.org/D137020
More information about the cfe-commits
mailing list