Bug 86611 - [1.4] 1.5 power double causes compiler internal failure
Summary: [1.4] 1.5 power double causes compiler internal failure
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 M6   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-25 07:00 EST by Philipe Mulet CLA
Modified: 2005-03-31 09:35 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Philipe Mulet CLA 2005-02-25 07:00:52 EST 
Build 3.1M5

When attempting to compile the following in 1.4 mode:

public class X {
	double foo() {
		return 0X.P-10;
	}
}

An exception occurs in compiler:

----------
1. ERROR in X.java
 (at line 0)
	public class X {
	^
Internal compiler error
java.lang.ArrayIndexOutOfBoundsException: 2
	at
org.eclipse.jdt.internal.compiler.ast.IntLiteral.computeConstant(IntLiteral.java:63)
	at org.eclipse.jdt.internal.compiler.ast.Literal.resolveType(Literal.java:48)
	at
org.eclipse.jdt.internal.compiler.ast.IntLiteral.resolveType(IntLiteral.java:126)
	at
org.eclipse.jdt.internal.compiler.ast.FieldReference.resolveType(FieldReference.java:518)
	at
org.eclipse.jdt.internal.compiler.ast.BinaryExpression.resolveType(BinaryExpression.java:1670)
	at
org.eclipse.jdt.internal.compiler.ast.ReturnStatement.resolve(ReturnStatement.java:195)
	at
org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:411)
	at
org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:167)
	at
org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:389)
	at
org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1046)
	at
org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1095)
	at
org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:283)
	at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:510)
	at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:335)
	at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:2378)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1106)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1003)
	at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:995)
	at Compile.main(Compile.java:19)
Comment 1 Philipe Mulet CLA 2005-02-25 07:17:08 EST 
Scanner should have rejected this invalid hex.
Added ScannerTest#test026.
Scanner#scanNumber(...) {
...
} else if (getNextChar('.')) {
  if (this.sourceLevel < ClassFileConstants.JDK1_5) {
+   if (end == start) {
+     throw new InvalidInputException(INVALID_HEXA);
+   }
    this.currentPosition = end;
    return TokenNameIntegerLiteral;
  }

}
Comment 2 Philipe Mulet CLA 2005-02-25 07:17:25 EST 
Fixed, also upgraded PublicScanner.

Olivier - pls double check
Comment 3 David Audel CLA 2005-03-31 09:35:37 EST 
Verified in I20050330-0500