use of org.eclipse.jdt.internal.compiler.lookup.TypeVariableBinding in project lombok by rzwitserloot.
the class PatchDelegate method checkConflictOfTypeVarNames.
public static void checkConflictOfTypeVarNames(BindingTuple binding, EclipseNode typeNode) throws CantMakeDelegates {
TypeVariableBinding[] typeVars = binding.parameterized.typeVariables();
if (typeVars == null || typeVars.length == 0)
return;
Set<String> usedInOurType = new HashSet<String>();
EclipseNode enclosingType = typeNode;
while (enclosingType != null) {
if (enclosingType.getKind() == Kind.TYPE) {
TypeParameter[] typeParameters = ((TypeDeclaration) enclosingType.get()).typeParameters;
if (typeParameters != null) {
for (TypeParameter param : typeParameters) {
if (param.name != null)
usedInOurType.add(new String(param.name));
}
}
}
enclosingType = enclosingType.up();
}
Set<String> usedInMethodSig = new HashSet<String>();
for (TypeVariableBinding var : typeVars) {
char[] sourceName = var.sourceName();
if (sourceName != null)
usedInMethodSig.add(new String(sourceName));
}
usedInMethodSig.retainAll(usedInOurType);
if (usedInMethodSig.isEmpty())
return;
// We might be delegating a List<T>, and we are making method <T> toArray(). A conflict is possible.
// But only if the toArray method also uses type vars from its class, otherwise we're only shadowing,
// which is okay as we'll add a @SuppressWarnings.
TypeVarFinder finder = new TypeVarFinder();
finder.visitRaw(binding.base);
Set<String> names = new HashSet<String>(finder.getTypeVariables());
names.removeAll(usedInMethodSig);
if (!names.isEmpty()) {
// We have a confirmed conflict. We could dig deeper as this may still be a false alarm, but its already an exceedingly rare case.
CantMakeDelegates cmd = new CantMakeDelegates();
cmd.conflicted = usedInMethodSig;
throw cmd;
}
}
Aggregations