[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdt-dev] RE: RecursionResolvingBinding
|
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