Community
Participate
Working Groups
Even though this problem report is marked as being by recommenders.types, i believe this to be a JDT problem. Please reassign if this is wrong. Should there be a check whether the supplied index is out of bounds, or should the calling code never have been able to supply such an index? I notice there are quite a few checks to see that the error is not null or empty, but none on the length. The following incident was reported via the automated error reporting: code: 1 plugin: org.eclipse.recommenders.types.rcp_2.2.0.v20150609-1848 message: HIDDEN fingerprint: 5ad6153a exception class: java.lang.ArrayIndexOutOfBoundsException exception message: HIDDEN number of children: 0 java.lang.ArrayIndexOutOfBoundsException: HIDDEN at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.substitute(ParameterizedTypeBinding.java:1217) at org.eclipse.jdt.internal.compiler.lookup.Scope$Substitutor.substitute(Scope.java:487) at org.eclipse.jdt.internal.compiler.lookup.Scope$Substitutor.substitute(Scope.java:624) at org.eclipse.jdt.internal.compiler.lookup.Scope$Substitutor.substitute(Scope.java:505) at org.eclipse.jdt.internal.compiler.lookup.Scope.substitute(Scope.java:432) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.superclass(ParameterizedTypeBinding.java:1239) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superclass(BinaryTypeBinding.java:1784) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:611) at org.eclipse.jdt.internal.core.hierarchy.HierarchyBuilder.buildSupertypes(HierarchyBuilder.java:116) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:136) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:301) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1268) at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:90) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:729) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:789) at org.eclipse.jdt.internal.core.BinaryType.newSupertypeHierarchy(BinaryType.java:826) at org.eclipse.jdt.internal.core.BinaryType.newSupertypeHierarchy(BinaryType.java:778) at org.eclipse.recommenders.internal.types.rcp.ProjectTypesIndex.indexType(ProjectTypesIndex.java:422) at org.eclipse.recommenders.internal.types.rcp.ProjectTypesIndex.rebuild(ProjectTypesIndex.java:364) at org.eclipse.recommenders.internal.types.rcp.ProjectTypesIndex$2.run(ProjectTypesIndex.java:332) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) General Information: reported-by: anonymous-id: 4a9999e5-48fd-408d-90ed-32b70e0a1d66 eclipse-build-id: 4.5.0.I20150603-2000 eclipse-product: org.eclipse.epp.package.jee.product operating system: MacOSX 10.10.4 (x86_64) - cocoa jre-version: 1.8.0_45-b14 The following plug-ins were present on the execution stack (*): 1. org.eclipse.core.jobs_3.7.0.v20150330-2103 2. org.eclipse.jdt_3.11.0.v20150603-2000 3. org.eclipse.jdt.core_3.11.0.v20150602-1242 4. org.eclipse.recommenders.types.rcp_2.2.0.v20150609-1848 Please note that: * Messages, stacktraces, and nested status objects may be shortened. * Bug fields like status, resolution, and whiteboard are sent back to reporters. * The list of present bundles and their respective versions was calculated by package naming heuristics. This may or may not reflect reality. Other Resources: * Report: https://dev.eclipse.org/recommenders/committers/confess/#/problems/55bb85dee4b0853a544d552a * Manual: https://dev.eclipse.org/recommenders/community/confess/#/guide Thank you for your assistance. Your friendly error-reports-inbox. This bug was created on behalf of johannes.dorn@codetrails.com.
(In reply to EPP Error Reports from comment #0) > Should there be a check whether the supplied index is out of bounds, or > should the calling code never have been able to supply such an index? I > notice there are quite a few checks to see that the error is not null or > empty, but none on the length. We have "excuses" for null type arguments (raw type) and empty (diamond), but I see no excuse why the number of typeVariables and type arguments could legally differ (see that "originalVariable.rank" is in the valid range for "typeVariables").
It is a valid and useful assumption to expect equal lengths between formals (typeVariables) and actuals (arguments). This assumption is used in several locations in PTB. See also that callers of ProblemReporter.incorrectArityForParameterizedType() do not assign a resolvedType, i.e., a type binding resulting from that situation should never be found in the AST. I'm not in favour of blurring this design by range checks for which we have no explanation. If the error is reproducible, it would be great to debug it, to find out, why lengths differ. Without a reproducing example there's nothing we can/should do, IMHO.
Verified for Eclipse Neon 4.6 M1 Build id: I20150803-2000
