Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 348526 - [1.7] In 1.5 mode compiler stops reporting errors once it encounters a binary literal or a literal with underscore
Summary: [1.7] In 1.5 mode compiler stops reporting errors once it encounters a binary...
Status: VERIFIED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.7   Edit
Hardware: All All
: P3 minor (vote)
Target Milestone: 3.7.1   Edit
Assignee: Ayushman Jain CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-07 05:39 EDT by Deepak Azad CLA
Modified: 2011-08-05 02:54 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Deepak Azad CLA 2011-06-07 05:39:34 EDT
Try the following snippet in 1.5 mode. The compiler stops reporting errors in a method once it encounters a binary literal or a literal with underscore.
------------------------------------------------------------------
package org.eclipse;

class Literals1 {
	public static void main(String[] args) {
		int binaryLiteral = 0b1100;
		
		no error
		no error 
		
		int underscoreInNumericLiteral = 0xCAFE_BABE;

	}
	
	void foo() {
		error
		error
	}
}
-------------------------------------------------------------------
Comment 1 Ayushman Jain CLA 2011-06-07 05:54:24 EDT
This is the usual behaviour for scanner errors such as invalid string, invalid hex, invalid float, etc. An invalid token in the scanner does not match any parser rule, and so we just bail out.

See also
class Literals1 {
    public static void main(String[] args) {
        String str = "abc
        no error
        no error 
    }

    void foo() {
        error
        error
    }
}
Comment 2 Curtis Windatt CLA 2011-07-19 14:17:48 EDT
This can be confusing if you have multiple literals with issues.  If you have the following fields :

int x5 = 0_x55;  
int x6 = 0_x56;

You only get an error on the first entry.  This makes the user wonder why their second value is allowed.  It would be better if the compiler could continue and report all the errors.
Comment 3 Ayushman Jain CLA 2011-07-20 00:50:17 EDT
(In reply to comment #2)
> This can be confusing if you have multiple literals with issues.  If you have
> the following fields :
> 
> int x5 = 0_x55;  
> int x6 = 0_x56;
> 
> You only get an error on the first entry.  This makes the user wonder why their
> second value is allowed.  It would be better if the compiler could continue and
> report all the errors.

The problem is in correctly parsing the first erreneous statement itself. Since the parser will not be able to reduce to some valid rule on encountering that, if we let it continue to parse, we cannot say what kind of errors the parser will report for the subsequent statements as well. SO, one might end up with seeing two different errors for the above two assignments. Its safer to make the parser stop when the scanner doesn't contain meaningful tokens anymore.

Also, note that similar errors are reported only once anyway. i.e. suppose you do not declare a variable and use it in 3 places, we will just report it once. This is the usual norm so as to avoid pollution with too many error markers.