Community
Participate
Working Groups
Created attachment 167645 [details] Annotated call stack CDT HEAD: The infinite loop is due to 'a' and 'p' variables in TemplateArgumentDeduction.fromType method wrapping null type: p CPPQualifierType (id=9805) isConst true isVolatile false type null a CPPQualifierType (id=9806) isConst true isVolatile false type null SemanticUtil.getNestedType returns an unchanged argument in such cases. I've attached a call stack annotated with values of local variables. Will try to reproduce the problem on a small example, but it may not be easy.
Created attachment 167668 [details] workaround The attached patch should work around the issue. However, I think this is not a complete fix. Type containers pointing to null-types cause all sorts of problems. I think we should introduce a special problem-type to be used instead of null-types. That's probably something we should do in the next release. It'd be interesting to understand why the qualified types point to null (could be an unresolved typedef or some type we fail to store in the index).
(In reply to comment #1) I completely agree that null types are evil and should be replaced by ProblemType. I'm not sure if it's the only source of CPPQualifierType wrapping null type, but one such source is marshaling/unmarshaling of a CPPQualifierType wrapping a type for which fLinkage.addTypeBinding((IBinding) type) inside TypeMarshallBuffer.marshalType(IType type) return null. This seems to happen always for ProblemBinding's and quite often for CPPTemplateTypeParameter's.
(In reply to comment #1) > The attached patch should work around the issue. It does indeed.
(In reply to comment #2) > (In reply to comment #1) > I completely agree that null types are evil and should be replaced by > ProblemType. I have created bug 312423 for that. > > I'm not sure if it's the only source of CPPQualifierType wrapping null type, > but one such source is marshaling/unmarshaling of a CPPQualifierType wrapping a > type for which fLinkage.addTypeBinding((IBinding) type) inside > TypeMarshallBuffer.marshalType(IType type) return null. This seems to happen > always for ProblemBinding's and quite often for CPPTemplateTypeParameter's. I am not aware of problems with adding template type parameters to the index. If possible, please provide an example. We must make sure that these parameters can properly be represented in the index. (In reply to comment #3) > (In reply to comment #1) > > The attached patch should work around the issue. > It does indeed. Let's apply the patch as a fix for 7.0 and deal with the larger issue via bug 312423. If you agree, please go ahead and commit the workaround.
Markus' workaround submitted.
