[cdt-dev] Re: RecursionResolvingBinding

["Sergey Prigogin" <eclipse.sprigogin@xxxxxxxxx>]

I've tried to run AutomatedIntegrationSuite with CPPASTName.fAllowRecursionBindings = false. Results were better than I expected, but 6 tests failed due to RecursionResolvingBinding:

AST2Tests.testRedefinePtrdiff_Bug230895
AST2CPPTests.testPMKoenig_2
AST2CPPTests.testBug100403
AST2CPPTests.testBug174791
AST2CPPTests.testQualifiedMemberDeclaration_Bug222026
AST2TemplateTests.testBug238180_ArrayOutOfBounds

Some of these failures may be legitimate, but they deserve a closer look.

-sergey

On Mon, May 26, 2008 at 6:42 AM, Schorn, Markus <Markus.Schorn@xxxxxxxxxxxxx> wrote:

Creating the RecursionResolvingBinding object is a mechanism to work
around recursions, it should not happen.

The special case you are reporting is a consequence of attempting a name
resolution in response to calling IASTName.isReference(). It's done
because of 7.1.5.3.3 in the C++-spec.

I can see two ways to fix that:
(a) In CPPASTElaboratedTypeSpecifier.getRoleForName(): treat the
elaborated type
   specifiers in the simple form '<class-key> <identifier>' as
declaration.

or

(b) In CPPSemantics.resolveAmbiguities(): don't call name.isReference()
for the name
   in an elaborated type specifier in the simple form '<class-key>
<identifier>'.

Markus.


________________________________

       From: Sergey Prigogin [mailto:eclipse.sprigogin@xxxxxxxxx]
       Sent: Sunday, May 25, 2008 6:45 AM
       To: Schorn, Markus
       Cc: CDT General developers list.
       Subject: RecursionResolvingBinding

       I've noticed that RecursionResolvingBinding gets created large
number of times during indexing. Here is a code fragment extracted from
stdio.h that triggers one of the cases:

         typedef struct _IO_FILE FILE;

         struct _IO_FILE {
           struct _IO_FILE *_chain;
         };

         int fclose(FILE *__stream);

       Here's the stack with recursion:
       Thread [Worker-1] (Suspended (breakpoint at line 48 in
CPPASTName$RecursionResolvingBinding))
           CPPASTName$RecursionResolvingBinding.<init>(IASTName) line:
48
           CPPASTName.resolveBinding() line: 74
           CPPASTElaboratedTypeSpecifier.getRoleForName(IASTName) line:
95
           CPPASTName.isReference() line: 235
           CPPSemantics.resolveAmbiguities(LookupData, IASTName) line:
1653
           CPPSemantics.resolveAmbiguities(IASTName, Object[]) line:
1530
           CPPNamespaceScope(CPPScope).getBindingInAST(IASTName,
boolean) line: 212
           CPPNamespaceScope(CPPScope).getBinding(IASTName, boolean,
IIndexFileSet) line: 136
           CPPSemantics.lookup(LookupData, Object) line: 679
           CPPSemantics.resolveBinding(IASTName) line: 172
           CPPVisitor.createBinding(ICPPASTElaboratedTypeSpecifier)
line: 343
           CPPVisitor.createBinding(IASTName) line: 237
           CPPASTName.resolveBinding() line: 77
           CPPASTElaboratedTypeSpecifier.getRoleForName(IASTName) line:
95
           CPPASTName.isReference() line: 235
           CPPSemantics.resolveAmbiguities(LookupData, IASTName) line:
1653
           CPPSemantics.resolveAmbiguities(IASTName, Object[]) line:
1530
           CPPNamespaceScope(CPPScope).getBindingInAST(IASTName,
boolean) line: 212
           CPPNamespaceScope(CPPScope).getBinding(IASTName, boolean,
IIndexFileSet) line: 136
           CPPSemantics.lookup(LookupData, Object) line: 679
           CPPSemantics.resolveBinding(IASTName) line: 172
           CPPVisitor.createBinding(ICPPASTElaboratedTypeSpecifier)
line: 343
           CPPVisitor.createBinding(IASTName) line: 237
           CPPASTName.resolveBinding() line: 77
           CPPASTElaboratedTypeSpecifier.getRoleForName(IASTName) line:
95
           CPPASTName.isReference() line: 235
           CPPSemantics.resolveAmbiguities(LookupData, IASTName) line:
1653
           CPPSemantics.resolveAmbiguities(IASTName, Object[]) line:
1530
           CPPNamespaceScope(CPPScope).getBindingInAST(IASTName,
boolean) line: 212
           CPPNamespaceScope(CPPScope).getBinding(IASTName, boolean,
IIndexFileSet) line: 136
           CPPSemantics.lookup(LookupData, Object) line: 679
           CPPSemantics.resolveBinding(IASTName) line: 172
           CPPVisitor.createBinding(ICPPASTElaboratedTypeSpecifier)
line: 343
           CPPVisitor.createBinding(IASTName) line: 237
           CPPASTName.resolveBinding() line: 77
           CPPASTElaboratedTypeSpecifier.getRoleForName(IASTName) line:
95
           CPPASTName.isReference() line: 235
           CPPSemantics.resolveAmbiguities(LookupData, IASTName) line:
1653
           CPPSemantics.resolveAmbiguities(IASTName, Object[]) line:
1530
           CPPNamespaceScope(CPPScope).getBindingInAST(IASTName,
boolean) line: 212
           CPPNamespaceScope(CPPScope).getBinding(IASTName, boolean,
IIndexFileSet) line: 136
           CPPSemantics.lookup(LookupData, Object) line: 679
           CPPSemantics.resolveBinding(IASTName) line: 172
           CPPVisitor.createBinding(ICPPASTElaboratedTypeSpecifier)
line: 343
           CPPVisitor.createBinding(IASTName) line: 237
           CPPASTName.resolveBinding() line: 77
           CPPASTElaboratedTypeSpecifier.getRoleForName(IASTName) line:
95
           CPPASTName.isReference() line: 235
           CPPSemantics.resolveAmbiguities(LookupData, IASTName) line:
1653
           CPPSemantics.resolveAmbiguities(IASTName, Object[]) line:
1530
           CPPNamespaceScope(CPPScope).getBindingInAST(IASTName,
boolean) line: 212
           CPPNamespaceScope(CPPScope).getBinding(IASTName, boolean,
IIndexFileSet) line: 136
           CPPSemantics.lookup(LookupData, Object) line: 679
           CPPSemantics.resolveBinding(IASTName) line: 172
           CPPVisitor.createBinding(ICPPASTElaboratedTypeSpecifier)
line: 343
           CPPVisitor.createBinding(IASTName) line: 237
           CPPASTName.resolveBinding() line: 77

PDOMFastIndexerTask(PDOMWriter).resolveNames(Map<IIndexFileLocation,Symb
ols>, IIndexFileLocation[], ArrayList<IStatus>, IProgressMonitor) line:
236

PDOMFastIndexerTask(PDOMWriter).addSymbols(IASTTranslationUnit,
IIndexFileLocation[], IWritableIndex, int, boolean, int,
ITodoTaskUpdater, IProgressMonitor) line: 150
           PDOMFastIndexerTask(AbstractIndexerTask).writeToIndex(int,
IASTTranslationUnit, int, IProgressMonitor) line: 634
           PDOMFastIndexerTask(AbstractIndexerTask).parseFile(Object,
int, IIndexFileLocation, IScannerInfo, IProgressMonitor) line: 599
           PDOMFastIndexerTask(AbstractIndexerTask).parseLinkage(int,
Map<Integer,List<Object>>, IProgressMonitor) line: 485

PDOMFastIndexerTask(AbstractIndexerTask).runTask(IProgressMonitor) line:
235
           PDOMFastIndexerTask(PDOMIndexerTask).run(IProgressMonitor)
line: 109
           PDOMIndexerJob.run(IProgressMonitor) line: 94
           Worker.run() line: 55

       The name being resolved is _IO_FILE inside the typedef.

       It's interesting that the resulting AST doesn't contain any
problem bindings. Still, creation of an intermediate
RecursionResolvingBinding doesn't look right. I suspect that 5 recursive
calls leading to creation of a RecursionResolvingBinding cause
significant overhead and should better be avoided. It looks like on real
code base some RecursionResolvingBindings do remain in AST and become
user-visible problems, but I'm not sure if they have similar causes or
not.

       I tried to reproduce creation of RecursionResolvingBinding in a
test, but surprisingly the same code inside a test doesn't trigger a
RecursionResolvingBinding.

       Please let me know if routine creation of
RecursionResolvingBinding is expected or not.

       -sergey