fogsong233 wrote: @vgvassilev After carefully tracing the invocation path of `isCXXDeclarationStatement`, I have reached a few conclusions.
I believe `isCXXSimpleDeclaration` is actually sufficient as it already covers full function signature detection. Any future enhancements regarding function signature detection should likely be implemented within `isCXXSimpleDeclaration`. The reason for the error is that, within the stack frame mentioned earlier, the parser performs an immediate lookup while parsing the return type at the beginning of the function declaration. Sema then discovers that this type is private and issues an error. I also discovered that this error is entirely dependent on the parsing logic within `isCXXSimpleDeclaration`. This explains why my previous attempt to suppress access checks was problematic: it caused valid access checks to be suppressed even for non-member functions using private types, which is incorrect behavior. Under normal circumstances, `ParseDeclarationOrFunctionDefinition` (the standard, non-incremental Clang path) performs these checks correctly. I suspect the issue is that the parsing in `isCXXSimpleDeclaration` is not strictly tentative. Specifically, `TryAnnotateTypeOrScopeTokenAfterScopeSpec` modifies the token stream (annotating tokens) after the type lookup, which seemingly causes ParseDeclarationOrFunctionDefinition to rely on these pre-annotated tokens rather than performing a fresh lookup. My current strategy is to continue using `isCXXSimpleDeclaration` but to fully revert the token state after the check. If the construct is identified as a function definition, we can then let it fall through to `ParseDeclarationOrFunctionDefinition`. This ensures the execution logic remains entirely consistent with standard Clang. If it is not a definition, we proceed to `ParseTopLevelStmtDecl()`. I would modify `ParseTopLevelStmtDecl()` to adapt to the parsing flow now that it can no longer rely on the side effects (token annotations) previously produced by `isCXXSimpleDeclaration`. What do you think about this approach? https://github.com/llvm/llvm-project/pull/178842 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
