| Summary: | [10][syntax highlighting] type 'var' colored as keyword if compliance < 10 | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Dani Megert <daniel_megert> |
| Component: | Core | Assignee: | Sarika Sinha <sarika.sinha> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | eric.milles, jarthana, manoj.palat, noopur_gupta |
| Version: | 4.8 | Flags: | manoj.palat:
review+
|
| Target Milestone: | 4.8 M7 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://git.eclipse.org/r/121467 https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=17f843244d722f7543dc33e0f4ea19424b12c6b0 |
||
| Whiteboard: | |||
| Bug Depends on: | 532313 | ||
| Bug Blocks: | |||
|
Description
Dani Megert
SimpleType.isVar() returns true for 'var' in a Java 9 project also. Manoj, is this expected?
Example code in a Java 9 project:
public static void main(String[] args) {
var v;
}
(In reply to Noopur Gupta from comment #1) > SimpleType.isVar() returns true for 'var' in a Java 9 project also. Manoj, > is this expected? I'd say "no". (In reply to Dani Megert from comment #2) > (In reply to Noopur Gupta from comment #1) > > SimpleType.isVar() returns true for 'var' in a Java 9 project also. Manoj, > > is this expected? > > I'd say "no". Moving to JDT Core. Please move back if the API behavior is as expected. Manoj, please look at this. thanks Sarika for agreeing to take a look - see 532535 for the api related changes. (In reply to Noopur Gupta from comment #1) > SimpleType.isVar() returns true for 'var' in a Java 9 project also. Manoj, > is this expected? > > Example code in a Java 9 project: > > public static void main(String[] args) { > var v; > } Looks like it is expected. As the isVar() is aware about the AST level only and does the check accordingly. Looked at varargs also, in the ast view it shows as true for the jre versions where varargs are not supported. Other findings during the analysis (Different problem) - 1. enum is not colored for 1.4 2. module, requires, exports in module-info.java in java 8 project is also colored (In reply to Sarika Sinha from comment #6) > (In reply to Noopur Gupta from comment #1) > > SimpleType.isVar() returns true for 'var' in a Java 9 project also. Manoj, > > is this expected? No, this is wrong. When JDT UI creates or gets an AST from JDT Core there's always an ICompilationUnit or ITypeRoot known. Hence JDT Core can get the project and can get the source level and hence can return the correct and expected value for isVar(). New Gerrit change created: https://git.eclipse.org/r/121467 (In reply to Eclipse Genie from comment #8) > New Gerrit change created: https://git.eclipse.org/r/121467 AST creation uses just the ast level and we don't want to overload AST. But ast scanner has source and compliance level which can be updated and used for these validation. @Sarika: if (this.ast.apiLevel >= AST.JLS10_INTERNAL && Long.compare(this.ast.scanner.complianceLevel, 10) >= 0) {
- in SimpleName.clone() - Is this (second condition) check redundant? do we have a testcase to prove otherwise?
(In reply to Manoj Palat from comment #10) > @Sarika: if (this.ast.apiLevel >= AST.JLS10_INTERNAL && > Long.compare(this.ast.scanner.complianceLevel, 10) >= 0) { > > - in SimpleName.clone() - Is this (second condition) check redundant? do we > have a testcase to prove otherwise? Yes, @Manoj! Clone can be created with a different target ast level, so the check will help. When the new AST level is 10 or more but compliance level is less than 10 this condition will be false and thus it will not do a setVar. Gerrit change https://git.eclipse.org/r/121467 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=17f843244d722f7543dc33e0f4ea19424b12c6b0 (In reply to Eclipse Genie from comment #12) > Gerrit change https://git.eclipse.org/r/121467 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=17f843244d722f7543dc33e0f4ea19424b12c6b0 @Sarika: Thanks for pitching in and putting the fix. I believe we are done here. Please resolve for M7 if you are not planning to add any more tests/code. Verified for 4.8 M7 with build I20180508-2000 |